Re: ode csets

[c.]

On 19 Oct 2016, at 21:01, Rik <address@hidden> wrote:

> 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.

This is actually by design.

The previous version of odeset [1] would invoke 
ode_struct_value_check to check consistency of the values
assigned to options.

This behavour is not compatible as Matlab only checks validity
of option values when the solver is invoked, not when they are 
passed to odeset.

This also assumes that all possible option names are known, which
is not possible if we want advanced solvers to define their own set
of additional otpions.

So the idea is to 

 - assign the a value to all options that are required by a given solver before 
simulation starts
 - check consistency only for those options that make sense for a given solver 
and ignore others

'odemergeopts' deduces the set of options that make sense for the current 
solver from the fields
in the third input structure 'defaults' for those fields 'validateattributes' 
is invoked,
any other fields contained in the second input 'odeopts' are not considered 
meaningful and are discarded.

For example ode23 and ode45 cannot use options such as 'Jacobian' therefore 
this is silently accepted (like in Matlab)

[t, y] = ode45 (@(t, y) - y, [0 3], 1, odeset ('Jacobian', 's'));

while this is an error

[t, y] = ode45 (@(t, y) - y, [0 3], 1, odeset ('initialstep', 's'));
error: ode45: InitialStep must be of class:

  double single

but was of class char


c.



[1] 
http://hg.savannah.gnu.org/hgweb/octave/file/ee0df00e12d6/scripts/ode/odeset.m#l132