fmi-standard
fmi-standard copied to clipboard
modelica
Missing dependencies on tunable parameters
Reported by manuel.graeber on 10 Oct 2017 15:00 UTC For optimization applications I need the structural information, if outputs of a model exchange FMU directly depend on tunable parameters.
Use Case: FMU outputs in cost functions or constraints of an optimization problem. Derivative based algorithms need to know, if there are direct dependencies on optimization variables (tunable parameters).
Reading the FMI Spec, there seems to be something missing. On page 58 tunable parameters are listed, just as I would expect it:
(𝐲𝑐, 𝐲𝑑) ≔ 𝐟𝑜𝑢𝑡𝑝𝑢𝑡(𝐱𝑐, 𝒖𝑐, 𝒖𝑑, 𝑡, 𝒑𝑡𝑢𝑛𝑒)
But on page 61 in the description of the attribute "dependencies", tunable parameters are not listed anymore.
Is there a reason for it?
Migrated-From: https://trac.fmi-standard.org/ticket/424
Regular design meeting:
We should add this to output dependencies. "Tunable parameters are essentially discrete inputs".
Regular Design Meeting:
Adding partial derivatives w.r.t. to parameters would introduce a larger change for implementing partial derivatives by tools. We can move to this to FMI 3.1
A clarification is needed that by intent that parameters and tunable parameters are not part of the knowns in step mode. @friedrichatgc : I could create a PR for this.
To add a bit more detail to this issue, Suppose I have the following model.
Parameters: $p_0$
Tunable Parameters: $p_1$
Calculated Parameters: $p_2$
Inputs: $u_3$
Outputs: $y_4$
All vars are reals (Float64): $p_0, p_1, p_2, u_3, y_4 \in \mathbb{R}$
Assignments active on initialization mode:
$p_2 := p_0 + p_1$
$y_4 := (p_1 + p_2)*u_3$
Assignments active on continuous time mode (when doStep executes):
$y_4 := (p_1 + p_2)*u_3$
Assignments active when tunable parameter $p_1$ changes:
$p_2 := p_0 + p_1$
$y_4 := (p_1 + p_2)*u_3$
Question 1: It is clear from the standard that the value of calculated parameter $p_2$ can be queried with fmi3GetFloat64 during initialization mode. Does the FMU exporter have to explicitly declare $p_2$ as an initial unknown with dependencies to $p_1$ and $p_0$, so that the FMU importer knows that $p_0$ and $p_1$ must be set before querying $p_2$ during initialization mode? The standard says that dependencies on "freeze variables" (= variables which cannot be changed in the current mode) are implicit. Since parameters can be changed in initialization mode, then I presume that they are not freeze variables and therefore the FMU exporter needs to declare the aforementioned dependencies, right?
Question 2: Given that we can change the values of tunable parameters during the simulation, then I would expect that $p_2$ is declared as an <Output> element of the <ModelStructure> , with a dependency to $p_1$, right? Moreover, $y_4$ needs to include a dependency to $p_2$ as well.
The answer to question 1 takes a bit of digging around the document to find, mostly because the definition of "freeze variables" is given in an informal way (and repeated multiple times).
The answer to question 2 seems impossible to get, because the <Output> of the <ModelStructure> is defined as:
Ordered list of all outputs, in other words, a list of value references where every corresponding variable must have <<causality>> = <<output>> (and *every variable with <<causality>> = <<output>> must be listed here*).
That is, it excludes variables whose causality is calculatedParameter.
@andreas-junghanns, @chrbertsch, and @friedrichatgc, I understand that the decision was not to include this because it would be too large of a change (see https://github.com/modelica/fmi-standard/pull/830), and I agree with that decision.
However, as you can see in the above example, the FMU importer has to assume that $y_4$ depends on the tunable parameters as well as the other parameters.
In short, this needs to be clarified in the standard:
- Freeze variables include tunable parameters (maybe we should not use the term "freeze" anymore in that case).
The consequence is that, e.g, an FMU with 1000 outputs and 1 tunable parameter, will need to recompute all outputs when that tunable parameter changes. Given the need to reinitialize solvers and all that stuff that needs to be done to avoid impulses, I'd say this is a small price.
FMI Design Meeting Berlin:
Torsten: We do not exclude tunable parameters in FMI 3.0 in 2.3.8 "model structure" Markus F.: a tunable parameter is not a continuous variable Torsten B: it is up to the tool how to do this
@CSchulzeTLK : I will check
The issue is resolved with FMI 3.0. The dependency information and the partial derivatives can be provided.
In table 24 (https://fmi-standard.org/docs/3.0/#dependencies) variables with causality "parameter" are counted as knowns in Continuous-Time Mode and Event-Model (ME) and at communication points (CS and SE). Therefore the dependency information of parameters on outputs can be provided by an exporting tool using the dependencies attribute.
Additionally, the derivative can be provided (https://fmi-standard.org/docs/3.0/#partial-derivatives). The section for the partial derivatives refers to the dependencies attribute description mentioned above.
