Opened 5 years ago

Closed 5 years ago

#5791 closed defect (invalid)

Wrong valueReference in modelDescription.xml

Reported by: Lennart Ochel Owned by: Lennart Ochel
Priority: high Milestone: 1.16.0
Component: FMI Version: v1.16.0-dev
Keywords: Cc: arunkumar palanisamy

Description

OpenModelica produces a wrong FMU for the following model:

model foo
  parameter Boolean p = false;
  Real y;
equation
  y = sin(time);
end foo;

Output of OpenModelica v1.16.0-dev.97+g2047f530b:

<ModelVariables>
  <!-- Index of variable = "1" -->
  <ScalarVariable
    name="y"
    valueReference="0"
    >
    <Real/>
  </ScalarVariable>
  <!-- Index of variable = "2" -->
  <ScalarVariable
    name="p"
    valueReference="0"
    variability="fixed"
    causality="parameter"
    >
    <Boolean start="false"/>
  </ScalarVariable>
</ModelVariables>

The problem is that both y and p got the same value for the valueReference attribute.

Change History (5)

comment:1 by Lennart Ochel, 5 years ago

Owner: set to Lennart Ochel
Status: newaccepted

comment:2 by Lennart Ochel, 5 years ago

Version: v1.16.0-dev

comment:3 by Lennart Ochel, 5 years ago

Please consider also the following model:

model foo2
  parameter Boolean p_bool = false;
  parameter String p_str = "foo";
  parameter Integer p_int = 3;
  parameter Real p_real = 1.23;

  Real y_real = sin(time);
  Boolean y_bool = y_real > 0.0;
  Integer y_int = integer(y_real);
end foo2;

Wrong output of OpenModelica v1.16.0-dev.97+g2047f530b:

<ModelVariables>
  <!-- Index of variable = "1" -->
  <ScalarVariable
    name="y_real"
    valueReference="0"
    >
    <Real/>
  </ScalarVariable>
  <!-- Index of variable = "2" -->
  <ScalarVariable
    name="p_real"
    valueReference="1"
    variability="fixed"
    causality="parameter"
    >
    <Real start="1.23"/>
  </ScalarVariable>
  <!-- Index of variable = "3" -->
  <ScalarVariable
    name="y_int"
    valueReference="0"
    variability="discrete"
    >
    <Integer/>
  </ScalarVariable>
  <!-- Index of variable = "4" -->
  <ScalarVariable
    name="p_int"
    valueReference="1"
    variability="fixed"
    causality="parameter"
    >
    <Integer start="3"/>
  </ScalarVariable>
  <!-- Index of variable = "5" -->
  <ScalarVariable
    name="y_bool"
    valueReference="0"
    variability="discrete"
    >
    <Boolean/>
  </ScalarVariable>
  <!-- Index of variable = "6" -->
  <ScalarVariable
    name="p_bool"
    valueReference="1"
    variability="fixed"
    causality="parameter"
    >
    <Boolean start="false"/>
  </ScalarVariable>
  <!-- Index of variable = "7" -->
  <ScalarVariable
    name="p_str"
    valueReference="0"
    variability="fixed"
    causality="parameter"
    >
    <String start="foo"/>
  </ScalarVariable>
</ModelVariables>

comment:4 by Andreas Heuermann, 5 years ago

I can't see why the generated value References are not correct.
According to FMI specification 2.0.1 section 2.1.2 Platform Dependent Definitions the value reference is defined as:

typedef unsigned int fmi2ValueReference;
This is a handle to a (base type) variable value of the model. Handle and base type (such as
fmi2Real) uniquely identify the value of a variable. Variables of the same base type that have
the same handle, always have identical values, but other parts of the variable definition >might be
different [(for example, min/max attributes)].
All structured entities, such as records or arrays, are “flattened” into a set of scalar >values of
type fmi2Real, fmi2Integer, etc. An fmi2ValueReference references one such scalar. The
coding of fmi2ValueReference is a “secret” of the environment that generated the FMU. The
interface to the equations only provides access to variables via this handle. Extracting >concrete
information about a variable is specific to the used environment that reads the Model
Description File in which the value handles are defined.

So the valueReference is unique in combination with the data type. For each type (Real, Integer, Bool, String) we will start counting at 0.

Is there a concrete error you have with a FMU?
We could make it completely unique, but for that we had to update SimCodeUtil.getValueReference
and check that fmi2GetXXX and fmi2SetXXX are generated correctly.

comment:5 by Lennart Ochel, 5 years ago

Resolution: invalid
Status: acceptedclosed

This ticket is indeed invalid. I tried to make a simple test case from an issue we have in a rather complicated example. I will open a new ticket if I succeed.

Note: See TracTickets for help on using tickets.