modelica-tools/fmucompliancechecker

FMI Compliance Checker for validation of FMUs 1.0 and 2.0

Important

The development of the FMU Compliance Checker has been discontinued. Please use one of the tools listed on https://fmi-standard.org/validation/ instead.

FMI Compliance Checker

Background information for FMI Compliance Checker (FMUChecker) application.

• For build instructions see: BUILD.md
• License information is provided in: LICENSE
• Acknowledgements for used software: ACKNOWLEDGEMENTS.md
• Instructions for how to make a release: HOW-TO-RELEASE.md

The FMI Compliance Checker is intended for validation of FMU 1.0 and 2.0 compliance to the standard specification as published at http://www.fmi-standard.org

The basic features include:

• automatic unzipping into a temporary directory
• checking of XML model description
  • for syntax errors
  • for correct order of elements and correct cardinality or relations
  • for correct cross-references
  • for semantic consistency
• validation of binary FMUs compiled for "standard32/default" platform for Windows (.dll), Linux (.so) and Mac OS (.dylib).
  • loading of the binary module
  • checking whether all required functions are available
  • for model exchange FMUs test whether the FMU can be simulated with explicit (forward) Euler method
    • fixed step size is used
    • no iterations for exact location of state events
  • for co-simulation FMUs test whether the FMU can be simulated with fixed communication step size
  • log computed solution to csv result file (comma separated values, file format is by default compatible with RFC4180, the header contains variable names, first column is time, alternative field separator may be specified as an option).
  • can supply numerical input data to the simulation from an CSV file. Input start values from FMU binary (not XML) will be used in case no input is provided. String inputs are currently not supported. The input file is expected to be RFC4180 compatible with following modifications:
    • The file must be in UTF-8 encoding
    • First line must be a header listing the variable names
    • First column must be time
    • Variable names shall match the names in the modelDescription.xml file exactly
    • Variable names may be put in double quotes according to the RFC4180 rules
    • Decimal separator for numerical data is a dot
    • Numerical data shall not be quoted
    • Boolean data must be represented with 0 for false and 1 for true
    • Field separator may be any printable ASCII character (detected automatically)
    • End of line may be either CR-LF or just LF.
• validation log messages are written to stderr. Can be redirected to file.

Usage: fmuCheck.<platform> [options] <model.fmu>

Options:

-c <separator>   Separator character to be used in CSV output. Default is ','.

-d               Print also left limit values at event points to the output
                 file to investigate event behaviour. Default is to only print
                 values after event handling.

-e <filename>    Error log file name. Default is to use standard error.

-f               Print all variables to the output file. Default is to only
                 print outputs.

-h <stepSize>    For ME simulation: Decides step size to use in forward Euler.
                 For CS simulation: Decides communication step size for the
                 stepping.
                 Observe that if a small stepSize is used the number of saved
                 outputs will still be limited by the number of output points.
                 Default is to calculated a step size from the number of output
                 points. See the -n option for how the number of outputs is
                 set.

-i <infile>      Name of the CSV file name with input data.

-l <log level>   Log level: 0 - no logging, 1 - fatal errors only, 2 - errors,
                 3 - warnings, 4 - info, 5 - verbose, 6 - debug.

-m               Mangle variable names to avoid quoting (needed for some CSV
                 importing applications, but not according to the CrossCheck
                 rules).

-n <numSteps>    Maximum number of output points. "-n 0" means output at every
                 step and the number of outputs are decided by the -h option.
                 Observe that no interpolation is used, output points are taken
                 at the steps.
                 Default is 500.

-o <filename>    Simulation result output CSV file name. Default is to use
                 standard output.

-s <stopTime>    Simulation stop time, default is to use information from
                 'DefaultExperiment' as specified in the model description XML.

-t <tmp-dir>     Temporary dir to use for unpacking the FMU.
                 Default is to use system-wide directory, e.g., C:\Temp or /tmp.

-v               Print the checker version information.

-k xml           Check XML only.
-k me            Check XML and ME simulation.
-k cs            Check XML and CS simulation.
                 Multiple -k options add up.
                 No -k option: test XML, simulate ME and CS respectively if
                 supported.

-x               Check XML only. Same as -k xml.

-z <unzip-dir>   Do not create and remove a temp directory but instead use the
                 specified one for unpacking the FMU. The option takes
                 precendence over -t.


Command line examples:

fmuCheck.win32 model.fmu
        The checker on win32 platform will process 'model.fmu' with default
        options.

fmuCheck.win64 -e log.txt -o result.csv -c , -s 2 -h 1e-3 -l 5 -t . model.fmu
        The checker on win64 platform will process "model.fmu". The log
        messages will be saved in log.txt, simulation output in
        result.csv and comma will be used for field separation in the CSV
        file. The checker will simulate the FMU until 2 seconds with
        time step 1e-3 seconds. Verbose messages will be generated.
        Temporary files will be created in the current directory.

fmucompliancechecker's Issues

Clearly define that the entry point to the documentation contained in an fmu should be "index.html"

Reported by cbertsch on 8 Jan 2017 07:11 UTC
In the FMI 2.0 standard, on p. 66 it is suggested that the entry point to the documentation is “index.html” (in the Structure of zip file of an FMU).
However, it is not clear whether this is only an example name, or if this name is mandatory. (e.g. the FMU SDK uses _main.html instead of index.html in its examples).
My suggestion for FMI 2.0.1 would be, that if the optional documentation folder is present in the FMU, an “index.html” file will be mandatory. This could then be checked by the Compliance Checker.

