controllab / fmi-export-20sim Goto Github PK

To be able to get and set and restore the FMU state, we need to implement fmi2GetFMUstate(), fmi2SetFMUstate(). fmi2FreeFMUstate() functions.

When this works, we can also serialize/deserialize the state by implementing
fmi2SerializedFMUstateSize()
fmi2SerializeFMUstate()
fmi2DeSerializeFMUstate()

The model description which is exported will contain outputs in this format:

<ModelStructure>
        <Outputs>
            <Unknown index="45" />
            <Unknown index="48" />
        </Outputs>
    </ModelStructure>

this implies that index 45 and 48 must be of type output which they are but also that they depend on all other scalar variables defined in the model. The FMI standard refers to this as the worst case type of dependency. This is assumes if no dependency information is available.

Either the dependencies should be listed as dependencies="1 2 3" for dependency on 1, 2 and 3 where the dependenciesKind can be used to detail the type of dependency.

Otherwise dependencies="" can be used to indicate no dependencies.

See p. 61 in https://svn.modelica.org/fmi/branches/public/specifications/v2.0/FMI_for_ModelExchange_and_CoSimulation_v2.0.pdf

20-sim FMUs which access external resources are not working when FMUs are built for Mac using the INTO FMU builder (App version 1.1.1, COE version 0.1.1). Speaking to Kenneth, he suspects the issue is here:

https://github.com/controllab/fmi-export-20sim/blob/master/StandaloneFMU/src/%25FMI_PREFIX%25Functions.c#L75

he says: "this will make the absolute path /Users/kel/some/thing become Users/kel/some/thing on *nix systems but it will work correctly on windows since it is /c:/Users/kel/some/thing which then becomes c:/Users/kel/some/thing which is valid in C on windows"

Examples are available in the INTO repositories: case-study_fcu, branch rjp/coe0.1.0 and case-study_line_follower_robot, branch kgp/0.1.1

I would suggest that the attribute generationDateAndTime also is set during export and that the generationTool also includes the tool version. This way it is easier to identify how an existing FMU was created.

The xxTable2D functions only support reading Windows encoded files on Windows i.e. \r\n the code works on *nix as well but then the file must be in *nix file format which is not likely since 20-sim is Windows only.

A small investigation. We added some debug logging in xxTable2D. This looks like this on Windows

### path: 'C:/Users/kel/AppData/Local/Temp/Sensor_Block356382828422857220/resources/map.txt'
ERROR '' 
findpos x 
findPosition -0.011000, 000000001C31D8D0, 594 
findPos
ition array[0] = -0.297000 
X pos 285 
findpos y 
findPosition 0.064000, 000000001C31EB70, 841 
findPosition array[0] = -0.419500 
Y pos 483 
ERROR '' 
findpos x 
findPosition -0.010000, 000000001C31D8D0, 594 
findPosition array[0] = -0.297000 
X pos 286 
findpos y 
findPosition 0.064000, 000000001C31EB70, 841 
findPosition array[0] = -0.419500 
Y pos 483 
ERROR '' 
findpos x 
findPosition -0.009000, 000000001C31D8D0, 594 
findPosition array[0] = -0.297000 
X pos 287 
findpos y 
findPosition 0.064000, 000000001C31EB70, 841 
findPosition array[0] = -0.419500 
Y pos 483 
ERROR '' 

And on *nix it looks like

### path: '/Users/kel/Downloads/case-study_line_follower_robot/FMUs/new/Sensor_Block/resources/map.txt'
ERROR ''
findpos x
findPosition -0.011000, 0x7fb1a4a7ea00, 595
findPosition array[0] = -0.297000
X pos 595
findpos y
findPosition 0.064000, 0x7fb1a4a7fe00, 841
findPosition array[0] = -1.000000
Y pos 841
ERROR ''
findpos x
findPosition -0.010000, 0x7fb1a4a7ea00, 595
findPosition array[0] = -0.297000
X pos 595
findpos y
findPosition 0.064000, 0x7fb1a4a7fe00, 841
findPosition array[0] = -1.000000
Y pos 841
ERROR ''
findpos x
findPosition -0.009000, 0x7fb1a4a7ea00, 595
findPosition array[0] = -0.297000
X pos 595
findpos y
findPosition 0.064000, 0x7fb1a4a7fe00, 841
findPosition array[0] = -1.000000
Y pos 841
ERROR ''

We also observed that on Mac we got:

SIGSEGV (0xb) at pc=0x00000001244649ae, pid=5389, tid=22787

near:

