dont write 'INF' into modelDescription.xml

[j-heyden]

According to FMI standard using INF in xml files is not allowed (https://github.com/modelica/fmi-standard/issues/1784).

If there is a Simulink block Saturation, where the upper limit has the value inf and all parameters are visible (set_param(Sysroot,'VisibleParameters','')), this leads to

<ScalarVariable name="Parameters.Saturation_UpperSat" valueReference="1" causality="parameter" variability="tunable">
  <Real start="INF"/>
</ScalarVariable>

when using FMIKit 3.0 and Matlab 2021b. This INF is then wrong interpreted by other tools, as INF is not a allowed value.

[t-sommer]

What would be your preferred behavior for non-finite start values in FMI 2.0?

[chrbertsch]

What would be your preferred behavior for non-finite start values in FMI 2.0?

What about using the maximum allowed values?

[t-sommer]

The start value in the XML has to match the value in the binary. So you have two options:

• change the start value in the model, or
• remove the variable from the XML

[oliverkotte]

but isn't @chrbertsch 's suggestion a valid third option? the values in the XML and binary would match by convention, the max allowed value in the XML would correspond to INF in the binary.

[t-sommer]

If you have the following parameter in the binary

#include <math.h>

double Saturation_UpperSat = INFINITY;

// ...

how do you want to represent its start value in the XML without using the literal INF?

[chrbertsch]

how do you want to represent its start value in the XML without using the literal INF?

Perhaps it would be best (for FMI 2.0 FMUs) to replace INF during Code and XML generation by DBL_MAX (approx 1.8e308). Then XML and Code would be consistent.

This would work, if there are no hard comparisons to INF in the Code. (e.g., if x==INF)

[t-sommer]

You cannot make assumptions about the importers code. E.g. isfinite(x) would give different results when using the value from the XML vs. the binary.