modelica-tools / fmucompliancechecker Goto Github PK
View Code? Open in Web Editor NEWFMI Compliance Checker for validation of FMUs 1.0 and 2.0
License: BSD 3-Clause "New" or "Revised" License
FMI Compliance Checker for validation of FMUs 1.0 and 2.0
License: BSD 3-Clause "New" or "Revised" License
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.
(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
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:
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].
According to the FMI version 2.0 standard, page 60, variable listed should be:
causality = "output"
and (initial="approx"
or "calculated"
).causality = "calculatedParameter"
.<Derivatives>
from <ModelStructure>
) with initial="approx"
or "calculated"
(not “exact”
)<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
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.
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
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
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.
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
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
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
.
Consequently, FMUChecker will not use the stop time provided as parameter. Changing the value to tEnd
will lead to the correct behavior.
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
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
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
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.
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 ()
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
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)
EnergyPlus-8-5-0/ExampleFiles/BasicFiles/Excercise2B-Solution.idf
), which will create *.expidf(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!
FMUComplianceChecker/src/FMI2/fmi2_me_sim.c
Line 267 in dcc15ab
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.
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?
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)
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.
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
It is hard to understand the license for this project due to 2 reasons:
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
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
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.
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
.
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
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
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
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
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
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
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
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
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:
derivative
attribute has some more limitations (I guess it has to have causality=local/output
)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?
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.
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:
Please add additional issues to be checked for source code FMUs as comments.
Migrated-From: https://trac.fmi-standard.org/ticket/354
The checker should check that the FMUs accept calls with zero-size arrays (see 1.0.1 spec p. 13).
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.
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.
Hi all,
there is a general problem with FMUs that employ OpenMP. Symptoms are:
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):
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)
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.
(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.
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.
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
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.
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:
store/restore state check
multiple state handling checks
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.
At last, some consistency checks - may require use of valgrind or other memory leak checkers.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.