Have you tried using a different numerical solver?

No but I have now.  Rungekutta seems to work correctly (at least by scanning the plot by eye).  I was originally using DASSL.

So it appears like there is a problem with DASSL.  One other thing I tried earlier was to change the way the Jacobians were calculated, but it didn't fix the problem.

I'd like to continue to try and debug the problem, but for now what am I forgoing if I adopt the rungekutta method?  Is it speed, accuracy or poorer convergence?

It's an explicit method, so you don't get a solution within an error tolerance. You get whatever accuracy that your stepsize and model gives you. For some models, RK4 works very well. On stiff models, not good at all. You also can get no indication that your error tolerance is violated. The method can be very fast for some models.

Thanks for the info.

Back on the original problem.  Based on what you have seen does this seem like a failing of the numerical algorithm in dassl (wrong algorithm for the problem), a bug in dassl or a bug in the om interface to dassl?  If the algorithm was struggling with the problem I would have expected it to produce some kind of errors.  This is especially the case because it is an implicit method right?

Off topic again:  I see that the C++ runtime has an interface to IDA.  What is the state of the C++ simulation runtime, is it still in "beta"?  Is it expected to replace the C runtime or just be an alternative?  I got the source to compile on a simple problem (complication was very slow with clang++), but it would fail to compile on a more complicated model.

Thanks again for your help.  I plan on getting more involved with the OM community as I'm working on an open source tool that can be used by researchers to easily simulate and optimise solar thermal power plants using novel designs and working fluids.  Not much to show for it yet, however we plan on using OM as a core component for simulation and likely also optimisation.

Cheers

When I turn on LOG_SOLVER for the dassl I get:

|                 | |       | | solver: DASSL
|                 | |       | | | 84457 steps taken
|                 | |       | | | 110857 calls of functionODE
|                 | |       | | | 51853 evaluations of jacobian
|                 | |       | | |  4631 error test failures
|                 | |       | | |     0 convergence test failures

Are the "error test failures" anything to be worried about?  I seem to get them in both simulations (the broken long one and the short working one).

The C++ runtime is not a priority of the core development team, but it is used by some of our industrial partners and mostly maintained to support their models. Other models might not work. And yes, it uses a lot of templates and similar, so it needs to re-compile more code than the C runtime every time you run a model.

As for dassl, it sometimes fails if the number of intervals are too many. It works very well in many cases, but not for all problems.

So what is it about too many intervals that causes a problem?  Is it because the chosen interval size is so small that the equations barely change between steps or is it that the DASSL algorithm doesn't like long simulations not matter what the underlying equations are?  With my limited knowledge on the subject, the only explanation I can think of for these is that either it is somehow having trouble scaling the problem for the range of time values used, or it is a bug in the solver.  Do you know if someone has been investigating this problem?

There are some bugs with event handling and trying to calculate what is a small value to detect events, for example. Some of these kind of values in OM depend on the step size.

Hello pppsco,

pppsco wrote:

I have identified the time where the first mismatch occurs.  If I run the simulation starting just before the first mismatch (with the appropriate initial conditions so it comparable), the problem doesn't occur.  See the attached plots which show the difference between the two simulations for the region of interest, with the top plot working as expected.  Notice in the bottom plot how E doesn't change.

It seems there are some events missed. Are other variable, which may influence the events also the same?

pppsco wrote:

When I turn on LOG_SOLVER for the dassl I get:

|                 | |       | | solver: DASSL
|                 | |       | | | 84457 steps taken
|                 | |       | | | 110857 calls of functionODE
|                 | |       | | | 51853 evaluations of jacobian
|                 | |       | | |  4631 error test failures
|                 | |       | | |     0 convergence test failures

Are the "error test failures" anything to be worried about?  I seem to get them in both simulations (the broken long one and the short working one).

The "error test failures" is related to the step size control algorithm and just state that the algorithm has chosen 4631 times a step size which was too large to stay with the trajectory within the given tolerances.  So that is nothing to worry about, as long as the number is not too large. If it would get too large it's just an indicator for performance issues.

Could you try to run the model with Dassl and deactivate internal root finding algorithm, then a external root finding will be used. (There is check box)

so long.
Willi

Hey wbraun,

The first event that happens in that time window is at around 7000 for the working simulation (reading output from LOG_EVENTS).  This coincides with the first discrete drop in the derivative.  But already before this time there is an error.  From 3000 to 7000 the derivatives are positive, but in the second plot the energy E doesn't change.

In the second plot the events don't trigger at 7000 and beyond because they are dependent on E, which doesn't change.  So it doesn't seem like the problem is a missed event.  From the start of the time window up to 7000 all other variables are the same, except possibly some small numerical difference.

I just tried the `-dasslnoRootFinding` flag.  Same results.

Any other ideas?

Thanks for the help.

Hey,

hm, without the model to play with, I'm not sure where to search.
So would it be possible for you to provide your model
(perhaps in private via email.)

so long.
Willi

Hey,

hm, without the model to play with, I'm not sure where to search.
So would it be possible for you to provide your model
(perhaps in private via email.)

so long.
Willi

Please report bugs here.