Behaviour of the .reset method

3 posts / 0 new
Last post
Alfred
Offline
Joined: 2015-08-14
Behaviour of the .reset method

Hello,

As stated in an aside of a previous thread, the .reset method is puzzling me. I am using pyfmi version 2.3.1 on linux 64bits/python2.7[anaconda 64bits] and windows 64bits/python2.7[anaconda 32bits].

Here are 4 observations that I derived from my testing. In the following, we will consider the test model below

model testmodel
"A simplistic model for debugging purpose."
output Real out;
parameter Real in=100;
equation
out = in;
end testmodel;

The FMU on Linux was created with the OpenModelica compiler from OpenModelica 1.10 (model exchange and co-simulation, fmu 1 or 2), and with Dymola version 2017 (co-simulation, fmu 2)

  1. How should the word “state” be understood in the docstring of the .reset method below?

    Quote:

    Resets the FMU back to its original state. Note that the environment has to initialize the FMU again after this function-call.

  2. According to http://ext5.modelon.ideon.se/5858#comment-5364:
    Quote:

    In FMI 1 for model exchange there is no reset method

    Hence, I expected the following program to raise an exception :

    path_fmu = "Path to FMU ME1 on linux."
    import pyfmi
    model = pyfmi.load_fmu(path_fmu)
    model.simulate()
    print model.get("out") # prints 200

    import sys
    try:
        model.reset() # Crashes on ipython
    except Exception as e:
        print e
        sys.exit()
    else:
        print "Everything is fine."

    model.simulate()
    print model.get("out") # prints 200

    It runs and print two times “200” when executed with python test_script.py. It makes IPython crash when run interactively with an infinitely recurring error:

    /home/USERNAME/anaconda2/lib/python2.7/site-packages/IPython/terminal/interactiveshell.pyc in rawinput(self, prompt) 695 696 try: –> 697 line = py3compat.castunicodepy2(self.rawinputoriginal(prompt)) 698 except ValueError: 699 warn("\n********\nYou or a %run:ed script called sys.stdin.close()"

    IOError: [Errno 9] Bad file descriptor

    This happened with Python 2.7.11, Anaconda 64-bit and IPython 4.2.0. As a side note, I stumbled upon this crash is several other instances that I will document in a later topic.

  3. Calling .reset() between seems to be required on Linux (both ME and CS). The following code

    path_fmu = "Path to FMU ME2 or CS2 on linux."
    import pyfmi
    model = pyfmi.load_fmu(path_fmu)
    model.simulate()
    model.simulate() # raises: FMUException: Failed to setup the experiment.

    raises an FMUException (“Failed to setup the experiment”). This is not the case with the Windows FMU (maybe because it relies on a different solver?).

  4. Calling .reset() restores default parameter values on Linux but not on windows. Code snippet for Linux:

    path_fmu = "Path to FMU ME2 on linux."

    import pyfmi
    model = pyfmi.load_fmu(path_fmu)
    model.set("in", 999.)
    model.simulate()
    print model.get("in") # prints 999

    model.reset()
    model.simulate()
    print model.get("in") # prints 100 (the default value)

    Code snippet for Windows:

    path_fmu = "Path to FMU CS2 on windows."

    import pyfmi
    model = pyfmi.load_fmu(path_fmu)
    model.set("in", 999.)
    model.simulate()
    print model.get("in") # prints 999

    model.reset()
    model.simulate()
    print model.get("in") # prints 999

Which of those behaviour are intentional and which are unexpected? What could be the cause of the difference of behaviour (platform? FMU mode or version?) Where is this (or could be) documented?

Kind regards.

Alfred
Offline
Joined: 2015-08-14
Suppose the objective is to

Suppose the objective is to perform multiple simulation with the same model, varying some variable values at each call.

What would be the more robust, that is working the same no matter the FMI version and mode and the platform, and fastest way to achieve it using high level pyfmi methods?

Which of the following are correct? If not, why?

  1. Using .reset


    list_result = []
    for value in list_value:
        model.reset()
        result = model.set("variable_in", value)
        list_result.append(result["variable_out"])

  2. Using .instantiate


    list_result = []
    for value in list_value:
        model.instantiate()
        result = model.set("variable_in", value)
        list_result.append(result["variable_out"])

Is there any difference between using the .set method and the inputs argument of the .simulate method?

umutcanuguz
Offline
Joined: 2017-05-18
I would also like to ask the

I would also like to ask the the same question. After I had this problem I decided to use reset() method of models which are loaded with load_fmu function.

After I use reset(), the simulation results were quite incorrect. I thought the parameters should be set again as I resetted the model. I mean, instead of loading the model again, resetting would mean non-given parameters etc. That made sense. For this purpose, this topic helped me a lot. But at the end, simulation results were incorrect again.

This time I used instantiate() method of the model, which gives me correct answers. What I don't understand is why I get wrong simulation results when I use reset method and why everthing flows smoothly when I use instantiate method. I expected instantiate not to be working alone, therefore, I reset the the model first and then I use instantiate and everthing works well.

If you check the attachment, reset method implies that the model requires an initialization after resetting. That is ok actually because simulation method of the model makes an automatic initialization, which is a little bit problematic as I mentioned in this topic. Anyway, one would expect simulation to run flawlessly. Therefore, I don't get get it.

Again in the attachment, instantiate method implies that an instance of the model is going to be created but it is not the case as I tried. No matter what I give as an name argument, it just instantiate the model itself, as if it "resets" it.  Please explain how I can create different instances of this model from the model I loaded with load_fmu.

 

 

AttachmentSize
instantiate_vs_reset.png 16.05 KB
Login or register to post comments