Skip to content

Quadrature API changes #4076

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

Merged
merged 11 commits into from
Feb 28, 2025
Merged

Conversation

roystgnr
Copy link
Member

This strips out just the quadrature-related changes that #4074 depends on, as per @jwpeterson 's request for easier testing and review.

A couple of those commits had Polygon code leak in; that should be fixed here via interactive rebases but it does mean that I'll need to do a little of the same work in #4074 afterward.

@moosebuild
Copy link

moosebuild commented Feb 12, 2025

Job Coverage, step Generate coverage on 617e7d9 wanted to post the following:

Coverage

63b299 #4076 617e7d
Total Total +/- New
Rate 63.36% 63.37% +0.00% 84.75%
Hits 74049 74074 +25 100
Misses 42816 42825 +9 18

Diff coverage report

Full coverage report

Warnings

  • New new line coverage rate 84.75% is less than the suggested 90.0%

This comment will be updated on new commits.

Copy link
Member

@jwpeterson jwpeterson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me assuming you can figure out the transition path for MOOSE codes that use this API.

@roystgnr roystgnr force-pushed the quadrature_api_changes branch from 77b5807 to 16417d3 Compare February 13, 2025 15:09
These have been deprecated and ignored for a while, and this refactor is
a good time to get rid of them for good.
We don't need this in libMesh itself, but MOOSE has a subclass of QBase
and other codes might as well.
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".
@roystgnr roystgnr force-pushed the quadrature_api_changes branch from fd6779e to 617e7d9 Compare February 25, 2025 18:15
@roystgnr roystgnr merged commit ed2d1cf into libMesh:devel Feb 28, 2025
19 of 20 checks passed
@roystgnr roystgnr deleted the quadrature_api_changes branch February 28, 2025 15:27
roystgnr added a commit to roystgnr/libmesh that referenced this pull request Feb 28, 2025
This was supposed to be part of libMesh#4076 but I missed getting it in there
somehow.
roystgnr added a commit to roystgnr/libmesh that referenced this pull request Mar 1, 2025
This was supposed to be part of libMesh#4076 but I missed getting it in there
somehow.
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

Successfully merging this pull request may close these issues.

3 participants