-
Notifications
You must be signed in to change notification settings - Fork 80
Allow FMUs to require start values #38
Comments
The default start values given in the xml has to be included in the compiled or the source code fmu. |
As there is no current way of specifying different start values of the FMU in the cross check, an FMU that requires a different set than the default is not compliant with the cross check rules |
The point is to test if different start values are set correctly by the importing tool. If an FMU has different start values compiled in than what is in the XML it's simply illegal and should be excluded from the cross-check. |
Would people export such fmu's? Potentially make it harder for them to get passed by vendors not handling it correctly? |
This would indeed be an ideal case for "ReferenceFMUs" not exported by a commercial tool, but with the expectation that every tool can simulate them correctly (or explain why start value cannot be set in this tool). But in order to include this in the XC, we have to extend the XC infrastructure to support this. |
That is exactly the intention of the Feedthrough Test-FMU. |
Discussion at Design Meeting Regensburg: Good idea. |
Often simulations fail because start values are not being set correctly (e.g. in the wrong state). It would be good to optionally allow test FMUs to specify start values that have to be set in order to reproduce the reference results e.g. as an (optional) file
StartValues.csv
:Tunable parameters could be provided via the existing
*_in.csv
. These changes would not require any updates of the existing FMUs and results.The text was updated successfully, but these errors were encountered: