pyFMI too slow to be useful

5 posts / 0 new
Last post
Joined: 2017-11-10
pyFMI too slow to be useful



I have a model that I just exported as an FMU (2.0). It is, however, way too slow using pyFMI to be practically usable. It takes ten minutes to reach one model second, quite long when I want to model a full day (24 hrs, 24*3600 seconds). The model is not very big, less than 1000 equations, mostly Real variables and some components with Fluid and Media stuff.

The funny thing is, I have a similar model that is superfast, it solves 1000s in about one second (wall time). This model does not contain any transient input so I run it to steady-state, so this is a difference.

But the transient effects are not very large in the newer model. It runs fine under Wolfram SystemModeler and modeling a full 24 hrs takes a minute or so.

Any tips from someone regarding solver settings that might speed things up?

Joined: 2017-04-04
Why blame PyFMI?

I am a normal user of PyFMI, I just think the title of this post is unfair and offensive. If YOU think PyFMI is too slow to be useful, please provide proofs or suggestions to improve it.

  1. Which type of FMU are you using?
  2. Which solver were you using? What communication time step were you using? PyFMI options?
  3. What model were you simulating? 
  4. Which tool did you use to generate the FMU? How did you generated it? Which compiler? Compiler options? Platform?
  5. What computer did you use?

In the end, how much do you actually know about PyFMI? If you are posting questions on setting input signals to FMUs, in my personal point of view, you are not even reading the documentation carefully, so I think the blame is unfair.

Joined: 2017-11-08
Modeling Practices


    In terms of modeling time I would investigate your model first. You mention modeling fluids, and depending on the software this can generate some painful equations. Changing modeling practices can yield huge improvements in model time by changing your assumptions on fluid volumes, orifice sizes, etc.




Joined: 2017-11-10
Ok, I might need to be more

Ok, I might need to be more clear...

I export my FMU (version 2.0, model exchange) using the FMU eport utility in Wolfram System Modeler (WSM), where my model is built in Modelica. Platform is Windows 10, but I also use Linux CentOS 6.5 on our computational servers if the model is too large for my laptop. We have WSM (and pyMFI) on both platforms. I run the standard solver in pyFMI (cvode). Inside WSM I run DASSL or cvode, although Wolfram suggested cvode for our types of models. There is virtually no difference between the two inside WSM.

I have three models I experiment with regarding this issue. The legacy model no 1 consists of sub-systems A, B and C. Sub-system C contains fluids (and media). This models runs well in WSM and also when exported as FMU 1.0 and run in pyFMI. Wall-time is about 1 second for 10.000 model seconds. It is this fast partly because the input is steady-state (constant in time).

Model 2 is a model of a new system we are developing at our company. It consists of sub-systems A, B, C and D. As before sub-system C contains fluids (and media). In fact sub-system C is identical between modols 1 and 2, this part did not change in the upgrade so I kept the models the same. This model runs fine in WSM, running time is longer partly because it now takes transient input. The model is also a little bit larger than model 1, but still small (<1000 equations). Model no 2 does not run in pyFMI although exported the same way and run using standard solver settings. Well it runs, but wall time is 10 minutes for 1 second of model time. Not very useful when I need to run the model for 24 hours (24*3600 seconds).

Model 3 is a scaled down version of model 2, that does not have sub-system c (the ones with fluid in it). This runs fine in WSM and in pyFMI.

So, the fluid models are to blame, but I am at loss to find why. This sub-system runs well in model 1, WSM runs all models well (and fast). The fluid model is quite small, loosely resembles the cooling system of an ordinary car. All assumptions have been checked mutliple times. The model is very well built, was in fact built by Modelon as a consultancy :-) But I do not think it is the model. The only thing I can think of is that some (small) difference was introduced when copying the sub-system from model 1 to model 2, but as it runs in WSM I cannot see that difference is large.

Joined: 2017-11-10
Problem caused by FMU 2.0

Hi all,

just want to give an update that I have found the cause of the issue. It seems that when fed with an FMU2.0 pyFMI has initialization troubles and the subsequent sluggishness is a result from that. When exporting my models using FMU1.0, everything works just fine, and speed is restored (slower than running native in Wolfram SystemModeler (WSM), but still quite fast and entirely useful).

I realized this when parsing the xml-file contained in the FMU for the models mentioned above and realized the only working model was (apparently accidentally) exported using FMU1.0.

Note: this only is the case when I have my sub-model that includes Fluid components in the FMU. Without Fluid (and hence Media) components FMU2.0 models run just fine too.

I was under the impression that pyFMI is compliant with FMU2.0, but as it seems not with FMU2.0's exported from WSM. If any of the developers would like some FMU's for testing, please let me know.


Login or register to post comments