ode csets

[Rik]

10/19/16

Carlo,

I've checked in 4 changesets that improve things, although there are still
caveats.

First, I improved the performance of odeset by merging in extra fields only
when they exist.  And if they do exist, they are appended to the end of the
default options in sorted order.  I like this arrangement because it makes
it easy to distinguish the regular options from the new ones.  See
http://hg.savannah.gnu.org/hgweb/octave/rev/58c1c6aeb737.

One question is the sort order for default options.  Whenever a default
option is changed, it moves to the front of the list.  That is probably
something happening in inputParser, but I'm not sure I like it.  Does
anyone on the octave-maintainer's list have an opinion?  Example:

+verbatim+
odeset ("Vectorized", 1, "FooProp2", 2, "FooProp1", 1)
ans =

  scalar structure containing the fields:

    Vectorized =  1
    AbsTol = [](0x0)
    BDF = [](0x0)
    Events = [](0x0)
    InitialSlope = [](0x0)
    InitialStep = [](0x0)
    JConstant = [](0x0)
    JPattern = [](0x0)
    Jacobian = [](0x0)
    MStateDependence = [](0x0)
    Mass = [](0x0)
    MassSingular = [](0x0)
    MaxOrder = [](0x0)
    MaxStep = [](0x0)
    MvPattern = [](0x0)
    NonNegative = [](0x0)
    NormControl = [](0x0)
    OutputFcn = [](0x0)
    OutputSel = [](0x0)
    Refine = [](0x0)
    RelTol = [](0x0)
    Stats = [](0x0)
    FooProp1 =  1
    FooProp2 =  2
-verbatim-

The second cset (http://hg.savannah.gnu.org/hgweb/octave/rev/c28648e039da)
emits a warning from odeset when an unknown option is used.  It doesn't
stop processing by issuing an error, but the warning will help people
identify code that needs to be re-written.  Otherwise, Octave might
silently produce different answers than Matlab.

The third cset (http://hg.savannah.gnu.org/hgweb/octave/rev/18dd44e56815)
removes the property "MassConstant" for compatibility, and because we
didn't seem to use it either.

The fourth cset was just cleanup to remove useless persistent declarations
for variables which changed
(http://hg.savannah.gnu.org/hgweb/octave/rev/fb8b23754d76).

Outstanding issue #1: odedefaults calculates the value for InitialSlope and
OutputSel just once.

It seems that these two properties should vary with each call to an ode
solver, but because of the use of persistent variables in odedefaults they
do not.  Example code:

+verbatim+
run-octave -f --no-gui
addpath ("./scripts/ode/private")
def = odedefaults (5, 1, 2);
def.InitialSlope
ans =

   0
   0
   0
   0
   0

def = odedefaults (1, 1, 2);
def.InitialSlope
ans =

   0
   0
   0
   0
   0
-verbatim-

The issue is made worse by the fact that there are no BIST tests for
"InitialSlope", "MvPattern", and "MaxOrder" which might have caught this.

Outstanding issue #2: odemergeopts strips unknown options

I'm not sure this is a problem, as much as an observation.  I used the
following code.

+verbatim+
function ydot = fpol (t, y)  # The Van der Pol ODE
  ydot = [y(2); (1 - y(1)^2) * y(2) - y(1)];
endfunction

opt = odeset ("FooBar", 1, "Vectorized", true);
sol = ode23 (@fpol, [0 3], [2 0], opt);
-verbatim-

I also put a keyboard breakpoint before odemergeopts in ode23.m.

+verbatim+
  [defaults, classes, attributes] = odedefaults (numel (init),
                                                 trange(1), trange(end));

  defaults   = rmfield (defaults,   {"Jacobian", "JPattern", "Vectorized", ...
                                     "MvPattern", "MassSingular", ...
                                     "InitialSlope", "MaxOrder", "BDF"});
  classes    = rmfield (classes,    {"Jacobian", "JPattern", "Vectorized", ...
                                     "MvPattern", "MassSingular", ...
                                     "InitialSlope", "MaxOrder", "BDF"});
  attributes = rmfield (attributes, {"Jacobian", "JPattern", "Vectorized", ...
                                     "MvPattern", "MassSingular", ...
                                     "InitialSlope", "MaxOrder", "BDF"});

  keyboard;
  odeopts = odemergeopts ("ode23", odeopts, defaults, classes, attributes);
-verbatim-

Before the merge, odeopts contains property "FooBar".  After the merge, it
has been stripped.  If there are special Octave-only properties that need
to be passed to a solver then they need to be carried past odemergeopts in
some manner.  This isn't an issue for ode23.m and ode45.m which don't have
any.  But I think some solvers in odepkg do have special properties.

--Rik