Problem with the test of Modelica/Electrical/Machines/Examples/InductionMachines/IMC_DCBraking

[uschna]

There is a problem with the test of Modelica/Electrical/Machines/Examples/InductionMachines/IMC_DCBraking. If we reduce the tolerances the results will change. According to Modelica/Electrical/Machines/Examples/InductionMachines/IMC_DCBraking/creation.txt (in branches v4.0.0 and v4.1.0) the used tolerance is 1e-7.
With this tolerance the last value of "imc.idq_sr[1]" in IMC_DCBraking.csv is -15.240146546765066.
But with smaller tolerances (for example 1e-10) this value is approximately -14.1.
Could you please compute and save the reference results with Tolerance=1e-10?
Thank you.

[henrikt-ma]

Actually, it would be interesting to see results for a (logarithmic) sweep of Tolerance over the range 1e-10 to 1e-6 (at least two steps per decade, preferably).

We have an issue with the model if we can't find a [tolTight, tolBig] range of tolerance values where tolBig/tolTight is at least 10 and the result is only changing slightly when going from tolBig to tolTight. If such a range can be found, tolBig is a suitable setting for the experiment-annotation, while tolTight would be suitable for reference result creation. (This should be a requirement for pretty much all examples, but we can begin by doing the exercise for this model.)

[henrikt-ma]

I made a quick experiment with System Modeler. For a variable with dynamic range of approximately 280, I aimed for an absolute error tolerance of 1e-3 * 280 = 0.28. With tighter tolerance and when using DASSL for integration, the final result appears to approach −14.125 from below. When using CVODES for integration I get somewhat different results, but both methods agree on the final value -14.125 at tolerance 1e-10. At 1e-8 I was above −14.125 - 0.28 with DASSL (and as usual CVODES was consistently performing better), so based on this I would have set Tolerance = 1e-8 in the experiment-annotation, and used 1e-10 for reference result creation.

[AHaumer]

I can't promise that I can look after that problem before the conference since I'm recovering from a surgery.
Only a few questions to @uschna:

• Which simulator are you using on which operating system with which C-compiler?
• Which integrator algorithm are you using?
• Which version of the MSL are you using?

In general, for all machines examples we are using Tolerance = 1e-6.
For reference result creatio and regression test we are using Tolerance / 10 (if I remember correctly).
During the regression tests for release MSL 4.1.0 there were no issues.

[AHaumer]

Quick and short analysis:
MSL: 4.1.0 (master branch)
Simulator: Dymola 2025x Refresh 1
Algorithm: Dassl
Compiler: Visual Studio 2022
OS: Windows 11 24H2 (64 bit)
Unfortunately you onyl mentioned imc.idq_sr[1] in your comparison.
The problem stems from slightly different mechanical angles in the end position, which in turn influences the splitting of the current space phasor (with the same (!) length) to real and imaginary part. A small (and neglectible) difference in the angle (imc.phiMechnical = 1673.87 -> 1673.89 rad for Tolerance = 1e-6 -> 1e-7) leads of course to a larger change in real and imaginary part.
@christiankral what is your opinion about changing the tolerance?
I will perform a test with OM later.

[uschna]

• Which simulator are you using on which operating system with which C-compiler?
  SimulationX, BDF (with Byte-Code and with compiled C-Code) and CVODE
• Which integrator algorithm are you using?
  All these are BDF-methodes
• Which version of the MSL are you using?
  MSL 4.0 and MSL 4.1

Some results:
CVODE:
tolerance 1e-10: -> -14.1133
tolerance 1e-11: -> -14.1233
both BDF:
tolerance 1e-9: -> -14.2509
tolerance 1e-10: -> -14.1437
tolerance 1e-11: convergence problem (Newton-updates are to big)

[AHaumer]

Let me explain what happens:
The current in the windings and therefore the Clark-transformed space phasor w.r.t. the stator-fixed coordinate system is impressed.
The transformation to the rotor-fixed coordinate system depends on the mechanical angle imc.phiMechanical.
The dependency of imc.phiMechanical on Tolerance is rather weak.
But if the angle is either near npi or pi/2+npi either sine or cosine change significantly even with small changes of the angle.
Therefore currents w.r.t. the rotor-fixed coordinate system shouldn't be used for comparison, especially only comparing final values.
I think we should't change the Tolerance (with could be dependent on the algorithm, the tool, ...)
@uschna do you agree?

Thanks to @johhell another problem was detected - no idea why this didn't some uo during the last tests:
This example won't simulate in OpenModelica.
I have prepared an adapted version - see enclosed. @uschna could you please test?
Then I would prepare a PR.
BTW we are searching for MAP-Lib members which are willing to review PRs.

[uschna]

@AHaumer: Sorry for my bad English.

I think we should't change the Tolerance (with could be dependent on the algorithm, the tool, ...) @uschna do you agree?

In the theory: For smaller tolerances the results in the different algorithm and tools are approximately the same. For bigger tolerances the results are more different. That's why I think we should choose the tolerances small enough.

I have prepared an adapted version - see enclosed. @uschna could you please test?

Where can I find the adapted version?
Thank you for your answer.

[AHaumer]

@ushna
Yes but different algorithms react differently on changing the tolerance.
So you might get a satisfying result with one algorithm and a certain tolerance, but with another algorithm you need tighter tolerance. Consodering different tools and different algorithms I'm against changing the tolerance. Especially if this is driven by comparing a final value and if the comparison signal is not appropriate.
Sorry I did'nt upload the zip.

IMC_DC_Braking.zip

[uschna]

@AHaumer: Thank you.

So you might get a satisfying result with one algorithm and a certain tolerance, but with another algorithm you need tighter tolerance.

This is in general true. But in the specific case all tools have the same problem, that the tolerance are to big. That means, the results are changing for smaller tolerances.

Especially if this is driven by comparing a final value and if the comparison signal is not appropriate.

I'm agree, that it is also possible to change, which variables are result variables.

[uschna]

Sorry I did'nt upload the zip.

@AHaumer: Thank you. But I didn't find the new IMC_DCBraking.csv-file (and also the new comparisonSignals.txt) in the zip-file. Which results are the reference results?
Thank you for your answer.

[AHaumer]

@uschna ok here's my proposal with the new comparisonSignals and the new ReferenceResults.

IMC_DCBraking.zip

[uschna]

Dear @AHaumer,
thank you. I understand, this is the new model, not the model for the environment Modelica.Electrical.Machines.Examples.InductionMachines:

• within ;
  instead of
  within Modelica.Electrical.Machines.Examples.InductionMachines;
• record DcBrakeSettings
  instead of
  Modelica.Electrical.Machines.Utilities.DcBrakeSettings
  and so on.

It is easier for me when you also send me the variant for the environment Modelica.Electrical.Machines.Examples.InductionMachines.
Thank you.