added combitable1ds example #36
Conversation
chrbertsch
left a comment
chrbertsch
left a comment
There was a problem hiding this comment.
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
docs/index.adoc
Outdated
| include::examples/terminalsAndIcons_CombiTable1Ds.xml[] | ||
| ---- | ||
|
|
||
| The `combiTable1Ds1.table` variable appears twice: once with `variableKind="org.fmi-standard.fmi-ls-struct.map.domain"` and again with `variableKind="org.fmi-standard.fmi-ls-struct.map.codomain"`, since both domain and codomain data are stored in the same variable. The `terminalMemberVariable`, `combiTable1Ds1.y`, is a 2D-array, since the Modelica code specified two outputs with `columns = {2,3}`. |
There was a problem hiding this comment.
This must be defined above and may not appear for the first time in the example.
There was a problem hiding this comment.
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
Split CombiTable1Ds Example to a separate section "Maps represented by `CombiTable1Ds` " with definition and example. This defines a third terminalKind for CombiTable1Ds
|
I split the CombiTable1Ds Example to a separate section "Maps represented by |
Thanks Elmir. |
|
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 |
| Unlike maps sampled on rectilinear grids, a `CombiTable1Ds` instance stores both the domain and codomain data within the **same variable** (the `table` parameter of the link:https://doc.modelica.org/Modelica%204.0.0/Resources/helpDymola/Modelica_Blocks_Tables.html#Modelica.Blocks.Tables.CombiTable1Ds[Modelica.Blocks.Tables.CombiTable1Ds] component). The first column of this matrix defines the domain values, and the remaining columns define the codomain values. This sets the following restrictions on the variableKind for **domain** and **codomain**: | ||
|
|
||
| domain:: | ||
| The first column of the table variable defines the domain values. The corresponding FMU variable must be referenced with `variableKind="org.fmi-standard.fmi-ls-struct.map.domain"`. |
There was a problem hiding this comment.
In the rest of the document, we don't talk about columns and rows, only first, second, ... dimension is mentioned.
We currently just have the note:
[Note: This layered standard doesn’t define how maps have to be represented in a GUI. In particular, the standard doesn’t define if the first dimension is displayed as columns or rows. However, for the example lookup tables of this document, the sampling points of first dimension of the domain are shown as a column vector, and the values of second dimension are shown as a row vector.]
This needs to be resolved.
I guess we have several options:
- Change this note to indicate that that we will by convention use column for the first and row for the second dimension (or vice-versa) for the rest of the document. But we don't enforce this visualization
- Keep the note but add such a convention only combitables
- Change the current column/row to the corresponding dimension.
added an example for rectilineargrid with combitable1ds, and uploaded two .xml's for it