ANALYSIS

FMU Generation Analysis

The FMUAnalysis builds a binary Functional Mock-up Unit from a Dyad model, for use and execution in any FMI-compliant simulation tool.

Note that Dyad does not support generating source-code FMUs, although there will be some solutions for C-code generation for discrete-time models.

Current Limitations

• Cross-compilation is not supported; an FMU generated on an x86 Windows system will only run on another x86 Windows system. Note that this is not a limitation on e.g. the CPU or the version of the operating system, simply the general platform.

• If using Julia functions in the model, you must declare the Julia packages your model depends on in the additional_deps = ["Package1", "Package2", ...] argument to the analysis. Generally you would only need to put your current component library in this list - then, if the model works in simulation, it will work in the FMU.

• We currently only expose Float64/Real-typed parameters and variables through the FMI interface. This restriction will be lifted in future releases.

• There are a set of models which will not be able to compile to small FMUs (using the use_juliac parameter to the analysis). These include, but are not limited to:

  • Models with discrete-time components.

  • Models with missing parameters that need to be solved for at initialization time.

  • Models with Any-typed parameters or variables.

  • Models that run type-unstable code.

If you run into one of these limitations, please open an issue or contact us and we will be happy to help you out.

Example Definition

analysis MyFMUAnalysis
  extends DyadFMUGeneration.FMUAnalysis(
    n_inputs = 0,
    n_outputs = 1,
    outputs = ["y"],
  )
  model = BlockComponents.Sources.Sine(frequency = 1.0, amplitude = 1.0)
end

The Dyad compiler will generate the MyFMUAnalysis function that will run the analysis.

    MyFMUAnalysis()

UndefVarError: `MyFMUAnalysis` not defined in `Main`
Suggestion: check for spelling errors or missing imports.

This builds an FMU. The path for the FMU is given as an artifact:

using DyadInterface
fmu_path = artifacts(result, :FMU)

Analysis Arguments

Required Arguments

• model: the Dyad model that the analysis is being applied to.

Optional Arguments

• version::String: the FMU version to use. Defaults to "FMI_V2", with the other possible choice being "FMI_V3".

• type::String: the type of FMU to build. Choices are "FMI_ME" for Model Exchange, "FMI_CS" for Cosimulation, or "FMI_BOTH" for a binary which has both embedded within it.

• alg::ODEAlg: chooses the solver algorithm for the solution process of the Cosimulation FMU. This is the same as the argument in TransientAnalysis for the solver algorithm. The default is ODEAlg.Auto(). The choices are:

  • ODEAlg.Auto() - Automatic algorithm choice with stiffness detection, size detection, and linear solve swapping from OrdinaryDiffEq.jl.

  • ODEAlg.Rodas5P() - Adaptive time Rosenbrock method from OrdinaryDiffEqRosenbrock.jl. The Rosenbrock methods are specifically fast for small systems of stiff equations and DAEs which avoid Jacobian singularity issues (i.e. no variable-index DAE behavior).

  • ODEAlg.FBDF() - Adaptive order, adaptive time fixed leading coefficient backwards differentiation formulae (BDF) method from OrdinaryDiffEqBDF.jl, modeled after the FLC formulation of VODE. This is a good method for large stiff systems and DAEs.

  • ODEAlg.Tsit5() - 5th order explicit Runge-Kutta method from OrdinaryDiffEqTsit5.jl. This method is not applicable to DAEs and is only applicable to systems which have no algebraic constraints (post simplification).

• n_inputs::Integer: the number of inputs, i.e. the length of the $u(t)$ vector.

• inputs::String[n_inputs]: the variables of the Dyad model which will be defined by the inputs. The ordering of the vector needs to match the ordering of the $u(t)$ vector definition.

• n_outputs::Integer: the number of outputs, i.e. the length of the output of $h$.

• outputs::String[n_outputs]: the names of the variables to include in the output vector $h$. The ordering of the vector needs to match the ordering of $h$.

• use_juliac::Bool: Whether to use the juliac-based pipeline for small binaries. true by default.

• verbose::Bool: Whether to show all output on the terminal screen. false by default. When false, writes output to temporary log files.

• logfile::String: Path to write stdout and stderr to. When empty (default), temporary files are used. When a path is provided, both stdout and stderr are written there. Ignored when verbose is true.

• respecialize::Bool: Whether to re-specialize the model based on the current parameters. true by default. Generally should be true.

• additional_deps::Vector{String}: Additional Julia package dependencies to bundle into the generated FMU.

• overrides::Nothing: Defaults to nothing. This parameter is added for API compatibility with the Dyad AnalysisSpec. Currently this arg is ignored.

Artifacts

The FMUAnalysis returns the following artifacts:

Standard Artifacts

• :FMU: A string for the path to the generated FMU.

Method Overview

The Dyad compiler uses the physical description of the system to generate a system of differential-algebraic equations:

$$\begin{array}{rl}{x}^{\prime }& =f(x,y,u,p,t)\\ 0& =g(x,y,u,p,t)\\ & h(x,y,u,p,t)\end{array}$$

where $x$ are the differential variables, $y$ are the algebraic variables, $p$ are the parameters, and $t$ is the independent variable (time). Notably, the difference from the other analyses, such as TransientAnalysis and SteadyStateAnalysis, is the existance of the values $u$ which are the input functions. These u(t) are values which are given by connections in the system in which the FMU connected. Additionally, $h$ is the output function. As such the generated FMU is a causal component defined with only input and output connectors, no acausal connectors.

For a Model Exechange FMU, a binary is created which executes the $(f,g,h)$ functions of the right-hand side from the state and input values. For a Cosimulation FMU, an ODE solver of the form from a TransientAnalysis is embedded into the system. I.e. a Cosimulation FMU is a clocked component which takes a dt and solves using an ODE solver to predict $(x(t),y(t),h(x(t),y(t),u,p,t))$ where the input value $u$ is a constant given at the clock time.