-
Notifications
You must be signed in to change notification settings - Fork 91
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
Conversation
@@ -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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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], |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 addedFace
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.
array1d< localIndex > m_bubbleCells; | ||
|
||
/// List of face ids which are shared with the interface elements (useful for bubble elements) | ||
array2d< localIndex > m_toFaceElements; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it convenient?
//arrayView1d< integer const > const fractureState = subRegion.getField< contact::fractureState >(); | ||
//arrayView1d< integer > const oldFractureState = subRegion.getField< contact::oldFractureState >(); |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you mean?
There was a problem hiding this comment.
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?
array1d< localIndex > keys( n_max ); | ||
array1d< localIndex > perms( n_max ); | ||
array1d< localIndex > vals( n_max ); | ||
array1d< localIndex > localFaceIds( n_max ); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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:: |
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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 please check test results and apply rebaseline if everything looks ok |
This PR introduces the following three features:
kernelBaseInterface
: This new interface is designed to launch kernels that perform operations on interface elements.