Checkpoint splitter #1103
Checkpoint splitter #1103
Conversation
| */ | ||
| const processor_id_type & current_n_processors() const { return _my_n_processors; } | ||
| processor_id_type & current_n_processors() { return _my_n_processors; } | ||
|
|
There was a problem hiding this comment.
These aren't redundant with the ParallelObject APIs because during reading they come from the file rather than the CheckpointIO object?
If I'm understanding that correctly, could you make it clearer in the comments?
There was a problem hiding this comment.
Actually - those are for m->n splitting. Like run with m MPI processes... but create output files for n MPI processes.
To do that a code can loop over and set current_n_processors() and current_processor_id() and call write()... and the file that comes out will be for that situation.
I'll update the comment
There was a problem hiding this comment.
|
Hmm - that same test timed out yesterday as well. I don't recall it ever timing out before... |
|
@permcody It looks like it passed this time. It definitely doesn't have anything to do with this PR... so I don't know what's up. |
| @@ -1349,14 +1349,14 @@ void DistributedMesh::delete_remote_elements() | |||
| { | |||
| #ifdef DEBUG | |||
| // Make sure our neighbor links are all fine | |||
| MeshTools::libmesh_assert_valid_neighbors(*this); | |||
| //MeshTools::libmesh_assert_valid_neighbors(*this); | |||
There was a problem hiding this comment.
@roystgnr can we just delete these asserts altogether if they make the code too slow in DEBUG mode? Or maybe add some kind of "extra_pararnoid_slow" debugging flag that people can enable. I don't think they should just be commented out...
There was a problem hiding this comment.
I definitely don't want to delete them entirely. "This assert would pass here" is very useful information to leave in the code even if we don't compile it.
Personally, I thought DEBUG was the extra_paranoid_slow flag. We've already got -O0 and GLIBCXX_DEBUG* active in dbg mode too; it's basically as unoptimized as it gets.
There was a problem hiding this comment.
Sorry guys: I didn't mean to leave these changes in here. Those just slipped through. I'll revert those and force-push this.
BTW: As you can see with my newest commit... I'm still working on this a bit. One of my problems still won't run using this capability. Still hunting down why.
Only write out boundary info for truly local objects. Need to write out all point neighbors of local elements (and the nodes that connect to them)
|
Closing this in favor of #1106 |
Forget Nemesis reading. It's too damn complicated.
We can do this ourselves. DistributedMesh is actually really awesome at reinitializing itself... it barely needs anything. Just the local elements and the nodes they're connected to... along with BC info. Done.
That said... there is still a small issue with this PR that must be resolved before it can be merged. It currently throws an
assert()in devel/dbg mode if you leave mesh partitioning on when you prepare the newly read-in mesh for use.You can see the way I'm needing to do the reading over here:
friedmud/moose@6e08eef
@jwpeterson @roystgnr could I get just the tiniest bit of help tracking that one down?
To easily create meshes that are split using this new capability use this branch of my
simple_libmesh_app:https://github.com/friedmud/simple_libmesh_app/tree/splitter
refs idaholab/moose#7752 , idaholab/moose#7744 , idaholab/moose#7745 , #1087 , #1086