Compliance checker does not verify order of structured names

[modelica-trac-importer]

Reported by henning.larsson on 9 Mar 2017 11:11 UTC The FMI 2.0 standard specifies the ordering of structured variable names in modelDescription.xml (p. 65):

"The tree of names is mapped to an ordered list of ScalarVariable.name’s in depth-first order. Example:

 vehicle
   transmission
     ratio
     outputSpeed
   engine
     inputSpeed
     temperature

is mapped to the following list of ScalarVariable.name’s:

 vehicle.transmission.ratio
 vehicle.transmission.outputSpeed
 vehicle.engine.inputSpeed
 vehicle.engine.temperature

All array elements are given in a consecutive sequence of ScalarVariables. Elements of multidimensional arrays are ordered according to “row major” order that is elements of the last index are given in sequence."

FMI 1.0 has a similar definition.

Currently, the compliance checker verifies the content of structured names, but not the ordering. If a tool generates a modelDescription from the example above with ordering

 vehicle.transmission.ratio
 vehicle.engine.inputSpeed
 vehicle.transmission.outputSpeed
 vehicle.engine.temperature

it would be incorrect, but pass the compliance checker (version 2.0.3) without warnings or errors.

---

Migrated-From: https://trac.fmi-standard.org/ticket/413

[Maplesoft-fmigroup]

The specification document states (on page 65):

"The tree of names is mapped to an ordered list of ScalarVariable.name’s in depth-first order."

But this is the ‘tree’ as implemented by the importing tool. It is our interpretation that this only dictates how to construct the names from the tree structure. It does not specify the order in which the ScalarVariables must appear in the modelDescription.xml file.

It would be unnecessarily restrictive to force the xml to list all the ScalarVariables in such order. For example, we export FMUs for tools that require the variables to be ordered by causality: independent, input, output, parameter, etc. The proposed limitation would prevent them from using structured names.

The specification does state that the array elements must be given in a consecutive sequence but not all the other names. We’re not sure what the benefit of the ordering restriction would be other than "ease of implementation" for the importing tool.

[Maplesoft-fmigroup]

Also, the example of a modelDescrption.xml on pg. 91-92 of the spec lists: variableNamingConvention="structured" but the names appearing in the ModelVariables section are not ordered, and there's no need for them to be.

[KarlWernersson]

duplicate from https://trac.fmi-standard.org/ticket/413

I agree with Henning that this is a bug, that does need to be fixed. I disagree with maplesoft and thought that the specification is sufficient clear, however since we have some disagreement a clarification might be good for the FMI 2.0.1 release. Also as maplesoft pointed out the example on pg.91-92 is wrong in this regard and needs to be updated. If you are not able to generate an xml accordingly, the flat option exists. In the end, we want nice xml files and it would be nice if the importer don't have to rearrange and sort all scalars variables but rather use the declared order in the xml

[TorstenBlochwitz]

I agree to MapleSoft. I never read the specification in a way that structured variables have to be ordered in the modelDescription, but this might have been my fault. I don't really see a reason for that. These are my arguments:

• The implementation of the import could slightly be simplified by ordering, but the implementation of the exporter gets more complicated.
• The ordering is not defined in an unique way. The variables from above can be ordered in the following completely different wayand it would still be valid. For arrays and matrices a unique ordering is defined.

  vehicle.engine.temperature
  vehicle.engine.inputSpeed
  vehicle.transmission.outputSpeed
  vehicle.transmission.ratio

  I propose to discuss this. In any case, we have to update and to harmonize the specification document.

[ghost]

The ordering at each level of the tree, e.g. of vehicle.engine.temperature and vehicle.engine.speed, is undefined. However, the depth-first ordering of the tree implied by the structured names makes it non-compliant to mix variables from vehicle.engine and vehicle.transmission (see the original comment).

Of course it can be discussed whether this is a necessary restriction or not, but since it is written in the 2.0 standard I think it is acceptable for an importing tool to expect such an ordering, rather than sorting the names internally.

[Maplesoft-fmigroup]

We cannot find where it is "written in the 2.0 standard". There is this in the 'spec':

"The tree of names is mapped to an ordered list of ScalarVariable.name’s in depth-first order."

which is all well and good. The missing bit is where the mapping being refered to has any relation at all to the order of the names in the xml file that describes the ScalarVariables. We interpret this simply as a statement of how one may use the ScalarVariable names in the tool not how they need to be written in the xml.

If this is desirable, perhaps a new attribute orderedVariableNaming should be specified in addition to variableNamingConvention then one could choose to set it to 'true' if they provide the structured names in tree order in the file.

[ghost]

Ok, so the interpretation of the depth-first ordering is that the parts of the structured name should come in order (vehicle.engine.temperature and not vehicle.temperature.engine, for example)? I am fine with this, but agree to previous comments about clarification in 2.0.1 and future standards.

I do not think there has to be a special flag for ordered variables. While tools may depend on an interpretation of the starndard that requires ordered variables, it should not be too hard to sort the names within the tool once this is clarified.

[filip-stenstrom]

Closing since this restriction has been removed in FMI 2.0.1: https://github.com/modelica/fmi-standard/issues/413