Refs #3593: Fix documentation of quasi-static machine examples

[christiankral]

I checked the quasi static induction machine examples and updated the documentation to match the actual variables.

[christiankral]

The following models use the instance name iSensorQS instead of currentQuasiRMSSensorQS which makes the example collection a little inconsistent

• Modelica.Magnetic.QuasiStatic.FundamentalWave.Examples.BasicMachines.InductionMachines.IMC_Characteristics
• Modelica.Magnetic.QuasiStatic.FundamentalWave.Examples.BasicMachines.InductionMachines.IMS_Characteristics

@tobolar @beutlich Are we allowed to rename a sensor in the master branch? If yes, I would unify the appearance of the sensor names.

[christiankral]

There is one more issue with a synchronous machine example which I am going to fix.

[tobolar]

Are we allowed to rename a sensor in the master branch? If yes, I would unify the appearance of the sensor names.

Do you mean to rename a sensor element in that particular example model?

[christiankral]

Are we allowed to rename a sensor in the master branch? If yes, I would unify the appearance of the sensor names.

Do you mean to rename a sensor element in that particular example model?

Yes, this is what I mean

[tobolar]

IMO this is no problem when only an example is concerned. I remember there has been some comment on it by (I guess) @dietmarw but I can't find it anymore.

[dietmarw]

First of all you need to determine what is meant by "master branch". The question is what next version the master branch is aiming at. Backward compatible, i.e., 4.1.0, or non-backward compatible, i.e., 5.0.0. As far as I know this has not yet been decided within MAP-LIB. In the latter case there is no restrictions on renames as long as conversion scripts are given. In the former case we tended to allow renames within examples even if they break backward compatibility since the argument is that users should not let their usermodels extend from examples (copying is fine but not extend).

[christiankral]

OK, I propose to separate the issues which became mixed up in this PR.

• Fix documentation: this is covered by this PR
• Change spelling (currently, e.g., smpm|smpmQS.tauElectrical) of multiple similar variables as suggested by @tobolar: I propose to create a different ticket and PR, respectively, as this issue affects some more models of the MSL
• Unify naming of sensor: Optionally create a new PR as this issue is not directly related with the documentation; it may also require some more discussion if we are fine with renaming instance names of MSL examples in the future

So if there are not objections with this approach, I am asking @tobolar and @dietmarw to re-evaluate this PR so that we can proceed.

[dietmarw]

Looks good to me. I don't think parentheses would be strictly necessary in case of the choices but would not harm either. I leave that to the LOs to decide.

[dietmarw]

I've rebased the PR on current master in order to get the CI checks working.