Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save / Load method in simulation class #12

Open
AmosEgel opened this issue Apr 26, 2018 · 4 comments
Open

Save / Load method in simulation class #12

AmosEgel opened this issue Apr 26, 2018 · 4 comments
Assignees

Comments

@AmosEgel
Copy link
Contributor

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.

@lpattelli
Copy link
Contributor

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.

@AmosEgel
Copy link
Contributor Author

Why saving celes_tables? I assume they cost relatively much disc space, and it doesn't take much time to compute them once.

@lpattelli
Copy link
Contributor

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?

@AmosEgel
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants