MSL 4.1.0 Regressions - Electrical and ComplexBlocks

[GallLeo]

The following models fail in result comparison.
Tested revision: f9bddf8 (2024-02-16)

Changed models, need reference update after library officer check:

• Modelica.Electrical.Machines.Examples.ControlledDCDrives.CurrentControlledDCPM
  - Reason: Erroneous initialization of armatureInverter.iDCFilter has been fixed.
  @GallLeo pls. create new reference results.
  - Updated reference files?
• Modelica.Electrical.Machines.Examples.ControlledDCDrives.PositionControlledDCPM
  - Reason: Erroneous initialization of armatureInverter.iDCFilter has been fixed.
  @GallLeo pls. create new reference results.
  - Updated reference files?
• Modelica.Electrical.Machines.Examples.ControlledDCDrives.SpeedControlledDCPM
  - Reason: Erroneous initialization of armatureInverter.iDCFilter has been fixed.
  @GallLeo pls. create new reference results.
  - Updated reference files?
• Modelica.Electrical.PowerConverters.Examples.DCAC.PolyphaseTwoLevel.ThreePhaseTwoLevel_PWM
  - Reason: Bugfix in Modelica.Electrical.PowerConverters.DCAC.Control.SVPWM
  @GallLeo pls. create new reference results.
  - Updated reference files?
• Modelica.Electrical.PowerConverters.Examples.DCAC.SinglePhaseTwoLevel.SinglePhaseTwoLevel_R
  - Note: does not fail in csv-compare, but in integral check for inverter.ac.v
  - Reason: Changed formulation of comparison in Modelica.Electrical.PowerConverters.DCDC.Control.SignalPWM
  @GallLeo pls. create new reference results.
  - Updated reference files?
• Modelica.Electrical.PowerConverters.Examples.DCDC.HBridge.HBridge_R
  - Reason: Changed formulation of comparison in Modelica.Electrical.PowerConverters.DCDC.Control.SignalPWM
  @GallLeo pls. create new reference results.
  - Updated reference files?
• Modelica.Electrical.Spice3.Examples.Spice3BenchmarkFourBitBinaryAdder
  - Reason: Model has not been touched for ages, differences are neglectible.
  @GallLeo pls. create new reference results.
  - Updated reference files?
• Modelica.ComplexBlocks.Examples.ShowTransferFunction
  - Reason: Changed the parameters of the example to get more eye-catching results.
  @GallLeo pls. create new reference results.
  - Updated reference files?

Not classified yet, needs library officer check:

• Modelica.Electrical.Machines.Examples.InductionMachines.IMC_InverterDrive
  - Reason: Bugfix in Modelica.Electrical.PowerConverters.DCAC.Control.SVPWM
  @GallLeo pls. create new reference results.
  - Updated reference files?

• @GallLeo please note: We have improved the comparisonSignals.txt in PR comparisonSignals of PowerConverters #4353 of Modelica.Electrical.PowerConverters.Examples.DCDC.HBridge.{HBridge_R, HBridge_RL, HBridge_DC_Drive}, also back-ported to maint/4.1.x in comparisonSignals of PowerConverters #4372.
  Please create new reference results for all three examples.

• Release notes check: Are all classes mentioned which could lead to result changes in user models?

---

Useful Links

Current comparison report:
https://www.ltx.de/download/MA/Compare_MSL_v4.1.0/comparison_report_overview.html
-> Reference result test -> Comparison

Comparison signal definitions:
https://github.com/modelica/ModelicaStandardLibrary/tree/master/Modelica/Resources/Reference/Modelica
https://github.com/modelica/ModelicaStandardLibrary/tree/master/ModelicaTest/Resources/Reference/ModelicaTest

Reference results:
https://github.com/modelica/MAP-LIB_ReferenceResults

[maltelenz]

@GallLeo please note: We have improved the comparisonSignals.txt in PR #4353 of Modelica.Electrical.PowerConverters.Examples.DCDC.HBridge.{HBridge_R, HBridge_RL, HBridge_DC_Drive}
Please create new reference results for all three examples.

@AHaumer The LTX run actually shows a correctness failure in Modelica.Electrical.PowerConverters.Examples.DCDC.HBridge.HBridge_DC_Drive for the variable meanCurrent.y, so that should be checked specifically before resetting the baseline to get the new variables.

