Fix interpretation of coefficients of complex transfer function #3733

christiankral · 2021-01-24T13:31:34Z

AHaumer

Again we have the problem that the bugfix is not backwards compatible.
I'd suggest to:

leave the old implementatio unchanged and mark it as obsolete
move Christian's implemenatition to a new block
explain the situation in the documentation

dietmarw · 2021-02-22T08:26:16Z

Also here my comment. If it is a bugfix then something was calculated wrongly before and need to be fixed. It would be very strange that we "fix" bugs by introducing new models and keep the buggy models around. That is if it is a clear bug and not just a different interpretation of the implementation.

beutlich · 2021-02-22T08:27:39Z

I agree with @dietmarw here. Bugfixes shall be fixed in place and documented in the revision annotation. I also doubt that anyone used such a function if it was plainly wrong.

christiankral · 2021-03-08T17:10:40Z

OK. The block will not be renamed or marked as obsolete: The bug fix will be implemented and documented.

CLAassistant · 2021-03-08T17:13:33Z

All committers have signed the CLA.

christiankral · 2021-03-08T17:16:16Z

@beutlich Why is it asking again for signing the CLA? I just signed it at #3742 (comment)

beutlich · 2021-03-09T08:01:24Z

@beutlich Why is it asking again for signing the CLA? I just signed it at #3742 (comment)

Because you (accidently ?) committed as Christian Kral <christian@Yogix>. I will squash all commits as one later.

christiankral · 2021-03-09T08:18:44Z

@beutlich Why is it asking again for signing the CLA? I just signed it at #3742 (comment)

Because you (accidently ?) committed as Christian Kral <christian@Yogix>. I will squash all commits as one later.

Thanks for the hint. This happened accidentally. For some reason my git user.name and user.email got lost...

beutlich · 2021-03-17T17:25:54Z

I will squash all commits as one later.

Done. I also resolved the merge conflict of #3677 and HTML tag error when rebasing. Please check again.

christiankral · 2021-03-17T17:44:39Z

@beutlich Thanks for fixing the merge conflict. On my opinion the performed changes look all good.

beutlich · 2021-03-17T18:29:16Z

Modelica/ComplexBlocks/Examples/ShowTransferFunction.mo

-  parameter Real d=1/sqrt(2) "Damping coefficient";
-  parameter Real b[:]={1} "Numerator polynomial coefficients of the transfer function";
-  parameter Real a[:]={1,2*d,1} "Denominator polynomial coefficients of the transfer function";
+  parameter Real d=0.01 "Damping coefficient in kg/s (not the damping ratio)";


Would it als work if physical units are used actually instead of type Real?

changed my mind after discussion

christiankral · 2021-05-23T10:12:28Z

@HansOlsson Is it legal Modelica code to use different units in the elements of vector a?

  parameter Real d(unit = "kg/s")=0.01 "Damping coefficient in kg/s (not the damping ratio)";
  parameter Modelica.Units.SI.Mass m=0.2 "Mass in kg";
  parameter Modelica.Units.SI.TranslationalSpringConstant c=0.1 "Stiffness in N/m";
  parameter Real b[:]={-m} "Numerator polynomial coefficients {-m} of the transfer function";
  parameter Real a[:]={m,d,c} "Denominator polynomial coefficients {m,d,c} of the transfer function";

It, however, does check and simulate OK in Dymola.

HansOlsson · 2021-05-24T06:28:20Z

@HansOlsson Is it legal Modelica code to use different units in the elements of vector a?

Yes. Whether it is good style is another issue.

  parameter Real d(unit = "kg/s")=0.01 "Damping coefficient in kg/s (not the damping ratio)";
  parameter Modelica.Units.SI.Mass m=0.2 "Mass in kg";
  parameter Modelica.Units.SI.TranslationalSpringConstant c=0.1 "Stiffness in N/m";
  parameter Real b[:]={-m} "Numerator polynomial coefficients {-m} of the transfer function";
  parameter Real a[:]={m,d,c} "Denominator polynomial coefficients {m,d,c} of the transfer function";

It, however, does check and simulate OK in Dymola.

The specification does not make it illegal, and you could even explicitly create vectors with different unit elements in Modelica like: parameter Real a[3](unit={"kg","kg/s","kg.s-2"}); although Dymola currently ignores the unit in that case.

