Failed getting FMU state from slave

[Rolex]

Hi,

in Dymola 2020 wird endlich das Attribut "canGetAndSetFMUState" bei FMUs mit dem Solver Rk4fix unterstützt, leider erscheint aber eine Fehlermeldung "Failed getting FMU state from slave".

[Andreas Nicolai]

Hi, schau ich mir gleich an.

Folgende Parameter?

• Dymola FMU 2019 (aus den FMI Cross-Checks), mit CanGetAndSetState
• Feste Zeitschrittweite, 3 Iterationen
• Keine Fehlerkontrolle/Keine Zeitschrittadaption
• eine FMU ohne Verknüpfungen mit anderen

[Andreas Nicolai]

ich nehm die /cross-check/fmi-cross-check/fmus/2.0/cs/win64/Dymola/2019FD01/Engine1b/Engine1b.fmu

[Rolex]

Hi, ich meinte den internen Solver der FMUs mit fester Schrittweite wie Rkfix4 usw.
Ich hab die FMUs mit fester Schrittweite (z.B. Rkfix4) in Dymola 2020 exportiert, da Dymola 2019 canGetandSetFMUState nur bei FMUs mit internen Solver mit variabler Schrittweite wie Dopri45 unterstützt.

[Andreas Nicolai]

Mit der Dymola-TestFMU und Gauss-Seidel und Newton (jeweils mit 2 Iterationen, da ja hier nach 2 Iterationen bereits Konvergenz erreicht ist) funktioniert das ohne Probleme (MasterSim 0.7.1).

Entweder es handelt sich um einen Bug in Dymola, der bei der exportierten FMU auftritt, oder es liegt am Kopplungsszenario.

Bitte mal folgende Info bereitstellen:
- wie viele FMUs
- welche Variablentypen sind verknüpft (nur Real oder auch Bool/Integer?)
- Ausgabe bei Detailstufe "Entwickler" (aber nur die letzten 100 Zeilen vor dem Fehler)

Alternativ bitte einfach mal eine zip-Datei mit den FMUs und der MasterSim-Projektdatei anhängen, dass ich das testen kann.

Danke,
Andreas

[Rolex]

Dymola 2020 unterstützt nun canGetandSetFMUState auch bei FMUs mit fester Schrittweite (interner Solver wie Rkfix4). Und beim Testen dieser FMU mit den iterativen Algorithmen ist erst die Fehlermeldung aufgetreten.

[Andreas Nicolai]

Das scheint dann aber wirklich ein interner Fehler in Dymola zu sein. Das Problem bei Festschrittintegrationssolvern ist ja die Synchronisation mit den Master-Zeitschritten (siehe Rundungsproblematk, auch wenn Master-Zeitschritte ganzzahlige Vielfache des internen Schritte sind). Leider kann ich das ohne TestFMU nicht ausprobieren... Dein Testfall zeigt aber wieder mal sehr deutlich, wie wichtig die herstellerseitige Dokumentation der Algorithmenkompatiibilität ist!

MasterSim macht jedenfalls alles nach Vorschrift - unabhängig davon, was die FMU intern mit der Integration anstellt. Ich habe dazu (für meine eigenen FMU Implementierungen) aber mal irgendwo einen Artikel geschrieben, wie man das Rücksetzen/Rückinterpolieren sinnig implementiert... Wenn Du Interesse hast, such ich das mal raus. Für Dein Dymola-Problem, frag doch bitte mal beim Dymola-Support nach.

Grüße,
Andreas

[Rolex]

Anbei ist noch die zip-Datei.
Ja, ich würde beim Dymola-Support auch mal nachfragen.
Vielen Dank!

[Andreas Nicolai]

Hi,
hab das mal getestet. Die Dymola-FMU fliegt tatsächlich beim ersten Aufruf von getFMUState() raus.

Aufrufsequenz:

enterInitializationMode()
set/get xx functions
exitInitializationMode()
getFMUState() -> crash

Ich schick das Log (siehe Anhang) mal an die Dymola-Entwickler, hier kann ich leider nichts machen.
PS: Habe die Log-Ausgaben vom MasterSim etwas erweitert, damit man die Fehlerstelle besser findet (wenn man --verbosity-level=3 oder 4 verwendet).

-Andreas

[Rolex]

Alles klar, vielen Dank für die Info.