[AHaumer]

@maltelenz @GallLeo
The only difference I see is at the beginning of the trajectory of meanCurrent,y.
This is caused from improvements in the block SignalPWM.
Yes the new signal is correct, and please take the new signal as reference for the future.

[GallLeo]

Regressions not mentioned in this ticket:

1. Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator

2. Modelica.Electrical.Machines.Examples.SynchronousMachines.SMPM_NoLoad

Should they also get new references @AHaumer ?

Current comparison report:
https://www.ltx.de/download/MA/Compare_MSL_v4.1.0/Compare/Modelica/testrun_report.html

[maltelenz]

2. Modelica.Electrical.Machines.Examples.SynchronousMachines.SMPM_NoLoad

This model was already reported in #4363

[AHaumer]

@GallLeo

1. Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator
   opAmp1.out.v is a bad signal for comparison: only spikes.
   I suggest to remove opAmp1.out.v from comparisonSignals.txt and generate new reference results.

OUTDATED see below

[AHaumer]

@GallLeo
2. Modelica.Electrical.Machines.Examples.SynchronousMachines.SMPM_NoLoad
I admit details both of the model and the comparisonSignals.txt have been changed.
Please generate new reference results - thank you.

[AHaumer]

@GallLeo Regarding the timeout of Modelica.Electrical.Machines.Examples.InductionMachines.IMC_YD:
I have no idea why the example takes so long to simulate with tolerance/10.
It seems that something goes wrong with the iteration when the machine is switched on at time = 0,1 s:

@casella Could we keep the original tolerance for comparison?
@christiankral should we loosen the "normal" tolerance to 1e-5 so that the comparison tolerance gets 1e-6 and this works well?
I see no big difference in the results with tolerance = 1e-5 and tolerance = 1e-6.

[AHaumer]

I tried to analyze the problem a little bit:
Problems with Modelica.Magnetic.QuasiStatic.FundamentalWave.Examples.BasicMachines.InductionMachines.IMC_YD is due to the fact that this example compares a QuasiStatic machine with a dynamic/transient one.
The example Modelica.Electrical.Machines.InductionMachines.IMC_YD shows no problems.
It seems that the problems stem from a combination of Modelica.Electrical.Polyphase.Ideal.IdealClosingSwitch and Modelica.Magnetic.FundamentalWave.BasicMachines.InductionMachines.IM_SquirrelCage.
If I remove the IdealCLosingSwitch from the example (i.e. the machine is switched on at time = 0), we encounter no problmes with tighter tolerance.
I'll analyze a little bit more with a different implementation of the switch to avoid the problems.

[AHaumer]

Another quick solution:
Change the parameters of the idealCloser to Ron=1e-4 and Goff 1e-4 (both default 1e-5) and the example runs like a charm with tolerance 1e-6 and tolerance = 1e-7.
There's only negligible deviation in the results, mainly the current before the switch is closed grows from 0.5 mA by a factor of 10.
One more fact: With original parameters, the example simulates fine with OM and Dymola if you choose Algorithm = Cvode even with tolerance=1e-7.
@christiankral what's your opinion, what should we do?
@HansOlsson do you have an idea about the reason for this weird behavior (timeout with tolerance 1e-7)?

[christiankral]

I am in favor of keeping the original simulation tolerances and switch paramerers. If switching the simulation algorithm to cvode solves the issue, this is my preferred the way to go.

If we would reduce simulation tolerances and switch parameters instead, the following question arises: Why not change these tolerances and paramerers throughout the entire MSL, if we can live with less accuracy...

[casella]

I'm also definitely in favour of updating the parameters. We should not include in the MSL examples that are numerically challenged.

Regarding switching the simulation algorithm, unfortunately we don't have the standardized annotations to do so, only vendor-specific annotations. This should probably be discussed at some point, as there are some models that need certain kind of solvers to be simulated efficiently. For example, flexible multibody models have very fast and very poorly damped eigenvalues, which don't work well with the stability region of BDF codes like DASSL, which is horribly slow as it needs to take very small steps to avoid going unstable. Implicit Runge-Kutta algorithms such as RADAU instead work very well.

The question is, do we standardize individual solvers? Categories of solvers, such as implicit/explicit, single-step, multi-step? That's still unclear to me. Anyway, topic for another ticket 😃

[casella]