C  [Sensor_Block.dylib+0x49ae]  findPosition+0x39
C  [Sensor_Block.dylib+0x3f54]  Table2D_TableRead+0x15f
C  [Sensor_Block.dylib+0x5ca3]  XXCalculateDynamic+0x719
C  [Sensor_Block.dylib+0x80da]  XXInitializeSubmodel+0x5e
C  [Sensor_Block.dylib+0x36ce]  fmi2ExitInitializationMode+0x20

If this is due to the above issue or some sort of concurrency we don't know. It happened with a FMU where we created two instances.

If I export the cascading watertank from DESTECS (with the two tanks imploded) then the exporter creates these scalar variables for the tank1:

<ScalarVariable name="valve1.Valve.leakage" valueReference="17" variability="continuous" causality="local">
<Boolean />
</ScalarVariable>

<ScalarVariable name="valve1.leakage" valueReference="17" variability="continuous" causality="local">
<Boolean />
</ScalarVariable>

<ScalarVariable name="leakage" valueReference="21" variability="continuous" causality="input">
<Boolean start="false" />
</ScalarVariable>

Output form the COE:

Failed to load and parse model defintion in: src/test/resources/complete-models/cascading/cascadingwatertank1 Reason:  Invalid configuration of scalar variables: 
valve1.Valve.leakage Error: For a continuous variable the type has to be Real
valve1.leakage Error: For a continuous variable the type has to be Real
leakage Error: For a continuous variable the type has to be Real

However this is not valid according to the FMI standard version 2. It could look like this depending on what the meaning of the variables in the model is:

<ScalarVariable name="valve1.Valve.leakage" valueReference="17" variability="discrete" causality="local">
<Boolean />
</ScalarVariable>

<ScalarVariable name="valve1.leakage" valueReference="17" variability="discrete" causality="local">
<Boolean />
</ScalarVariable>

<ScalarVariable name="leakage" valueReference="21" variability="discrete" causality="input">
<Boolean start="false" />
</ScalarVariable>

Running a multi-model with multiple instances of 20-sim generated FMUs crashes the COE on termination:

