Better control of integration algorithms and output features in OMEdit

[Francesco Casella]

OMEdit allows to specify the tolerance and number of intervals for the integration algorithm. It seems that the semantics is the following:

• for variable step size algorithms with error control, the tolerance is used to set relative/absolute tolerances for the error control algorithm, which takes whatever steps are necessary to meet the required precision, then the output is re-sampled at regular intervals spaced (StopTime-StartTime)/NumberOfIntervals

• for fixed time step algorithms, the tolerance is ignored, and the fixed time step is set to (StopTime-StartTime)/NumberOfIntervals

Furthermore, in case of events, the values of all variables before and after the event are stored.

I think we need to give more flexibility to the end user.

1. In the case of variable-step size solver, it is often useful to store the results at the actual time steps of the algorithm, both for debugging purposes (in order to avoid missing fast transients that might be undersampled, to detect chattering, etc.), and for better use of storage space, as there will be many points when interesting things are happening fast, and few of them when the system is close to equilibrium. There should be a flag to activate this behaviour. This is what Dymola does when setting equidistantTimeGrid = false.

2. In the case of fixed time-step algorithms, it might be useful to set a different time step than the output base interval. For example, sometimes it is necessary to set small time steps to explicit algorithms for stability reasons, but it might be unnecessary to store all those small time steps. I would recommend having the fixed time step as a separate field - if left empty, the current output base interval might be used as a default

3. In systems with many events, it might be useful to suppress the output at events, to avoid cumbersome result files. I understand this is possible with the -noEventEmit simulation flag. This should be supported in OMEdit

4. There should be some way to pass solver-specific flags to the solvers, for advanced users. For example, DASSL has a parameter to determine the step length after event processing, which can be very useful to change in order to avoid the solver to restart with too long a step size after every event. A flexible mechanism to do so would be very welcome

See also #2480

[Adeel Asghar]

Added -noEventEmit simulation flag option in r22891. Now there is a Store Variables at Events checkbox in Output tab. The checkbox is checked bydefault. If user unchecks it then OMEdit sends the -noEventEmit flag to simulation executable.

[Willi Braun]

1. In the case of variable-step size solver, it is often useful to store the results at the actual time steps of the algorithm, both for debugging purposes (in order to avoid missing fast transients that might be undersampled, to detect chattering, etc.), and for better use of storage space, as there will be many points when interesting things are happening fast, and few of them when the system is close to equilibrium. There should be a flag to activate this behaviour. This is what Dymola does when setting equidistantTimeGrid = false.

We can do that by using the solver "dasslsteps".

[Lennart Ochel]

Replying to wbraun:

We can do that by using the solver "dasslsteps".

It sounds to me a bit strange to change the solver method to do this.

[Francesco Casella]

Replying to lochel:

Replying to wbraun:

We can do that by using the solver "dasslsteps".

It sounds to me a bit strange to change the solver method to do this.

I agree with Lennart. This option should be available (at least in principle) with all variable step-size solver, not only with dassl, so it should be orthogonal to the choice of method. How this is actually implemented in the back-end is irrelevant at this level.

[Martin Sjölund]

Well, it would make some sense to have integrator options for each algorithm. That way you don't need to create a new integrator for dasslsteps. It could just be:
dassl, with options:

  internalRootFinding=true
  equidistantTimeGrid=true (could make sense to move this to a general flag for all integrators)
  jacobian=default|symbolic|numerical|colored|internalNumerical

The same for lobatto (option order=2|4|6), and radau (order=1|3|5).

[Willi Braun]

Replying to sjoelund.se:

Well, it would make some sense to have integrator options for each algorithm. That way you don't need to create a new integrator for dasslsteps. It could just be:
dassl, with options:

  internalRootFinding=true
  equidistantTimeGrid=true (could make sense to move this to a general flag for all integrators)
  jacobian=default|symbolic|numerical|colored|internalNumerical

The same for lobatto (option order=2|4|6), and radau (order=1|3|5).

Yes, that's sounds good. I'll going to change that.

[Martin Sjölund]

Wait until after the release so OMEdit can keep up ;)

[Willi Braun]

Replying to sjoelund.se:

Wait until after the release so OMEdit can keep up ;)

Okay.

[Martin Sjölund]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[Willi Braun]

Replying to casella:

1. In the case of variable-step size solver, it is often useful to store the results at the actual time steps of the algorithm, both for debugging purposes (in order to avoid missing fast transients that might be undersampled, to detect chattering, etc.), and for better use of storage space, as there will be many points when interesting things are happening fast, and few of them when the system is close to equilibrium. There should be a flag to activate this behaviour. This is what Dymola does when setting equidistantTimeGrid = false.

In r22989 added the flag -noEquidistantTimeGrid.

Replying to casella:

4. There should be some way to pass solver-specific flags to the solvers, for advanced users. For example, DASSL has a parameter to determine the step length after event processing, which can be very useful to change in order to avoid the solver to restart with too long a step size after every event. A flexible mechanism to do so would be very welcome

In r22989 the following flags are available for dassl:

• <-maxStepSize=value> value specifies maximum absolute step size, used by dassl solver
• <-initialStepSize=value> value specifies an initial stepsize for the dassl solver
• <-maxIntegrationOrder=value> value specifies maximum integration order, used by dassl solver
• <-dasslnoRestart> flag deactivates the restart of dassl after an event is performed.

[Adeel Asghar]

Replying to wbraun:

Replying to casella:

1. In the case of variable-step size solver, it is often useful to store the results at the actual time steps of the algorithm, both for debugging purposes (in order to avoid missing fast transients that might be undersampled, to detect chattering, etc.), and for better use of storage space, as there will be many points when interesting things are happening fast, and few of them when the system is close to equilibrium. There should be a flag to activate this behaviour. This is what Dymola does when setting equidistantTimeGrid = false.

In r22989 added the flag -noEquidistantTimeGrid.

Replying to casella:

4. There should be some way to pass solver-specific flags to the solvers, for advanced users. For example, DASSL has a parameter to determine the step length after event processing, which can be very useful to change in order to avoid the solver to restart with too long a step size after every event. A flexible mechanism to do so would be very welcome

In r22989 the following flags are available for dassl:

• <-maxStepSize=value> value specifies maximum absolute step size, used by dassl solver
• <-initialStepSize=value> value specifies an initial stepsize for the dassl solver
• <-maxIntegrationOrder=value> value specifies maximum integration order, used by dassl solver
• <-dasslnoRestart> flag deactivates the restart of dassl after an event is performed.

All the above flags are valid for all variants of dassl solvers i.e dassl, dasslwort & dasslsteps?

[Lennart Ochel]

There is just one dassl solver: dassl.

[Adeel Asghar]

In r23165 a support for -noEquidistantTimeGrid flag is done. I have also added a button with an external link to IntegrationAlgorithms.pdf next to integration drop down.

[Adeel Asghar]

Done in r23249.

Added interface for following dassl flags,

• <-noEquidistantTimeGrid>
• <-dasslJacobian=[coloredNumericalJacobian|numericalJacobian|internalNumericalJacobian|coloredSymbolicalJacobian|symbolicalJacobian]>
• <-dasslnoRootFinding>
• <-dasslnoRestart>
• <-initialStepSize=value>
• <-maxStepSize=value>
• <-maxIntegrationOrder=value>