Added more options for homotopy-based initialization of limiters #2561

casella · 2018-05-29T15:32:41Z

With MSL 3.2.2, the behaviour of limiters in the Modelica.Blocks library was slightly changed, so that if homotopy-based initialization was used, a linear behaviour y = u was always assumed.

Although this obviously makes the simplified model more linear, and thus potentially easier to solve, it can be problematic if the model receiving the output of the limiter breaks for values outside the limiting range and one still wants to use homotopy.

Also, in some cases it is known a priori that in the initial conditions the output of the limiter is stuck at the upper or lower limit. In this case, it is much better to use y = uMin or y = uMax as output in the simplified model.

This pull requests solves all these issues by allowing to choose among several options that span all these cases, using an enumeration parameter in the Advanced tab.

The change is 100% backwards compatible, as the behaviour with the default values of the newly added parameters is exactly the same as with MSL 3.2.2

close #2270

AHaumer

Fine for me, looks good.

beutlich

I general, this looks like a relevant enhancement.

I am not sure if we really should push this in MSL v3.2.3 now, especially since we added homotopy in Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator (see #2017 and my commit 9d5bc99).

beutlich · 2018-05-29T18:57:50Z

Modelica/Blocks/Nonlinear.mo

+<li><code>noHomotopy</code>: the actual expression with limits is used</li>
+<li><code>linear</code>: a linear behaviour y = u is assumed (default option)</li>
+<li><code>uMax</code>: it is assumed that the output is stuck at the upper limit u = uMax</li>
+<li><code>uMin</code>: it is assumed that the output is stuck at the lower limit u = uMax</li>


Should read u = uMin.

Of course, that was a stupid copy&paste mistake

beutlich · 2018-05-29T18:59:05Z

Modelica/Blocks/Types.mo

+      linear "Simplified model: y = u",
+      fixed "Simplified model: y = ySimplified")
+    "Enumeration defining use of homotopy in variable limiter components" annotation (Evaluate=true);
+


Should these enumeration alternatives start with a capital letter?

Sure, will do

beutlich · 2018-05-30T13:43:57Z

Rescheduling milestone since MSL v3.2.3 is feature-complete, i.e., no more enhancements are allowed. Furthermore, test models for the other homotopy options are required.

casella · 2018-05-30T14:04:53Z

@beutlich I pushed in the fixes you requested.

Regarding your comment concerning #2017, I'm not sure I get your point. Please note this PR is not adding homotopy to the component, it is just fixing the way homotopy was already introduced in MSL 3.2.2, which actually broke some models in a way that was not possible to fix (so it was not really backwards compatible with MSL 3.2.1). With these changes, it is possible to get models that ran in MSL 3.2.1 to run again by just changing one parameter.

For the above-mentioned reasons, I do not consider this PR an enhancement, but rather a bug fix. We had models that ran in MSL 3.2.1 (and used homotopy for other components) and stopped running in MSL 3.2.2 because the new implementation in there using homotopy cannot have limits enforced, so it breaks stuff downstream the limiter. Unfortunately these models are confidential, so I cannot share them. I can open a specific ticket about that, though I thought the explanation of this PR was enough motivation. Maybe that was not clear enough, my fault.

So, I hope you can reconsider your decision to reschedule the milestone.

Regarding tests with the homotopy feature, I can provide them by next week.

beutlich · 2018-05-31T06:01:21Z

@casella Thanks for exaplanation that this PR rather is considered to be a bug-fix. In that case it is valid to be included in the MSL v3.2.3. Please provide a test model (for ModelicaTest.Blocks).

I still believe, we also should add the homotopy choices to the limiter in Modelica.Electrical.Analog.Ideal.IdealizedOpAmpLimted. What do you think?

casella · 2018-06-04T21:04:08Z

@beutlich, I added the requested test cases to ModelicaTest in bc99284. Can you proceed?

beutlich · 2018-06-05T07:13:37Z

@casella

What about the limiter in Modelica.Electrical.Analog.Ideal.IdealizedOpAmpLimted?
What about the limiter in Modelica.Electrical.Analog.Ideal.IdealOpAmpLimited?
And what about the limiter in Modelica.Blocks.Continuous.LimPID? Should the homotopyType be made available as parameter?

casella · 2018-06-05T13:34:01Z

@beutlich, regarding IdealizedOpAmpLimited and IdealOpAmpLimited,

These models not only include a saturation on the output voltage, but they also change the relationship between the input voltages according to that. Basically, if the output voltage is not saturated, then the two input voltage are bound to be equal, otherwise they are not. As you can see, this involves an auxiliary variable s. The logic is a bit the same as the one of the ideal diode.

I'm not sure how this model could be improved by using homotopy, because I'm not an expert of electrical models (my degree in electronic engineering is now almost 25 years old...). Anyway, it's way beyond the scope of this PR, which is only meant to provide Limiter blocks that can be used with homotopy.

casella · 2018-06-05T13:36:27Z

@beutlich, regarding LimPID, I guess propagating homotopyType is a good idea. I'lll do that and build a couple of test cases then I'll get back to you

