-
Notifications
You must be signed in to change notification settings - Fork 285
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
2d, 5th order Nédélec (first kind) and Raviart-Thomas FEs #3884
base: devel
Are you sure you want to change the base?
Conversation
Job Coverage on 9b88378 wanted to post the following: Coverage
Warnings
This comment will be updated on new commits. |
Co-authored-by: Nuno Nobre <nuno.nobre@stfc.ac.uk>
Is this ready to review? I've been busy, and currently the recent force pushes make me cautious, but if I don't get to it in between vacation prep work tomorrow then I'm definitely not getting to it until I get back. |
There are a couple things I want to do:
Okay Roy, I'm happy with this now. We can always transfer the discussion around 1) to #3874. Ready for review when you are. Enjoy your vacation! :) |
And on how we happen to recount nodes. I'd love to have an option someday to compute based on
In the general case, no, and it might be worthwhile to add an option to In a more-general-than-structured-grids case, yes. There are a lot of FEM users in general who use immersed boundary methods or who use grid generation schemes based on an overset structured grid or grids. In the former case you don't have a structured grid topology but you have lots of identical geometry that benefits from caching; in the latter case you have a lot of weirdly shaped elements but they're around a core of identical quads or hexes. I don't know if anyone is currently doing these with libMesh, but they're ideas that seem to keep resurfacing, usually with good reasons.
Yes, surprisingly; you can go quite far with geometries captured via phase field methods ... perhaps not on a structured grid but at least on an adaptively refined grid whose coarse level is structured. I did a lot of that in my PhD work (which is where the caching work came from), and I was just at a little conference this spring with a lot of MOOSE users doing that for subsurface modeling. |
You make good points, so let's keep things as they are. :) Actually... I wanted to convince myself that what I said here,
is in fact true, so I went ahead and implemented the 3rd order case... :P As a matter of fact, I may or may not have written a little script that generates the (code for the) shape functions (and their derivatives) for arbitrary order, https://github.com/farscape-project/libMeshGen. It uses symfem and it's only 2d for now, but the objective is to generalise to 3d of course. So, long story short, we can add any order we want in a matter of minutes. :) I think for our use cases 3rd order suffices, so I'd probably leave it there for now? Also, vector ex6 requires What's your take? What order is good enough? I can then add those commits to this PR and then we can finally review/merge. :) |
Oh that's beautiful. I'm of the general opinion that we should add as many orders as floating point arithmetic lets us get away with; in FEInterface I set But that was a cap for elements where we have code that handles arbitrary p. What degree we want to hand-code is another question, and I'm not sure we have a settled answer. With fe_hierarchic_shape_1D.C we wrote hand-coded shapes up to p=7 and only go to If you can't get a parametric solution out of symfem (it does get tricky outside 1D...) then we don't need to go up far. H(curl) stuff is where I've seen hp-adaptivity people go wild with p, but that could be because EM problems are inherently smoother in most domains or because these were academic researchers who tend to solve problems on simpler domains. I don't think I've personally done anything serious past p=4, and sometimes I feel like half of our MOOSE users would use p=-1 if that was an option, so even p=3 is a great start. Does vector ex6 really need |
😆
Probably not... I didn't even think of |
Good shout, libmesh/src/fe/fe_l2_hierarchic.C Line 103 in 7579290
I didn't add these higher orders to either Other than that, I'm struggling to converge the high-order, highly-refined configurations (the situation improved slightly with the latest commit), though I think I've got enough evidence the implementation is correct: EDIT: I've rerun the 2nd order case on QUADs in single precision and marked both |
Hi Roy,
The good:
The bad:
46% slowdown in
compute_shape_functions()
and 40% ininit_shape_functions()
when running vector fe ex3 with 1st order Nédélec elements.for i in {1..5}; do ./example-opt element_type=TRI6 -pc_type lu grid_size=150 | grep "| FE " -A2; done
BEFORE (196a0a4):
AFTER (c659c2b):
The ugly:
No support for non-conforming interfaces and the shape functions are still explicitly hard-coded. On the bright side, all other code should support arbitrary order Nédélec elements. In practice, this means that, in the future, adding support for 3rd order shape functions would literally 'only' require writing those functions and their derivatives.