---

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

CMakeLists.txt contains non-ascii characters (probably wrong quote chars)

In line 39 (and others) of CMakeLists.txt a comparison is made with the string ”unknown”, where the quote chars are not regular " quote chars, but others from a different code page. This may cause a build to fail or at least the check to fail. Unless intended, I suggest changing these to regular quotation characters.

Crash: linux64, version 2.0.4, when parameter misses type declaration

See attached file (rename to P_Control.fmu first)

fmuCheck.linux64 P_Control.fmu

[INFO][FMUCHK] FMI compliance checker 2.0.4 [FMILibrary: 2.0.3] build date: Nov  6 2017
[INFO][FMUCHK] Called with following options:
[INFO][FMUCHK] /home/ghorwin/git/FMICodeGenerator/third_party/FMUChecker-2.0.4-linux64/fmuCheck.linux64 P_Control.fmu
[INFO][FMUCHK] Will process FMU P_Control.fmu
[INFO][FMILIB] XML specifies FMI standard version 2.0
[ERROR][FMI2XML] No variable type element for variable P. Assuming Real.

Program received signal SIGSEGV, Segmentation fault.
0x00005555555841ac in fmi2_xml_compare_vr_and_original_index ()

P_Control.zip

Release 2.0.4 Server SSL certificate verification failed

The release 2.0.4 contains a reference to an untrusted SVN repo and this it is not possible to compile the tool. (required for mac as no binary is released for this platform)

Skipped one specific time step write out in simulation

Hello,

when I check a FMU with the following settings:
-h 1e-2 -s 5
the results write out goes directly from time 0.9 to 1.1 skipping time 1.

As far as I can tell the results are correct.
Only this time step is skipped, and only with these settings(?).
Any FMU; log from bouncingBall.fmu.
Tested with: Linux64, Win64, 2.0.4 binary release.

Logfile attached: see line 147

logfile.log
result_csv.txt

Unable to build FMI Compliance checker

The steps mentioned build are incorrect. If we create a build dir and give cmake command in that directory as describd in build steps, it give an error that CMakeList.txt file does not exist. If we copy it to build dir, it give an error that CMakeList location is not same as where source was created. Moreover it also does not allow you to build in source dir.

Deprecated capability flag canSignalEvents of FMU CS 1.0.1

The FMU Compliance Checker v2.0.4 raises an XML error if an FMU CS 1.0.x mentions the canSignalEvents capability flag in modelDescription.xml.

[ERROR][FMI1XML] Detected on line:555 of modelDescription.xml
[ERROR][FMI1XML] Found capability flag canSignalEvents which have been deprecated as it fills no function 

