Incorrect assumption of OMC solver on minimum time step should be removed

[Francesco Casella]

The model ​Modelica.Electrical.Spice3.Examples.Inverter currently does not pass the verification phase because of serious mismatch of the output w.r.t. the reference file.

The model has the following experiment annotation:

  experiment(
      StopTime=1e-11,
      Interval=5e-15,
      Tolerance=1e-7)

The following ​warning is reported by the default solver (DASSL)

Regular simulation: ./Modelica_3.2.3_Modelica.Electrical.Spice3.Examples.Inverter -abortSlowSimulation -alarm=480   -emit_protected
stdout | warning | The step-size 2.50125e-15 is too small. Adjust the step-size to 1e-12.

In fact, I get this very same message no matter what solver I select, so I suspect the "step size" may actually be the reporting interval; I also guess this limitation is enforced prior to the invocation of the specific solver.

Now, the time scale of this simulation is extremely short. Time constants of transistors are in the pico-second range (1e-12 s), and the entire simulation only lasts 1e-11 s, with a resolution of 5e-15, and a fairly tight tolerance of 1e-7. In this case, one expects both time step lengths and reporting intervals which may be way shorter than 1e-12.

Although it may be sensible to have a lower limit on the step time, this should be obtained based on the simulation time scale and on the simulated system dynamics. Putting an arbitrary limit at 1e-12 is questionable, and in fact makes the results of this simulation very inaccurate.

I would suggest to simply remove this check and let each specific solver judge on wheter the time step is too short or not, based on whatever state-of-the-art heuristics it may use.

[Martin Sjölund]

To resolve this, I would suggest putting the (scaled) minimum step size in the simInfo. Other solvers (non-linear, event detection) assert that any time lower than this is the "same" time.

[Francesco Casella]

Replying to sjoelund.se:

To resolve this, I would suggest putting the (scaled) minimum step size in the simInfo. Other solvers (non-linear, event detection) assert that any time lower than this is the "same" time.

In fact, I was going to suggest to use StopTime-StartTime as a scaling factor. However, this is not necessarily a good idea: in some cases I may want to run a very long simulation (say, one year of operation of a building, which is about 30e6 seconds, but that doesn't mean that I may be interested in short transients (e.g. a few seconds) if a variable step-size solver with error control is used.

From this point of view, using the reporting interval as a scaling factor is probably the best idea, because the user will set it to a problem-specific relevant value, that he knows about. In the above-mentioned case, the number of intervals will probably be of the order of 1e4-1e6, that is, much larger than the usual few thousand samples that are used for typical simulations.

So, my suggestion is that the minimum step size (of variable step-size solvers) should be some small fraction of the reporting interval, while I suggest to put no restrictions on the reporting interval itself, because the end user knows better what he/she wants.

The bottom line is: we need to be very, very careful when making this kind of assumptions.

[Martin Sjölund]

Well, you also need to adhere to double precision floating point restrictions. And that is roughly 1e-16 * time (the current time). So maybe the scaling factor should be scaled relative to max(abs(startTime),abs(stopTime)). And you need some difference between the step size and the minimum size taken (so a step size around 1e-11 times that scaling factor and a minimum step around 1e-15 of that step).

[Francesco Casella]

Sounds good

[Lennart Ochel]

See ​OpenModelica#219 for further discussions. I changed the default value to 1e-4 * min(1e-12, stopTime-startTime) which seem to work just fine. However, please feel free to propose a better term for the minimal step size.

[Francesco Casella]

See also #2648.

Apparently the Inverter model was previously not triggering events at all, unless the tolerance was very strict. The fix introuced then allowed to trigger the events, but the simulation is way too inaccurate, when compared to the reference data.

[Lennart Ochel]

Now it is reported as verified simulation. So I guess the results are actually accurate.

[Francesco Casella]

Replying to lochel:

Now it is reported as verified simulation. So I guess the results are actually accurate.

Where do you see that? The ​report I normally check is still 2 days old...

[Francesco Casella]

OK, I now see it too. Thanks!