Make sure variables which are practically constant are displayed as such in OMEdit

[Francesco Casella]

Try the following test case

model foo
  Real x(start = 1-1e-7, fixed = true);
equation
  der(x) = 1-x;
end foo;

Then, plot x. A monotonously increasing curve is displayed, which seems to imply that there is a transient until one looks at the values on the y axis and sees that they are all ones. Quite confusing. In general, this happens when a model is numerically initialized at steady-state, but there is a *very small* transient, which should not be unnecessarily magnified.

My proposal, when visualizing plots, is to make sure that the span of the y axis is bounded from below to

1e-4*max(v_start, v_end, v_nominal)

where v_start is the initial value of v, v_end is the final value, and v_nominal is its nominal attribute). In this way, the result of the above example will show a variable which is indeed constant for all practical purposes.

It should be still possible to zoom in, if needed, but the default initial view should not magnify a negligible transient.

[massimo ceraolo]

IMO we should let the user decide whether a variation is meaningful or not.
But I don't like OM plot with all ticmarks being "1" either.

Instead of showing a constant value, and instead of having tickmarks all equal to each other, better is Dymola's way, that in these cases shows a reference value and the displacement around that value. I mean the plot enclosed as plot.png, made using the following code:

model foo
  Real x(start=0.99999, fixed=true);
equation
  der(x)=1-x;
  annotation (Icon(coordinateSystem(preserveAspectRatio=false)), Diagram(
        coordinateSystem(preserveAspectRatio=false)));
end foo;

But if this is impossible I would prefer a plot like the one OM makes today, instead of one artificially transformed into constant.

[Christoph Buchner <buchner@…>]

The Python plotting library Matplotlib does something similar - an offset ​is added (sorry couldn't quickly find a better image) when the data range vs. absolute values is small.

In my experience, care has to be taken that this is not done too often/too early. Matplotlib's algorithm determines the number of significant tick label digits it can save by adding an offset (e.g. to avoid labels like 1.000001), and if that number is above a threshold (earlier default 2, recently changed to 4, which is much better), the offset is activated. The logic for that can be found ​here.

[massimo ceraolo]

Replying to Christoph Buchner <buchner@…>:

The Python plotting library Matplotlib does something similar - an offset ​is added (sorry couldn't quickly find a better image) when the data range vs. absolute values is small.

In my experience, care has to be taken that this is not done too often/too early. Matplotlib's algorithm determines the number of significant tick label digits it can save by adding an offset (e.g. to avoid labels like 1.000001), and if that number is above a threshold (earlier default 2, recently changed to 4, which is much better), the offset is activated.

Wow! This is exactly what had in mind and did not dare suggest! If this can be done with a reasonable effort, it will be the final solution. I also agree with the choice of four significant tic label digits.

[Francesco Casella]

De gustibus non est disputandum (thou shalt not argue about tastes) :)

That said, while I certainly do see @ceraolo's point, for many practical purposes I see Dymola's and Matplotlib's output as unnecessarily cumbersome.

In the test case I proposed, for all practical purposes the value of x is 1, and is a constant. This test is meant to emulate more realistic cases where the initial solution is solved for der(x) = 0 numerically, and there are "transients" with amplitude of 1e-6 superimposed to a value of 1e4 or something like that. Seeing these "transients", which are often riddled by numerical artefacts, sure tells you something about the quality of the steady-state solution and of the solver in general, but from all other practical purposes that transient doesn't mean anything relevant for the model you are simulating. As soon as you apply a small (intended) change to any of the system's inputs (e.g., a small step change from the equilibrium condition), those variations will be many orders of magnitude smaller than those caused by the intended changes, and show up as constant in any plot. It is only in the special case when you don't apply any change to the input that suddenly these "transients" actually show up, but they don't mean much.

In fact, they hardly mean anything, besides the fact that no solver is perfect, and they can be quit confusing for beginners - all my students have some trouble understanding them at first sight.

I would honestly prefer to have one (optional?) easy way too see, say, the values 0.999, 1.000 and 1.001, or possibly 0.9999, 1.0000 and 1.0001 on the y axis, with a nice curve looking like a constant on that scale. Incidentally, immediately understanding what is the value of 0.999988 + 2e-6 is really not easy: you have to count the 9's and spend some time figuring out.

Summing up: getting the offset as proposed by @ceraolo is fine for me; it would be great if I additionally got a button somewhere that turns this feature off and sets the y-axis span to 1e-4*max(v, v.nominal), making sure that this span is sufficient to show different marks on the axis (or setting the number of decimals there to do so)

[massimo ceraolo]

I agree, Francesco, it is a question of taste.

In some occasions I got so constant curves that they appeared as having discrete levels. 2-3 levels: this meant that the internal binary representation changed during the simulation on just the last one or two bits.

I liked those quantized plots, since they told me the whole story: that the quantity was constant and what "constant" means for a computer and for a human!

[Francesco Casella]

Replying to ceraolo:

In some occasions I got so constant curves that they appeared as having discrete levels. 2-3 levels: this meant that the internal binary representation changed during the simulation on just the last one or two bits.

I liked those quantized plots, since they told me the whole story: that the quantity was constant and what "constant" means for a computer and for a human!

Do not assume that the understanding of a seasoned university professor who probably wrote simulation code itself in the old days applies to modern students as such :)

[massimo ceraolo]

Replying to casella:

Do not assume that the understanding of a seasoned university professor who probably wrote simulation code itself in the old days applies to modern students as such :)

Do not assume that the understanding of a seasoned university professor who probably wrote simulation code itself in the old days applies to modern students as such :)

---

Just a final reply (I don't want to bother other readers with my personal views anymore).

After 30 years as a teacher I have some experience of students, also modern ones!

My personal belief is that "difficulties must be explained not hidden". Or, to use Einstein's words: "Everything should be made as simple as possible, but not simpler".

Then for me your proposal "hides difficulties", while mine "explains" them.
Or, in other words, our views on this ticket's topic diverge on whether your proposal is to make things just as simple as possible, or too simple...

Regards

[Francesco Casella]

I totally agree.

To summarize, the default view should have the offset and show the "transient". Then, once you've understood, you should have the option of clicking on a button and see a nice constant plot, because the "real" system is at steady state.

[Francesco Casella]

Rescheduled to 1.14.0 after 1.13.0 releasee

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

[Francesco Casella]

Today I stumbled again into this issue, namely the simulation of a steady state equilibrium that looks like the attached screenshot.png. The "transient" shown there is totally bogus, it is due to numerical noise, and it is not possible to understand how small it is because the four digits on the left axis are not enough to see any difference.

Furthermore, if I click on Setup in the plot window, the minimum and maximum values for the Y-axis are shown both to be 1.1552e+06, so if I just click ok they are taken by OMEdit to be equal, ending up in an empty screen.

I fully agree with @ceraolo in comment:8 that we shouldn't hide anything, but I am convinced that if we follow my initial advice, we are not really hiding anything: the span of the X axis actually be visible, because there should be enough digits to see different numbers there, while it is currently hidden, because I have no idea what the actual span is. Then one knows that within that scale there is no actual change worth mentioning, which IMHO after 25 years of experience in this field is what one would like to see in these cases. Of course if one wants to see if perchance there are some fluctuations on a smaller scale, it is always possible to zoom in or to click on Setup and choose a smaller interval for the Y axis.

@adeas31, can you please implement my original proposal?

Thank you!

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

One more end user (in the power engineering field BTW) got confused by this issue, see #6224 and the 6224.pdf attachment.

I think we should really avoid showing fluctuations on the 15th decimal digit by default. If you want to zoom in, fine, but that's not what you should see first.

[jean-philippe.tavella@…]

Yes I totally agree with casella: I think we should really avoid showing fluctuations as the simulations in PowerSysPro (refer to #6224) are all steady states, without time dependant variables.
Very disturbing for users. Plots under OM should be displayed as Dymola does.

[anonymous]

Well #6224 is a separate issue. Systems with no time dependence shouldn't even be recomputed, if it's possible to detect that. Showing their fluctuations actually helps to see something fishy is going on.

If a variable happens to be constant, that's another story. I'm not sure which option I'd prefer but in any case you must be able to perceive how far you are zoomed in. Dymola does a decent job there.

[Francesco Casella]

Replying to anonymous:

Well #6224 is a separate issue. Systems with no time dependence shouldn't even be recomputed, if it's possible to detect that.

True.

Showing their fluctuations actually helps to see something fishy is going on.

I respectfully disagree. I think we shouldn't really show machine-epsilon or even solver-epsilon fluctuations. There are systems where this happens all the time, e.g. the zero-current in 3-phase AC systems. You see a lot of fluctuations that look random and have absolutely no physical meaning. They aren't fishy by any means, they are simply the inevitable consequence of tolerance errors in the solver. Do we really want to show that numerical noise up front as a simulation result? I find it very confusing.

If you want to do debugging of the solver, that's one thing - you can always zoom in if you want to check that. But if you are mainly interested in the (physical) result of a simulation, they are just misleading.

[jean-philippe.tavella@…]

Replying to casella:

I respectfully disagree. I think we shouldn't really show machine-epsilon or even solver-epsilon fluctuations. There are systems where this happens all the time, e.g. the zero-current in 3-phase AC systems. You see a lot of fluctuations that look random and have absolutely no physical meaning. They aren't fishy by any means, they are simply the inevitable consequence of tolerance errors in the solver. Do we really want to show that numerical noise up front as a simulation result? I find it very confusing.

If you want to do debugging of the solver, that's one thing - you can always zoom in if you want to check that. But if you are mainly interested in the (physical) result of a simulation, they are just misleading.

As a basic user at EDF only interested in physical results I totally agree.

[jean-philippe.tavella@…]

Will this issue be solved or not?
Basic users are only interested in the (physical) result of a simulation, not in solver debugging.

[Francesco Casella]

As far as I am concerned, I am all for it. Ultimately, it is up to @adeas31 to implement, he may have higher priority tasks in the near future.

[Francesco Casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[Francesco Casella]

Ticket retargeted after milestone closed

[Adeel Asghar]

See ​https://github.com/OpenModelica/OpenModelica/issues/4232