-
Notifications
You must be signed in to change notification settings - Fork 283
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
Question regarding FE<Dim,T>::reinit() #3637
Comments
Not ⇒, ⇐. If the orientations match, then
The main reason for avoiding global ids is that we like to be able to renumber those; otherwise doing transient adaptive mesh refinement+coarsening can leave you with a very sparse id set very quickly, and lots of codes (perhaps unwisely, but understandably) want to use ids as efficient global array indices. On the other hand, the main reason to avoid using point coordinates is that doing so makes orientation-dependent finite elements unusable on problems with moving meshes. I could probably be talked into switching back (after rewriting our renumbering code to always be monotone; right now it does things like sorting by processor id on a |
Pinging @cticenhour since he might find the conversation interesting, either in a reassuring "yeah, we're using Nedelec on far more complicated meshes in the MOOSE EM module tests" way or in a dismaying "what do you mean we're not supposed to be using them on moving meshes" way... |
Let me rephrase, the orientation needs to be computed using the lexicographic order on point coordinates and not the natural order on global ids, because otherwise, the |
See libMesh#3637 for a detailed discussion as to why
See libMesh#3637 for a detailed discussion as to why
See libMesh#3637 for a detailed discussion as to why
I sure let this get buried, didn't I? I think we came to an understanding, despite me misunderstanding your question at first, so I'll close the issue unless there's still something confusing.
This is indeed the case. Which means that as soon as we add an option to determine orientation via |
Hi,
Basically, for orientation-dependent element families such as Nédélec (first kind), even though
shapes_need_reinit()
returns true:libmesh/src/fe/fe_nedelec_one.C
Lines 513 to 514 in 713688a
the following if statement:
libmesh/src/fe/fe.C
Lines 231 to 239 in 713688a
will only execute if
cached_nodes_still_fit
is false. For sufficiently regular grids (simple compositions of quads or hexes), however, it will be true, resulting in no new computation. This implies that the computed orientation for the quads/hexes on the grid must also match that of the first element, is that why you use point coordinates instead of global ids to compute orientation?Cheers,
Nuno (cc @karthichockalingam)
The text was updated successfully, but these errors were encountered: