Start values for inputs about fmi-guides HOT 4 CLOSED

@nickbattle I agree BTW that the whole set of rules on start values and the defaults of initial are quite involved and not particularly clear. And it makes sense to check for stuff that already is prohibited through other means. I just wanted to point out that at least for inputs and parameters the situation is slightly clearer and there is no such thing as a default start value value, so to speak.

from fmi-guides.

I'm not sure whether the start value has a default (the Standard is unclear), but there is a rule within the VDM model that checks that an "implicit zero" start value (ie. no value) is within the min/max range, if specified. Currently this is only a warning, because I'm not sure what the rule should be!

That is, "if the start is not defined, and the variable not calculated or independent, any min value must be <=0 and any max value must be >= 0". The "or true" on the end means this will never fail, but you see the warning.

from fmi-guides.

I would turn the problem description around:

Given the standard, all input variables must have a start value defined (see 2.4.5.7), and regardless of the value of initial, this start value must be suitable in the sense that the importer can, but explicitly does not have to, change its value during initialization.

In other words: An FMU must provide suitable start values for its inputs, i.e. an importer is always allowed to not set them at all (not during initialization and if the input value does not change even during runtime).

So an FMU that provides non-suitable start values, i.e. ones that already create errors inside the FMU if not changed, is not really a useful FMU. It might not be the fault of the exporting tool, since the user is in control, but the FMU is definitely broken from a usability point of view.

So the guidance in the IG should first of all warn exporters and users of exporters not to create such FMUs.

It can then also warn importers that stupid FMUs are going around, and that it might be a good idea to sometimes ignore the provided start values. But that will be highly problem-dependent: In general the FMU will have more knowledge of useful starting points for initialization than the importer.

To answer your question @chrbertsch: It is allowed to set start values (either exact or approx) in/before initialization, but it is neither required nor recommended to do so: Unless the importer has superior knowledge why would it deviate from what the FMU is advertising as good start values. Of course in a connected system it often will have superior knowledge in the form of outside constraints, but that depends on what the importer does with the FMU.

@nickbattle For inputs at least, the start attribute is mandatory, so the question of a default start value does not arise. Generally there is no default start value: If initial is (or defaults to) exact/approx, a start value must be provided, and if initial is (or defaults to) calculated, then a start value must not be provided (because the value is strictly unknown and must be inquired at run time), hence there is never any default that comes into play.

Aside: The guard of this rule also seems slightly wrong: initial can only be calculated not independent: The actual rule is that if initial is calculated or if causality is independent, then a start value must not be provided.

from fmi-guides.

@pmai thank you for the clarification. There are definitely other rules elsewhere about having or not having a start value, depending on other settings. The extract I quoted is looking for a mistake that the user may have made - so it may well be that such a configuration would fail on other points, and the value of this extra check is limited. (But yes, I'll fix the test!)

from fmi-guides.