Ambiguous array-size variables clutter the parameter list

[rokil]

When exporting to an grtfmi (2.7) FMU, and not using the Inline Parameters option in the Simulink model properties, then additional parameters appear in the generated modelDescription.xml which are not found in the Simulink model. They seem to be helper variables created by Simulink to handle block parameters.

Which parameters they belong to can only be identified by guessing, as they have nothing in common with the original parameter names. So the naming of these pooled, Size and maxIndex parameters (see examples below) is very ambiguous and their use is not clear to me. If they have some use to a user of the FMU, can their naming be fixed so that they are identifiable? If not, can they be removed from the modelDescription.xml?

Examples:

1. I created two blocks which both use the same parameter variable MyArray of size 1x3. Two additional parameters named pooled9 appear that seem to reflect the array parameter's size.

   <ScalarVariable name="pooled9[1]" valueReference="106" causality="parameter" variability="tunable">
     <Real start="1.0"/>
   </ScalarVariable>
   <ScalarVariable name="pooled9[2]" valueReference="107" causality="parameter" variability="tunable">
     <Real start="3.0"/>
   </ScalarVariable>
   <ScalarVariable name="MyArray[1]" valueReference="108" causality="parameter" variability="tunable">
     <Real start="1.0"/>
   </ScalarVariable>
   <ScalarVariable name="MyArray[2]" valueReference="109" causality="parameter" variability="tunable">
     <Real start="2.0"/>
   </ScalarVariable>
   <ScalarVariable name="MyArray[3]" valueReference="110" causality="parameter" variability="tunable">
     <Real start="3.0"/>
   </ScalarVariable>

2. I created an S-Function block named MyBlockName with a parameter myScalarParameter. Two additional parameters named MyBlockName_P5_Size appear that seem to reflect the parameter's size.

    <ScalarVariable name="MyBlockName_P5_Size[1]" valueReference="114" causality="parameter" variability="tunable">
      <Real start="1.0"/>
    </ScalarVariable>
    <ScalarVariable name="MyBlockName _P5_Size[2]" valueReference="115" causality="parameter" variability="tunable">
      <Real start="1.0"/>
    </ScalarVariable>
    <ScalarVariable name="myScalarParameter" valueReference="116" causality="parameter" variability="tunable">
      <Real start="3.0"/>
    </ScalarVariable>

3. I created a 2D-Table block from the native Simulink library containing parameters defining a 3x3 table. Two additional parameters named uDLookupTable_maxIndex appear -- and strangely this time the block is not named uDLookupTable but different!

    <ScalarVariable name="uDLookupTable_maxIndex[1]" valueReference="163" causality="parameter" variability="tunable">
      <Integer start="2"/>
    </ScalarVariable>
    <ScalarVariable name="uDLookupTable_maxIndex[2]" valueReference="164" causality="parameter" variability="tunable">
      <Integer start="2"/>
    </ScalarVariable>

If required I can send an example fmu via mail. Uploading (even with zip extension) failed here.

[t-sommer]

If required I can send an example fmu via mail.

Yes, please mail them to torsten.sommer@3ds.com. I will attach them to this issue.

[t-sommer]

array-size-example.zip

[t-sommer]

The variables in the modelDescription.xml represent the structure of the generated code which is different from the original model.

To remove parameters from the XML you can inline the parameters using the options in Configuration Paramters > Optimization > Signals and Paramters or list the parameters to include in the XML in Configuration Paramters > Code Generation > FMI > Visible parameters.

[rokil]

You are right, inlining and configuring all parameters as tunable seems to be a viable option. (I want all the parameter variables I created to be visible.) I am not sure whether there are any other side-effects of inlining and selecting all parameters as tunable, compared to keeping the global setting "tunable". Do you consider inlining a default setting for grtfmi which should always be done?

[t-sommer]

Do you consider inlining a default setting for grtfmi which should always be done?

If you don't want to access these parameters you should consider inlining them, especially for larger models.