Declare parameter records as replaceable?

[AHaumer]

Recently I had a discussion with @casella and @perost about parameter records, as used in Modelica.Magnetic.FluxTubes.

As today, the parameter record is instantiated as

  parameter FluxTubes.Material.SoftMagnetic.BaseData material=Material.SoftMagnetic.BaseData()
    annotation (choicesAllMatching=true);

A tool is free to extend the standard and present a drop-down menu, modifying the parameter material with a record constructor component(material=Modelica.Magnetic.FluxTubes.Material.SoftMagnetic.ElectricSheet.M350_50A())

As @casella pointed out, the specification is very clear:

Only classes and components declared as replaceable can be redeclared with a new type, which must have an interface compatible with the constraining interface of the original declaration, and to allow further redeclarations one must use redeclare replaceable.

As @perost pointed out, the specification currently only specifies the use of choicesAllMatching on replaceable elements,

So the point is: Either should the specification get extended to use choicesAllMatching for modifying parameters, too, or we should use in MSL the following instantiation:

  replaceable parameter FluxTubes.Material.SoftMagnetic.BaseData material=Material.SoftMagnetic.BaseData()
    annotation (choicesAllMatching=true);

causing the tool to use a redeclaration: component(redeclare Modelica.Magnetic.FluxTubes.Material.SoftMagnetic.ElectricSheet.M350_50A material);

Different tools should offer the same behaviour for MSL models. What's your opinion? I suppose the issue should get discussed in MAP-Lang and MAP-Lib.

[HansOlsson]

Making it replaceable allows you to redeclare it as a sub-class record with additional members, and then there's the final vs. redeclare trap as well. I simply don't see that as a good option.

Having choicesAllMatching for records seems simpler.

[eshmoylova]

I believe the problem with choicesAllMatching is that we currently have:

The annotation choicesAllMatching = true on a replaceable element indicates that....

There is no indication that choicesAllMatching can be used for modifications that are not redeclarations of replaceable components or how the offered choices should be interpreted. I think it might be one of those cases where it is not in the specification but (some of) the tools do it anyway. Is it possible that, when choicesAllMatching was standardized from __Dymola_choicesAllMatching, not all aspects of it were recorded in the specification?

[casella]

There is no indication that choicesAllMatching can be used for modifications that are not redeclarations of replaceable components or how the offered choices should be interpreted.

That is exactly the problem we are facing. I believe what Dymola does makes lots of sense, but we should standardize it in Modelica 3.6.

[HansOlsson]

The proposal is to extend choicesAllMatching to record-parameters where you select record-values; which includes using record-constructors for matching record-classes and record constants.

Select one of the matching emojis before start of August:

• In favor: thumb up
• Against: thumb down

[henrikt-ma]

I guess the idea would be to only present record constructors that can be called without arguments, or would it also be expected to search available code for other record constructor calls with constant arguments (I think the record constants case could be seen as a special case of this)?

[HansOlsson]

I guess the idea would be to only present record constructors that can be called without arguments, or would it also be expected to search available code for other record constructor calls with constant arguments (I think the record constants case could be seen as a special case of this)?

I would say the latter, since it is a matching record-class and you can change it in the call - but possibly they are shown slightly differently. In particular this allows the call to the original record-class.

Basically it seems natural to allow changes to the record-constructor-call, and to then say that tools should only include calls that work without modification in the list seems odd.

Note that for Modelica.Magnetic.FluxTubes.Material and Modelica.Thermal.FluidHeatFlow.Media all of record-classes have non-final settings for the parameters - allowing you to set them, but normally you just keep them as is.