Regarding the first issue with Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator, opAmp1.out.v should not have any spikes at all. This is the result obtained with OpenModelica:

which looks like a perfectly legitimate square wave between the two supply voltage levels. I'm not sure what is going on with the regression testing infrastructure, but there is for sure some issue there. Removing opAmp1.out.v doesn't seem like a good idea to me.

[GallLeo]

Regressions not mentioned in this ticket:

1. Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator

2. Modelica.Electrical.Machines.Examples.SynchronousMachines.SMPM_NoLoad

Should they also get new references @AHaumer ?

Current comparison report: https://www.ltx.de/download/MA/Compare_MSL_v4.1.0/Compare/Modelica/testrun_report.html

Status:

1. Waiting for concensus between @casella and @AHaumer

2. New reference is pushed.

[AHaumer]

@casella you are right, I was mistaken. OM is correct, Dymola seems to have a problem with this example!
@GallLeo Let's keep the comparisonSignals.txt.
I have to investigate a little bit more in the evening, especially the influence of the parameter strict on the Advanced tab.

[HansOlsson]

Regarding the first issue with Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator, opAmp1.out.v should not have any spikes at all.

How do you know that for the Modelica model?

After investigation: in Dymola it depends on how smooth is handled.

Importantly it is not an error in the automatic handling of smooth since:

• Enabling events for smooth generates a solution without spikes (some warnings for convergence issues). Similar result as in OpenModelica.
• Disabling events for smooth (i.e., treating it as noEvent) generates a solution with spikes, and some warnings for failures to solve non-linear systems of equations for dassl and just a failure for other solvers. Similar result as reference.

With events you also get two events very close together; which might indicate another numerical issue.

The reason to have smooth in the model is that in some other operating mode the OpAmp might change back and forth a lot, and you don't want events for that.

My estimate is that in reality such a model has some extra part (capacitance, inductance) that is missing from this model - and that extra part avoids the issue.

[AHaumer]

For me it seems that the parameter {opAmp1, opAmp2}.strict (on the Advanced tab) has a great influence.
With strict = false the Dymola result is nonsense, with strict = true it seems correct to me.
With both strict = true and strict = false the OM result is not correct:

I suggest the following:

• Keep the comparisonSignals.txt
• Set {opAmp1, opAmp2}.strict: I'll prepare a PR: see MSL 4.1.0 Regressions: OpAmps/SignalGenerator #4485
• Compare the results again and if necessary generate new reference results

[HansOlsson]

Another quick solution: Change the parameters of the idealCloser to Ron=1e-4 and Goff 1e-4 (both default 1e-5) and the example runs like a charm with tolerance 1e-6 and tolerance = 1e-7. There's only negligible deviation in the results, mainly the current before the switch is closed grows from 0.5 mA by a factor of 10. One more fact: With original parameters, the example simulates fine with OM and Dymola if you choose Algorithm = Cvode even with tolerance=1e-7. @christiankral what's your opinion, what should we do? @HansOlsson do you have an idea about the reason for this weird behavior (timeout with tolerance 1e-7)?

The problem seems to be the state imc.stator.zeroInductor.i0, increasing its nominal value to 10 avoids the issue for tolerance 1e-7 and dassl.

That signal looks like a very small sine-signal with period 0.02 s (or 50 Hz), as if it is caused by some residual current. I have not analyzed that further.

[AHaumer]

The problem seems to be the state imc.stator.zeroInductor.i0, increasing its nominal value to 10 avoids the issue for tolerance 1e-7 and dassl.
That signal looks like a very small sine-signal with period 0.02 s (or 50 Hz), as if it is caused by some residual current. I have not analyzed that further.
@HansOlsson indeed this signal should be zero but isn't due to numerical inaccuracy.
I'll check your solution. How would it work for other simulators?
Ok checked the specification. The nominal attribute is a common definition, and it works!
I'll prepare a PR: #4486

[casella]

Regarding the first issue with Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator, opAmp1.out.v should not have any spikes at all.

How do you know that for the Modelica model?

I don't know it from the Modelica. I know that from the physics: this circuit has +/- 15 V supply, so the output voltage of the op-amp shall be within that range.

Whether this is a tool issue or a modelling issue I also don't know, but for certain resolving the issue (whatever it is) by removing the signal from the set of references is a classical dirt-under-the-carpet action I wouldn't recommend 😃