Skip to content
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

Augmented Lagrangian (stick mode) - InterfaceKernelBase - Bubble Functions #3130

Merged
merged 31 commits into from
Jun 19, 2024

Conversation

matteofrigo5
Copy link
Contributor

@matteofrigo5 matteofrigo5 commented May 17, 2024

This PR introduces the following three features:

  • Development of kernelBaseInterface: This new interface is designed to launch kernels that perform operations on interface elements.
  • Implementation of Bubble Element and Face Basis Functions: These functions are used for stabilizing the first-order displacement cell constant pressure formulation in contact mechanics (and the formulation can be easily extended to flow problems).
  • Augmented Lagrangian Method for Contact Mechanics: This initial implementation focuses on the stick mode. Subsequent PRs will address the slip and open modes once this PR is merged.

Copy link

codecov bot commented May 17, 2024

Codecov Report

Attention: Patch coverage is 0.54795% with 1089 lines in your changes missing coverage. Please review.

Project coverage is 55.71%. Comparing base (9134c42) to head (057f692).
Report is 99 commits behind head on develop.

Files with missing lines Patch % Lines
...ntact/SolidMechanicsAugmentedLagrangianContact.cpp 0.00% 591 Missing ⚠️
...hysicsSolvers/contact/SolidMechanicsALMKernels.hpp 0.00% 106 Missing ⚠️
...Solvers/contact/SolidMechanicsALMBubbleKernels.hpp 0.00% 98 Missing ⚠️
...ers/contact/SolidMechanicsALMJumpUpdateKernels.hpp 0.00% 53 Missing ⚠️
...csSolvers/contact/SolidMechanicsALMKernelsBase.hpp 0.00% 46 Missing ⚠️
...iteElement/kernelInterface/InterfaceKernelBase.hpp 0.00% 39 Missing ⚠️
...niteElement/elementFormulations/LagrangeBasis1.hpp 0.00% 37 Missing ⚠️
...ntFormulations/H1_Tetrahedron_Lagrange1_Gauss1.hpp 0.00% 35 Missing ⚠️
...Solvers/contact/SolidMechanicsALMKernelsHelper.hpp 0.00% 17 Missing ⚠️
...lations/H1_Hexahedron_Lagrange1_GaussLegendre2.hpp 0.00% 15 Missing ⚠️
... and 8 more
Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #3130      +/-   ##
===========================================
- Coverage    56.41%   55.71%   -0.71%     
===========================================
  Files         1023     1031       +8     
  Lines        86596    87698    +1102     
===========================================
+ Hits         48857    48863       +6     
- Misses       37739    38835    +1096     

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

@@ -75,6 +75,10 @@ class H1_Hexahedron_Lagrange1_GaussLegendre2 final : public FiniteElementBase
public:
/// The number of nodes/support points per element.
constexpr static localIndex numNodes = LagrangeBasis1::TensorProduct3D::numSupportPoints;

/// The number of nodes/support points per element.
Copy link
Collaborator

Choose a reason for hiding this comment

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

?

Copy link
Contributor Author

@matteofrigo5 matteofrigo5 Jun 11, 2024

Choose a reason for hiding this comment

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

Fixed the comment with: faces/support point

@@ -209,6 +213,42 @@ class H1_Hexahedron_Lagrange1_GaussLegendre2 final : public FiniteElementBase
return calcN( q, N );
}

