How to represent input variables of a lookup table

[klausschuch]

We have a 2-d lookup table with first axis x, second axis y, values v and 2 input variables (in_x, in_y) that access this lookup table :

<Float64 name="x" valueReference="1" causality="parameter" start="2.0 3.0">
  <Dimension start="2"/>
</Float64>
<Float64 name="y" valueReference="2" causality="parameter" start="10.0 25.0 30.0">
  <Dimension start="3"/>
</Float64>
<Float64 name="v" valueReference="3" causality="parameter" start="11.0 12.0 13.0 21.0 22.0 23.0">
  <Dimension start="2"/>
  <Dimension start="3"/>
</Float64>
<Float64 name="in_x" valueReference="6" causality="input" start="2.0"/>
<Float64 name="in_y" valueReference="7" causality="input" start="10.0"/>

We could compose a lookup table called map2d via terminals:

<fmiTerminalsAndIcons fmiVersion="3.0">
  <Terminals>
    <Terminal name="map2d" terminalKind="org.fmi-standard.fmi-ls-struct.regularMap" matchingRule="plug">
      <TerminalMemberVariable variableName="x" memberName="x" variableKind="org.fmi-standard.fmi-ls-struct.domain" />
      <TerminalMemberVariable variableName="y" memberName="y" variableKind="org.fmi-standard.fmi-ls-struct.domain" />
      <TerminalMemberVariable variableName="v" memberName="v" variableKind="org.fmi-standard.fmi-ls-struct.codomain" />
    </Terminal>
  </Terminals>
</fmiTerminalsAndIcons>

One option to indicate inputs (in_x, in_y) to a lookup tables would be:

<fmiTerminalsAndIcons fmiVersion="3.0">
  <Terminals>
    <Terminal name="map2d" terminalKind="org.fmi-standard.fmi-ls-struct.regularMap" matchingRule="plug">
      <TerminalMemberVariable variableName="x" memberName="x" variableKind="org.fmi-standard.fmi-ls-struct.domain" />
      <TerminalMemberVariable variableName="in_x" memberName="in_x" variableKind="org.fmi-standard.fmi-ls-struct.domain_input" />
      <TerminalMemberVariable variableName="y" memberName="y" variableKind="org.fmi-standard.fmi-ls-struct.domain" />
      <TerminalMemberVariable variableName="in_x" memberName="in_x" variableKind="org.fmi-standard.fmi-ls-struct.domain_input" />
      <TerminalMemberVariable variableName="v" memberName="v" variableKind="org.fmi-standard.fmi-ls-struct.codomain" />
    </Terminal>
  </Terminals>
</fmiTerminalsAndIcons>

Note that here the order is important, e.g., if there is no variable that indicates the current operating point in the x direction (i.e., no in_x), it would be omitted.

Note 2: In the original proposal the xml entry would look like this:

<RegularMap name="map2d">
  <Domain name="x" input="in_x" />
  <Domain name="y" input="in_y" />
  <Codomain name="v" />
</RegularMap>

[klausschuch]

Another option to specify input variables of a map (within terminals) would be adding annotations:

<fmiTerminalsAndIcons fmiVersion="3.0">
  <Terminals>
    <Terminal name="map2d" terminalKind="org.fmi-standard.fmi-ls-struct.regularMap" matchingRule="plug">
      <TerminalMemberVariable variableName="x" memberName="x" variableKind="org.fmi-standard.fmi-ls-struct.domain" />
        <Annotations>
          <Annotation type="org.fmi-standard.fmi-ls-struct.input">
            <Input name="in_x"/>
          </Annotation>
        </Annotation>
      </TerminalMemberVariable>
      <TerminalMemberVariable variableName="y" memberName="y" variableKind="org.fmi-standard.fmi-ls-struct.domain" />
        <Annotations>
          <Annotation type="org.fmi-standard.fmi-ls-struct">
            <Input name="in_y"/>
          </Annotation>
        </Annotations>
      </TerminalMemberVariable>
      <TerminalMemberVariable variableName="v" memberName="v" variableKind="org.fmi-standard.fmi-ls-struct.codomain" />
    </Terminal>
  </Terminals>
</fmiTerminalsAndIcons>

[chrbertsch]

Design Meeting: Klaus: Option 1 is my preferred, if we use the Terminals. What are the benefits of the general approach at all? Drawback we loose XSD supports. Pierre: it is extendible, we use our general mechanism "terminals", not always..., regarding XSD: you have to check additional things anyway. E.g., if the variables exist ... Are the terminals suitably defined? We will get the same discussion in LS-BUS Klaus: Will we define new Terminal kinds there? I do not think so. In LS-BUS it is still for connecting. Christian: What would we need for the Terminals? Klaus: The terminals work, but they are not so useful. Pierre: We either could extend them, but we could also come to the conclusion to use other means

Pierre: the parameter grouping would have to be one level above the look-up tables anyway. Could be done in different ways with each of the proposals.

Pierre: All of the proposals can be realized. My main point was against creating a new generic concept parallel to the terminals.

Regarding matching rule, we could leave this open.

Klaus: One can use Terminals as grouping, maps are a special kind of grouping.

Klaus: We need a decision before we start writing it down.

Conclusion: let's continue with Terminals and the first option

[chrbertsch]

FMI Webmeeting:

Torsten B: Why use matching rule "plug"? Klaus: Something has to be there, it is up to the FMU Torsten B: I would expect a connector Klaus: You could to this Torsten B: a use would expect the these parameter to be treated as a map. Klaus: We still have a terminaKind. One could connect two regular maps. Torsten B.: I will have a look at this.

[klausschuch]

Meeting 14.5.2024: The domain_input isn't required to be a scalar, it could be variable with several dimensions. However the size of each domain_inputs must be the same for each domain.

"For non-scalars, the each element of the array is used as an individual eof the lookup table."

For a nonscalar input v=[v1,...vn] the function is evalutated elementwisely and we get and output vector o=[f(v1), .... f(vn)]

For a nonscalar inputs v=[v1,...vn], w=[w1,...wn], ... the function is evalutated elementwisely and we get an output vector o=[f(v1, w1, ...), .... f(vn, wn, ...)]