Update deal.II context with fe capabilities in FEValues fashion #996

marksidoro · 2025-07-14T15:54:40Z

In the code below, the DealiiWrappers namespace is extended by functionality so that a finite element discretization can be set up using the dealii::FEValues objects. The code allows for assembling global FE matrices in a typical deal.II fashion while keeping the DOF layout compatible with 4C. The goal is to be able to assemble coupling blocks between 4C and deal.II based discretizations.

The main classes added are FEValuesContext (and FEFaceValuesContext), which are wrappers around an FEValues object, together with some functionality that handles the reindexing of the local shape functions so that the underlying finite element objects are compatible with the internal ones from 4C.

For this, currently already available parts of the namespace have been reworked, namely the Context class has been updated to provide some further utility, akin to what a dealii::DofHandler would provide. I have also updated the structure/namespaces in the element_conversion.hpp.

A helper class to handle the required deal.II mapping is implemented together with a function to set it up with an isogeometric mapping (currently only working for a single cell_type in the Discretization).

Besides that, there are some further quality of life functions, as well as tests computing an L2-projection, from a simple deal.II Vector directly onto a vector in 4C layout. The problem is solved using a deal.II solver interface and using deal.II matrices and vectors.

Next steps/limitations

Using this code, I have already successfully set up a small FSI toy problem which is based on the tutorial step-46 of the deal.II library using the code provided there for the Fluid part of the Domain, while using the Solid from 4C. That code will be merged next once this PR is through.
Currently, I have not tested this code in parallel yet.
The code is not tested yet for multiple different cell_types within the same discretization

sebproell · 2025-07-14T16:12:59Z

@marksidoro Awesome, I will review this ASAP! In the meantime, could you clean up the commits a little? In the current form, they do not really help in reviewing, since they repeatedly change the same file. Also, could you split out the one commit that changes something in PackBuffer to a separate PR? I am not sure about that change, but this might be better discussed in a dedicated PR.

sebproell

I had a high-level view over the code. This code is quite high quality, great job! The docs and tests are nice 👍

I will do a detailed review tomorrow and we can also discuss a few things in person.

One thing you can already do is to activate the development environment by calling utilities/set_updev_env.sh. I can see that the pre-commit hooks are not run on this state.

src/deal_ii/src/4C_deal_ii_context.hpp

src/deal_ii/src/4C_deal_ii_element_conversion.hpp

src/deal_ii/src/4C_deal_ii_fe_values_context.hpp

src/deal_ii/tests/4C_deal_ii_interploate_and_assembly_test.cpp

marksidoro · 2025-07-15T11:04:03Z

@marksidoro Awesome, I will review this ASAP! In the meantime, could you clean up the commits a little? In the current form, they do not really help in reviewing, since they repeatedly change the same file. Also, could you split out the one commit that changes something in PackBuffer to a separate PR? I am not sure about that change, but this might be better discussed in a dedicated PR.

Thats a good idea. I moved it into its own PR #997

sebproell

First batch of comments (I reviewed from CLion, but it is lacking some features for code suggestions, so I will switch to GH now ;)

src/deal_ii/src/4C_deal_ii_context.hpp

src/deal_ii/src/4C_deal_ii_context_implementation.hpp

src/deal_ii/src/4C_deal_ii_dofs.hpp

sebproell · 2025-07-15T14:03:20Z

src/deal_ii/src/4C_deal_ii_element_conversion.hpp

+          const std::span<const int>& reindex_scalar, std::vector<int>& reindexing);
+    }  // namespace Internal
+
+    namespace FourCToDeal


Maybe the two namespaces are a bit much. How about just FourCToDealii and remove ConversionTools?

sebproell

I know I am repeating myself, but anyway: this code is so nice! It was a real pleasure to review, and I think the PR is in very good shape already.

src/deal_ii/src/4C_deal_ii_element_conversion.hpp

src/deal_ii/src/4C_deal_ii_mapping.hpp

sebproell · 2025-07-15T14:51:16Z

src/deal_ii/src/4C_deal_ii_mapping.hpp

+      return dealii::MappingFEField<dim, spacedim, VectorType>(
+          iso_dof_handler, position_vector, mask);


After reading through the code and the docs of MappingFEField, I am beginning to understand this. The iso_dof_handler is required, since you need to have a DoFHandler with dofs in all space dimensions, and this is not guaranteed for whichever DoFHandler we use for evaluation? So you create it here and create the according position vector. Idk, but maybe my thought process helps you in documenting this a bit clearer (or you can tell me where my assumptions are wrong).

You are basically correct and I have now added some docs to the mapping class to explain its usage.

src/deal_ii/src/4C_deal_ii_triangulation.hpp

src/deal_ii/tests/4C_deal_ii_interpolate_and_assembly_test.cpp

