Open mehdisadeghi opened 8 years ago
Is the plan to have this as an optional functionality?
Some simulations, like CFD simulations, can be very demanding on memory and storing results for many/several time steps could be difficult or even impossible.
AFAIK, this is part of the plan as discussed in M24.
Since this part should be provided by the wrappers, each wrapper can simply return the last CUDS, i.e. only one CUDS. This issue is only about laying the foundation of the work, customizing the process is up to wrapper developers.
Ok.
Just some idea, an engine wrapper should keep only one CUDS for one time step; the engine wrapper does not need to provide bookkeeping support. With that, I imagine one CUDS for each time step. So with many run steps you have many CUDS.
The Simulation
class can do the bookkeeping of CUDS, and CUDS can be stored in memory or in files, at the user's discretion. (Note: For saving CUDS in files, we would require serialisation support for CUDS.)
Simulation
may have a number of attributes:
attribute Simulation.save_cuds_to_file : boolean (optional)
Do we save subsequent CUDS in files or in memory
attribute Simulation.cuds_file_path : str (optional)
Where we store the subsequent CUDS (not used if save_cuds_to_file is False)
attribute Simulation.current_cuds: CUDS
The CUDS currently used by the engine wrapper
property Simulation.current_step : int
The corresponding step for the current_cuds
property Simulation.number_of_cuds: int
Number of CUDS we have
method Simulation.get_cuds(step=-1)
The CUDS at step=`step`, step=-1 means the last one
For example, on initialisation, Simulation.number_of_cuds
is 1, current_cuds
is the first CUDS given. After Simulation.run
updates its record of CUDS, and number_of_cuds
becomes 2, current_cuds
becomes the result of the simulation. If the user wants to run the simulation with an older CUDS at step=i
, the user can do Simulation.current_cuds = Simulation.get_cuds(step=i)
and go ahead with Simulation.run()
, Simulation.run
would update the engine wrapper with the current_cuds before calling wrapper.run
. After that run, Simulation
would overwrite(?) the CUDS at step=i+1
on its book.
Simulation.run would update the engine wrapper with the current_cuds before calling wrapper.run
Correction: The current_cuds
would be a property and update the wrapper's cuds when it is being set, run
should just do run
and update the bookkeeping after run.
The Simulation class can do the bookkeeping of CUDS, and CUDS can be stored in memory or in files, at the user's discretion
Exactly! This is our purpose.
Regarding the Simulation class' methods, one could delegate the task of persisting results to another entity:
# Initialize
sim = Simulation('mysimulation', cuds, ...)
# even though we don't have name and id for simulations yet.
sim.run()
# Store a simulation
sim_store = SimulationStore('hdf5:///sim.hdf5')
sim_store.dump(sim)
# Load a simulation
sim = sim_store.load('mysimulation')
Then we decouple the storage strategy from the CUDS entity and leave room for introducing more storage mechanisms in future.
The Simulation class should be able to run a wrapper for a give number of times and keep the result for each internally. This requires implementing a simple workflow manager class, probably provided by each wrapper separately.
Related to #286 and #277