wrong results in: res = model.simulate(......)

9 posts / 0 new
Last post
hanshell
Offline
Joined: 2015-10-07
wrong results in: res = model.simulate(......)

dear all,

I have some troubles with simulation results. In some cases the signals of res['signal'] are wrong.

fmuCheck.linux64 reports:

[INFO][FMUCHK] The FMU contains:
96 constants
502 parameters
0 discrete variables
842 continuous variables
6 inputs
0 outputs
932 local variables
0 independent variables
381 calculated parameters
1677 real variables
42 integer variables
18 enumeration variables
61 boolean variables
23 string variables

Following observations in different versions:

  • svn10626 : results WRONG
  • svn10313 : results WRONG
  • svn10214 : results CORRECT

For "small size models" the results are OK.

Thanks in advance
Johann

jsten
Offline
Joined: 2012-09-17
Thank you for the bug report

Hi Hanshell

Thank you for the bug report. Unfortunately we need further information in order to debug this further, is this something that you can provide?

Best regards
Jon Sten

hanshell
Offline
Joined: 2015-10-07
Hi Jon, The problem occurs

Hi Jon,

The problem occurs only when using the filter option.

e.g.  with

opts['filter'] = ["FTURB*"]

then

Y = res['FTURB2.rpm'] is not correct.

When turn off variable filter option, everything is fine.

system infomation:

>uname -a
Linux notebook.all 4.4.104-39-default #1 SMP Thu Jan 4 08:11:03 UTC 2018 (7db1912) x86_64 x86
_64 x86_64 GNU/Linux

>python --version
Python 2.7.13

Thanks & regards
Johann

jsten
Offline
Joined: 2012-09-17
Hi Johann Okay, thank you for

Hi Johann

Okay, thank you for the reply! Unfortunately this is hard to debug without a model wich reporduces this issue, I've tried the following:

from pymodelica import compile_fmu
from pyfmi import load_fmu

n = compile_fmu("Modelica.Blocks.Examples.PID_Controller")

m = load_fmu(n)
res = m.simulate()
noFilter = res['inertia1.phi']

m = load_fmu(n)
opts = m.simulate_options()
opts['filter'] = 'inertia*'
res2 = m.simulate(options=opts)
withFilter = res2['inertia1.phi']

The variables noFilter and withFilter are identical...

Best regards
Jon

hanshell
Offline
Joined: 2015-10-07
one step closer

Hallo Jon,

system: JModelica version svn10629

Only when using :

      opts["result_handling"] = "binary"    

the results are wrong.

 

For all other options like:

    opts["result_handling"] = "custom"
    opts["result_handler"] = ResultWriterDymola(model)    # --> OK

or

    opts["result_handling"] = "csv"  # --> OK

    opts["result_handling"] = "memory"  # --> OK

the results are correct.

 

In other words:

   a possible problem in ... /Python/pyfmi/common/io.py    in  class ResultHandlerBinaryFile(ResultHandler):

 

The simulation problem I try to solve is using external data sources. So I have to make some modifications before sendung to you for debugging.

best regards Johann

jsten
Offline
Joined: 2012-09-17
Hi Johann Thank you for

Hi Johann

Thank you for investigating this further! Unfortunately I'm still not able to reproduce this on my side. So I'll wait for you to get back to us with a model/script which reproduces this issue.

Thanks

Jon

hanshell
Offline
Joined: 2015-10-07
result error - example FMU

sorry for late responding.

I attached the linux64 FMU, the needed datafile (please rename ist to data-M0.dat), and the PYTHON script for running simulation.

The expetced results for both signals is   -750.0

When using FILTER and opts["result_handling"] = "binary"   then the results are wrong. With opts["result_handling"] = "memory"  results are correct.

All files shoult be located in the same folder.

Thanks in advance Johann

 

AttachmentSize
Man01input.fmu 898.05 KB
data-M0.mat_.jpeg 8.82 KB
runFMUinput.py.txt 730 bytes
chria
Offline
Joined: 2009-07-29
Thanks for the example! With

Thanks for the example! With the example I've found the problem and fixed it in https://trac.jmodelica.org/ticket/5597

 

Best

/Christian

chria
Offline
Joined: 2009-07-29
I've made a second commit to

I've made a second commit to the ticket to fix a special case that was missed in the first commit.

Login or register to post comments