You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, we must consider if we want this to be useful for moving meshes as well. Connectivities for 2:1 octree meshes are much easier to implement and it is a good addition even if we eventually go for more complex cases.
We also should define a new type of face (now we have interior, boundary and MPI) for mortars. I think the cleanest would be to use a different derived type, but if no one likes the idea I would then suggest using parametrized types (more on this below).
I will keep this list updated with all the parts of the code that need to be modified:
FaceClass.f90
Add a new MortarFace type that contains three "sides": the first one is the big one, and the other two are the smaller faces on the other side. If we do not do this, modify the basic face type from Face to Face(n) so that we can use n to allow different array sizes depending on the face type. This applies to attributes like NelLeft, NelRight, NfLeft, NfRight, nodeIDs...
All the subroutines in this file must also be modified to accommodate two or three sides, depending on the face type.
HexElementClass.f90
Modify faceSide to take into account mortar faces. For example, if we consider that the left side of a face is always the big one, we could have something like: 1 -> left, 2 -> right, 3 -> top-right and 4 -> bottom-right.
It seems that most subroutines here will work as they are now.
HexMesh.f90
Add an attribute to store the indices of the mortars, faces_mortar.
Maybe add a logical :: hasHangingNodes to skip all this for usual meshes?
Mesh formats that implement hanging nodes (HOPR?) will probably need updating.
AllocateStorage, pAdapt will need some work as well.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
First, we must consider if we want this to be useful for moving meshes as well. Connectivities for 2:1 octree meshes are much easier to implement and it is a good addition even if we eventually go for more complex cases.
We also should define a new type of face (now we have interior, boundary and MPI) for mortars. I think the cleanest would be to use a different derived type, but if no one likes the idea I would then suggest using parametrized types (more on this below).
I will keep this list updated with all the parts of the code that need to be modified:
MortarFace
type that contains three "sides": the first one is the big one, and the other two are the smaller faces on the other side. If we do not do this, modify the basic face type fromFace
toFace(n)
so that we can usen
to allow different array sizes depending on the face type. This applies to attributes likeNelLeft
,NelRight
,NfLeft
,NfRight
,nodeIDs
...faceSide
to take into account mortar faces. For example, if we consider that the left side of a face is always the big one, we could have something like: 1 -> left, 2 -> right, 3 -> top-right and 4 -> bottom-right.faces_mortar
.logical :: hasHangingNodes
to skip all this for usual meshes?AllocateStorage
,pAdapt
will need some work as well.Beta Was this translation helpful? Give feedback.
All reactions