CompositeModel::solveAlgLoop: max. number of iterations

[Boldizsár Németh <nboldi@…>]

While trying to simulate two connected FMUs, I got the following error.

nboldi@nboldi-VirtualBox:~/OMSimulator$ build/linux/src/OMSimulator/OMSimulator ../moonlander.lua
info:	New temp directory: "/home/nboldi/OMSimulator/temp"
# FMI composite model "model"
## FMI sub model "Lander"
type: FMU
## FMI sub model "World"
type: FMU
## Connections
model: World:h -> Lander:h
model: World:v -> Lander:v
model: Lander:u -> World:u
warning: Alg. loop (size 3)
error:   CompositeModel::solveAlgLoop: max. number of iterations (10) exceeded at time = 0.000000
info:	Result file: results.mat (bufferSize=1)
error:   failed to fetch variable Lander:u
error:   Failed to log simulation results
MoonLander::InitToFF
MoonLander::FFtoControlled
Segmentation fault (core dumped)

The FMUs World and Lander are connected. There is one variable from Lander to World (u) and two variables from World to Lander (h and v).

After initialization, Lander outputs 0 for u, and World returns 1000 and 0 for h and v. They should return the same value for repeated calls regardless of the inputs they are given. I checked this behavior by simulating individual FMUs.

Since the FMUs were generated from different sources, it is possible that they are unconventional in some way. Could you suggest what can be the problem behind the errors?

[Lennart Ochel]

I don’t quite get the issue. Do you expect an algebraic loop when connecting the two FMUs? Can you provide the FMUs for testing? What tool did you use to generate the FMUs?

And did you run the example with the latest version of OMSimulator or which version did you use?

[Boldizsár Németh <nboldi@…>]

I attached the models and the lua script that loads them. I do not quite understand algebraic loops, I expected the simulation to be run without errors. One of the FMUs is handwritten (WorldModel.fmu), the other is generated by txtUML (MoonLander.fmu). I'm on a commit about a month old, I will check out if the error is still present in the current master.

[Lennart Ochel]

I run the model with the latest version of OMSimulator and got the following log file:

info:    Initializing logging (OMSimulator v2.0.0-dev-596-gf3c4549-linux)
info:    New temp directory has been created: "./temp/"
info:    New temp directory: "/tests/5103/temp"
warning: No solver instance is assigned to FMU "Lander"; A default solver will be selected: internal
warning: No solver instance is assigned to FMU "World"; A default solver will be selected: internal
warning: Alg. loop (size 3)
error:   CompositeModel::solveAlgLoop: max. number of iterations (10) exceeded at time = 0.000000
info:    Result file: results.mat (bufferSize=1)
error:   failed to fetch variable Lander:u
error:   Failed to log simulation results
error:   failed to fetch variable Lander:u
error:   Failed to log simulation results
info:    Removed model from scope: model
info:    Logging completed properly

Apparently, it is not possible to fetch signal Lander:u. I guess this is an issue with the FMU itself. Can you please verify this?

[Lennart Ochel]

Alg. loop (size 3)

[Lennart Ochel]

The main issue seems to be the alg. loop. As you can see from the graph, the signals depend directly on each other and form a loop. That makes it difficult to do the communication. An iterative approach is used to handle these cases, but in your case the system diverges. Maybe you could introduce a delay to break this this loop.

[Boldizsár Németh <nboldi@…>]

Thank you! Yes, I think I should add a delay. The u variable of lander should be accessible. I could read it when debugging only the Lander model.

[Lennart Ochel]

Replying to Boldizsár Németh <nboldi@…>:

Thank you! Yes, I think I should add a delay. The u variable of lander should be accessible. I could read it when debugging only the Lander model.

Yes, I noticed that as well. I think the error message (failed to fetch variable Lander:u) is misleading in this case, and occurs only because the algebraic loop couldn't be solved.

[Boldizsár Németh <nboldi@…>]

I tried to add the delay internally in one of the FMUs (by making doStep use previous inputs), but it didn't work. Is there a way to instruct the simulator to impose a delay on one of the FMUs?

[Lennart Ochel]

No, there is no such functionality available. But you are very welcome to make a feature request: ​https://github.com/OpenModelica/OMSimulator/issues/new/choose

[Boldizsár Németh <nboldi@…>]

Unfortunately I couldn't solve this issue over the last weeks.

My situation is:

• My two models (World and Lander) are depending on each other with their inputs and outputs.
• The two models are discrete in nature.
• The models have matching initial values for their variables, h=1000, v=0 and u=0.
• The models are constructed in a way that output values will only change when doStep is called.

How should I simulate these two models together to avoid the algorithmic loop error?

[Lennart Ochel]

Sorry, that it took so long time to come back to you. I did some more investigation, and it seems not related to the alg. loop. Even without any connection between the two FMUs, the model fails with following error message:

error:   [updateSignals] failed to fetch variable u
h: 1000 v: -0.1625 u: 0 crash: 0
MoonLander::InitToFF
MoonLander::FFtoControlled
Segmentation fault (core dumped)

I think the MoonLander.fmu has internal problems.

[Lennart Ochel]

Replying to Boldizsár Németh <nboldi@…>:

• The models are constructed in a way that output values will only change when doStep is called.

The modelDescription.xml of both FMUs contain direct dependencies between the outputs and their inputs. That is actually where the algebraic loop is coming from. It seems that the dependency information in the FMUs are wrong.