casella · 2018-06-05T14:15:16Z

In fact, LimPID is still using the obsolete limitsAtIniti parameter, which is propagated to the limiter but actually not used sinces 3.2.2. I'll move that to a Dummy tab as for Limiter and put homotopyType instead

AHaumer · 2018-06-05T14:53:30Z

I agree wirh Francesco, Ideal(ized)OpAmpLimited need some more investigation.
Shift that issue to the next release.

AHaumer · 2018-06-05T14:55:05Z

Regarding the LimPID (which is a commonly used block) I apperciate Franseco's idea propagating homotopyType.

casella · 2018-06-05T15:13:29Z

Updated implementation of LimPID and added relevant test cases to ModelicaTest in 153352f.
Also updated the documentation of LimPID.

MartinOtter

Nice and useful improvement.

beutlich · 2018-06-05T19:00:05Z

I do not quite understand why there are two enumeration types InitPIDHomotopy and LimiterHomotopy with the same semantics of the alternatives. I'd simply reuse LimiterHomotopy in LimPID and generalize the alternative names and descriptions, say NoHomotopy, Linear, UpperLimit, LowerLimit.

casella · 2018-06-06T09:19:49Z

@beutlich I just could not find general enough names for the enumeration, but I guess your idea is good. I'll take care of that later today.

casella · 2018-06-07T15:57:43Z

@beutlich do we need another review? I lost track after so many changes

dietmarw · 2018-06-07T16:51:15Z

Yes by either @AHaumer or @MartinOtter

beutlich · 2018-06-11T20:56:59Z

@HansOlsson 9d7df7b and 68f1beb should fix the Modelica.Electrical.Analog.Examples.OpAmps.Multivibrator issue of #2270 (comment) while still generating events for Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator (see #2017). Can you please cross-check and give your review.

beutlich · 2018-06-13T06:49:27Z

@HansOlsson Can you please check if this fixes all examples in Modelica.Electrical.Analog.Examples.OpAmps?

HansOlsson

All of the MSL-models using the model now works (also with homotopy).

However, to make it more backwards compatible I would prefer that strict was as default true - corresponding to the previous version.

beutlich · 2018-06-13T11:21:51Z

I would prefer that strict was as default true - corresponding to the previous version.

You mean the IdealizedOpAmpLimted.strict?

HansOlsson · 2018-06-13T11:23:29Z

You mean the IdealizedOpAmpLimted.strict?

Yes; having it as default true would mean that we as default had the same semantics as in 3.2.2.

beutlich · 2018-06-13T11:26:16Z

Yes; having it as default true would mean that we as default had the same semantics as in 3.2.2.

And touch each of the examples to have strict modified to false, at least if we want to see events (as in Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator)?

HansOlsson · 2018-06-13T11:30:05Z

And touch each of the example to have strict modified to false, at least if we want to see events (as in Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator)?

I would skip that for the examples in MSL - since I the events are not needed.
However, the external code that triggered the change should have strict=false.

beutlich · 2018-06-13T11:31:32Z

According to #2017, Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator should generate events, right? Thus strict=false.

HansOlsson · 2018-06-13T11:41:41Z

According to #2017, Modeling of Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator, Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator should generate events, right? Thus strict=false.

According to that issue, yes, but based on the problem we had with examples in MSL I thought that backwards compatibility was more important, so to get #2017 to run you set strict=false.

* Restore MSL 3.2.2 behaviour, i.e., without events * Force events for SignalGenerator example model

HansOlsson

Looks good.

casella requested review from beutlich and MartinOtter May 29, 2018 15:32

dietmarw requested a review from AHaumer May 29, 2018 15:39

dietmarw added the L: Blocks Issue addresses Modelica.Blocks label May 29, 2018

dietmarw added this to the MSL3.2.3 milestone May 29, 2018

AHaumer previously approved these changes May 29, 2018

View reviewed changes

beutlich added the enhancement New feature or enhancement label May 29, 2018

beutlich requested changes May 29, 2018

View reviewed changes

beutlich modified the milestones: MSL3.2.3, MSL_next-MAJOR-version May 30, 2018

casella dismissed AHaumer’s stale review via ba19809 May 30, 2018 13:52

dietmarw modified the milestones: MSL_next-MAJOR-version, MSL3.2.3 May 31, 2018

dietmarw removed the enhancement New feature or enhancement label May 31, 2018

dietmarw mentioned this pull request Jun 5, 2018

Remove obsolete parameter "limitsAtInit" #2590

Closed

MartinOtter previously approved these changes Jun 5, 2018

View reviewed changes

beutlich dismissed MartinOtter’s stale review via ebec89b June 5, 2018 18:53

beutlich previously approved these changes Jun 6, 2018

View reviewed changes

This was referenced Jun 11, 2018

IdealizedOpAmpLimted has issues #2270

Closed

Missing test or example model for Modelica.Electrical.Analog.Ideal.IdealOpAmpLimited #2608

Closed

beutlich added 2 commits June 11, 2018 21:16

Enable/disable parameter ySimplified

ef3225b

Consistently have strict parameter in Advanced tab

d3a7c13

beutlich dismissed their stale review via d3a7c13 June 11, 2018 19:19

beutlich self-assigned this Jun 11, 2018

beutlich added 2 commits June 11, 2018 22:48

Add homotopy-based initialization for IdealizedOpAmpLimted

9d7df7b

Update examples utilizing IdealizedOpAmpLimted

68f1beb

beutlich requested a review from HansOlsson June 11, 2018 20:57

beutlich added the L: Electrical.Analog Issue addresses Modelica.Electrical.Analog label Jun 11, 2018

HansOlsson reviewed Jun 13, 2018

View reviewed changes

Set IdealizedOpAmpLimted.strict to true as default

a4083f2

* Restore MSL 3.2.2 behaviour, i.e., without events * Force events for SignalGenerator example model

HansOlsson approved these changes Jun 13, 2018

View reviewed changes

beutlich approved these changes Jun 13, 2018

View reviewed changes

beutlich merged commit e5947aa into modelica:master Jun 13, 2018

beutlich added the L: ModelicaTest Issue addresses ModelicaTest, ModelicaTestConversion4 or ModelicaTestOverdetermined label Jun 13, 2018

casella deleted the LimiterHomotopy branch June 13, 2018 21:13

beutlich mentioned this pull request Apr 9, 2019

Remove unused initialization parameters from limiter blocks and DeadZone #2891

Merged

maltelenz mentioned this pull request Oct 22, 2024

MSL 4.1.0 Regressions: OpAmps/SignalGenerator #4485

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added more options for homotopy-based initialization of limiters #2561

Added more options for homotopy-based initialization of limiters #2561

casella commented May 29, 2018 •

edited by beutlich

Loading

AHaumer left a comment

beutlich left a comment

beutlich May 29, 2018

casella May 30, 2018

beutlich May 29, 2018

casella May 30, 2018

beutlich commented May 30, 2018

casella commented May 30, 2018

beutlich commented May 31, 2018 •

edited

Loading

casella commented Jun 4, 2018

beutlich commented Jun 5, 2018 •

edited

Loading

casella commented Jun 5, 2018

casella commented Jun 5, 2018

casella commented Jun 5, 2018

AHaumer commented Jun 5, 2018

AHaumer commented Jun 5, 2018

casella commented Jun 5, 2018

MartinOtter left a comment

beutlich commented Jun 5, 2018 •

edited

Loading

casella commented Jun 6, 2018

casella commented Jun 7, 2018

dietmarw commented Jun 7, 2018

beutlich commented Jun 11, 2018 •

edited

Loading

beutlich commented Jun 13, 2018

HansOlsson left a comment

beutlich commented Jun 13, 2018

HansOlsson commented Jun 13, 2018

beutlich commented Jun 13, 2018 •

edited

Loading

HansOlsson commented Jun 13, 2018

beutlich commented Jun 13, 2018

HansOlsson commented Jun 13, 2018

HansOlsson left a comment

Added more options for homotopy-based initialization of limiters #2561

Added more options for homotopy-based initialization of limiters #2561

Conversation

casella commented May 29, 2018 • edited by beutlich Loading

AHaumer left a comment

Choose a reason for hiding this comment

beutlich left a comment

Choose a reason for hiding this comment

beutlich May 29, 2018

Choose a reason for hiding this comment

casella May 30, 2018

Choose a reason for hiding this comment

beutlich May 29, 2018

Choose a reason for hiding this comment

casella May 30, 2018

Choose a reason for hiding this comment

beutlich commented May 30, 2018

casella commented May 30, 2018

beutlich commented May 31, 2018 • edited Loading

casella commented Jun 4, 2018

beutlich commented Jun 5, 2018 • edited Loading

casella commented Jun 5, 2018

casella commented Jun 5, 2018

casella commented Jun 5, 2018

AHaumer commented Jun 5, 2018

AHaumer commented Jun 5, 2018

casella commented Jun 5, 2018

MartinOtter left a comment

Choose a reason for hiding this comment

beutlich commented Jun 5, 2018 • edited Loading

casella commented Jun 6, 2018

casella commented Jun 7, 2018

dietmarw commented Jun 7, 2018

beutlich commented Jun 11, 2018 • edited Loading

beutlich commented Jun 13, 2018

HansOlsson left a comment

Choose a reason for hiding this comment

beutlich commented Jun 13, 2018

HansOlsson commented Jun 13, 2018

beutlich commented Jun 13, 2018 • edited Loading

HansOlsson commented Jun 13, 2018

beutlich commented Jun 13, 2018

HansOlsson commented Jun 13, 2018

HansOlsson left a comment

Choose a reason for hiding this comment

casella commented May 29, 2018 •

edited by beutlich

Loading

beutlich commented May 31, 2018 •

edited

Loading

beutlich commented Jun 5, 2018 •

edited

Loading

beutlich commented Jun 5, 2018 •

edited

Loading

beutlich commented Jun 11, 2018 •

edited

Loading

beutlich commented Jun 13, 2018 •

edited

Loading