Re: Updated odeset/odeget

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Updated odeset/odeget

Rik-4
On 10/10/2015 09:11 AM, [hidden email] wrote:
Subject:
Re: Updated odeset/odeget in core
From:
Sebastian Schöps [hidden email]
Date:
10/09/2015 11:53 PM
To:
[hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
References:
<MTAwMDAwOC5ub21hZA.1444417841@quikprotect>
In-Reply-To:
<MTAwMDAwOC5ub21hZA.1444417841@quikprotect>
Message-ID:
[hidden email]
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?

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: Updated odeset/odeget

Jacopo Corno


Il 16/10/2015 20:26, Rik ha scritto:
On 10/10/2015 09:11 AM, [hidden email] wrote:
Subject:
Re: Updated odeset/odeget in core
From:
Sebastian Schöps [hidden email]
Date:
10/09/2015 11:53 PM
To:
[hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
References:
<MTAwMDAwOC5ub21hZA.1444417841@quikprotect>
In-Reply-To:
<MTAwMDAwOC5ub21hZA.1444417841@quikprotect>
Message-ID:
[hidden email]
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: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Updated odeset/odeget

Carlo de Falco-2
In reply to this post by Rik-4

On 16 Oct 2015, at 20:26, Rik <[hidden email]> wrote:

> The non-Matlab compliant options have been removed.  See this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/00caf63edcdf).

I think your changeset makes the functions integrate_constant and integrate_n_steps
useless as there is now probably no way to trigger their use through the options.

Do we want to support that behaviour, even though it is not present in Matlab?
Maybe Sebastian's proposal to have an (non compatible) option to pass a list
of fixed time steps to use for integration is easier to support and more useful?

c.
Reply | Threaded
Open this post in threaded view
|

Re: Updated odeset/odeget

Carlo de Falco-2
In reply to this post by Rik-4

On 16 Oct 2015, at 20:26, Rik <[hidden email]> wrote:

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

This change will definitely break all functions in the current version of odepkg, yet I think it is worth doing.
Jacopo already bumped up the minimum required version of Octave in the odepkg descripton and will work to keep odepkg compatible with the development branch.
We should make a new release of odepkg as soon as Octave 4.2 is out.

The main question for this new release is what is the list of other methods that should be moved into core before the new release?

The easiest function to move should be ode23, what else is in the list?

c.
Reply | Threaded
Open this post in threaded view
|

Re: Updated odeset/odeget

Rik-4
In reply to this post by Carlo de Falco-2
On 10/17/2015 04:41 AM, Carlo De Falco wrote:
> On 16 Oct 2015, at 20:26, Rik <[hidden email]> wrote:
>
>> The non-Matlab compliant options have been removed.  See this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/00caf63edcdf).
> I think your changeset makes the functions integrate_constant and integrate_n_steps
> useless as there is now probably no way to trigger their use through the options.

Not useless.  Unrecognized options can still be set, and Octave will only
print a warning, but otherwise pass the option through.  In ode45.m the
decision on which algorithm to use is based on the options TimeStepNumber
and TimeStepSize.  Even before removal, odeset() would have returned empty
entries by default for these fields resulting in the adaptive algorithm
being chosen.  Just as before, one will have to specifically set these
options with opts = odeset ("TimeStepNumber", XXX, "TimeStepSize", YYY) in
order to get a different solver.  The only change will be the warning,
"odeset: unknown field 'TimeStepNumber' in ODE options".


>
> Do we want to support that behaviour, even though it is not present in Matlab?
> Maybe Sebastian's proposal to have an (non compatible) option to pass a list
> of fixed time steps to use for integration is easier to support and more useful?

I can't answer these questions as my perspective is only about how to bring
the ODE code into the core.  Generally, however, we like to think of Octave
as a superset of Matlab; It should be able to do everything Matlab does,
but it certainly is okay to do more.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Updated odeset/odeget

Rik-4
In reply to this post by Carlo de Falco-2
On 10/17/2015 04:43 AM, Carlo De Falco wrote:
>
>
> The main question for this new release is what is the list of other methods that should be moved into core before the new release?

In ode45.m I see this:

  if (isempty (vodeoptions.OutputFcn) && nargout == 0)
    vodeoptions.OutputFcn = @odeplot;
    vodeoptions.vhaveoutputfunction = true;

It seems that at a minimum odeplot.m should be imported into core.  Other
solvers would also be good.

I will publish a list of the modifications I needed to make which should
make it fairly easy to import new solvers.

--Rik

>
> The easiest function to move should be ode23, what else is in the list?
>
> c.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Updated odeset/odeget

Sebastian Schöps

> In ode45.m I see this:
[...]
> It seems that at a minimum odeplot.m should be imported into core.  Other
> solvers would also be good.


true,we will need to move also

- odeplot
- odeprint
- odephas2
- odephas3
- odeexamples

..and possibly we should create

- odedemo (currently unimplemented, http://de.mathworks.com/help/matlab/examples/differential-equations.html)

for full compatibility.

> The easiest function to move should be ode23, what else is in the list?
Once we agreed on the changes in ode45 it should be very easy to adapt ode23. However, we should have at least one stiff solver in 4.2. Maybe ode23tb could be a good option... ASFAIK this solver is currently worked on.

Sebastian


Reply | Threaded
Open this post in threaded view
|

Re: Updated odeset/odeget

Carlo de Falco-2

On 17 Oct 2015, at 18:30, Sebastian <[hidden email]> wrote:

> However, we should have at least one stiff solver in 4.2.
the default stiff solver in Matlab is ode15s, we really should get that warking
ASAP but I don't think that will be in time for 4.2 ...

> Maybe ode23tb could be a good option... ASFAIK this solver is currently worked on.
Yes that is being worked on, ode23t should also be very easy to implement, but
what I was really asking is the list of solvers that are ALREADY implemented in
odpkg and use the same low level functions as ode45 and thus are ready to be moved to core.

c.



Reply | Threaded
Open this post in threaded view
|

Re: Updated odeset/odeget

Carlo de Falco-2
In reply to this post by Rik-4

On 17 Oct 2015, at 17:36, rik <[hidden email]> wrote:

> I will publish a list of the modifications I needed to make which should
> make it fairly easy to import new solvers.

I also made some changes in ode45 that need to be replicated in other solvers, e.g.:

http://hg.savannah.gnu.org/hgweb/octave/rev/27c091f4b66d
http://hg.savannah.gnu.org/hgweb/octave/rev/a22d8a2eb0e5

c.



Reply | Threaded
Open this post in threaded view
|

Improved performance of ode45 in core

Rik-4
10/19/15

Immediately after the introduction of ode45 into the core the code "tic;
test ('ode45'); toc" resulted in an average runtime of 16.625 seconds on my
computer.  Today, the same benchmark takes 10.28 seconds or a -38%
reduction.  So the vectorization that Carlo did and the general code
cleanup made a large difference.

--Rik