For serialization purposes or avoiding restarting an extremely long integration from zero, it would be a useful feature to intermittently checkpoint the integration, saving all state to disk.
This would become part of the #90 effort.
I'd suggest not getting stuck on a particular seriallization format, rather setup writer & reader interfaces which can handle our relatively limited set of primitive types (double, uint32_t, bool, sd_stat and pointers there of). Every non-primitive would be able to make appropriate calls to a writer/reader.
then, provide a basic writer/reader implementation in json or hdf5 or sql or whatever.
During integration, at predefined frequency, the solver checkpoints to given writer, and then continues. This could also be done if a given signal is received, as with the OAR job system which sends SIGUSR a few minutes before killing your job.
For serialization purposes or avoiding restarting an extremely long integration from zero, it would be a useful feature to intermittently checkpoint the integration, saving all state to disk.
This would become part of the #90 effort.
I'd suggest not getting stuck on a particular seriallization format, rather setup writer & reader interfaces which can handle our relatively limited set of primitive types (
double,uint32_t,bool,sd_statand pointers there of). Every non-primitive would be able to make appropriate calls to a writer/reader.then, provide a basic writer/reader implementation in json or hdf5 or sql or whatever.
During integration, at predefined frequency, the solver checkpoints to given writer, and then continues. This could also be done if a given signal is received, as with the OAR job system which sends SIGUSR a few minutes before killing your job.