Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

amboschman
Copy link
Collaborator

This PR allows the user to specify whether a HDiv-conforming element (e.g. Raviart-Thomas or BDM) should be used with the (default) contravariant Piola map or a rescaled version through the use of an extra (optional) argument in FESpace when constructing an HDiv-conforming finite element space, e.g. FESpace(model, reffe_RT, conformity=:HDiv, contra_variant_piola_map_type=ScaledContraVariantPiolaMap()). The scaled contravariant Piola map is defined as the standard contravariant Piola map for which the determinant of the Jacobi matrix is rescaled using ^{1/D} (with D the D1-dimensional volume of the parallelepiped formed by the rows of J). The use of this scaled contravariant Piola map can result in better conditioning of certain (mixed) problems, such as the Darcy equation.

For this to work,

  • the interface of CellFE has been updated to not only pass along args but also kwargs to get_cell_shapefuns and get_cell_dof_basis, so that the user can (optionally) specify the contra_variant_piola_map_type in FESpace;
  • the scaled_meas operation has been introduced to define the scaled version of the contravariant Piola map;
  • the lazy_map's and evaluate!'s are changed in RaviartThomasRefFEs.jlso that either the default operation ContraVariantPiolaMap() or the selected (ContraVariantPiolaMap() or ScaledContraVariantPiolaMap()) is performed.

@amartinhuertas
Copy link
Member

Hi @amboschman ... thanks for your work! It looks good.

The only major thing I am missing is a test that stresses the ScaledContraVariantPiolaMap (i.e., the new kw-arg added to the FESpace).

Perhaps you may some tests here:
https://github.com/gridap/Gridap.jl/blob/master/test/FESpacesTests/DivConformingFESpacesTests.jl

Also, have we tried this with (1) BDM. (2) RT elements on triangles?

Copy link

codecov bot commented Jun 27, 2025

Codecov Report

Attention: Patch coverage is 24.13793% with 22 lines in your changes missing coverage. Please review.

Project coverage is 89.16%. Comparing base (c2a8af2) to head (4aa7c9e).

Files with missing lines Patch % Lines
src/ReferenceFEs/RaviartThomasRefFEs.jl 14.28% 18 Missing ⚠️
src/TensorValues/Operations.jl 0.00% 4 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1120      +/-   ##
==========================================
- Coverage   89.23%   89.16%   -0.08%     
==========================================
  Files         208      208              
  Lines       26196    26217      +21     
==========================================
  Hits        23377    23377              
- Misses       2819     2840      +21     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@amartinhuertas amartinhuertas requested a review from Copilot June 27, 2025 06:37
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR introduces a scaled contravariant Piola map for HDiv-conforming elements and enables users to select between the default and scaled Piola maps via an additional argument in the finite element space constructor. Key changes include:

  • Adding the scaled_meas operation and its documentation for rescaled Jacobian determinants.
  • Updating the interface in CellFE, ReferenceFEs, and various FESpace modules (Div-, Curl-, and ConformingFESpaces) to pass and honor the new contra_variant_piola_map_type argument.
  • Adjusting exports and imports across TensorValues, Fields, and FESpace modules to expose the new functionality.

Reviewed Changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Show a summary per file
File Description
src/TensorValues/TensorValues.jl Exports the new scaled_meas operation.
src/TensorValues/Operations.jl Introduces scaled_meas implementations with updated docstrings.
src/ReferenceFEs/ReferenceFEs.jl Exports new types for contravariant Piola maps.
src/ReferenceFEs/RaviartThomasRefFEs.jl Redefines Piola map types and adds evaluate!/lazy_map overloads for the scaled option.
src/Fields/FieldsInterfaces.jl & Fields.jl Imports and exports the scaled_meas operation.
src/FESpaces/FESpaceFactories.jl, DivConformingFESpaces.jl, CurlConformingFESpaces.jl, ConformingFESpaces.jl Updates FESpace construction interfaces to pass additional keyword arguments including the new Piola map type.
Comments suppressed due to low confidence (2)

src/TensorValues/Operations.jl:798

  • Consider clarifying in the docstring that this method applies specifically to square matrices and ensure that its behavior is clearly distinguished from the rectangular case defined below.
scaled_meas(a::MultiValue{Tuple{D,D}}) where D = abs(det(a))^(1/D)

src/FESpaces/FESpaceFactories.jl:75

  • It may be beneficial to add inline documentation or usage examples for the new 'contra_variant_piola_map_type' keyword argument to help users understand its purpose and usage.
  contra_variant_piola_map_type::ContraVariantPiolaMapType=ContraVariantPiolaMap())