amgebauer

I have a few minor comments. Your added code is very readable! 👍

amgebauer · 2025-07-22T11:19:53Z

src/deal_ii/src/4C_deal_ii_element_conversion.hpp

+      /**
+       * reinidexings of the shape functions from 4C to deal.II for different cell types.
+       */
+      namespace FourCToDeal


Suggested change

namespace FourCToDeal

namespace FourCToDealii

amgebauer · 2025-07-22T11:21:59Z

src/deal_ii/src/4C_deal_ii_element_conversion.hpp

+
+    }  // namespace FourCToDeal
+
+    namespace DealToFourC


Suggested change

namespace DealToFourC

namespace DealiiToFourC

amgebauer · 2025-07-22T11:30:13Z

src/deal_ii/src/4C_deal_ii_element_conversion.hpp

+              "FE_NAME<dim>(degree) within the '< >' brackets. If thats not the case use the "
+              "templated version of this function, where you can specify the dimension explicitly.",
+              finite_element_name);
+          return Core::FE::CellType::dis_none;


Suggested change

return Core::FE::CellType::dis_none;

amgebauer · 2025-07-22T11:31:23Z

src/deal_ii/src/4C_deal_ii_element_conversion.hpp

+          FOUR_C_THROW(
+              "The finite element name {} must contain a dimension (dim) in the form of "
+              "FE_NAME<dim>(degree) within the '< >' brackets. If thats not the case use the "
+              "templated version of this function, where you can specify the dimension explicitly.",
+              finite_element_name);


Why a runtime error and not a compile time error? Are there elements that we don't support?

amgebauer · 2025-07-22T11:32:09Z

src/deal_ii/src/4C_deal_ii_element_conversion.hpp

+          FOUR_C_THROW("Unsupported finite element type '{}' for dim = {} and spacedim = {}.",
+              finite_element_name, 1, 1);
+          return Core::FE::CellType::dis_none;


I think you don't need this here (you have it at the bottom already)

amgebauer · 2025-07-22T11:32:35Z

src/deal_ii/src/4C_deal_ii_element_conversion.hpp

+        }
+        FOUR_C_THROW("Unsupported finite element type '{}' for dim = {} and spacedim = {}.",
+            finite_element_name, dim, spacedim);
+        return Core::FE::CellType::dis_none;


No need to return something if you throw

amgebauer · 2025-07-22T11:38:58Z

src/deal_ii/src/4C_deal_ii_mapping.hpp

+      const Context<dim, spacedim>& context)
+  {
+    FOUR_C_ASSERT(context.n_finite_elements() == 1,
+        "Currently only supported for the case that there is only one finite element in the "


Suggested change

"Currently only supported for the case that there is only one finite element in the "

"Currently only supported for the case that there is only one finite element type in the "

Is it one finite element or one finite element type?

sebproell · 2025-08-12T13:02:00Z

@marksidoro Can you address the few comments, so we can proceed here?

marksidoro requested a review from sebproell July 14, 2025 15:55

sebproell reviewed Jul 14, 2025

View reviewed changes

marksidoro force-pushed the update-deal-context-with-fe-capabilities branch 3 times, most recently from 0e36477 to e14e775 Compare July 15, 2025 12:30

sebproell reviewed Jul 15, 2025

View reviewed changes

marksidoro force-pushed the update-deal-context-with-fe-capabilities branch 3 times, most recently from ba63f5a to 3d4649c Compare July 16, 2025 13:15

marksidoro self-assigned this Jul 16, 2025

marksidoro added 5 commits July 16, 2025 16:28

Update already existing functionality

0916187

Add mapping class with isogeometric mapping

511523c

Add FEValues Wrapper usable with the 4C layout

8a41bb6

Add helper function to create a sparsity pattern

cb31978

Update tests and add new ones

ea52227

marksidoro force-pushed the update-deal-context-with-fe-capabilities branch from 3d4649c to ea52227 Compare July 16, 2025 14:29

amgebauer reviewed Jul 22, 2025

View reviewed changes

		return dealii::MappingFEField<dim, spacedim, VectorType>(
		iso_dof_handler, position_vector, mask);

	"Currently only supported for the case that there is only one finite element in the "
	"Currently only supported for the case that there is only one finite element type in the "

Update deal.II context with fe capabilities in FEValues fashion #996

Are you sure you want to change the base?

Update deal.II context with fe capabilities in FEValues fashion #996

Uh oh!

Conversation

marksidoro commented Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sebproell commented Jul 14, 2025

Uh oh!

sebproell left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

marksidoro commented Jul 15, 2025

Uh oh!

sebproell left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sebproell left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

amgebauer left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sebproell commented Aug 12, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

marksidoro commented Jul 14, 2025 •

edited

Loading