(Arbitrary-) Polygon elements #4074
Open
+3,951
−779
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some subclasses like Polygon might have to do this for themselves, because they can't heap allocate until after initializing Elem.
Throwing in other method tests here while I'm at it, just to get a quick check before I try to instantiate a Polygon1 in our usual Elem tests
These have been deprecated and ignored for a while, and this refactor is a good time to get rid of them for good.
If we have a POLYGON1 or a future POLYHEDRON1 or anything else where the quadrature rule will need to depend on more than just a single element type, we'll need to initialize quadrature objects with the physical element.
With two ways to be initialized (with a physical element vs with just an element type), this simplifies a lot of "initialize one quadrature rule based on another rule" code elsewhere in the quadrature rules.
We can't deprecate this overload entirely, because there are use cases where we e.g. want a 1D quadrature rule without wanting to create an actual Edge2 to pass to the const Elem& overload, but we don't want application codes to manually init() a quadrature rule in a way that will break on general polygons and polyhedra. So we'll provide a way to say "no, we're not screwing up, we know we're specifying an ElemType for which you don't need a full Elem".
When we need a 1D rule then we can init() and get one; when we don't need a 1D rule then there's no sense in constructing one only to erase it again immediately afterward.
Obviously we can't rely on static maps here in general anymore, since we're not going to have a different ElemType and map entry for every possible polyhedron. So, add some invalid_uint entries for the general types, and handle invalid_uint where we might run into it, and query the Elem itself instead of these maps whereever we can.
This lets us do a lot in Polygon that might otherwise have to be pushed down to subclasses, which will be good if we ever have any higher-order or internal-node-having subclasses.
I'll finish Lagrange+Polygon1 support soon, but this will be faster even then, and it'll get Polygon elem unit tests working earlier.
Not sure how I missed this earlier
Putting this in FEInterface was kind of an unintuitive decision in the first place, and now that we're adding runtime-dependent element topology like Polygons we're going to *need* a physical Elem to work with in those cases.
This should make it compatible with Polygon, etc.
We make this one an equilateral pentagon because a non-skewed polygon won't give us an exact representation of linears for p>1 MONOMIAL
This also makes one of the app options redundant
We're already beginning a big shakeup for user code so we might as well pull the bandaid off quickly.
Ripping off all the bandaids at once
libmesh_deprecated() is sometimes necessary, when one possible input is deprecated but another supported, but if *any* call to a method is deprecated we can just get rid of it completely in `--disable-deprecated` builds.
We can't build the old Side objects for Polygon1; the build code there relies on `side_nodes_map`.
This is a bit more descriptive of an important aspect (triangulated mapping), and we can still add terms to indicate higher order in later higher-order versions.
QComposite was hitting undefined behavior here, creating temporary subelements for an internal Lagrange FE, and then when that FE would reinit afterward it would test `get_elem_type()` and hit a dangling pointer.
This was referenced Feb 11, 2025
|
Job Coverage, step Generate coverage on 48c594b wanted to post the following: Coverage
Warnings
This comment will be updated on new commits. |
||||||||||||||||||||||||||
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This ended up being a larger diff than I'd hoped for - we need to change a whole swath of Quadrature and FE APIs, to take an
Elem *orElem &instead of just anElemType, if we want to be able to handle elements where a single type might have differing subelement decompositions and/or different values for things liken_dofsfrom element to element.With just
Polygonsubclasses, it might been conceivable to just addPENTAGON,HEXAGON, etc. enumerated types until we reachedn_sides()=17 or some such too-crazy-to-exceed value, but I'm hoping that the refactoring here also lets us handle an upcomingPolyhedronclass hierarchy.Since I'm deprecating a bunch of functions, I also uncommented the
libmesh_deprecated()on a bunch of others while I was at it, and wrapped everything I could in#ifdef LIBMESH_ENABLE_DEPRECATEDto try and catch use cases at compile time.Some InfFE code was using FE/FEInterface calls that were deprecated by @lindsayad as part of his work on p-refinement flexibility, and I'm not sure if I updated them correctly for
p_level() > 0cases. I don't think anybody has yet tried combining infinite elements with p refinement (@BalticPinguin?), but if somebody did and I just broke it then on the one hand I apologize but on the other I consider that acceptable punishment for not getting an example with feature coverage into CI.