detJ::Number,
sign_flip::Bool)
((-1)^sign_flip*v)⋅((1/detJ)*Jt)
((-1)^sign_flip*v)⋅((1/(detJ))*Jt)
Copy link
Preview

Copilot AI Jun 27, 2025

Choose a reason for hiding this comment

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

The use of extra parentheses around detJ improves clarity; consider applying a consistent formatting style to similar expressions in the codebase.

Suggested change
((-1)^sign_flip*v)((1/(detJ))*Jt)
((-1)^sign_flip*v)((1/((detJ)))*Jt)

Copilot uses AI. Check for mistakes.

@JordiManyer
Copy link
Member

Why did we do this in master? I would be working directly on the new moment based branch, otherwise we are doing redundant work. Also, the implementation in the new branch could be done much more elegantly by overwriting the pushforward instead of propagating a kwarg all the way into the depths of the code.

@amboschman
Copy link
Collaborator Author

Thanks Jordi for looking at this.

Why did we do this in master? I would be working directly on the new moment based branch, otherwise we are doing redundant work.

I had a very brief chat with Antoine, but he mentioned that one or two things still had to be finished, so it might take ~ 1 month(? if I remember correctly) for it to be released. Ideally, I would like to use this switch within a shorter timeframe. But happy to learn what can be done to better coordinate this, or contribute/develop a similar thing in the moment-based branch.

Also, the implementation in the new branch could be done much more elegantly by overwriting the pushforward instead of propagating a kwarg all the way into the depths of the code.

That would not give the option to the user to switch between the two different ContraVariantPiolaMappings. I wanted the standard one to be the default, as that is what a user would expect this code to do.

@amboschman
Copy link
Collaborator Author

The only major thing I am missing is a test that stresses the ScaledContraVariantPiolaMap (i.e., the new kw-arg added to the FESpace).

I fully agree.

Perhaps you may some tests here:
https://github.com/gridap/Gridap.jl/blob/master/test/FESpacesTests/DivConformingFESpacesTests.jl

Looking at this at the moment. At a quick glance, having a good test with interpolate and DIV in combination with the ScaledContraVariantPiolaMap require some more work...

Also, have we tried this with (1) BDM. (2) RT elements on triangles?

I tested this once quickly on my system (h-convergence test), but will include this in a test.

@amartinhuertas
Copy link
Member

Why did we do this in master?

  1. Because it is a relatively simple change.
  2. Because we need it relatively urgently for a code base which currently relies on Gridap#master.
  3. Because (we thought) it could also be useful for other users via a non-breaking patch release while they familiarize themselves with the new machinery for moment-based RefFEs.

I would be working directly on the new moment based branch, otherwise we are doing redundant work. Also, the implementation in the new branch could be done much more elegantly by overwriting the pushforward instead of propagating a kwarg all the way into the depths of the code.

Anyway, as you say, we also need to implement this in that branch. It would be great if you can assist us with additional details on how to do this. Thanks!

@JordiManyer
Copy link
Member

That would not give the option to the user to switch between the two different ContraVariantPiolaMappings. I wanted the standard one to be the default, as that is what a user would expect this code to do.

I wanted to keep both as well, just override the pushforward on the kwarg, directly on the reffe instead of propagating it to the functions.

I had a very brief chat with Antoine, but he mentioned that one or two things still had to be finished, so it might take ~ 1 month(? if I remember correctly) for it to be released. Ideally, I would like to use this switch within a shorter timeframe. But happy to learn what can be done to better coordinate this, or contribute/develop a similar thing in the moment-based branch.

Sure, but you can always use the branch. It doesn't need to be released for you to be able to use it in another package.

@JordiManyer
Copy link
Member

Anyway, lets just add some tests and merge this as it is, with the understanding it will get modified soon.

@Antoinemarteau
Copy link
Contributor

Who are those potential users?

The user API implemented here could change in next minor if:

  • this scaling is generalized to Curl-conforming elements / all piola maps, so renaming the kwarg will be needed
  • the choice of Piola map is attached to the reffe rather than fespace, like currently done on moment-based-reffes

So I'm not sure if its a good idea to let users adopt a possibly temporary API design. But if its mostly for you of course this is not an issue..

@amartinhuertas
Copy link
Member

amartinhuertas commented Jul 4, 2025

Let us put this PR on hold ... There are still several issues that we do not understand and thus not ready to be merged.

I have transformed the PR into a draft PR.

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.

4 participants