GEOS icon indicating copy to clipboard operation
GEOS copied to clipboard

VEM support in small strain solid mechanics solvers

Open andrea-borio opened this issue 2 years ago • 1 comments

The purpose of this PR is to add support of Virtual Elements to SolidMechanicsLagrangianFEM and SolidMechanicsSmallStrainQuasiStaticKernel in order to solve linear elasticity with VEM.

Summary of relevant changes

  • solidMechanicsLagrangianFEMKernels::QuasiStatic and SolidMechanicsLagrangianFEM modified introducing enhanced FEM syntax compatible with VEM.
  • classes in finiteElement/elementFormulations modified to be able to add stabilization terms in case of vectorial problems.
  • the stabilization matrix is scaled locally by a factor that is computed by solidMechanicsLagrangianFEMKernels::QuasiStatic::computeStabilizationScaling. The method is currently implemented for a linear elastic model.
  • to avoid long compilation time which caused failure of some Travis builds, the SolidMechanicsLagrangianFEM solver is compiled only with VEM types that do not overlap with existing FEM types.

Changes in FiniteElementDispatch

The behavior of dispatch methods was changed as follows: if the GEOSX_DISPATCH_VEM flag is defined, the class tries to dispatch also VEM types that overlap with standard FEM, otherwise it considers only the ones defined on non-standard shapes (currently H1_Prism5_VEM_Gauss1 and H1_Prism6_VEM_Gauss1.

andrea-borio avatar Mar 21 '22 11:03 andrea-borio

Hi @andrea-borio, I have a question that is not directly related to this PR. However, if the concern is legitimate, it may be resolved here. The convenience typedefs introduced in ConformingVirtualElementOrder1.hpp (see below) are not quite clear to me. Specifically I don't understand the second template parameter. https://github.com/GEOSX/GEOSX/blob/b8d4a23007add5677e65aaf9965e6ca9078b87f7/src/coreComponents/finiteElement/elementFormulations/ConformingVirtualElementOrder1.hpp#L567-L574 My understanding is that such parameter defines the maximum number of nodes per face for each element type. Hence, I would expect it to be 3 for the tetrahedra and 4 for the all the other elements, namely:

 /// Convenience typedef for VEM on tetrahedra. 
 using H1_Tetrahedron_VEM_Gauss1 = ConformingVirtualElementOrder1< 4, 3 >; 
 /// Convenience typedef for VEM on hexahedra. 
 using H1_Hexahedron_VEM_Gauss1 = ConformingVirtualElementOrder1< 8, 4 >; 
 /// Convenience typedef for VEM on pyramids. 
 using H1_Pyramid_VEM_Gauss1 = ConformingVirtualElementOrder1< 5, 4 >; 
 /// Convenience typedef for VEM on wedges. 
 using H1_Wedge_VEM_Gauss1 = ConformingVirtualElementOrder1< 6, 4 >; 

castelletto1 avatar May 05 '22 06:05 castelletto1