remove fmi3SetTime

[masoud-najafi]

After adding the Float32 datatype, fmi3SetTime needs to support both Float32 and Float64, unless we do an explicit cast for Fload32. Explicit cast does not seem to be a good idea, because we have already had the casting experience with Integer datatype. My proposal is just simply remove the fmi3SetTime API and adding an attribute indicating the refernce of the "Independent" variable (time) in the ModelExchnage FMI3 attributes.

[KarlWernersson]

This is true and a good solution if we want to support 32 bit float for time, however we have said that other functions like, Get/SetContinouosStates getDirectionalDerivatives SetInpuDerivatives, getEventIndicators etc are limited to 64bit float in the api, why should we not also limit this for time?

[andreas-junghanns]

I agree with Karl here. Plus, numeric dirt is already a headache with 64bit float as time. Why would anyone want 32bit? Masoud: Can you please give us more rational on why a 32bit time is desirable?

[masoud-najafi]

No I am not for Float32 at all. My point is since it was agreed to introduce Flaot32, all API with fmi2Real need also support this new datatype. Foar setTime it is easy, because it can be removed and we get rid of one API.

[andreas-junghanns]

But time is special and deserves explicit handling with it's own API, right?

[masoud-najafi]

We have an 'independent' causality that can indicate the independent time variable. Unless 'independent' means other thing that Time. I have seen some FMUs that already expose their internal time as a varaible. The only issue to remove this API may be the necessity of doing some speacial treating in the stateChart (the same that we do for fmi2SetTime).

[KarlWernersson]

From the standard

"independent": The independent variable (usually “time”). All variables are a function of this independent variable. variability must be "continuous". At most one ScalarVariable of an FMU can be defined as "independent". If no variable is defined as "independent", it is implicitely present with name = "time" and unit = "s". If one variable is defined as "independent", it must be defined as "Real" without a "start" attribute. It is not allowed to call function fmi2SetReal on an "independent" variable. Instead, its value is initialized with fmi2SetupExperiment and after initialization set by fmi2SetTime for ModelExchange and by arguments currentCommunicationPoint and communicationStepSize of fmi2DoStep for CoSimulation. [The actual value can be inquired with fmi2GetReal.]

As I understand now what you can do with the independent variable is to specify different time unit for the FMU, and to allow getDirectoinalDerivatives to retrieve the time derivative of variables. And call getReal to retrieve the time value.

By enforcing the use of the "independent" variable and removing setTime we might have to change the setupExperiment. In addition with the current definition any FMU that provides directional derivatives must provide the time derivative of all output, and all state time-derivatives (second time derivative), and we would have to explicitly forbid it to be float32 if we want to forbid that. Or we will have to redefine all these things.

If we instead keep things as is, we don’t have to do all these things. We could even allow 32float for the independent as a signal to the environment that this FMU internally uses 32bit float for time evaluation so that an importer can give appropriate warnings (while still enforcing casts in the setTime function).

[chrbertsch]

FMI-Design Meeting Regensburg:

• currently we could do a redundant exposure of time
• one is not allowed to call a setReal on it

proposal: keep it as is, one could expose it (also getting directional derivatives.