Add ExodusII_IO option to set {node,elem} unique_ids based on {node,elem}_num_map #4308
Conversation
…e_num_map are used to set unique_ids
Fix missing initialization of this flag in ExodusII_IO.
…() to support _set_unique_ids_from_maps flag
Although in this case both types in the tuple are the same, this syntax allows you to define local variables with different types directly in the for-loop clause.
Also, add an error check to the get_libmesh_node_id() function so that we get a nice error message rather than accessing past the end of the node_num_map vector.
The helper function effectively does nothing in the case where set_unique_ids_from_maps == true, since in that case the libmesh id is just a (zero-based) version of the input. We then determine the unique_id after the new Node has already been added, since that is when it is most convenient to set the unique_id value.
Previously, we just wrote an identity vector for the node_num_map, but now we populate it with the Node unique_ids if the user sets the _set_unique_ids_from_maps boolean.
…ique_ids of spline NodeElems
|
Job Test mac on d1ffb61 : invalidated by @jwpeterson Failed to connect to conda server |
…t_libmesh_{node,elem}_id()
* Fix signed vs. unsiged warning * Fix ambiguous std::max() overload * Fix unused variable warning
jwpeterson
force-pushed
the
exodus_unique
branch
from
e781b1d to
fc30535
Compare
|
The "Test MOOSE GCC min" failures should be completely unrelated. |
|
Job Test MOOSE GCC min on fc30535 : invalidated by @jwpeterson See if unrelated failures go away |
| * without any gaps in the numbering). | ||
| * .) When writing an Exodus file, populate the elem_num_map and | ||
| * node_num_map with the unique_ids of the Elems/Nodes being | ||
| * written. |
There was a problem hiding this comment.
Let's add a comment on why one might want to do this? (ReplicatedMesh using O(max_id) storage)
| * that flag is false. The input index is assumed to be a zero-based | ||
| * index into the {node,elem}_num_map array. | ||
| */ | ||
| void set_node_unique_id( |
There was a problem hiding this comment.
I do not like set_foo_unique_id for the name of a method that may set the unique id or may not do anything ... but I can't actually think of a better name, I'm afraid. If you don't have any better ideas we can keep this.
There was a problem hiding this comment.
possibly_set_node_unique_id()
conditionally_set_node_unique_id()
?
There was a problem hiding this comment.
Either of those is an improvement. I like conditionally.
3 participants
The basic idea here is that the Elems and Nodes will always be numbered sequentially starting from zero in libmesh while their "true" ids are stored as their unique_id (this idea is from @roystgnr). The idea behind this option is to better support non-contiguous numberings by simply using a contiguous numbering within libmesh and maintaining the {node,elem}_num_maps on the Elems and Nodes themselves until the information is written back to file. There will likely be a lot of follow-up work on this, but this PR adds the option (off by default) so that I can start experimenting further with it.