/**
* @brief Calculate shape functions values for each support face at a
Copy link
Collaborator

Choose a reason for hiding this comment

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

what's a support face? A face to which we are associating a bubble function?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, a face to which we are associating a bubble function. I have modified this comment with: Calculate face bubble functions values for each face at a given point in the parent space.

*/
GEOS_HOST_DEVICE
GEOS_FORCE_INLINE
static void calcBubbleN( real64 const (&pointCoord)[2],
Copy link
Collaborator

Choose a reason for hiding this comment

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

it seems that for 3D elements the bubble functions live on the faces whereas for 2D elements there is one per element. This is clearly how we are using them for contact but if we want this to be more generic we will need element wise bubbles for the 3D cells elements, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are two types of bubble functions both for 3D and 2D elements:

  • face bubble functions, which live on the faces/edges, for 3D/2D respectively;
  • element bubble functions, which live on the elements.
    In the code, when I refer to the first type, I have added Face in the function name.
    Hence, the answer to your question is yes, in the more generic case we will need element wise bubbles functions for the 3D and also face bubble functions for 2D elements.

Comment on lines 409 to 412
array1d< localIndex > m_bubbleCells;

/// List of face ids which are shared with the interface elements (useful for bubble elements)
array2d< localIndex > m_toFaceElements;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I am not sure I fully understand these 2 lists. They also don't seem to be initialized nor registered as wrappers. I would do that. Make sure you set the sizeFromParent to false.

it seems to be that m_bubbleCells just contains the indices of all 3D cells that are connected to a 2D fracture cell. I would say:
"List of the elements adjacent to a faceElement (useful for bubble elements)"

The second list is a bit more confusing. What's the size of that array2d? Are you trying to store the localIndex of each face connected to the faceElement ? That map already exists in the FaceElementSubRegion so I would use that one.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, you are right. I have to register the two lists as wrappers.

The second list is a 2D array containing the localIndex of each face in both the physical and parent element spaces, which are connected to the faceElement. I can't use the map in the FaceElementSubRegion because I need to access this list during the loop over the cells adjacent to a faceElement.

static constexpr int numUdofs = numNodesPerElem * 3;

/// The number of jump dofs per element.
static constexpr int numBubbleUdofs = numFacesPerElem * 3;
Copy link
Collaborator

Choose a reason for hiding this comment

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

are you currently assuming that all faces get a bubble?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I'm. But I assemble in the global matrix only the contribute of the face bubble connected to the fracture.


} );

// Loop for assembling contributes of bubble elements (Abb, Abu, Aub)
Copy link
Collaborator

Choose a reason for hiding this comment

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

you may want to break this down into multiple functions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is it convenient?

Comment on lines 400 to 401
//arrayView1d< integer const > const fractureState = subRegion.getField< contact::fractureState >();
//arrayView1d< integer > const oldFractureState = subRegion.getField< contact::oldFractureState >();
Copy link
Collaborator

Choose a reason for hiding this comment

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

clean up


}

// TODO: Is it possible to define this method once? Similar to SolidMechanicsLagrangeContact
Copy link
Collaborator

Choose a reason for hiding this comment

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

what do you mean?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This function is very similar to the one used in SolidMechanicsLagrangeContact.
I was wondering if a new method could be defined in ContactSolverBase, for example.
Anyway I will have a clearer idea about this function when the slip mode for ALM is also implemented.
In the meantime may I leave this comment as a reminder?

Comment on lines +855 to +858
array1d< localIndex > keys( n_max );
array1d< localIndex > perms( n_max );
array1d< localIndex > vals( n_max );
array1d< localIndex > localFaceIds( n_max );
Copy link
Collaborator

Choose a reason for hiding this comment

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

if you only need these in here and they don't need to go on device I would use std::vector

Copy link
Contributor Author

@matteofrigo5 matteofrigo5 Jun 11, 2024

Choose a reason for hiding this comment

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

These variables are necessary to compute the lists of elements and faces required to assemble the bubble contributions.
All the operations to compute these lists are designed to run on GPU, so yes, they need to go on device.

dt,
faceElementList );

real64 maxTraction = finiteElement::
Copy link
Collaborator

Choose a reason for hiding this comment

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

you probably can define this not to return a max traction since it's just updating the jump.

template< typename CONSTITUTIVE_TYPE,
typename FE_TYPE >
class ALMJumpUpdate :
public ALMKernelsBase< CONSTITUTIVE_TYPE,
Copy link
Collaborator

Choose a reason for hiding this comment

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

I may be wrong but I don't think this Kernel needs to know the constitutive_type. You can write it's own launch if you only need to dispatch on the fe_type.

@matteofrigo5 matteofrigo5 added flag: requires rebaseline Requires rebaseline branch in integratedTests ci: run integrated tests Allows to run the integrated tests in GEOS CI ci: run CUDA builds Allows to triggers (costly) CUDA jobs changes XML input and removed flag: ready for review changes XML input labels Jun 14, 2024
@paveltomin
Copy link
Contributor

@matteofrigo5 please check test results and apply rebaseline if everything looks ok

@CusiniM CusiniM merged commit 949a758 into develop Jun 19, 2024
24 of 26 checks passed
@CusiniM CusiniM deleted the feature/mfrigo/augmentedlagrangian branch June 19, 2024 16:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci: run CUDA builds Allows to triggers (costly) CUDA jobs ci: run integrated tests Allows to run the integrated tests in GEOS CI flag: requires rebaseline Requires rebaseline branch in integratedTests type: feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants