Open AmosEgel opened 6 years ago
Yes, everything is now subclassed from the matlab.System superclass in order to implement a property-value input and one-time calculations inside setupImpl. The constructor calls the one-time methods, which in turn requires that all input parameters have been passed properly at construction time.
I've added two standalone functions to dump few relevant fields of a simulation object to a struct and instantiate a simulation object reading from one such struct. probably this is not the most elegant way to go, but provides a good flexibility to include only the relevant variables and don't bloat the dump file. the correct approach would be probably to specify custom saveobj/loadobj or saveObjImpl/loadObjImpl methods, but I didn't succeed to make them work.
To make these functions meaningful I guess that the next step is to manually store the content of celes_tables as well, and then change the run method to check whether these tables are already set so to use their content instead of recalculating everything from scratch.
Why saving celes_tables? I assume they cost relatively much disc space, and it doesn't take much time to compute them once.
I think that one of the goals we could pursue by saving/loading simulations could be to save the simulation inside tempdir with a tempname every ~10 iterations, so that we can restart it later if we want to achieve, say, better convergence. Then I guess we would need to save the coefficients obtained so far. Aren't they saved inside a tables instance?
Another interesting use case that we could explore, is that of using the result of a smaller simulation as the initial guess for a larger one (e.g., where we increase the number of peripheral particles). This is also why I decided to write standalone functions instead of methods of the simulation class, so that we can tweak the structure that we save before we feed it back to the next simulation. Do you think this is feasible?
Oh, right - the scattered field coefficients are in the celes_tables
. Yes, saving between the iterations and then resuming a cancelled simulation is a good idea and should be possible.
Up to now, CELES simulations were saved by trivially saving the celes_simulation object as a whole. This seems broken since recent updates in the data structure (Lorenzo, is that correct?). Another drawback of saving the whole celes_simulation object is that lookup tables and other heavy stuff might be saved leading to large file sizes.
To meet this issue, we could implement a save method in the simulation class that manually stores the relevant attributes into some data structure which is then saved, as well as a load method that reads from that structure and initializes a simulation object.