Let the Simulation contain a limited timestep-CUDS history

[mehdisadeghi]

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

[kemattil]

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.

[mehdisadeghi]

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.

[kemattil]

Ok.

[kitchoi]

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.

[kitchoi]

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.

[mehdisadeghi]

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.