Rework CombiTable description

[klausschuch]

as discussed in the webmeeting, the combitables section(s) need some rework

[TorstenBlochwitz]

I would propose to use this Modelica model as example:

model Model2 "CombiTable1D.mo"
	Modelica.Blocks.Tables.CombiTable1Ds combiTable1Ds1(
		table={{1,2,4,7},
		{2,3,2,5},
		{3,4,1,2}},
		columns={2,3},
		smoothness=Modelica.Blocks.Types.Smoothness.LinearSegments) annotation(Placement(transformation(extent={{-70,15},{-50,35}})));
	Modelica.Blocks.Sources.RealExpression realExpression1(y=time) annotation(Placement(transformation(extent={{-115,15},{-95,35}})));
	equation
		connect(realExpression1.y,combiTable1Ds1.u) annotation(Line(
			points={{-94,25},{-89,25},{-77,25},{-72,25}},
			color={0,0,127}));
	annotation(
		uses(Modelica(version="4.0.0")),
		experiment(
			StopTime=3,
			StartTime=1,
			Interval=0.001));
end Model2;

I will use it to generate the modelDescription.xml with the parameters and some variables and to manually generate the terminalsAndIcons.xml.

[KarlWernersson]

after looking at it and thinking about it, I think it’s better to not use the terminal member codomain and domain for combatables, any way of splicing or re representation would be error prone. We should keep the matching rule, just open up how to define the domain and the co-domain so for comitables we should use variable kind org.fmi-standard.fmi-ls-struct.map.table and let it define both the domain and the co-domain as this is how it is actually done in the MSL combitables.
//table because that’s what the parameter is called in the model. but open for other suggestions.

varialbeKind=”table”
defines both the domain and codomain for org.fmi-standard.fmi-ls-struct.map.combitable1d and org.fmi-standard.fmi-ls-struct.map.combitable2d
CombiTable1D, the table defines a 1-d rectangular grid (curve) where the first column is the domain and the subsequent columns are the co-domains.
//extra info, combitable 1d exists in two versions, 1 were there is 1 input and 1 output for every codomain. And a second version where there is 1 input and one output for every co-domain still only 1 domain. This clashes with current definition of domain Input and domain Output, here we have 1 domain output for each codomain, and (1 domain Input for the domain or 1 domain Input for each co-domain)

Comiitable2D, the table defines a 2-d rectangular grid (MAP) where the 2:last element of the first column is the first domain, and the 2:last element of the first row is the second domain. The codomain is defined by [2:end,2:end].
//The combinable as 2 input and one output, all with the same dimension.

We might need to relaxes the requirements for domain input and domain output, as these tables reuses the same domain for different inputs to create new outputs

[klausschuch]

As discussed in the webmeeting on 19.12.2024:
Keeping the individual terminal members for domain, domainInput, ... for the combitables allows us to reuse the definition of e.g. the domainInput.

[HansOlsson]

I'm not 100% about the issue (wasn't fully clear from the above), but to me it seems be that a major issue is that combitable2d doesn't really match the definitions of domain and codomain.

To me there seems to two kinds of solutions for the problem with domain as variable kind:

• Have a special "domainWithCodomain" to reference one array in this special way (or use codomain for this if variableType is combiTable2d).
• Have a general mechanism to reference only parts of matrices (using a new attribute), so that the codomain references the entire table but the sub-part [2:end,2:end] and the domains are [2:end,1] and [1,2:end]. (Syntax to be defined.) Note that this is similar to having headers in tables, which are fairly common. E.g., pandas.read_csv has skipRows and I assume other matrix imports have something similar.

Note that in general we should also consider that all domainInputs (for different domains corresponding to one domainOutput) could be in one vector; it seems that the discussed vector case was something else.

[GallLeo]

Should we mention CombiTimeTable?
ls-struct would probably work as well?

[HansOlsson]

Should we mention CombiTimeTable? ls-struct would probably work as well?

Probably, and that can fit either of those descriptions as well.

[klausschuch]

I'm not 100% about the issue (wasn't fully clear from the above), but to me it seems be that a major issue is that combitable2d doesn't really match the definitions of domain and codomain.

@HansOlsson
Yes, for combitables the domain and codomain values are stored in a single matrix.
This topic was discussed in #7

We discussed the option to introduce a generic mechanism to refer to a slice of the matrix that contains everything (basically your 2. suggestion).

However, we agreed (see #7) to just introduce specific terminalkinds for combitables (basically your 1. suggestion).
The importer can extract the domain and codomain values form a single fmi variable (the matrix) and show it in a user friendly representation.
And the main purpose of the CombiTable section in the specification would be to describe this mapping.