octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Status of ode solvers in core


From: c.
Subject: Status of ode solvers in core
Date: Mon, 24 Oct 2016 15:46:06 +0200

Rik,

Below are the remaining "FIXME" in scripts/ode and the open bugs 
about ode solvers in the tracker. 

The FIXME's seem to be all requests for clarification and the open
bugs are mostly about thinks that are been worked on but should
be probably fixed in the default branch.

So I would say this is a good time to move development on the default
branch and release 4.2, what do you think? 

c.

----------- FIXME comments in scripts/ode ------------------------

* ./ode23.m:215:  ## FIXME: How is this comment supposed to end?

213:  if (havemasshandle)   # Handle only the dynamic mass matrix,
214:    if (! strcmp (odeopts.MStateDependence, "none"))
215:      ## FIXME: How is this comment supposed to end?
216:      ## constant mass matrices have already

  that sounds incomplete in English but literally translating back to italian
  it can be interpreted as "constant mass matrices have already been handled"

  @Roberto that comment should be yours, can you confirm?


* ./odeset.m:152: ## FIXME: Add an inexact match option once it is available in 
inputParser.
  ./odeset.m:279: ## FIXME: Add an inexact match option once it is available in 
inputParser.

  This is the issue being discussed in bug #49364 I am working on a patch for 
inputParser
  to fix this but I think it should be handled in the default and not stable 
branch,
  as a temporary workaround you added a warning for unknown options 

* ./private/runge_kutta_45_dorpri.m:73:   ## FIXME: Which source is c_prime 
derived from?
 
73:  ## FIXME: Which source is c_prime derived from?
74:  ##        Can't the Shampine clause be deleted if it will never be used?
75:  ## According to Shampine 1986:
76:  ## persistent c_prime = [(1951/21600) 0 (22642/50085) (451/720), ...
77:  ##                       (-12231/42400) (649/6300) (1/60)];

  According to the docstring refers the source is this wikipedia page:
  https://en.wikipedia.org/wiki/Dormand%E2%80%93Prince_method

  The wikipedia page has the complete tableau that we are using and cites two
  sources:
  
  (Shampine 1986; Hairer, Nørsett & Wanner 2008, pp. 178–179).

  the second reference has the same tableau as we are using while the Shampine
  paper has a different definition of c_prime.

  I think the comment is meant to point out that the two references do not 
agree.
  My suggestion would be to get rid of the reference to wikipedia and only cite 
  Hairer, Nørsett & Wanner, then the comment can certainly go.
  

* ./private/runge_kutta_interpolate.m:38: ## FIXME: Do we need an algorithm for 
order = 4?

  An old version of ode45 was using the fehlberg method without local 
extrapolation 
  which is order 4, since that was removed I don't think we have any order 4 
method left.

----------- end FIXME comments in scripts/ode ------------------------


----------- open tickets for ode ------------------------

* odeset lacks 3 of 4 OutputFcns for Matlab Compatibility
  https://savannah.gnu.org/bugs/?func=detailitem&item_id=49362

This is actually a wish / missing feature

* odeset does not implement non-exact match to property name.
  https://savannah.gnu.org/bugs/?func=detailitem&item_id=49364

This is being worked on in the default branch

* ode{23,45} option "Refine" has no effect
  https://savannah.gnu.org/bugs/?func=detailitem&item_id=49408

This is partially fixed, a complete fix is probably dependent on
correctly solving bug #49427

* structure returned by ode solvers invoked with one output is incomplete
  https://savannah.gnu.org/bugs/?func=detailitem&item_id=49427

This one was just submitted I have a plan on how to implement it but
it is quite invasive so should be done on development branch

----------- end open tickets for ode ------------------------





reply via email to

[Prev in Thread] Current Thread [Next in Thread]