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.

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?

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

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

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?

Hey I'm having a problem with a longish simulation (1 year, 60 sec intervals).  It seems like a bug, as I'm not getting any errors, but I haven't narrowed it down enough to concisely explain the problem in a bug report.  I'm here looking for general suggestions about how I can go about diagnosing/fixing the problem.

I have a very simple equation in one of my models (derivative of energy equals power):

der(E) = p

After running the simulation (no errors with the default logging), and viewing the results, I see at times that a positive value of der(E) has no affect on E (it doesn't increase as expected).  In other sections of the simulation it works perfectly.

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.



Has anyone had a similar problem?  Do you have any general advice for where I should look?

I'm trying to diagnose the problem by reading the source code and outputting more detailed debugging info.  I'm also trying to trim the model down to the smallest subset which still has trouble so that I can share it for others to try.  So far I haven't had much luck with either.

Thanks

OK thanks.  I did a bit more reading on fixed and it seems to make a bit more sense now.  I found another way of doing what I originally wanted:

parameter String x = if 3 > 1 then "it" else "works";

Hey everyone, new modelica user here.

I've been trying to initialise a String parameter within an initial algorithm section, for example:

model Fail

    parameter String x(fixed=false);

initial algorithm

    x := "please work";

end Fail;

But it won't simulate.  I get errors:

"Simulation execution failed for model: Fail

LOG_INIT          | error   | The initialization problem is inconsistent due to the following equation: 0 != 1 = not x == $TMP_x_1

stdout            | warning | Error in initialization. Storing results and exiting.

|                 | |       | Use -lv=LOG_INIT -w for more information.

"

and

Warning: Parameter x has no value, and is fixed during initialization (fixed=true), using available start value (start="") as default value.

Warning: The initial conditions are over specified. Use +d=initialization for more information.

It is as if 'fixed' gets forced to true for some reason.  However if I instead try the same thing with a Real it works:

model Pass

    parameter Real x(fixed=false);

initial algorithm

    x := 10;

end Pass;

Does anyone know why this is the case?  I would like to do this because I would like to conditionally set the string parameter.  If anyone has an alternative approach that would be welcome also.

Thanks