search

modelica / ModelicaStandardLibrary

Free (standard conforming) library to model mechanical (1D/3D), electrical (analog, digital, machines), magnetic, thermal, fluid, control systems and hierarchical state machines. Also numerical functions and functions for strings, files and streams are included.
https://doc.modelica.org
BSD 3-Clause "New" or "Revised" License
472 stars 169 forks source link

Delay blocks do not belong to Blocks.Nonlinear #3460

Open casella opened 4 years ago

casella commented 4 years ago

The Blocks.Nonlinear package contain three time delay implementations: FixedDelay, PadeDelay, and VariableDelay.

As everybody knows, pure time delay y(t) = u(t - tau) is a linear operator, linear as linear can be, since obviously the superposition principle applies to it 100%. It is in principle infinite-dimensional, but that doesn't make it less linear. Also its Padé approximation is of course linear, as explicitly explained in the documentation.

I guess the only reason why these blocks belong to Blocks.Nonlinear is to mimick the Simulink Block library, where the delay block was put in the Nonlinear category 30 years ago for reasons I cannot fathom.

I don't think we need to worry too much looking the same as Simulink, at least as far as wrong features are concerned. We should rather worry about not calling Nonlinear something which is most definitely 100% linear.

I would propose to move those three blocks to Continuous, where they belong, now that we have a once-in-a-lifetime opportunity to do so with the conversion scripts. If there is consensus about this, I can open a proper PR with the code change ASAP.

Please note this can only be done in 4.0.0, not in a subsequent minor release.

beutlich commented 4 years ago

Since we won't touch upcoming MSL 4.0.0 to introduce any new conversion rules, we have to postpone the proposed changes until MSL 4.0.0 is released and branched to maint/4.0.x.

now that we have a once-in-a-lifetime opportunity to do so with the conversion scripts

Next opportunity already is for MSL v5.0.0 or v4.1.0 to be expected in spring 2021 (provided we decide on #3461, and if we claim that changes requiring conversion imply a new MAJOR revision).

HansOlsson commented 4 years ago

(Well, VariableDelay is non-linear in the delay argument.) However, NonLinear is a bad name - especially as most non-linear blocks are in Math.

Since they all have internal states Continuous does seem like a better fit for the delays. And the remaining ones in NonLinear are then limiters and deadzone, and we might be able to find a better name for them.

casella commented 4 years ago

Next opportunity already is for MSL v5.0.0 or v4.1.0 to be expected in spring 2021 (provided we decide on #3461, and if we claim that changes requiring conversion imply a new MAJOR revision).

Just as a clarification, according to SEMVER, a major revision is required if you change the API. In case we have a conversion script, would this change be considered as "not changing the API", so it could end up in 4.1.0?

dietmarw commented 4 years ago

No because the conversion script would change the user library so it can work with the new MAJOR version. It will no longer be able to work with the previous version. Conversion script is a one-off operation to the user library.

MartinOtter commented 4 years ago

I would propose to move those three blocks to Continuous, where they belong, now that we have a once-in-a-lifetime opportunity to do so with the conversion scripts. If there is consensus about this, I can open a proper PR with the code change ASAP.

Fine for me

casella commented 4 years ago

No because the conversion script would change the user library so it can work with the new MAJOR version. It will no longer be able to work with the previous version. Conversion script is a one-off operation to the user library.

I'm confused. @beutlich mentioned 4 days ago that this change could end up in 4.1.0, which is a MINOR version. Do I miss something?

dietmarw commented 4 years ago

He said " MSL v5.0.0 or v4.1.0" and it will depend what the exact nature of the change is.