Dear,
I made an FMU from a Dymola Model and import it at Jmodelica. The FMU simulates in the Jmodelica environment.
But when I want to set a variable to another value it gives an error:
"FMUException: Failed to set the Real values.".
When I asked for a value like a = FMUModel.get("variable") , I get the value of the variable. But when I set the variable to the same value like FMUModel.set("variable",a) I got the same error. It is not only this variable but for all other variables and parameters.
What could be the problem, or what is the solution to change the variable?
With kind regards
Failed to set real values on FMU
Fri, 2012-03-02 11:59
#1
Failed to set real values on FMU
Fri, 2012-03-02 14:03
#2
Hi,
What you could try is
Hi,
What you could try is to look at the log, the information output from the model and then post back.
Try this:
model = FMUModel(..., enable_logging=True)
... (Try to set something)
log = model.get_log()
And paste the log.
Best
/Christian
Fri, 2012-03-02 15:07
#3
Hi,
I get next log:
In
Hi,
I get next log:
In [112]: log
Out[112]:
[['Model', 1, '', 'fmiInitialize: tolerance control not supported'],
['Model',
0,
'',
'... "..\\Inputs\\climate_15.txt" loading (tables for interpolatio
['Model',
3,
'',
'fmiSetReal: may not change #r16777350# after initialization'],
['Model',
3,
'',
'fmiSetReal: may not change #r16777348# after initialization']]
It seems that I can not change my variable after initialization. Isn't it possible to change it after initialization or must I always load my FMU again. Because when I load it and I don't initalize it before then I can change my value but after initialization and simulation I can't change it anymore.
Thanks for the fast respons.
Greets,
Rutger
Sun, 2012-03-04 19:38
#4
Hi,
Your analysis is
Hi,
Your analysis is correct: parameter values cannot be changed after initialization of the FMU, only inputs. In principle, you should be able to reinstantiate the FMU without reloading the model, but there is currently a (documented) limitation in Dymola generated FMUs in that this is not possible. Therefore, the only way to do this is to reload the FMU.
If you need to do batch simulations, this is problematic since you will eventually run out of memory. The workaround for this is to run the simulations in a separate process - this is a crude way but it works well.
Best
/Johan
Wed, 2012-03-28 13:33
#5
Thanks, I made an input of it
Thanks, I made an input of it so I can change it.
With kind regards,
Rutger
Tue, 2012-05-01 12:59
#6
Hi,
I have another
Hi,
I have another question. I have a FMU and I must set a parameter when I simulate the FMU. But when I want to simulate it again with another parameter, what are then the options that I can do?
So it isn't possible to reinstantiate the FMU without reloading the model? Because when I reload the model then I run out of memory. So that is not an option. I also can't change the parameter to an input because a lot of other parameters are linked to this parameter.
So what are the other options? I can't run the simulations in a separate process beacause I'm doing a least squares optimization (from scipy.optimize) with the FMU. Is it possible to clear my mermory of the FMUeach time, and then reload it again? Or can I make my memory bigger?
With kind regards,
Rutger Baeten
Wed, 2012-05-09 09:39
#7
Hi Rutger,
The limitations
Hi Rutger,
The limitations that you mention are well known, we have run into them in previous projects.
- In FMI 1.0, it is not possible to change parameters after model initialization - in the upcoming FMI 2.0 standard "tunable parameters" will be supported.
- Dymola's FMUs cannot be reinstantiated, which means that you need to reload the FMU for each new simulation.
- Python/ctypes cannot release loaded dlls in Windows - this deficiency has caused problems for Windows users previously - any input on this issue is welcome :) See https://trac.jmodelica.org/ticket/121 for a summary of our efforts to solve this problem.
There is a package for DFO optimization included in JModelica.org (see Section 8.8), where we run into the same issues: in this case we resolved the problem by running simulation in separate processes and communicated results to the optimizer through files.
/Johan