FMU export generates an empty ModelStructure

[Adrian Pop]

When FMU exporting the attached model we get some elements in the ModelStructure but they are empty:

translateModelFMU(Driver,"2.0","cs"); getErrorString();

gets you:

  <ModelStructure>
    <Outputs>
    </Outputs>
    <Derivatives>
    </Derivatives>
    <InitialUnknowns>
    </InitialUnknowns>
  </ModelStructure>

[Adrian Pop]

Partially fixed in f11f59c2012caedbe53899b220b65916e030edaf/OMCompiler

We have now the Outputs, still missing InitialUnknowns:

  <ModelStructure>
    <Outputs>
      <Unknown index="1" dependencies="" dependenciesKind="" />
      <Unknown index="8" dependencies="" dependenciesKind="" />
    </Outputs>
    <Derivatives>
    </Derivatives>
    <InitialUnknowns>
    </InitialUnknowns>
  </ModelStructure>

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Lennart Ochel]

@wbraun You stated in several OSMC dev meetings that you will also provide the missing information for initial unknowns, as requested in #4424. Therefore, I assign this ticket to you.

This missing part of the model description information is crucial. Can you please elaborate on the status and estimate when this can be tested?

[Willi Braun]

In ​PR1938 I prepared an initial implementation for the detection of dependencies for the initialization.

The missing part is to filter the initialization BackendDAE for the relevant variables:

FMI spec page 60
(1) causality = "output" and ( initial="approx" or "calculated" ), and
(2) causality = "calculatedParameter" and
(3) all continuous-time states and all state derivatives (defined with element
<Derivatives> from <ModelStructure> ) with initial="approx" or
"calculated" [if a Co-Simulation FMU does not define the
<Derivatives> element, (3) cannot be present.].

@lochel You know the initialization part best, so can you can fix this part.

[Lennart Ochel]

Replying to wbraun:

In ​PR1938 I prepared an initial implementation for the detection of dependencies for the initialization.
@lochel You know the initialization part best, so can you can fix this part.

I cannot spend any time on this in, at least, the next weeks. There is also no connection to the actual implementation of the initialization, right? So I suggest that you just finish the PR, since you did already most of the work anyway. That would also save the work power needed to understand what you already did.

[Willi Braun]

Replying to lochel:

Replying to wbraun:

In ​PR1938 I prepared an initial implementation for the detection of dependencies for the initialization.
@lochel You know the initialization part best, so can you can fix this part.

I cannot spend any time on this in, at least, the next weeks.

Me too :(, so let's split the work :).

Replying to lochel:
There is also no connection to the actual implementation of the initialization, right? So I suggest
that you just finish the PR, since you did already most of the work anyway. That would also save
the work power needed to understand what you already did.

Yes, I think there is a clear connection to the current implementation of the initialization, since we need to know, how specific variables are initialized:

FMI Spec, page 47
values for initial:
• = " exact ": The variable is initialized with the start value (provided under Real ,
Integer , Boolean , String or Enumeration ).
• = " approx ": The variable is an iteration variable of an algebraic loop and the
iteration at initialization starts with the start value.
• = " calculated ": The variable is calculated from other variables during initialization.
It is not allowed to provide a “ start ” value.

So we need the crefs of the variables (states, states derivatives, outputs and parameters) with initial="approx" or initial="calculated" and causality = "calculatedParameter" at this
​line. Collecting this information from the initBDAE should be quite easy for you, since I'm not that familiar with it.

[Willi Braun]

Only the model structure for InitialUnknowns is left.

[Francesco Casella]

@lochel, do you think you can take care of this in time for the 1.13.0 release?

Thanks!

[Lennart Ochel]

Milestone changed as discussed in today’s meeting.

[Francesco Casella]

@lochel, can you take care of this issue for the 1.14.0 release?

[Francesco Casella]

@lochel, could you post an update on the status of this issue? ​PR1938 is still open, it would be good to go through it.

Thanks!

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2.

This issue, previously marked as blocker for 1.14.0, is rescheduled to 1.15.0

[Lennart Ochel]

The ModelStructure is now generated correctly:

  <ModelStructure>
    <Outputs>
      <Unknown index="1" dependencies="" dependenciesKind="" />
      <Unknown index="9" dependencies="" dependenciesKind="" />
    </Outputs>
    <InitialUnknowns>
      <Unknown index="1" dependencies="3 4 5 6" dependenciesKind="dependent dependent dependent dependent" />
      <Unknown index="9" dependencies="2 10" dependenciesKind="dependent dependent" />
    </InitialUnknowns>
  </ModelStructure>

[Francesco Casella]

@lochel, is it possible to backport this to 1.15.0 also?

Thanks!

[Lennart Ochel]

Replying to casella:

@lochel, is it possible to backport this to 1.15.0 also?

This would require to pick all the related changes from the last 7 weeks. There are also known regressions that I have to fix first. I would rather like to not include the changes now in 1.15.0 and instead provide a strongly improved 1.16.0 release for all fmi related things.

[Francesco Casella]

Sounds good.

Maybe we could release a 1.16.0-dev.01 stable version at some point when you think we have reached a significantly improved situation, before the July release. That could be useful for people with FMI needs.