henrikt-ma · 2021-05-24T07:09:59Z

The specification does not make it illegal, and you could even explicitly create vectors with different unit elements in Modelica like: parameter Real a[3](unit={"kg","kg/s","kg.s-2"}); although Dymola currently ignores the unit in that case.

While the specification doesn't make it illegal today, we also know that the specification is rather incomplete when it comes to defining a system for unit handling that would give tools the necessary foundation to reject models with unclear/erroneous unit consistency. Hence, I think one should at least be prepared that arrays with heterogenous unit could be something we'll be forced to drop support for once we take on unit checking more seriously.

If one really wants to do transfer functions with units in a future-proof way, I have no better idea than making a fixed order wrapper model with only scalar coefficients that takes care of all the units, with the actual dynamics internally implemented using a unit-less transfer function.

christiankral · 2021-05-24T16:04:59Z

@beutlich I suggest to keep the implementation with Real parameters then. OK?

beutlich · 2021-05-24T16:56:02Z

A third option to unitless parameters or array with heterogenous unit would be something like:

parameter Real d(unit = "kg/s")=0.01 "Damping coefficient in kg/s (not the damping ratio)";
parameter Modelica.Units.SI.Mass m=0.2 "Mass in kg";
parameter Modelica.Units.SI.TranslationalSpringConstant c=0.1 "Stiffness in N/m";
final parameter oneReciprocalDamping(unit="s/kg") = 1;
final parameter oneReciprocalMass(unit="kg-1") = 1;
final parameter oneReciprocalSpringConstant(unit="m/N") = 1;
parameter Real a[:]={m*oneReciprocalMass, d*oneReciprocalDamping, c*oneReciprocalSpringConstant}
  "Unitless denominator polynomial coefficients {m,d,c} of the transfer function";

I think this is the cleanest Modelica can offer for now.
I also propose to utilize TranslationalDampingConstant for d.

henrikt-ma · 2021-05-24T23:36:45Z

I think this is the cleanest Modelica can offer for now.

Looks like a splendid place to use final constant instead of final parameter, doesn't it?

beutlich · 2021-05-25T05:43:29Z

Right, here's a nicer proposal, inspired from

ModelicaStandardLibrary/Modelica/Electrical/Analog/Examples/Utilities/SwitchedCapacitor.mo

Lines 29 to 30 in 39fe805

    
           protected 
        
             constant SI.Resistance oneOhm=1 "Helping constant to satisfy unit check";

:

  parameter Modelica.Units.SI.Mass m = 0.2 "Mass in kg";
  parameter Modelica.Units.SI.TranslationalDampingConstant d = 0.01 "Damping coefficient in kg/s (not the damping ratio)";
  parameter Modelica.Units.SI.TranslationalSpringConstant c = 0.1 "Stiffness in N/m";
protected
  constant Modelica.Units.SI.Mass oneKilogram = 1
    "Helping constant to satisfy unit check";
  constant Modelica.Units.SI.TranslationalDampingConstant oneUnitDampingConstant = 1
    "Helping constant to satisfy unit check";
  constant Modelica.Units.SI.TranslationalSpringConstant oneUnitSpringConstant = 1
    "Helping constant to satisfy unit check";
public
  final parameter Real a[:]={m/oneKilogram, d/oneUnitDampingConstant, c/oneUnitSpringConstant}
    "Unitless denominator polynomial coefficients {m,d,c} of the transfer function";

henrikt-ma · 2021-05-25T06:45:31Z

Right, here's a nicer proposa, inspired from

Yes, this is nicer. Still, in principle, these constants should also be final, as they shouldn't even be modified in derived classes. Of course, I can also see that the need for final is much bigger when dealing with public elements.

christiankral · 2021-05-31T19:32:37Z

OK, I will implement @beutlich's proposal then.

Modelica/ComplexBlocks/Examples/ShowTransferFunction.mo

Co-authored-by: Thomas Beutlich <modelica@tbeu.de>

beutlich

Please also update the table of critical errors in Modelica.UsersGuide.ReleaseNotes.Version_X_Y_0. Thanks.

christiankral self-assigned this Jan 24, 2021

christiankral added bug Critical/severe issue L: Complex* Issue addresses Complex, Modelica.ComplexBlocks or Modelica.ComplexMath labels Jan 24, 2021

christiankral requested review from AHaumer and beutlich January 24, 2021 13:53

christiankral linked an issue Jan 24, 2021 that may be closed by this pull request

Complex transfer function block uses wrong order of coefficients #3651

Closed

christiankral mentioned this pull request Feb 5, 2021

Do not fail for w<=0 in Complex TransferFunction #3677

Merged

AHaumer previously requested changes Feb 21, 2021

View reviewed changes

christiankral marked this pull request as ready for review March 8, 2021 17:20

christiankral requested a review from AHaumer March 8, 2021 17:21

beutlich force-pushed the fix-complex-transferfunction branch from fe2c9b6 to 08c88c9 Compare March 17, 2021 17:24

Fix bug in calculation of complex transfer function

ab5b5fb

beutlich force-pushed the fix-complex-transferfunction branch from 08c88c9 to ab5b5fb Compare March 17, 2021 17:26

beutlich reviewed Mar 17, 2021

View reviewed changes

AHaumer approved these changes May 1, 2021

View reviewed changes

Use physical units to parameterize transfer function

6e5de83

christiankral requested review from beutlich and AHaumer June 6, 2021 21:17

beutlich reviewed Jun 8, 2021

View reviewed changes

Modelica/ComplexBlocks/Examples/ShowTransferFunction.mo Outdated Show resolved Hide resolved

Calculate unitless coefficient b

555393c

Co-authored-by: Thomas Beutlich <modelica@tbeu.de>

christiankral requested a review from beutlich June 8, 2021 09:40

beutlich approved these changes Jun 8, 2021

View reviewed changes

beutlich added this to the MSL4.1.0 milestone Jun 8, 2021

beutlich reviewed Nov 12, 2021

View reviewed changes

AHaumer approved these changes Dec 13, 2021

View reviewed changes

MartinOtter merged commit 1fc91db into modelica:master Oct 7, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix interpretation of coefficients of complex transfer function #3733

Fix interpretation of coefficients of complex transfer function #3733

christiankral commented Jan 24, 2021

AHaumer left a comment

dietmarw commented Feb 22, 2021

beutlich commented Feb 22, 2021

christiankral commented Mar 8, 2021 •

edited

Loading

CLAassistant commented Mar 8, 2021 •

edited

Loading

christiankral commented Mar 8, 2021

beutlich commented Mar 9, 2021

christiankral commented Mar 9, 2021

beutlich commented Mar 17, 2021 •

edited

Loading

christiankral commented Mar 17, 2021

beutlich Mar 17, 2021

christiankral commented May 23, 2021

HansOlsson commented May 24, 2021

henrikt-ma commented May 24, 2021

christiankral commented May 24, 2021 •

edited

Loading

beutlich commented May 24, 2021

henrikt-ma commented May 24, 2021

beutlich commented May 25, 2021 •

edited

Loading

henrikt-ma commented May 25, 2021

christiankral commented May 31, 2021

beutlich left a comment

Fix interpretation of coefficients of complex transfer function #3733

Fix interpretation of coefficients of complex transfer function #3733

Conversation

christiankral commented Jan 24, 2021

AHaumer left a comment

Choose a reason for hiding this comment

dietmarw commented Feb 22, 2021

beutlich commented Feb 22, 2021

christiankral commented Mar 8, 2021 • edited Loading

CLAassistant commented Mar 8, 2021 • edited Loading

christiankral commented Mar 8, 2021

beutlich commented Mar 9, 2021

christiankral commented Mar 9, 2021

beutlich commented Mar 17, 2021 • edited Loading

christiankral commented Mar 17, 2021

beutlich Mar 17, 2021

Choose a reason for hiding this comment

christiankral commented May 23, 2021

HansOlsson commented May 24, 2021

henrikt-ma commented May 24, 2021

christiankral commented May 24, 2021 • edited Loading

beutlich commented May 24, 2021

henrikt-ma commented May 24, 2021

beutlich commented May 25, 2021 • edited Loading

henrikt-ma commented May 25, 2021

christiankral commented May 31, 2021

beutlich left a comment

Choose a reason for hiding this comment

christiankral commented Mar 8, 2021 •

edited

Loading

CLAassistant commented Mar 8, 2021 •

edited

Loading

beutlich commented Mar 17, 2021 •

edited

Loading

christiankral commented May 24, 2021 •

edited

Loading

beutlich commented May 25, 2021 •

edited

Loading