Support for (u, t) Input Functions about fmi.jl HOT 5 CLOSED

Makes sense!

from fmi.jl.

Also in-place-input-modification (as option) would be a thing ...

from fmi.jl.

Thinking about it, there are some problems, for example the state u is not known (in general) for CS-FMUs. So (u, t) input functions would only be a thing for ME-FMUs... I will keep this in mind and try to find a good solution. In general, also the FMU2Component would be useful to know inside f.

So f(component::FMU2Component, t::fmi2Real) for CS- and ME-FMUs
and as an alernative f(component::FMU2Component, u::Array{fmi2Real, 1}, t::fmi2Real) for ME-FMUs only?

from fmi.jl.

Yes, input functions which depend on u makes sense only in ME FMUs.

from fmi.jl.

This will be supported in the release v0.10.0:

Input functions need to meet one of the following patterns:

• inputFunction(comp::FMU2Component, t::fmi2Real)
• inputFunction(t::fmi2Real)

Additionally - for ME only - there are:

• inputFunction(comp::FMU2Component, u::Union{AbstractArray{fmi2Real,1}, Nothing}, t::fmi2Real)
• inputFunction(comp::FMU2Component, u::Union{AbstractArray{fmi2Real,1}, Nothing})
• inputFunction(u::Union{AbstractArray{fmi2Real,1}, Nothing}, t::fmi2Real)

Note to check u !== nothing before using it, because the first call might be u=nothing (if no start state is given, the start state is solved during initalization of the FMU, after the initial inputs are set).

from fmi.jl.