Since this flag was only deprecated for FMI 1.0.1 (see modelica/fmi-standard#370) and a valid FMU 1.0.0 also is a valid FMU 1.0.1 this should not be considered as error. Rather I propose to consider it as XML warning.

@TorstenBlochwitz FYI

Improve allocation diagnosis

With FMUComplianceChecker v2.0.4 I can see an error message if freeMemory was called less often than allocateMemory, e.g.,

[ERROR][FMUCHK] Memory leak: freeMemory was not called for 1 block(s) allocated by allocateMemory
FMU check summary:
FMU reported:
	0 warning(s) and error(s)
Checker reported:
	0 Warning(s)
	1 Error(s) 

It would be more convenient if the FMUComplianceChecker directly prints the leaked pointer(s), at least if the log level is verbose or debug. This way, I could run the FMUComplianceChecker with log level verbose or debug and can directly see the leaked pointer(s), which simplifies the actual debugging of the leaks.

Technically, you can use troydhanson/uthash to build lists or hash maps in C in order to keep track of the allocated pointers.

What is the scope of the Compliance Checker?

Reported by andreas.junghanns on 12 Nov 2015 12:13 UTC
It is currently not clear to everyone what the Compliance Checker should be used for.

---

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

eventInfo flags ignored during event iteration

Reported by ottot on 5 Feb 2016 07:59 UTC
The compliance checker ignores the nominalsOfContinuousStatesChanged and valuesOfContinuousStatesChanged eventInfo flags except for the last call during event iteration. See the following code:

fmi2_status_t do_event_iteration(fmi2_import_t *fmu, fmi2_event_info_t *eventInfo)
{
	fmi2_status_t fmistatus = fmi2_status_ok;
	eventInfo->newDiscreteStatesNeeded = fmi2_true;
	eventInfo->terminateSimulation     = fmi2_false;
	while (eventInfo->newDiscreteStatesNeeded && !eventInfo->terminateSimulation) {
		fmistatus = fmi2_import_new_discrete_states(fmu, eventInfo);
	}
	return fmistatus;
}

We have the following fragments from the specification.

If valuesOfContinuousStatesChanged = fmi2True then at least one element of the
continuous state vector has changed its value due to the function call.

If no element of the continuous state vector has changed its value, valuesOfContinuousStatesChanged must return fmi2False. [if

The end effect of this is that the compliance checker ignores all nominalsOfContinuousStatesChanged and valuesOfContinuousStatesChanged flags returned from fmi2NewDiscreteStates expect the ones returned from the last call.

Tested with 2.0.1.

---

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

Compliance checker should signal crash on exit/unloading of FMU caused by OpenMP-spindown

Hi all,
there is a general problem with FMUs that employ OpenMP. Symptoms are:

• compliance checker runs successfully through FMU compiled in debug mode with 0 warnings and 0 errors
• when compliance checker runs with release-mode FMU, it stops silently after the last simulation output line

4.3200000000000000E+005,0.0000000000000000E+000,2.0000000000000000E+001,0.0000000000000000E+000
[INFO][FMUCHK] Simulation finished successfully at time 432000

> (command prompt appears)

Cause of the problem is a untrapped segfault. On both Visual Studio and gcc compilers, for performance reasons, the OpenMP threads spawned in parallel sections are kept for a few milliseconds after the parallel section was closed. This is to avoid the overhead of repeatedly opening/closing parallel sections. In debug mode, the delay of a few milliseconds between last parallel section and unloading/deleting FMU memory is sufficient. In release mode, the threads are still spinning while the master thread terminates and dll memory is freed. Thus, threads access the mutex/lock variable memory which has been freed already and segfault.

This problem should be adressed in the FMU itself by adding a sufficient delay past in the destructor of the FMU memory/dll unload function.

However, the compliance checker should still gracefully trap such a problem by raising a warning/error about crashes/segfaults during unloading/terminating of FMUs. When such an FMU is used in a simulation environment (i.e. Modelica simulator), it will may potentially crash the host application and thus cause data loss.

To analyse this problem, please see attached FMUs (remove the trailing zip extension first):

• PipeCollectorModel_win64.fmu the original variant without explicit spin-down waiting
• PipeCollectorModel_win64_waiting.fmu, variant with spin-down waiting

Note the console output of both FMUs at unloading of FMU.

PipeCollectorModel_win64.fmu.zip
PipeCollectorModel_win64_waiting.fmu.zip

4.3200000000000000E+005,0.0000000000000000E+000,2.0000000000000000E+001,0.0000000000000000E+000
[INFO][FMUCHK] Simulation finished successfully at time 432000
[InstanceData::~InstanceData] waiting 100 ms
[InstanceData::~InstanceData] end
[fmi2FreeInstance]
FMU check summary:
FMU reported:
        0 warning(s) and error(s)
Checker reported:
        0 Warning(s)
        0 Error(s)

Verify that all derivatives have the derivative attribute

Reported by ottot on 3 Jan 2017 10:39 UTC
From page 54 of the standard (2.0), regarding the derivative attribute:

The state derivatives of an FMU are listed under element
<ModelStructure><Derivatives>. All ScalarVariables listed in this element must have 
attribute derivative

The compliance checker could be enhanced to actually verify that all variables listed in <Derivatives> have the required derivative attribute.

---

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

FMUComplianceChecker-2.0.3 illegal calling sequence

Reported by awad.mukbil on 26 Jan 2017 15:29 UTC
During my work on creating reference FMUs, I tried to test the Compliance Checker with a reference FMU that deals with integer variables to test integer capabilities. I provided the Compliance Checker with integer inputs and the FMU triggered the following errors:

[FMU][logError][FMU status:Error] fmi2SetInteger: Illegal call sequence.
[FATAL][FMUCHK] Simulation loop terminated at time ... since FMU returned status: Error

because the it calls fmi2SetInteger in Continuous-Time Mode, which is not allowed according to the standard p. 85.

[FMU][logError][FMU status:Error] fmi2Terminate: Illegal call sequence.
[ERROR][FMUCHK] fmiTerminate returned status: Error

Last error returned fmi2Error, by which the state changed to error and it is not allowed to call fmi2Terminate.

This is related to the ticket #20. The experiment data are attached.
experiment.zip

---

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

Additional checks for correct model structure in Compliance Checker needed

Reported by awad.mukbil on 7 Feb 2017 11:53 UTC
The compliance checker does not detect errors in the attached FMU (which is, e.g. rejected by Dymola). The attached FMU is an erroneous FMU of bouncingBall.fmu that came with QTronic FMUSDK 2.0.4. The following two errors in the <ModelStructure> element of the modeldescription.xml should be detected:

Error 1: Invalid Derivatives indices in ModelStructure element

According to the FMI version 2.0 standard, page 58, only state derivatives should be listed in <Derivatives>(not states). In this FMU, the <Derivatives> has elements with indices of states [1, 3], instead of state derivatives [2, 4].

Error 2: Invalid InitialUnknowns indices in ModelStructure element

According to the FMI version 2.0 standard, page 60, variable listed should be:

1. causality = "output" and (initial="approx" or "calculated").
2. causality = "calculatedParameter".
3. continuous-time states and all state derivatives (defined with element <Derivatives> from <ModelStructure>) with initial="approx" or "calculated" (not “exact”)
   In this FMU, the <InitialUnknowns> has elements with indices of states with initial="exact" [1, 3], instead of state derivatives with initial="calculated" [2, 4].

The Compliance Checker should be updated to detect these errors in the modelDescription.xml file. Attached are the FMU and batch of Compliance Checker command to run this FMU and generate log file.
CC_ModelStructure.zip

---

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

How does FMUComplianceChecker Manage StepIncomplete?

Hello,
I would like to know how FMUComplianceChecker deals with an FMU which is in the StepIncomplete status following a do_step call, as in the attached image.

My question fits in a larger context: we have a software which uses FMUs (FMI version 1) as slaves. We observe do_step failures when we call the FMUs with our software. However, despite our best efforts to provide exactly the same input sequence to FMUComplianceChecker, we do not manage to reproduce the do_step failure.

One hypothesis brought by the team developing the FMU slaves is that we do not handle properly the StepIncomplete status and that we should do just as the FMUComplianceChecker since it works (no do_step failure). However, so far and with my limited understanding of the FMUComplianceChecker code, I have not found how this was done.

Thank you for any input!
Best regards,
Amélie

specify license explicitly

It is hard to understand the license for this project due to 2 reasons:

• the license.md is formatted wrongly, therefore the 3 bullet points of the license text are not seen as bullet points
• everyone coming along must identify the text of license.md by himself/herself. Please use the github repository settings to explicitly select "BSD 3 clause" (at least that is my guess for your license text). That way github will show that term immediately on the top right of the homepage, instead of only linking to the license.md file. See https://help.github.com/en/github/building-a-strong-community/adding-a-license-to-a-repository for details.

Extend FMU compliance checker to Source Code FMUs

Reported by cbertsch on 9 Nov 2015 19:16 UTC
Currently for C-source code FMUs only the XML file can be checked.
As more and more support import and export of C-Code FMUs (e.g. for HiL applications), the FMU compliance checker should be extended in this direction.

The final goal of automatic compilation and execution of the Source code FMU within the compliance checker might be a hard task.

However, there are some steps in-between, that do not require too much effort:

• Check for the Correct directory structure within the FMU's sources directory
• fmi2TypesPlatform.h and fmi2FunctionTypes.h/fmi2Functions.h *not* included in the FMU
• all necessary c source filed, header files and run-time libraries are present in the FMU according to the include structure
• ...

Please add additional issues to be checked for source code FMUs as comments.

---

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

States shouldn't be set to their nominal values

FMUComplianceChecker/src/FMI2/fmi2_me_sim.c

Line 267 in dcc15ab

!fmi2_status_ok_or_warning(fmistatus = fmi2_import_get_nominals_of_continuous_states(fmu, states, n_states))) {

The states should not be set to their nominal values when the nominal values change.

Since the checker currently uses a fixed step euler it doesn't have any use for the nominal values so a possible fix could be to store the nominals in a temporary buffer that is later discarded, in that way it at least verifies that it's possible to call the fmi2GetNominalContinuousStates.

Access is denied

I am attempting to test an FMU generated from Dymola 2017 FD01 as a version 1 co-simulation.

In the command line I type:
C:\Users\jshul\Desktop\FMUChecker-2.0.4-win32>fmuCheck.win32.exe -e log.txt -o results.csv -c , -t . TACE_West.fmu C:\Users\jshul\Desktop\FMUChecker-2.0.4-win32\fmucktmpa28968\binaries\win32\TACE_West.dll - Access is denied.

I get the log file:

`[INFO][FMUCHK] FMI compliance checker 2.0.4 [FMILibrary: 2.0.3] build date: Nov 6 2017
[INFO][FMUCHK] Called with following options:
[INFO][FMUCHK] fmuCheck.win32.exe -e log.txt -o results.csv -c , -t . TACE_West.fmu
[INFO][FMUCHK] Will process FMU TACE_West.fmu
[INFO][FMILIB] XML specifies FMI standard version 1.0
[INFO][FMI1XML] Processing implementation element (co-simulation FMU detected)
[INFO][FMUCHK] Model name: TACE_West
[INFO][FMUCHK] Model identifier: TACE_West
[INFO][FMUCHK] Model GUID: {c0013606-7e0b-4b03-8918-8b24cfc220f0}
[INFO][FMUCHK] Model version:
[INFO][FMUCHK] FMU kind: CoSimulation_StandAlone
[INFO][FMUCHK] The FMU contains:
0 constants
486 parameters
2 discrete variables
7 continuous variables
3 inputs
6 outputs
486 internal variables
0 variables with causality 'none'
494 real variables
1 integer variables
0 enumeration variables
0 boolean variables
0 string variables

[INFO][FMUCHK] No input data provided. In case of simulation initial values from FMU will be used.
[INFO][FMUCHK] Printing output file header
[INFO][FMILIB] Loading 'win32' binary with 'standard32' platform types
[INFO][FMUCHK] Version returned from FMU: 1.0
[INFO][FMUCHK] Checking that FMI set functions can be called with zero length arrays
[INFO][FMUCHK] Initialized FMU for simulation starting at time 0
[INFO][FMUCHK] Checking that FMI get functions can be called with zero length arrays
[INFO][FMUCHK] Simulation finished successfully at time 1.3171e-07
FMU check summary:
FMU reported:
0 warning(s) and error(s)
Checker reported:
0 Warning(s)
0 Error(s)
`

Is this a known issue? Is there a way around it?

Invalid link to FMILibrary repository

The link
SVN_REPOSITORY "https://svn.jmodelica.org/FMILibrary/tags/2.0.3"
is invalid. The FMI library has moved to
https://github.com/svn2github/FMILibrary

Check for mandatory elements in the model structure.

Reported by cbertsch on 8 Jan 2017 08:06 UTC
The FMI Compliance Checker 2.0.3 does currently not check for mandatory elements of the model structure in the modeldescription.xml

p.58 of the FMI 2.0 Standard: Outputs: Ordered list of all outputs, in other words a list of ScalarVariable indices where every corresponding ScalarVariable must have causality = "output" (and every variable with causality=”output” must be listed here).

Currently it is not checked, if the "outputs" are present in model structure. If the outputs are defined in the model structure, it is not checked, if the provided index really corresponds to an output. It is not checked if defined dependencies follow the rules defined on p. 61 of the FMI 2.0 standard.

E.g. instead of the following modeldescription.xml (part)

...

<ModelVariables>
  <ScalarVariable name="a_" valueReference="0" causality="input" variability="continuous" initial="approx">
    <Real start="1"/>
  </ScalarVariable>
  <ScalarVariable name="b_" valueReference="1" causality="input" variability="continuous" initial="approx">
    <Real start="2"/>
  </ScalarVariable>
  <ScalarVariable name="c_" valueReference="2" causality="output" variability="continuous" initial="calculated">
    <Real />
  </ScalarVariable>
</ModelVariables>

<ModelStructure>
  <Outputs>
    <Unknown index="3" dependencies="1 2"/>
  </Outputs>
</ModelStructure>

...

also

<ModelStructure>
</ModelStructure>

or

<ModelStructure>
  <Outputs>
    <Unknown index="1" dependencies="2 3"/>
  </Outputs>
</ModelStructure>

are accepted by the current compliance checker.

The same as for outputs is also true for the derivatives.

---

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

Problem when compiling with Visual Studio 2015 / 2017

Hi,

I get the following error, when I try to compile the Compliance Checker with Visual Studio 2015 or 2017

fatal error C1189: #error: Macro definition of vsnprintf conflicts with Standard Library function declaration

The error is caused by the redefinition of (v)snprintf in the c99_snprintf project.

I suggest to insert the following preprocessor directive.

#if defined(_MSC_VER) && _MSC_VER >= 1900
#define HAVE_SNPRINTF 1
#define HAVE_VSNPRINTF 1
#endif

Best
Olaf

Debugging Segmentation Fault.

Hi,

I am trying to validate EnergyPlus's FMU export function in Ubuntu. I convert a basic example inside EnergyPlus 8.5 and then validate it through this Checker, but it shows "Segmentation Fault".

Here's what I did:
(EnergyPlus-specific steps)

1. Create an expanded IDF file from EnergyPlus (EnergyPlus-8-5-0/ExampleFiles/BasicFiles/Excercise2B-Solution.idf), which will create *.expidf
2. Convert the IDF file into FMU using an export tool (http://simulationresearch.lbl.gov/fmu/EnergyPlus/export/)

(Checker step)
3. Run fmuCheck.linux64 -l 6 ./eplusout_expidf.fmu

It results in

[VERBOSE][FMUCHK] Setting log level to [DEBUG]
[VERBOSE][FMUCHK] This binary is build without debug log messages.
 Reconfigure with FMUCHK_ENABLE_LOG_LEVEL_DEBUG=ON and rebuild to enable debug level logging
[INFO][FMUCHK] FMI compliance checker Test [FMILibrary: Test] build date: Oct 11 2018
[INFO][FMUCHK] Called with following options:
[INFO][FMUCHK] /home/jbkoh/tools/FMUComplianceChecker-2.0.4/build/fmuCheck.linux64 -l 6 ./eplusout_expidf.fmu
[INFO][FMUCHK] Will process FMU ./eplusout_expidf.fmu
[VERBOSE][FMILIB] Allocating FMIL context
[VERBOSE][FMILIB] Detecting FMI standard version
[VERBOSE][FMIZIP] Unpacking FMU into /tmp/fmucktmpTD5gNL
[VERBOSE][FMIXML] Parsing XML to detect FMI standard version
[VERBOSE][FMIXML] XML specifies FMI 1.0
[INFO][FMILIB] XML specifies FMI standard version 1.0
[VERBOSE][FMILIB] Parsing model description XML
[VERBOSE][FMI1XML] Parsing XML element fmiModelDescription
[VERBOSE][FMI1XML] Parsing XML element ModelVariables
[VERBOSE][FMI1XML] Checking alias information
[VERBOSE][FMI1XML] Setting up direct dependencies cross-references
[INFO][FMI1XML] Processing implementation element (co-simulation FMU detected)
Segmentation fault (core dumped)

I wanted to have a hint from the EnergyPlus communuity, but was out of luck, so decided to debug it myself. How should I devug Segmentation fault in this case?

Thanks!

Verify target of Real variables with attribute 'derivative'

When a variable references what other variable they are a derivative of, no warning/error is produced if the referenced variable cannot have a derivative.

Example of part of XML that doesn't produce any warnings/errors:

<ModelVariables>
    <!-- idx: 1 -->
    <ScalarVariable name="state_var" valueReference="0" variability="discrete" initial="exact">
      <Boolean start="true"/>
    </ScalarVariable>
    <!-- idx: 2 -->
    <ScalarVariable name="der(state_var)" valueReference="1" causality="output" variability="continuous" initial="approx">
      <Real derivative="1" start="1.0"/>
    </ScalarVariable>
</ModelVariables>

<ModelStructure>
  <Derivatives>
    <Unknown index="2"/>
  </Derivatives>
</ModelStructure>

I believe there are two levels of strictness:

1. continuous/discrete Real variables
2. (continuous/discrete) state variables - the target of the derivative attribute has some more limitations (I guess it has to have causality=local/output)

Checking Directory Structure

Reported by mtiller on 17 Sep 2015 21:02 UTC
In working with JModelica, I identified an issue that probably appears in other tools and is a direct artifact of how Windows delimits directories.

The issue I have found relates to page 40 of the FMI 1.0 specification. I didn't check, but I suspect the same will be true for 2.0. There, you will see that the specification very explicitly indicates that within an FMU, the structure should be:

binaries/
win32/
.dll

This indicates that the zip file (at least for Windows) should contain a directory named binaries which contains a directory named win32 which should contain the .dll files for the model.

In JModelica, this is not the case although I suspect somehow unzip utilities are compensating in some way. With JModelica, the file structure is this:

binaries\win32/
.dll

The essential point here is the presence of the \ in the name. The net effect here is that what you have created is a zip file with a directory named "binaries\win32" which contains the .dll files. This is not simply an issue with my unzip tool, I've confirmed this more than one zip implementation.

Given that most of these FMUs are run on Windows systems and tools in that environment probably have to be tolerant of such things, I can perfectly understand how this was not caught before.

This is something that should be added to the FMI compliance checker

---

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

Error removing tmp/ clang

Hi,

When I launch fmuChecker on a FMU containing a .so compiled with clang++, I get the following log :

[INFO][FMUCHK] Simulation finished successfully at time 1  
[ERROR][JMPRT] Error removing /tmp/fmucktmpjbhZ6x (Success)  
FMU check summary:  
FMU reported:  
	0 warning(s) and error(s)  
Checker reported:  
	0 Warning(s)  
	1 Error(s)  

Command that I have entered : fmuCheck.linux64 lambda.fmu
When the .so of the FMU is compiled with g++ there is no problem.

Incorrect instance name initialized in cdata structure

In line 37 in file fmi2_cs_sim.c, instanceNameToCompare initialized with incorrect value "Test FMI2.0 CS". The value is not overwritten anywhere again and thus I get a runtime error while using compliance checker. Should be initialized as in the attached file line 38
and then the compliance checker works fine.

Check calls with zero-size arrays as mentioned in the new 1.0.1 standard

The checker should check that the FMUs accept calls with zero-size arrays (see 1.0.1 spec p. 13).

Add check for missing initial value when using enumerations in input variables

Hi there. I noticed a (probably) invalid modelDescription that is not yet flagged as wrong by compliance checker 2.0.4. Please see the following scalar variable definition:

<!-- Index of variable = "523" -->
<ScalarVariable
    name="Input.flowDirection"
    valueReference="20"
    description="Allowed flow direction"
    variability="fixed"
    causality="input"
    >
    <Enumeration declaredType="Modelica.Fluid.Types.PortFlowDirection"/>
</ScalarVariable>

Here, the initial value is missing and according to the table in "Functional Mock-up Interface 2.0", July 25, 2014, Page 48 of 126 the combination of fixed and input is invalid without initial variable.

From the co-simulation master point of view, the initial value is needed for initializing the input variable, so that a calculation is possible even without connected inputs.

Suggestion: as stated in the standard, "do not use fixed inputs, but rather use fixed parameters". So this may be a warning issued by the compliance checker, even if a start value is given.

IMHO, in any case, "initial"="exact" and a start value should be given in the enumeration for such cases.

FMU Checker does not perform semantic checks on scalar variables

(moved from https://trac.fmi-standard.org/ticket/398; reported by Lausdahl)

The FMU Checker seems to be missing the semantics checks from the standard and thus not reporting any error for modelDescription.xml which contain obvious errors.

Here is an example. The model description includes this scalar variable:

<ScalarVariable

    name="logicalNot.y"
    valueReference="186">
    <Boolean/>

</ScalarVariable>

This is of cause not allowed since the standard says as follows:

    variability
    "continuous": Only a variable of type = “Real” can be “continuous”.
    ModelExchange: No restrictions on value changes.
    CoSimulation: By convention, the variable is from a differential

and

The default is “continuous”

So the above scalar variable can be expanded as follows:

<ScalarVariable

    name="logicalNot.y"
    variability="continuous"
    valueReference="186">
    <Boolean/>

</ScalarVariable>

So defining this with type Boolean is an error and should be reported.

Some of the Test_FMUs have this issue e.g:
Test_FMUs/FMI_2.0/CoSimulation/win32/MWorks/2016/ControlledTemperature/ControlledTemperature.fmu
Test_FMUs/FMI_2.0/CoSimulation/win32/MWorks/2016/BooleanNetwork1/BooleanNetwork1.fmu Reason

Already built in compliance checker executable is looking for incorrect FMI API

The compliance checker downloaded is looking for API name "fmi2GetModelTypesPlatform" in the fmu for version 2.0. This API had been renamed to "fmi2GetTypesPlatform" sometime back.

Improved error messages for structured naming check

The messages generated by the structured naming check could be more informative. Example of a current message with little information on what is actually wrong:

[ERROR][FMI2XML] Invalid structured ScalarVariable name "Rectifier_r(60)": syntax error, unexpected $undefined, expecting $end.

Exception handling

Reported by anonymous on 14 Dec 2012 21:38 UTC
The official FMU Checker 2.0a1 (on Windows 7) crashes if the loaded FMU DLL gives an exception like an access violation or floating point overflow. The FMU Checker shall catch such exceptions and shall give a hint which function threw which kind of exception (if possible), e.g.

Exception in Model.dll: Model_fmiSetTime.
Access violation at address 012345678. Read of address 00000000.

or simply

Exception in Model.dll:
Floating point division by zero.

.

---

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

Check for present start values

It would be good to include a check if start values are set according to “If initial= exact or approx, or causality = ′′input′′ a start value must be provided”. on p. 47 of the FMI 2.0 standard.

FMU Checker does not terminate for fmi2Status fmi2Fatal

When returning a fatal error in function fmi2NewDiscreteStates the FMUComplianceChecker does not terminate model simulation but tries to call function fmi2NewDiscreteStates again.

So setting
FMI2_Export fmi2Status fmi2NewDiscreteStates(fmi2Component c, fmi2EventInfo* fmiEventInfo) { return fmi2Fatal; }
yields to an infinite loop.

The FMI specification 2.0 page 17 states:

fmi2Fatal – the model computations are irreparably corrupted for all FMU instances. [For example,
due to a run-time exception such as access violation or integer division by zero during the execution
of an fmi function]. Function “logger” was called in the FMU (see below) and it is expected that this
function has shown the prepared information message to the user. It is not possible to call any other
function for any of the FMU instances.

I get this behavior with pre-build executable version 2.0.4 on 64Bit Windows 10 and build of commit dcc15abc94038a7afb8d4828d2bf3ea359de6c09 on 64Bit Unix system.
Can someone reproduce this problem?

Add pre-built Windows and Linux binaries to Release Assets

Would be really nice if the binaries from https://trac.fmi-standard.org/browser/branches/public/Test_FMUs/Compliance-Checker would also be available as assets at the releases page.

Testing procedure for FMI 2.0 interface and setting/getting state support

Slowly the number of FMI 2.0 supporting FMUs increases and quite a few provide the feature of storing/restoring the state. I suggest adding the following test procedure to the compliance checker for Co-Simulation FMUs with FMI 2.0 support:

1. store/restore state check

   • After "exitInitializationMode" ask FMU to store its state via fmi2GetFMUstateXXX (compliance checker remembers handle)
   • Simulation is done for a few steps, results are logged in file 1
   • tell FMU to restore its state to saved state via fmi2SetFMUstate
   • Simulation is done again for same number of steps, results are compared to those stored in file 1 -> exakt match is required (since even multi-step integrators will not have a history at simulation start)

2. multiple state handling checks

   • start simulation, run until say 10% of simulation time
   • store handle 1
   • continue simulation, run until say 20% of simulation time
   • store handle 2
   • continue simulation, run until say 30% of simulation time
   • restore state to handle 2
   • run again until 30% -> compare results -> close match is required in interval 20-30% compared to first run
   • restore state to handle 1
   • run again until 30% -> compare results -> close match is required in interval 20-30% compared to first run

Note about "close match" requirement:
See discussion about restoring state of error controlled, multi-step methods: When the stored state does not include full history, or when last step was not synchronized with communication interval end - the continued simulation will likely have different results; for example, the simulation could be continued with a "cold-start", i.e. method order 1, smallest time step, hereby taking completely different steps within the communication interval as in the first iteration, thus yielding (slightly) different results.

3. Serialization test (only for FMUs that support this; mainly necessary to check for correct re-initialization of external resources being used by the FMU)
   • run full simulation once
   • re-init (completely from scratch)
   • start simulation, run until say 10% of simulation time
   • retrieve FMU state and store to file
   • re-init (completely from scratch)
   • read FMU state from file and set state in FMU
   • continue simulation until end -> close match is required for results in both runs

At last, some consistency checks - may require use of valgrind or other memory leak checkers.

4. (optional) memory allocation/consistency check:
   Motivation: often, problems with resource leaks are not detected in small test cases. However, when an iterative master algorithm is used for a whole simulation, the get/set-state procedure may be repeated many 1000 times, and even a small mistake in memory/resource allocation will cause problems here.
   • procedure 1 (with short simulation interval in between) is repeated at n times, with intermittend calls to fmi2FreeFMUstateXXX
   • memory footprint of FMU model should not grow uncontrolled (a growth of memory footprint would indicate a resource leak) -> alternatively check with valgrind or other leak checker

FMUComplianceChecker stops compiling on recent macOS / xcode with clang 12

Hi,
the reason for the failing build is that FMIL no longer compiles, because its thirdparty dependency minizip no longer compiles with clang 12.
I opened an issue at the FMIL Repository - see here. If those guys fix their 3rd party dependency code to work with clang 12, you will probably need to fix your CMake build config to pull the most recent version of FMIL - instead of 2.0.x.

End of simulation time not propagated for FMUs 2.0 for co-simulation

The latest version of FMUChecker (2.0.4) seems to not propagate the simulation stop time to FMUs 2.0 for co-simulation.

The following line indicates that the last argument of fmi2_import_setup_experiment() is set to 0 as opposed to tEnd.

FMUComplianceChecker/src/FMI2/fmi2_cs_sim.c

Line 50 in f0fd0b2

fmi2_status_ok_or_warning(fmistatus = fmi2_import_setup_experiment(fmu, toleranceControlled,relativeTolerance, tstart, fmi2_false, 0.0)) &&

Consequently, FMUChecker will not use the stop time provided as parameter. Changing the value to tEnd will lead to the correct behavior.

Compliance checker: attribute initial forbidden for inputs

Reported by cbertsch on 17 Jan 2017 17:11 UTC
In the FMI 2.0 specification it is stated on p.47:
"Enumeration that defines how the variable is initialized. It is not allowed to provide a value for initial if causality = input or independent".
This is currently not checked by the compliance checker.
I attached an FMU containing this error.

---

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

The XML checking of the compliance checker does not validate the schema

Reported by sjoelund.se on 19 Jan 2017 12:43 UTC
Currently, if you try to upload an FMU containing:

<ModelStructure>
  <Outputs>
  </Outputs>

this is rejected by the post-commit hook with a cryptic error message. This is due to failing to validate the XML schema (xsd files). The fmuChecker happily accepts the FMU though, and it works in all importing tools I have encountered. It would be good if FMIL could validate the schema.

---

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

Simulation both for ME and CS

Reported by andreas.pfeiffer on 30 Jan 2015 07:27 UTC
If an FMU contains both ME and CS models, then the FMU compliance checker simulates ME and CS, but there is only one result file. Please could you clarify?

Would it be possible to add an option to specify if the simulation for ME or CS or both should be run?

---

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

Validation of FMI 2.0 InitialUnknown indices

The compliance checker does not validate indices used in unknowns in the ModelStructure/InitialUnknowns element of modelDescription.xml.

The FMI 2.0 standard (p. 60) specifies that InitialUnknowns is an

Ordered list of all exposed Unknowns in Initialization Mode. This list consists of all variables with
(1) causality = "output" and (initial="approx" or "calculated"), and
(2) causality = "calculatedParameter" and
(3) all continuous-time states and all state derivatives (defined with element from ) with initial="approx" or "calculated" [if a Co-Simulation FMU does not define the element, (3) cannot be present.].

However, the following example passes an XML check:

<ModelVariables>
  <ScalarVariable name="v1" valueReference="0" causality="parameter" variability="fixed" initial="exact">
    <Real start="0"/>
  </ScalarVariable>
  <ScalarVariable name="v2" valueReference="1" causality="parameter" variability="fixed" initial="exact">
    <Real start="0"/>
  </ScalarVariable>
</ModelVariables>
<ModelStructure>
 <InitialUnknowns>
    <Unknown index="1"/>
    <Unknown index="2"/>
  </InitialUnknowns>
</ModelStructure>

A check should be made that the listed unknowns are actually unknowns. This could also be extended to cover the knowns it depends on.

Compliance checker does not verify order of structured names

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

Compliance Checker should check for unit referred to by scalar variables or simple types

Reported by aviel on 22 Sep 2016 08:37 UTC
In FMI 2.0, the units referred to by the simple types or scalar variables shall be defined in the unit definitions section. A missing unit name should be reported as an error, since it is mandatory to define all the units that are used by the FMU.

---

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

FMUChecker missing check for optional authority in fmuResourceLocation URI

(moved from https://trac.fmi-standard.org/ticket/389; reported by: lausdahl)

The FMUChecker does not check if the FMU respects the FMI standard concerning the fmuResourceLocation URI for the instantiate call.

The check must check that instantiate can be called with the scheme file and a fully qualified path both with and without the authority as described in the standard:

Argument fmuResourceLocation is an URI according to the IETF RFC3986 syntax to
indicate the location to the “resources” directory of the unzipped FMU archive. The
following schemes must be understood by the FMU:

Mandatory: file with absolute path (either including or omitting the authority component)
Optional: http, “https”, “ftp”
Reserved: fmi2 for FMI for PLM. 

The FMU checker only tries to call it with authority. e.g. "file:///C:/temp/MyFMU/resources but it should also check that "file:/C:/temp/MyFMU/resources is accepted.

The defect was discovered when exported FMUs for the FMI standard version 2 was exported from FMI Toolbox for MATLAB/Simulink version 2.3.3 where the FMU checker reported that the FMU was ok. This as shown in the tool site for FMI.

However, they are not compliant because they only support the fmuResourceLocation with empty authority but the standard states that they must support an URI where the authority is left out.

FMUChecker-2.0.3 issues in Continuous Time Mode

Reported by arunkumar.palanisamy on 31 Oct 2016 11:24 UTC
I was doing FMU cross checking tests with fmus (FMI2.0) generated from OpenModelica, When performing tests I am getting errors related to some fmi2 functions in continuous-time mode. According to the fmi2specification Page 85.

In Continuous-Time Mode only fmi2SetReal is allowed, but some examples involves setting fmi2setInteger and fmi2setBoolean in time continuous mode also, Currently when generating fmus from OpenModelica we generate fmus allowing only fmi2SetReal in Time-continuous mode. So when checking with FMU compliance checker the model fails.

Should all the fmi2set(Integer,string,Boolean) be allowed in time-continuous mode like fmi2setReal?

---

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

Compliance Checker should allow string inputs

Reported by cbertsch on 24 May 2017 15:26 UTC
When passing a string input in the input CSV-file to the compliance checker, an error is returned:

[ERROR][FMUCHK] Inputs must be real, integer, enum or boolean. Cannot process variable 'b'

---

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

FMUChecker not exiting when fmiGetReal() returns error

Reported by maplesoft on 16 Jun 2016 19:11 UTC
For FMI 1.0 Model Exchange, the FMUChecker (version 2.0.3b2) fails to exit when fmiGetReal() returns an error.

When the FMUChecker log level is greater than 1, an error returned by fmiGetReal is repeated in the log for each variable in the model.

The FMUChecker will only exit when fmiGetDerivatives() returns the error.

---

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

Real discrete input values not read correctly from the input file (v2.0.4)

Using a co-simulation with multiple real value inputs that are discrete I have seen that the first value in the input file is copied to all real inputs. For example a model with real discrete variables A, B, C and an input file that using the compliance checker with an input similar to:

"time","A","B","C"
0,1.0,2.0,3.0

The output file (using -f) will show:

"time","A","B","C"
0,1.0,1.0,1.0

If I use integers or continuous no issue.

I originally raised this here:
ghorwin/FMICodeGenerator#32

But I believe the issue is not with the code generator but seems to be the compliance checker.