Closed arnoutaertgeerts closed 9 years ago
I see your point. This is tricky. We could handle that in SimResList.plot()
, but it makes that method more complicated and SimResList
isn't really intended to concatenate results anyway. We could add a merge() to SimRes
or as a standalone function, but the details to truely merge the data depend on the format it was loaded from. I wasn't planning to add a method to write or rewrite simulation result files (although SimRes.to_pandas()
can export to some standard formats).
The easiest way might be to create a dedicated class that extends from SimRes
. There are two abstract methods in SimRes
: values
and times
. As it stands these are populated by the Dymola file loader (_modelicares.io.dymola.readsim). We could create a SimResSequence
class that extends from SimRes
but has an __init__
method similar to that of SimResList
. It would define the values()
and times()
methods to pull from the SimRes
instances stored within it. In theory, everything else (its plot()
, min
, max
, etc.) would fall into place.
What do you think?
Good thinking, that could be an easy solution!
Would you consider taking the first shot at it?
Sure, I was planning to ;)
I followed your approach and everything works :) see https://github.com/kdavies4/ModelicaRes/commit/75b565b892196b2b845244424cf53dfffb1d3b27. However, I did had to change values in NamedTuple
instances which is something you should normally not do.
If you are okay with my implementation, we can close this.
PS: I think the continue_run()
method is a great addition to the module. It enables developers to use external control methods on Dymola models (as is also possible in Matlab). I think the FMU approach works best but I did not yet succeed in running FMUs with the Dymola solvers.
Some considerations after I tried this with a large simulations:
continue_run()
method, this creates a lot of overhead. The PyFMI
module does provide the ability to create a custom result handler which might be useful here.SimResSequence
is unable to process these files the way it is programmed now due to Memory issues. We might need to merge the result files first and delete the redundant data for the files to be able to be read by a SimRes
instance..mat
file. This .mat file does work for continued simulations by simply adding the new results to the file. If the FMU is able to create such a file, the simulation results should be stored in memory instead of creating extra .txt
files. However, it is impossible to know from the fmu
object if it has this option. I added a method `move_mat_file()
to the fmi
simulator to move the .mat file to the result directory but currently I see no generic way to automate this.CS-2.0/1.0-Dymola
FMU which is a Co-Simulation FMU with internal Dymola solvers.Note that when working with continued simulations, the file writing is the bottleneck, especially when the iterations are short. This can cause the following overhead:
dsin.txt
can get big (~50 MB) and it can take a long time to write these files because Python needs to rewrite the entire file everytime you change even a single value.`fmu('model.fmu', log_level=0, result_handling='memory'
I changed the approach to generate new NamedTuple
instances for each variable (179571d). I'm not sure if this will reduce the memory load but it could.
We could speed up the dsin.txt
writing, but it would take some work. Options:
I think I'll close this because we've solved the original issue. I'll open a new issue (#27) related to file size and processing time.
The
SimResList
class does an excellent job of plotting simulation results of different simulations with the same start and stop time.For continued simulations, it is unnecessary to divide the plot in different segments and give each segment a new name and color. For example:
I see two solutions:
plot()
method to take this into accountmerge()
) which merges the different simulation results in a new single result file