search

ThummeTo / FMIFlux.jl

FMIFlux.jl is a free-to-use software library for the Julia programming language, which offers the ability to place FMUs (fmi-standard.org) everywhere inside of your ML topologies and still keep the resulting model trainable with a standard (or custom) FluxML training process.
MIT License
56 stars 15 forks source link

Usage of an input-function in the FMU-layer of a Chain is not possible, yet #132

Open juguma opened 6 months ago

juguma commented 6 months ago

Please provide an example (and presumably missing functionality) to include an input-function into the FMU-layer of an FMIFlux.Chain. This is crucial when you work with FMUs that only create reasonable output with nonzero input.

Remark:

  1. I know there are several options to define an input-function to an FMU: inputFunction!(t::T, u::AbstractArray{<:T}) inputFunction!(comp::FMU2Component, t::T, u::AbstractArray{<:T}) inputFunction!(comp::FMU2Component, x::Union{AbstractArray{<:T,1}, Nothing}, u::AbstractArray{<:T}) inputFunction!(x::Union{AbstractArray{<:T,1}, Nothing}, t::T, u::AbstractArray{<:T}) inputFunction!(comp::FMU2Component, x::Union{AbstractArray{<:T,1}, Nothing}, t::T, u::AbstractArray{<:T}) However I am not sure, if support of the more complex function types (i.e. those which do not only depend on t) are actually relevant for many users. I would be happy, if a purely time-dependent input function was supported.

  2. When extending functionality, please keep in mind that in batched training one might want to use different inputs on different batches. (..as we discussed for the batch-wise parameters. This might be worth a second ticket, once this one is finished).

juguma commented 3 months ago

As an update: I found a workaround for this one. If you are the owner of the FMU, you can export this FMU with a variable being equal to the (simulation) time. E.g. in Modelica: Real mytime = time: Export this variable together with the FMU. Then, in julia, you can "use" this variable via fmiGetReal(fmu.components[end],"mytime"), e.g. to define the "t" in the FMU-call: myFMU(;x=x,dx_refs=:all, t = fmiGetReal(fmu.components[end],"mytime")) or, to define an input function: myFMU(;x=x,dx_refs=:all,u_refs = my_input_refs, u = inputFctOOP(fmiGetReal(fmu.components[end],"mytime")) Remark (for myself 😏): For this, the inputFct which you define for your FMU (which by the FMI.jl-requirements should be in-place, see above), has to be rewritten as its out of place (OOP) variant.

One should be very well aware that this is really only a workaround (an ugly but working one). It's no excuse for not implementing this feature 🙃.