added combitable1ds example

[elmir-nahodovic]

added an example for rectilineargrid with combitable1ds, and uploaded two .xml's for it

[chrbertsch]

Currently we explain the behaviour via and example. I think we must define the implicit slicing cor in the definition of the domain and co-domain.

We will not support CombiTable1Dv, right? (Nor CombiTable2Ds, nor CombiTable2Dv?)
see https://build.openmodelica.org/Documentation/Modelica.Blocks.Tables.html

[chrbertsch]

This must be defined above and may not appear for the first time in the example.

[elmir-nahodovic]

Ah, good points! Let's discuss it at today's design meeting and afterwards I'll rework this PR

I think we start with a CombiTable1Ds since it is simpler and then we have at least something for CombiTables in the spec. After that we can include the more complex examples

[elmir-nahodovic]

I split the CombiTable1Ds Example to a separate section "Maps represented by CombiTable1Ds " with definition and example. This defines a third terminalKind, terminalKind = "org.fmi-standard.fmi-ls-struct.map.CombiTable1Ds" to express that domain and codomain are in the same variable

[chrbertsch]

I split the CombiTable1Ds Example to a separate section "Maps represented by CombiTable1Ds " with definition and example. This defines a third terminalKind, terminalKind = "org.fmi-standard.fmi-ls-struct.map.CombiTable1Ds" to express that domain and codomain are in the same variable

Thanks Elmir.
However, in contrast to PR #33, which reflects the state of the discussion before the Berlin F2F Design Meeting, we discussed (in Berlin, see https://github.com/modelica/fmi-design/tree/master/Meetings/2025/2025-06-02-04-FMI-F2F-Berlin#ls-struct , you were not yet involved at that time) that we won't have a separate TerminalKind "org.fmi-standard.fmi-ls-struct.map.CombiTable1D" but consider them as terminalKind="org.fmi-standard.fmi-ls-struct.map.rectilinearGrid" with a convention "if all domains and co-domains are the same, then auto-slice". This is what would be to be specified in more detail ...

[elmir-nahodovic]

Hi Christian, thank you for reviewing!

I started with the assumption that it should be under rectilinear as well but thought it would be better with a third terminalKind. I should have been more clear in the PR that I proposed we instead "go back" to having a separate terminalKind for Combitables, to not make the presentation too cluttered.

But if keeping Combitables under Rectilinear section is more inline with what the group wants I can move it inside there instead. It's no issue to me! I pushed a new pr so please see if that fits better with the idea.

The thing left to change is to better specify the domain/codomain variableKind to agree with combitables. Both under [#common-concepts] and the definition for rectilinear grids we specify that the variable needs to be one-dimensional but that is not inline with combitables