purg DumbCheckpoint#5228
Conversation
connorjward
left a comment
connorjward
left a comment
There was a problem hiding this comment.
I have a bad feeling that we haven't deleted this yet because there are some things CheckpointFile can't do.
| Since Firedrake does not currently support reading data from a | ||
| checkpoint file on a different number of processes from that it was | ||
| written with, whenever a :class:`~.Function` is stored, an |
There was a problem hiding this comment.
It's fun that we never deleted this
And Gusto is using |
I'm not sure we are... we still have it hanging around and it is tested but I can't see that we actually use it in any examples or case studies... @tommbendall can you think of anywhere we need it? |
|
Part of me thinks we should just go ahead and finally get rid of this. But I also worry that we've created a boy who cried wolf situation and there will be users out there who are using Depending on how cautious we want to be, we could first update the deprecation warning to give a specific date for removal. So after the next major release it says something like |
I know of at least this: #2452 |
The last comment on that issue is 3 years old now, do we know if it's still the case? If it is, do you have a rough idea how big a fix it would be? |
The trouble is that I don't know the exact strategy to follow. Checkpointing is funny because you have to reconstruct all of the Firedrake objects on top of the loaded PETSc ones and pass extra things around (e.g. With pyop3 I found that the Firedrake interface can be very limiting for this. For instance I had to abandon doing checkpointing for extruded meshes 'properly' because We would have to think about the interfaces of things. It would be nice if a VoM took a DMSwarm as input for example. |
When we brought in |
6 participants
Description
Am I being irresponsible/drastic/controversial? 🙃