The debugger output with dummy derivatives is inconsistent and confusing

[casella]

Please consider the following test case (also attached)

model TestDummyDer
  Real x1(stateSelect = StateSelect.avoid);
  Real x2(stateSelect = StateSelect.avoid);
  Real z1(stateSelect = StateSelect.prefer);
  Real z2(stateSelect = StateSelect.prefer);
equation
  der(x1) = -x1 + x2;
  der(x2) = x2 - x1;
  z1 = 4*x1 + 3*x2;
  z2 = 3*x1 - 2*x2;
end TestDummyDer;

The debugger shows the following regular equations:

linear (torn), unknowns: 2, iteration variables: 1
  (torn) x2 := 1.5 * x1 - 0.5 * z2
  (residual) 3.0 * x2 + 4.0 * x1 - z1 = 0
(assign) der(x2) := x2 - x1
(assign) der(x1) := x2 - x1
(assign) der(z1) := 4.0 * $DER.x1 + 3.0 * $DER.x2
(assign) der(z2) := 3.0 * $DER.x1 + (-2.0) * $DER.x2

On the right-hand sides I see symbols $DER.XXX that apparently indicate dummy derivatives. Unfortunately, they are not used on the left-hand sides, nor do they ever show up in the Depends windows. This is very confusing. Shouldn't we use consistent symbols everywhere?

[Karim.Abdelhak]

That is due to the fact that in the backend we save the assignment of derivative-equation by the name of the state rather than the name of the derivative, because the variable representing the derivative does not exist up to that point. When printing such an assignment, we just wrap the state with der().

For simulation the derivative is created and therefore the RHS shows the derivative expressions. The debugger shows matching information and therefore the LHS is shown as der(state) and the RHS shows the assigned expression as it is in simcode.

What would you rather like:

1. always der(state) or
2. always$DER.state?

The way these are printed can easily be changed. We could follow dymola here, they keep the der() operator in all their outputs. Debugging for new Developers would be easier if we keep $DER.state. I still would follow dymola here since most of the output is supposed to be user friendly and we want to differ between user and developer debug flags in the future anyway.

This behaviour will not happen in the new backend btw. We create the derivatives right at the beginning of the new backend.

[casella]

Knowing if a derivative is dummy or real is not particularly interesting when debugging. What you want to understand is why certain quantities (including derivatives) have trouble being computed, or are computed wrongly, rather than actually looking at their values to compute the state values at the next step. That is the work of the ODE integration algorithm.

Furthermore, in case of dynamic state selection there's no way to actually know what are the dummy and real derivatives in the debugger, because the state choice is not statically available.

Last, but not least, if you are looking for a specific derivative in the results, you'll definitely look for der(myvar), not for $DER.myvar

So, I'd suggest to go for option 1.

Thanks!

[Karim.Abdelhak]

Replying to casella:

Knowing if a derivative is dummy or real is not particularly interesting when debugging.

I think you misunderstand the dump. $DER.state does not mean that it is a dummy derivative. All state derivatives (and dummy derivatives) are represented this way. From this representation you cannot determine if it is a dummy. The only reason the left hand side is not also represented this way, is that the matching (and strong components) are based on states not derivatives.

Last, but not least, if you are looking for a specific derivative in the results, you'll definitely look for der(myvar), not for $DER.myvar

So, I'd suggest to go for option 1.

Thanks!

Yes that what i also was thinking. Modelers will always look for der(state). I will change the dumping and see what has to be changed. Unfortunately that is such a fundamental change in dumping that it should affect all tests that dump anything and could take some time to make sure everything works as expected.

[casella]

Replying to Karim.Abdelhak:

I think you misunderstand the dump. $DER.state does not mean that it is a dummy derivative.

Indeed. I agree that keeping a different representation which is only dictated by the internal data structures of the (current) backend makes no sense. First and foremost because it is only understood by the very few persons that have the privilege of working on the OMC backend :)

Yes that what i also was thinking. Modelers will always look for der(state). I will change the dumping and see what has to be changed. Unfortunately that is such a fundamental change in dumping that it should affect all tests that dump anything and could take some time to make sure everything works as expected.

True. Good luck with that...

[casella]

This issue bugs me every time I look at the debugger output, see ticket:6254#comment:7. I guess I'm not alone with that...

Please have it fixed for 1.17.0.

[casella]

Rescheduled to 1.18.0

[casella]

Ticket retargeted after milestone closed

[casella]

1.18.0 blocker tickets moved to 1.19.0