INFO [NanoHttpd Request Processor (#1)] (CoeSimulator.scala:178) - Freeing serilized states from: 10.0
TRACE [NanoHttpd Request Processor (#1)] (ResultLogger.scala:42) - org.intocps.orchestration.coe.scala.CoeObject$GlobalState@36388bcb
DEBUG [NanoHttpd Request Processor (#1)] (CoeSimulator.scala:405) - Calling terminate for: {uav}.uav2
DEBUG [NanoHttpd Request Processor (#1)] (CoeSimulator.scala:407) - Calling freeInstance for: {uav}.uav2
DEBUG [NanoHttpd Request Processor (#1)] (CoeSimulator.scala:405) - Calling terminate for: {uav}.uav
java(51300,0x12fe9f000) malloc: *** error for object 0x7f9551cb5c50: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

Suggested test model is the UAV case study: https://github.com/into-cps/case-study_uav_swarm/tree/development (use 3-UAV-Non-3D\Experiment 1). You can obviously set the end time to very short to reach termination quickly.

Hello,
since installation of version 4.6.2 I have an error during FMU compilation:
xxfuncs.obj : error LNK2001: unresolved external symbol xx_stop_simulation

The logger always writes

g_fmiCallbackFunctions->logger(NULL, "bouncingBall", fmi2Error, "error",
                    "Exceeded model finish time: %g > %g\n", xx_time, xx_finish_time);

template function is:

if(g_fmiCallbackFunctions != NULL && g_fmiCallbackFunctions->logger != NULL)
            {
                g_fmiCallbackFunctions->logger(NULL, "bouncingBall", fmi2Error, "error",
                    "Exceeded model finish time: %g > %g\n", %VARPREFIX%%XX_TIME%, %VARPREFIX%finish_time);
            }

Error from a model which uses workarrays in the generated code:

c:\temp\body_blocke006\src\xxmodel.c(733): error C2065: 'xx_workarray': undeclared identifier

TODO: add a define that redirects xx_workarray to the corresponding xx_model_instance member.

When xxTable2D is used through FMI there are no error checks relating to the file being loaded. The xxTable2D functions do generate both error codes and error messages but these does not affect the fmi2Status returned from ex the initialisation method. Also the logger received through the instantiate call should be used with e.g. logStatusFatal since I assume failure to read is fatal otherwise logStatusError see page 42 https://svn.modelica.org/fmi/branches/public/specifications/v2.0/FMI_for_ModelExchange_and_CoSimulation_v2.0.pdf remember to declare the category before using it, and respect the logging on flag.

Add the Vode Adams Integration routing in the FMU target

Trying to export an FMU from the SmartGrid_5_house.emx in the SmartGrid pilot study. I get the following output. I don't know if this is an issue with the moel or the FMU builder:

20-sim standalone co-simulation FMU export for 'Grid_5_house'

Creating an empty FMU
Generating a GUID: 3ebc31ed-23d2-4bc0-bfc9-5d92a0e34eb6
Generating the modelDescription.xml

Collecting resources

Searching for Visual C++ compiler...
Found Visual C++ 2015
Loading vsvar32
Microsoft (R) Build Engine version 14.0.23107.0
Copyright (C) Microsoft Corporation. All rights reserved.

EulerAngles.c
motionprofiles.c
xxfuncs.c
xxinteg.c
xxinverse.c
xxmodel.c
....\src\xxmodel.c(145): error C2065: 'xx_A': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(145): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(148): error C2065: 'xx_A': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(148): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(154): error C2065: 'xx_A': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(154): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(160): error C2065: 'xx_A': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(160): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(166): error C2065: 'xx_A': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(166): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(201): error C2065: 'xx_a': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(201): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(205): error C2065: 'xx_A': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(205): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
xxmatrix.c
fmi2Functions.c
xxsubmod.c
xxTable2D.c
Generating Code...
Microsoft (R) Build Engine version 14.0.23107.0
Copyright (C) Microsoft Corporation. All rights reserved.

EulerAngles.c
motionprofiles.c
xxfuncs.c
xxinteg.c
xxinverse.c
xxmodel.c
....\src\xxmodel.c(145): error C2065: 'xx_A': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(145): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(148): error C2065: 'xx_A': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(148): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(154): error C2065: 'xx_A': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(154): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(160): error C2065: 'xx_A': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(160): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(166): error C2065: 'xx_A': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(166): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(201): error C2065: 'xx_a': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(201): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(205): error C2065: 'xx_A': undeclared identifier [c:\temp\G
rid_5_house\project\VS2015\Grid_5_house.vcxproj]
....\src\xxmodel.c(205): error C2109: subscript requires array or pointer type
[c:\temp\Grid_5_house\project\VS2015\Grid_5_house.vcxproj]
xxmatrix.c
fmi2Functions.c
xxsubmod.c
xxTable2D.c
Generating Code...

Error: "Grid_5_house.dll failed to build! See ..\VS2015\Release\BuildLog.htm for details."

Press any key to exit...

I have just downloaded and tried the new version of 20-sim (4.6.2-intocps) with the Line Follower Sensor to see if the issue with Mac co-simulation is still present. I successfully generated the FMU and ran the co-sim in Windows without issue. I then used the FMU builder in the INTO-CPS app as normal and have tried this newly compiled FMU in Mac. I now get a different error which appears to crash the COE. Screenshot below.

The multi instance support assumes that the const fmi2CallbackFunctions* functions is available and points to a valid memory location during the library life time.

When I run two simulations in the same process with matching end time it works (by luck) but if one of the simulations has a longer simulation time then it crashes in freeInstance. By inspecting the code it seems like you store the fmi2CallbackFunctions pointer in a global variable g_fmiCallbackFunctions instead of inside the instance. Therefore field g_fmiCallbackFunctions is overriden by the fast running simulation and when the longer running simulation terminates it may happen medially after the location which g_fmiCallbackFunctions points to have been freed, and right before instantiate again is called resetting it to a valid memory address.

The COE in into-cps creates a callback object per instance and frees this after the instance is freed.

I modified the generated code to look like:

void fmi2FreeInstance(fmi2Component c) 
{
    XXModelInstance* xx_model_instance = (XXModelInstance*) c;

    if (xx_model_instance->resourceLocation != NULL)
    {
        //g_fmiCallbackFunctions->freeMemory
        free((void*)xx_model_instance->resourceLocation);
        xx_model_instance->resourceLocation = NULL;
    }

    if(xx_model_instance->instanceName != NULL)
    {
        //g_fmiCallbackFunctions->freeMemory
        free((void *)xx_model_instance->instanceName);
        xx_model_instance->instanceName = NULL;
    }
    //g_fmiCallbackFunctions->freeMemory
    free((void *) xx_model_instance);
    xx_model_instance =  NULL;
}

and ran two simulations simultaneously 873 and 1061 times without any issues with the fix shown above directly calling free to avoid using the global field (it should probably have been stored inside the instance instead). Without it I can run between 1 and 3.

The default way to specify the data file for table 2d to use is to right click and set the file name in the parameters menu, however if you do this the exported fmu does not contain the data file.

In the line follow sensors and the fan coil unit we had to add the file name directly into the parameters section (as below) and then the FMU export script correctly copies the data file when it creates the FMU.

parameters string table_file_name = 'ratSP5WorkingDays_2column.txt';

Currently the generated code supports only a single instance for each FMU.
To support the usage of multiple instances of the same FMU in a single co-simulation experiment, the FMU should internally have a separate model state storage for each instance, such that we can distinquish between instances...

Section 2.1.1 of the FMI 2.0 standard describes that FMUs shipped with source code should define the FMI2_FUNCTION_PREFIX as "theFMUname_".

The 20-sim generated FMUs contain both binaries for Windows and the source code. The generated source code should set this define.

As the initial states of a model ar set in the ModelInitialize function, which is called before initialEquations, it is not possible to influence a model by changing the parameters via FMI, as this would invalidate the initial state.

A possible fix would be to set the initial states again after the initialEquations have been executed.

This is more of a feature request then an issue, but as far as i can tell the fmi model is not capable of throwing fmi event via fmiEventUpdate when a state event happens.

Is there a possibility that this will be implemented?

I get the following compile error, when I try to compile export FMU code from 20-sim:

>make
------------------------------------------------------------
20-sim standalone co-simulation FMU export for:
vehicle
------------------------------------------------------------
[cc] src/fmi2Functions.c
[cc] src/EulerAngles.c
[cc] src/motionprofiles.c
[cc] src/xxfuncs.c
[cc] src/xxinteg.c
[cc] src/xxinverse.c
[cc] src/xxmatrix.c
[cc] src/xxmodel.c
[cc] src/xxsubmod.c
make: *** No rule to make target `project/gcc/Table2D.o', needed by `dll'.  Stop.

The bug is apperring with gcc and make on ubuntu 14.04.
But is is clearly a mistake in the make file that is being exported.

When building an FMU on Mac OS, strip is not able to remove some symbols resulting in an error:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: symbols referenced by indirect symbol table entries that can't be stripped in: /Users/tomlankhorst/20sim/pid/fmu/project/gcc/controller.so
_malloc
_strcpy
_strlen
_strncpy
_strtol
dyld_stub_binder
__DefaultRuneLocale
make: *** [dll] Error 1

This is fixed by adding the -x option to strip in the Makefile to only remove local symbols.

Alternatively, using GCC's gstrip works as well.

Referring to FMI 2.0.1 standard page 56: “Variables with causality = "parameter" or "input", as well as variables with variability = "constant", must have a "start" value.”

We noted that the exporter (standalone) doesn't register start values for the followings:
causality="local" variability="constant"
causality="input" variability="continuous"
causality="output" variability="continuous"

I tried to export the FMU2 standalone FMU on Mac and it almost generated enough code + config to be useful.

However, the xslt transformation fails, and the fmiGUID.h file is not generated:

------------------------------------------------------------
20-sim standalone co-simulation FMU export for 'SingleWatertank'
------------------------------------------------------------
Creating an empty FMU
Generating a GUID: 722f5355-81d2-4583-95f7-842f393862d4
Generating the modelDescription.xml

Error occurred while executing stylesheet 'Z:\Users\kel\data\into-cps\case-studi
es\case-study_single_watertank\FMUs\cg\template\mcf2modelDescription.xsl'.

Code:   0x800c0006
System error: -2146697210.
Collecting resources
Unable to collect resources. Could not find Python in "C:\ProgramData\Controllab
 Products B.V\Python34\python.exe"
Please re-install 20-sim 4.6 with Python support enabled.
------------------------------------------------------------
Searching for Visual C++ compiler...
"Could not find a supported Visual C++ (Express) compiler. Currently supported v
ersions in this template: 2010, 2013 and 2015"
Press any key to continue...

I manually created the fmiGUID.h header from the guid.txt and the XSLT transformation using http://www.freeformatter.com/xsl-transformer.html#ad-output and copied the source files to the correct location, inserted the guid in the modelDescription.xml and compiled it and it worked.

 #define FMI_GUID "{722f5355-81d2-4583-95f7-842f393862d4}"

This is not an issue report but information to improve the generator to work on mac. It could be cool if it could generate all the source files and modelDescription.xml so the user only had to compile it.

When the endless simulation is set (Run Properties > More > Endless) and a FMI model is exported.
The model still stops simulation after the finish time.
While one would expect the model to continue indefinitely.

This happens on version 4.6.1 (build 6898)

The index used in the index attribute in Unknown in outputs under model structure is wrong:

<?xml version="1.0" encoding="ISO-8859-1"?>
<fmiModelDescription fmiVersion="2.0" modelName="tank2" guid="{67d835d6-8a93-41f6-bd55-ed668d3c5b52}" generationTool="20-sim" numberOfEventIndicators="0" copyright="Controllab Products B.V." license="-">
<CoSimulation modelIdentifier="tank2" needsExecutionTool="false" canHandleVariableCommunicationStepSize="false" canInterpolateInputs="true" maxOutputDerivativeOrder="0" canRunAsynchronuously="false" canBeInstantiatedOnlyOncePerProcess="true" canNotUseMemoryManagementFunctions="true" canGetAndSetFMUstate="false" canSerializeFMUstate="false" providesDirectionalDerivative="false" />
<DefaultExperiment startTime="0.0" stopTime="16.0" />
<ModelVariables>
<ScalarVariable name="Drain1.p.p" valueReference="8" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="Drain1.r" valueReference="1" variability="fixed" causality="parameter">
<Real start="1.0" />
</ScalarVariable>
<ScalarVariable name="Drain1.puddle" valueReference="9" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.Node1.p1.p" valueReference="10" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.Node1.p2.p" valueReference="10" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.Node1.p3.p" valueReference="10" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.Node1.p1.phi" valueReference="14" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.Node1.p2.phi" valueReference="24" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.Node1.p3.phi" valueReference="12" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.Tank.p.e" valueReference="10" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.Tank.level" valueReference="11" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.Tank.area" valueReference="2" variability="fixed" causality="parameter">
<Real start="1.0" />
</ScalarVariable>
<ScalarVariable name="tank2.Tank.gravity" valueReference="3" variability="fixed" causality="parameter">
<Real start="9.81" />
</ScalarVariable>
<ScalarVariable name="tank2.Tank.liquid_density" valueReference="4" variability="fixed" causality="parameter">
<Real start="1.0" />
</ScalarVariable>
<ScalarVariable name="tank2.p1.p" valueReference="10" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.p1.phi" valueReference="14" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.p.p" valueReference="10" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.p.phi" valueReference="12" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.level" valueReference="11" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.FlowOut.p.e" valueReference="8" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.FlowOut.p.f" valueReference="23" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.FlowOut.flow" valueReference="23" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.FlowOut.effort" valueReference="8" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.R.p.e" valueReference="15" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.R.p.f" valueReference="23" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.R.FlowOut" valueReference="23" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.R.r" valueReference="5" variability="fixed" causality="parameter">
<Real start="7.0" />
</ScalarVariable>
<ScalarVariable name="valve2.R.waterFlow" valueReference="13" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.Valve.valvecontrol" valueReference="16" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.Valve.powerIn.p" valueReference="10" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.Valve.powerIn.phi" valueReference="14" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.Valve.powerOut.p" valueReference="15" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.Valve.powerOut.phi" valueReference="23" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.waterOut.e" valueReference="8" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.waterOut.f" valueReference="23" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.valveControl" valueReference="16" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.waterIn.p" valueReference="10" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="valve2.waterIn.phi" valueReference="14" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="p.p" valueReference="17" variability="continuous" causality="output">
<Real />
</ScalarVariable>
<ScalarVariable name="p.phi" valueReference="18" variability="continuous" causality="input">
<Real start="0.0" />
</ScalarVariable>
<ScalarVariable name="level" valueReference="19" variability="continuous" causality="output">
<Real />
</ScalarVariable>
<ScalarVariable name="valveControl" valueReference="20" variability="discrete" causality="input">
<Boolean start="0" />
</ScalarVariable>
<ScalarVariable name="Drain1.p.phi" valueReference="23" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="Drain1.p.phi_int" valueReference="21" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="Drain1.p.phi_int_initial" valueReference="6" variability="fixed" causality="parameter">
<Real start="0.0" />
</ScalarVariable>
<ScalarVariable name="tank2.Tank.p.f" valueReference="24" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.Tank.volume" valueReference="22" variability="continuous" causality="local">
<Real />
</ScalarVariable>
<ScalarVariable name="tank2.Tank.volume_initial" valueReference="7" variability="fixed" causality="parameter">
<Real start="0.0" />
</ScalarVariable>
</ModelVariables>
<ModelStructure>
<Outputs>
<Unknown index="17" />
<Unknown index="19" />
</Outputs>
</ModelStructure>
</fmiModelDescription>

it should have been

    <ModelStructure>
        <Outputs>
            <Unknown index="39" />
            <Unknown index="41" />
        </Outputs>
    </ModelStructure>

Note that index is the index of the scalarvariable = the number in the list of declared

E-mail reported: setting certain parameters in the Fan Control Unit example https://github.com/into-cps/case-study_fcu using the INTO-CPS co-simulation engine does not seem to work