Chemical.Components.Substance.substanceData only shows "incompressible" substances

[dietmarw]

It looks to me like there is a bug in the contrainedby condition. When one uses Chemical.Components.Substance the drop-down list (in Dymola) of substanceData will only list substances that are of type Chemical.Interfaces.Incompressible.SubstanceData but none of type Chemical.Interfaces.IdealGas.SubstanceData.

The problem is most likely caused by the implementation in:

Chemical/Chemical/package.mo

Lines 2502 to 2509 in dd9375a

	replaceable package stateOfMatter = Incompressible constrainedby
	StateOfMatter
	"Substance model to translate data into substance properties"
	annotation (choicesAllMatching = true);
	parameter stateOfMatter.SubstanceData substanceData
	"Definition of the substance"
	annotation (choicesAllMatching = true);

[MarekMatejak]

It is may be an error in Dymola GUI, which is not dynamical enough to change this drop-down list with change of replaceable package in the same user dialog, isn't it? Ignoring this drop-down list and writing directly the name of substance in another state of matter should work.

[dietmarw]

Relying on choicesAllMatchin = true without specifying a restricting base is quite dangerous since Dymola (I think) is using some heuristics here. Of course manual entering the substance class names works but is very cumbersome.

Have you ever thought about implementing the substances as simple records that extend a base record class? This would in addition give the benefit of substances to be "clickable" which is not possible when defined as constants in a package.

[MarekMatejak]

I do not understand why "choicesAllMatchin = true" cannot be used using record type definition form replaceable package. In my opinion the type of parameter such as "parameter stateOfMatter.SubstanceData substanceData;" should be well defined always if "stateOfMatter" is set to an existing package. E.g. if the replaceable package is set to "stateOfMatter = Chemical.Interfaces.IdealGas" then type "stateOfMatter.SubstanceData" should be "Chemical.Interfaces.IdealGas.SubstanceData", not "Chemical.Interfaces.Incompressible.SubstanceData".

I feel that using base record type for definition of the "substanceData" parameter allows users to set here also substance data, which are not compatible with "stateOfMatter". Specific substance data need to be always compatible with the specific state of matter. This comes from definitions of the substance in physical chemistry, where e.g. water in liquid state is different substance as water in solid state.

[dietmarw]

So I played a bit around. And you are probably right that is seems to be simply a shortcoming of Dymola's parameter dialogue that does not take into account modifications of the package and hence only displays matching choices for the default record type. Perhaps a future version will do this. I probably would leave this issue open until it is either confirmed to be a sole tool issue or a workaround can be found.

[HansOlsson]

So I played a bit around. And you are probably right that is seems to be simply a shortcoming of Dymola's parameter dialogue that does not take into account modifications of the package and hence only displays matching choices for the default record type. Perhaps a future version will do this. I probably would leave this issue open until it is either confirmed to be a sole tool issue or a workaround can be found.

We will try to correct this.

Note that choicesAllMatching is only standarized for replaceable elements, and this parameter-record case was added later in Dymola.

For replaceable elements this issue does not occur, since the constraining class must be transitively non-replaceable - section 6.2.1 and 7.1.4 in Modelica 3.4 spec.