[GeoMechanicsApplication] Extend class LineInterfaceElement such that it also includes planar interface elements by markelov208 · Pull Request #13634 · KratosMultiphysics/Kratos

markelov208 · 2025-07-15T18:20:45Z

📝 Description
A brief description of the PR.

Please mark the PR with appropriate tags:

renamed LineInterfaceElement as InterfaceElement
added pStressStatePolicy in constructors
added LumpedIntegrationScheme
added LocalSpaceDimension check
added Calculate3DRotationMatrixForPlaneGeometry in geometry_utilities
added unit tests
updated element_hierarchy.svg

…Geometry

# Conflicts: # applications/GeoMechanicsApplication/custom_elements/interface_element.cpp # applications/GeoMechanicsApplication/tests/cpp_tests/custom_elements/test_interface_element.cpp

…terialProperties

…ithUDofs

rfaasse

Thank you for adding this well-tested extension of the interface element. I have some suggestions, but nothing major

applications/GeoMechanicsApplication/custom_elements/interface_element.cpp

applications/GeoMechanicsApplication/custom_utilities/geometry_utilities.cpp

applications/GeoMechanicsApplication/tests/cpp_tests/custom_elements/test_interface_element.cpp

applications/GeoMechanicsApplication/custom_elements/interface_element.cpp

applications/GeoMechanicsApplication/tests/cpp_tests/custom_elements/test_interface_element.cpp

avdg81

Hi Gennady,

Thanks a lot for generalizing the line interface element to an interface element that supports both line and surface geometry. I'm also happy to see that you've added lots of unit tests. Well done! I have several suggestions, but they're all minor. We may want to revisit the test code at some point, but for now this looks good enough to me. Let's try to get this in as soon as possible.

avdg81 · 2025-07-16T08:40:11Z

applications/GeoMechanicsApplication/custom_elements/interface_element.cpp

-    : Element(NewId, rGeometry, rProperties),
-      mIntegrationScheme(std::make_unique<LobattoIntegrationScheme>(GetGeometry().PointsNumber() / 2)),
-      mStressStatePolicy(std::make_unique<Line2DInterfaceStressState>())
+InterfaceElement::InterfaceElement(IndexType                                             NewId,


I'm just wondering whether we should name this class GeoInterfaceElement to avoid future name clashes with other applications? Alternatively, we could consider to wrap this class in a Geo namespace. I'm curious how you and @rfaasse feel about this?

Agreed. Currently, it is not changed.

avdg81 · 2025-07-16T08:44:02Z

applications/GeoMechanicsApplication/custom_elements/interface_element.cpp

+InterfaceElement::InterfaceElement(IndexType                          NewId,
+                                   const GeometryType::Pointer&       rGeometry,
+                                   std::unique_ptr<StressStatePolicy> pStressStatePolicy)
+    : Element(NewId, rGeometry), mpStressStatePolicy(std::move(pStressStatePolicy))


Just something to consider: perhaps we can use forwarding constructors to avoid some code duplication?

Sorry I've heard about the forwarding constructors but AI does not help. Perhaps, we can discuss it tomorrow.

applications/GeoMechanicsApplication/custom_elements/interface_element.cpp

applications/GeoMechanicsApplication/tests/cpp_tests/custom_elements/test_interface_element.cpp

avdg81 · 2025-07-16T12:41:42Z

applications/GeoMechanicsApplication/tests/cpp_tests/custom_elements/test_interface_element.cpp

+template <typename TElementFactory>
+InterfaceElement CreateAndInitializeElement(TElementFactory&&          rFactory,
+                                            const Properties::Pointer& rProperties,
+                                            const std::vector<std::pair<std::size_t, array_1d<double, 3>>>& rDisplacements = {})


I find the first function parameter hard to read (rvalue reference). When I look at its usages, my understanding is that you'd like to pass a function object that builds an interface element given the model and the desired properties. Perhaps removing the && already helps?

I'm also a bit worried about the model instance here, since model will go out of scope as soon as this function returns. Any other objects that keep a pointer or reference to that model, will then have dangling pointers and references, which is very dangerous and hard to debug.
I've discussed this with @rfaasse and we agreed that we can look into that later, in order to not delay merging this PR.

Now, removed &&. It still works ;)

applications/GeoMechanicsApplication/tests/cpp_tests/custom_elements/test_interface_element.cpp

avdg81 · 2025-07-16T14:19:59Z

applications/GeoMechanicsApplication/tests/cpp_tests/custom_elements/test_interface_element.cpp

+    const auto p_geometry = std::make_shared<TriangleInterfaceGeometry3D3Plus3Noded>(nodes);
+    const InterfaceElement element(0, p_geometry, p_properties,
+                                   std::make_unique<Line2DInterfaceStressState>());


Also here I'm confused. We're creating a surface interface element (that's what the geometry suggests), but then we pass it a stress state instance that is intended for 2D line interfaces. Perhaps we should not allow that? At least, we shouldn't showcase that in a unit test, in my opinion.

Oh, another mistake. I think we should not allow. Perhaps, a space dimension shall be added to the StressStatePolicy then we can check a correspondence of the geometry and the stress state.

applications/GeoMechanicsApplication/tests/cpp_tests/custom_elements/test_interface_element.cpp

markelov208

Hi Richard and Anne, thank you very much for the reviews. Not everything is changed, hope we can discuss it.

avdg81

Hi Gennady, thanks for processing the review suggestions so swiftly. I feel we're almost there. I have one more question about the function that calculates the expected LHS matrices.

avdg81 · 2025-07-17T07:10:32Z

applications/GeoMechanicsApplication/tests/cpp_tests/custom_elements/test_interface_element.cpp

+Matrix CreateExpectedLeftHandSideForTriangleElement(std::size_t dimension,
+                                                    double      NormalStiffness,
+                                                    double      ShearStiffness,
+                                                    double      divider1 = 3.0,
+                                                    double      divider2 = 3.0)
+{
+    Matrix      expected_left_hand_side = ZeroMatrix(dimension, dimension);
+    double      value;
+    std::size_t counter        = 0;
+    std::size_t half_dimension = dimension / 2;
+    for (std::size_t i = 0; i < half_dimension; i++) {
+        if (++counter == 3) {
+            value   = NormalStiffness;
+            counter = 0;
+        } else {
+            value = ShearStiffness;
+        }
+        if (i < 9) {
+            value /= divider1;
+        } else {
+            value /= divider2;
+        }
+        expected_left_hand_side(i, i)                                   = value;
+        expected_left_hand_side(i, i + half_dimension)                  = -value;
+        expected_left_hand_side(i + half_dimension, i)                  = -value;
+        expected_left_hand_side(i + half_dimension, i + half_dimension) = value;
+    }
+
+    return expected_left_hand_side;
+}


I understand that you'd like to reuse one or a few of the expected left hand side matrices, but I'm not sure whether this is the way to go. I don't understand the implementation of this function. How can I check that this makes sense from a physics/FEM point of view? My understanding of @rfaasse's suggestion was to extract a function that returns a matrix with hard-coded numbers, since some of these matrices were repeated.
If we'd like to keep the current implementation, I feel that we need a comment that explains the calculation, perhaps with some references to finite element books/papers?

Thank you for the clarification. Now there is a function that provide these values. I put a comment that the values are taken from the element. The theory, it looks 3D case with matrix of 18x18 is consistent with 2D case 8x8 but 3D case of 36x36 is something special.

avdg81 · 2025-07-17T07:14:13Z

applications/GeoMechanicsApplication/tests/cpp_tests/custom_elements/test_interface_element.cpp

+    const auto prescribed_displacements = PrescribedDisplacements{
+        {2, array_1d<double, 3>{0.2, 0.5, 0.0}}, {3, array_1d<double, 3>{0.2, 0.5, 0.0}}};
+    auto element = CreateAndInitializeElement(CreateHorizontalUnitLength2Plus2NodedLineInterfaceElementWithUDofs,
+                                              p_properties, prescribed_displacements);


Much clearer. Thank you.

rfaasse

Thanks for processing the review comments, to me this looks ready to go!

markelov208 added 12 commits July 7, 2025 15:48

renamed LineInterfaceElement as InterfaceElement

06a8272

added LocalSpaceDimension check and Calculate2DRotationMatrixForPlane…

811c1cc

…Geometry

updated element_hierarchy.svg

dd05141

added unit tests and 8 still red

21b9475

Merge branch 'master' into geo/13334-extend-LineInterfaceElement

853227a

added LumpedIntegrationScheme

5baff85

changed 2D triangle into 3D triangle

4cc79f6

Merge branch 'master' into geo/13334-extend-LineInterfaceElement

bdba42e

column based rotation matrix

a56ad83

Merge branch 'master' into geo/13334-extend-LineInterfaceElement

3a72374

# Conflicts: # applications/GeoMechanicsApplication/custom_elements/interface_element.cpp # applications/GeoMechanicsApplication/tests/cpp_tests/custom_elements/test_interface_element.cpp

added pStressStatePolicy in constructors

9b50abe

fixed unit tests

225d11c

markelov208 self-assigned this Jul 15, 2025

markelov208 requested a review from a team as a code owner July 15, 2025 18:20

markelov208 linked an issue Jul 15, 2025 that may be closed by this pull request

[GeoMechanicsApplication] Extend class LineInterfaceElement such that it also includes planar interface elements #13334

Closed

markelov208 added 9 commits July 16, 2025 09:21

extracted MakeIntegrationSheme

d3c8352

removed code smells

2db8caf

joint CreateLinearElasticMaterialProperties and CreatePlanarElasticMa…

d1d11d0

…terialProperties

joint Create2DInterfaceElementWithUDofs and Create3DInterfaceElementW…

693a07a

…ithUDofs

introduced serializer

3bacf00

extracted CreateAndInitializeElement

9b58c73

used emplace_back

19fac87

added static_assert

c922966

added function pointer mfpCalculateRotationMatrix

a7267fe

rfaasse reviewed Jul 16, 2025

View reviewed changes

avdg81 reviewed Jul 16, 2025

View reviewed changes

markelov208 added 3 commits July 16, 2025 18:30

response to the review 1

b962afa

response to review 2

7384a74

created CreateExpectedLeftHandSideForTriangleElement

e23db2a

markelov208 requested a review from avdg81 July 16, 2025 19:33

markelov208 requested a review from rfaasse July 16, 2025 19:33

markelov208 commented Jul 16, 2025

View reviewed changes

markelov208 added 2 commits July 16, 2025 22:19

a bit nicer

2cbde03

one more use of CreateExpectedLeftHandSideForTriangleElement

6f34cb0

avdg81 reviewed Jul 17, 2025

View reviewed changes

markelov208 added 2 commits July 17, 2025 09:52

reverted expected_left_hand_side vlaues

0f216b9

renamed as ExpectedLeftHandSideForTriangleElement

227d9f0

rfaasse approved these changes Jul 17, 2025

View reviewed changes

markelov208 merged commit ec79f44 into master Jul 17, 2025
10 checks passed

markelov208 deleted the geo/13334-extend-LineInterfaceElement branch July 17, 2025 12:45

Conversation

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

Uh oh!

Uh oh!

rfaasse left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

avdg81 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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

markelov208 left a comment

Choose a reason for hiding this comment

Uh oh!

avdg81 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!

rfaasse left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

markelov208 commented Jul 15, 2025 •

edited

Loading