Issues found in FMI2 configuration of Reference FMUs about reference-fmus HOT 4 CLOSED

@nickbattle, can you propose a fix?

from reference-fmus.

@t-sommer I can propose arbitrary changes that will pass validation, but these are reference FMUs which presumably are intended to work in a particular way, so I think the FMU authors really ought to decide what the correct settings should be.

In the Resource/FMI2.xml case, the variable "y" is invalid because its "initial" clause defaults to "calculated" and you cannot have a "start" value if a variable is calculated. So one solution would be to remove the start clause. Or you could define a different "initial" setting. I don't know the intent of the model, so I can't guess which is appropriate.

Fixing the "InitialUnknowns" just means adding a InitialUnknowns section to the ModelStructure that is the same as the Outputs section. Though if you change the initial value of "y", you don't have to include it in the InitialUnknowns (only "approx" or "calculated" outputs are needed in InitialUnknowns).

The fix for Stair/FMI2.xml is easier. From the name "counter", I assume it is discrete rather than continuous, and therefore should have a variability of "discrete" rather than the default, which is "continuous".

If someone can indicate which changes are appropriate, I can re-validate them.

from reference-fmus.

therefore should have a variability of "discrete" rather than the default, which is "continuous"

The FMI 2.0.1 Spec is ambiguous here:

on page 48 it says:

(a) Only a variable of type = “Real” can be “continuous”. [...] (b) The default is “continuous”.

IMHO the (b) takes precedence over (a).

In FMI 3.0 this has been clarified:

The default is continuous for variables of type <Float32> and <Float64>, and discrete for all other types.

from reference-fmus.

Yes, I agree, otherwise we do not know the variability of non-Reals without explicit variabilities. The formal model always regards ScalarVariables with a missing variability as "continuous". In the case of your PR, that causes another error, because the type is now "Integer" which cannot be "continuous". It needs a variability clause to say the variable is "discrete".

As you say, this is clarified in FMI3 and the formal model therefore implements this and your PR changes for the FMI3.xml are accepted (though the InitialUnknowns issue remains in both).

from reference-fmus.