Re: Updated odeset/odeget

[Jacopo Corno]

Il 16/10/2015 20:26, Rik ha scritto:

On 10/10/2015 09:11 AM, address@hidden wrote:

Subject:

Re: Updated odeset/odeget in core

From:

Sebastian Schöps <address@hidden>

Date:

10/09/2015 11:53 PM

To:

address@hidden

List-Post:

<mailto:address@hidden>

Content-Transfer-Encoding:

7bit

Precedence:

list

MIME-Version:

1.0

References:

<address@hidden>

In-Reply-To:

<address@hidden>

Message-ID:

<address@hidden>

Content-Type:

text/plain; charset=us-ascii

Message:

2

Rik-4 wrote

> Can anyone who solves odes regularly comment whether these are needed
> anymore?  Otherwise, I would remove them to lower the number of lines of
> code that need to be maintained.
> 
> Cheers,
> Rik

Some of the options were renamed due to Matlab compatibility and Jacopo kept
them because of backward compatibility with odepkg. I think we can break
with that. 
Some other options are solver specific (e.g. I have introduced 5 years ago
NewtonTol for radau5). I suggest that we remove them but we should allow
arbitrary parameter/value pairs (maybe with a warning). This is different
from Matlab (I believe) but still allows odepkg to work. More elegant but
rather complicated: odeset/get checks if odepkg is installed and loads a
corresponding list of acceptable strings.

Sebastian

10/16/15

Sebastian,

I implemented the first solution of accepting and passing through unknown options, but with a warning.  The non-Matlab compliant options have been removed.  See this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/00caf63edcdf).

In addition I got rid of the function odepkg_structure_check since it was nearly identical to ode_struct_value_check.  There was no point in trying to maintain two very long, nearly identical, functions.  All errors and warnings now use the Octave core id "Octave:invalid-input-arg" rather than the package id "OdePkg:InvalidArgument".

In terms of what remains to be done before ODE support is fully in core, I see 1) a final review of ode45.m for style and efficiency, and 2) dealing with the unnecessary variable 'v' prefix.  For item 2, is this likely to cause a problem with OdePkg interactions between core and package?  Or are the core routines standalone since ode45 and all of it's necessary solver routines are in the ode/private directory?

Dear rik,

regarding item 2, I don't think there will be any problem. The core routines should work independently and since I am now starting the clean up in the package after moving the core functions, I was already considering to do it for the other explicit solver. Now that ode45 is almost done, I have a road map of the changes necessary in the other solvers and this should speed up things in the future when dropping other solvers to core.

Best,
jack

--Rik

-- 
Jacopo Corno M.Sc.
Technische Universität Darmstadt
Graduate School of Computational Engineering
Dolivostraße 15
64293 Darmstadt / Germany

Office: S4|10-232
Phone: +49 6151 16 - 76877
Email: address@hidden