Closed germa89 closed 2 years ago
While it's a good idea, I think this will be quite challenging. For one, while we could serialize the MAPDL mesh, we'd still have to track boundary conditions, solver settings, mesh settings, etc. There's quite a bit to track here and I think that serializing everything in the MAPDL database would be quite an undertaking. That's not to say it's not doable, but I think it might not be something worth investing time in considering the multitude of other issues to track.
If there are Python specific parameters that we need to keep track of, we can consider creating a "companion" pickle file, but as of now within pymapdl, I don't think we create anything "orphaned" from MAPDL's database.
mmhh... I see what you mean. Wouldn't you track the boundary conditions, mesh settings, etc using the RESUME
apdl command?
I agree it could overload the grpc connection if you need to send the whole CDB
file to be RESUME
D. But I feel it will be quite useful to be able to load an existing session.
Anyway, it might be useful to have a look in the future.
Closing issue. #Stale We can just run the same code again.
Current situation When you issue
mapdl.save()
, PyMAPDL is issuingSAVE
MAPDL command which is fine.Request I believe there should be an optional argument to also store the
mapdl
instance in an additional binary file hence when you issue next timemapdl. resume()
in a different python session, you will get back to the state you were when you issuedSAVE
with all the correspondentmapdl
attributes.Suggestion We could use the
pickle
library to create the binary object. Some attributes might not be appropriate to get restored/saved or they might need to be reseted when issuingmapdl.resume()
, it should be considered which ones.