Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More fine-grained alternatives to MeshBase::is_prepared() #3634

Open
roystgnr opened this issue Sep 1, 2023 · 0 comments
Open

More fine-grained alternatives to MeshBase::is_prepared() #3634

roystgnr opened this issue Sep 1, 2023 · 0 comments
Assignees

Comments

@roystgnr
Copy link
Member

roystgnr commented Sep 1, 2023

We have is_prepared() to say that every bit of batch-computed information is up to date, and we have set_isnt_prepared() to manually warn future users that a mesh change has been made that will make some of that cached data invalid ... and we have very little to say that some particular bit of cached data has been invalidated. It's too easy for user code to be left with no recourse beyond "call prepare_for_use() and recompute everything" even when previous code only invalidated a bit.

See idaholab/moose#25378 for a recent such issue.

So ... what do we need to be able to mark and check?

I guess technically we already have clear_point_locator(), so that's one down!

is_partitioned?
has_synced_id_counts?
has_neighbors?
has_elem_data?
has_interior_parents?
has_removed_remote_elements?
has_boundary_id_sets?

Maybe needs_renumbering? Though a mesh never needs renumbering except if it has numbering gaps going into Exodus output; at any prior time renumbering is just for performance reasons...

@roystgnr roystgnr self-assigned this Sep 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant