ratel user manual

Ratel User ManualRelease v0.0.0

Jed Brown Ren Stengel Jeremy L. Thompson

Oct 04, 2021

Contents

1 Introduction 2

2 Mathematical modeling 22.1 Continuum mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1.1 Material coordinates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.1.1 Lagrangian view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.1.2 Eulerian view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.1.3 Material derivative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.2 Balance laws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2.1 Lagrangian view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2.2 Eulerian view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Constitutive modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.1 Neo-Hookean Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1.1 Linearization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1.2 Current configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2 Mooney-Rivlin Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2.1 Linearization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2.2 Current Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Numerical formulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.1 Hyperelasticity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1.1 Initial configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.1.2 Current configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.2 Elastodynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.3 Material point method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 API Documentation 123.1 Matrials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1 Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Boundary Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.1 Boundary Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Internal Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.1 Internal Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Developer Notes 214.1 Style Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Clang-tidy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 Header Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1

4.4 restrict semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Ratel: How to Contribute 225.1 Developer’s Certificate of Origin 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2 Authorship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Ratel Code of Conduct 246.1 Our Pledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2 Our Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.3 Enforcement Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.5 Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.6 Enforcement Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.6.1 1. Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.6.2 2. Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.6.3 3. Temporary Ban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.6.4 4. Permanent Ban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.7 Attribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7 Indices and tables 26

References 26

Index 27

1 Introduction

Ratel is a solid mechanics application based upon libCEED and PETSc.

2 Mathematical modeling

2.1 Continuum mechanics

In continuum mechanics, we model materials as continuous pieces of matter and define quantities of interest,such as density, velocity, and force, on these pieces of matter. In this section, we cover notation and principalsused in the mathematical modeling of materials and methods in Ratel.

2.1.1 Material coordinates

In continuum mechanics, material is deformed from an initial configuration with, coordinates denoted X ,to the current configuration, with coordinates denoted x. The Lagrangian view of the material is based inthe current configuration while the Eulerian view of the material is based in the initial configuration.

2

2.1.1.1 Lagrangian view

In the Lagrangian view, deformation from the initial configuration is given by

x = χ (X, t) .

Velocity and acceleration functions are therefore given by

V (X, t) =∂χ

∂t(X, t) ,

A (X, t) =∂2χ

∂t2(X, t) .

2.1.1.2 Eulerian view

It is natural to assume that the mapping from the initial configuration to the current configuration is smooth,as we assume in continuum mechanics that no two particles occupy the same space at the same time. There-fore, can ‘push forward’ these velocity and acceleration functions to the current configuration by using theinverse mapping

X = χ−1 (x, t) .

Velocity is relatively straightforward to compute

vi (x, t) = Vi

(χ−1 (x, t) , t

)=

∂χi

∂t

(χ−1 (x, t) , t

),

while acceleration is a more involved computation

ai (x, t) = Ai

(χ−1 (x, t) , t

)=

∂vi∂t

(x, t) +∂vi∂xj

(x, t) vj (x, t) .

Note that this leads to the somewhat surprising result in the Eulearian view that

ai (x, t) =∂vi∂t

(x, t) .

Also note that we can ‘pull back’ to the Lagrangian view via

V (X, t) = v (χ (X, t) , t) ,

A (X, t) = a (χ (X, t) , t) .

2.1.1.3 Material derivative

The relationship between v (x, t) and a (x, t) is common in our derivations and is known as the materialderivative.

ai (x, t) =D

Dtvi (x, t) =

∂vi∂t

(x, t) +∂vi∂xj

(x, t) vj (x, t)

For an Eulerian function f (x, t) with a corresponding Lagrangian function F (X, t), the material derivativeDDtf arises from pushing forward the derivative ∂

∂tF .

3

2.1.2 Balance laws

Mathematical models for continuum mechanics rely upon governing laws that ensure the balance of massand momentum in the system being modeled. Below we provide the equations for balance of mass andlinear momentum used in the material methods section.

2.1.2.1 Lagrangian view

Law FormulationBalance of Mass ρJ − ρ0 = 0

Balance of Linear Momentum ρ∂V∂t −∇X · P − ρ0b = 0

P is the first Piola-Kirchhoff stress tensor and b are the body forces. ρ and ρ0 denote the mass density andinitial mass density, respectively.

The first Piola-Kirchhoff stress tensor can be decomposed as

P = FS,

where S is the second Piola-Kirchhoff stress tensor, given by the constitutive model for the material, and F =dxdX = I3 +∇Xu is the deformation gradient with displacement u = X − x from the initial configuration.

2.1.2.2 Eulerian view

Law FormulationBalance of Mass D

Dtρ− ρ∇X · v = 0

Balance of Linear Momentum ρDvDt −∇X · σ − ρ0g = 0

Recall that DDt denotes the material derivative.

The Cauchy stress tensor, given by

σ =1

JPF T .

Some methods also use the symmetric Kirchhoff stress tensor, given by

τ = Jσ = FSF T .

2.2 Constitutive modeling

In their most general form, constitutive models define stress, S, in terms of state variables. For the materialsused in Ratel, the state variables are constituted by the vector displacement field u, and its gradient ∇u.We consider constitutive models for stress in terms of strain due to deformation, given by S (E), which is atensor-valued function of a tensor-valued input.

A physical model must not depend on the coordinate system chosen to express it; an arbitrary choice offunction will generally not be invariant under orthogonal transformations and thus will not admissible.Given an orthogonal transformation Q, we desire

QS (E)QT = S(QEQT

), (2.1)

4

which means that we can change our reference frame before or after computing S and get the same result.Constitutive relations in which S is uniquely determined by E while satisfying the invariance property (2.1)are known as Cauchy elastic materials.

For our constitutive relationships, we define a strain energy density functional Φ(E) ∈ R and obtain thestrain energy from its gradient,

S (E) =∂Φ

∂E. (2.2)

Note: The strain energy density functional cannot be an arbitrary function Φ(E). It can only depend oninvariants, scalar-valued functions γ satisfying

γ (E) = γ(QEQT

)for all orthogonal matrices Q.

2.2.1 Neo-Hookean Materials

In the total Lagrangian approach for the Neo-Hookean constitutive model, the model is formulated withrespect to the initial configuration. Our notation for the Neo-Hookean constitutive model is inspired by[Hol00] to distinguish between the current and initial configurations. As explained in the Continuum me-chanics section, we denote coordinates in the reference frame by capital letters and the current frame bylowercase letters.

For the constitutive modeling of Neo-Hookean hyperelasticity at finite strain, we need the deformation gra-dient,

F = I3 +∇Xu,

where the subscript X in∇X indicates that the gradient is calculated with respect to the initial configuration.

Using the deformation gradient, we define two symmetric tensors in the initial configuration, the rightCauchy-Green tensor

C = F TF

and the Green-Lagrange strain tensor

E =1

2(C − I3) =

1

2

(∇Xu+ (∇Xu)

T+ (∇Xu)

T ∇Xu). (2.3)

Note that the Green-Lagrange strain tensor converges to the linear strain tensor ϵ in the small-deformationlimit.

We will assume without loss of generality that E is diagonal and take its set of eigenvalues as the in-variants. It is clear that there can be only three invariants, and there are many alternate choices, such astrace (E) , trace

(E2

), |E|, and combinations thereof. It is common in the literature for invariants to be taken

from C = I3 + 2E instead of E.

For example, if we take the compressible Neo-Hookean model,

Φ(E) =λ

2(log J)

2 − µ log J +µ

2(traceC − 3)

=λ

2(log J)

2 − µ log J + µ traceE,

(2.4)

5

where J = |F | =√|C| is the determinant of deformation (i.e., volume change) and λ and µ are the Lamé

parameters in the infinitesimal strain limit.

To evaluate the gradient of the strain energy density functional (2.2), we make use of

∂J

∂E=

∂√|C|

∂E= |C|−1/2|C|C−1 = JC−1,

where the factor of 12 has been absorbed due to C = I3 + 2E. Carrying through the differentiation (2.2) for

the model (2.4), we arrive at

S = λ log JC−1 + µ(I3 −C−1

), (2.5)

which is the second Piola-Kirchoff tensor for Neo-Hookean materials.

Tip: An equivalent form of (2.5) is

S = λ log JC−1 + 2µC−1E, (2.6)

which is more numerically stable for small E, and thus preferred for computation. Note that the productC−1E is also symmetric, and that E should be computed using (2.3).

Similarly, it is preferable to compute log J using log1p, especially in case of nearly incompressible materials.To sketch this idea, suppose we have the 2×2 non-symmetric matrix F =

(1+u0,0 u0,1

u1,0 1+u1,1

). Then we compute

log J = log1p (u0,0 + u1,1 + u0,0u1,1 − u0,1u1,0) , (2.7)

which gives accurate results even in the limit when the entries ui,j are very small. For example, if ui,j ∼ 10−8,then naive computation of I3−C−1 and log J will have a relative accuracy of order 10−8 in double precisionand no correct digits in single precision. When using the stable choices above, these quantities retain fullεmachine relative accuracy.

Note: One can linearize (2.5) around E = 0, for which C = I3 + 2E → I3 and J → 1 + traceE, therefore(2.5) reduces to

S = λ (traceE) I3 + 2µE, (2.8)

which is the St. Venant-Kirchoff model (constitutive linearization without geometric linearization).

This model can be used for geometrically nonlinear mechanics (e.g., snap-through of thin structures), but isinappropriate for large strain.

2.2.1.1 Linearization

For the Neo-Hookean model (2.5),

dS =∂S

∂E:dE = λ

(C−1 :dE

)C−1 + 2 (µ− λ log J)C−1 dEC−1, (2.9)

where we have used

dC−1 =∂C−1

∂E:dE = −2C−1 dEC−1.

The quantity ∂S/∂E is known as the incremental elasticity tensor, and is analogous to the linear elasticitytensor C.

6

dS in index notation

It is sometimes useful to express (2.9) in index notation,

dSIJ =∂SIJ

∂EKLdEKL

= λ(C−1

KL dEKL

)C−1

IJ + 2 (µ− λ log J)C−1IK dEKLC

−1LJ

=(λC−1

IJ C−1KL + 2 (µ− λ log J)C−1

IKC−1JL

)︸︷︷︸CIJKL

dEKL ,

(2.10)

where we have identified the effective elasticity tensor C = CIJKL. It is generally not desirable to store C,but rather to use the earlier expressions so that only 3 × 3 tensors (most of which are symmetric) must bemanipulated.

2.2.1.2 Current configuration

Push forward, then linearize

Recall that the symmetric Kirchhoff stress tensor is given by

τ = Jσ = PF T = FSF T = µ (b− I3) + λ log JI3. (2.11)

To derive a useful expression of dτ for Neo-Hookean materials, we will use the representations

db = dFF T + F dF T

= ∇x du b+ b (∇x du)T

= (∇x du) (b− I3) + (b− I3) (∇x du)T+ 2dϵ

and

d (log J) =∂ log J

∂b:db =

∂J

J∂b:db =

1

2b−1 :db

=1

2b−1 :

(∇x du b+ b (∇x du)

T)

= trace(∇x du)

= trace dϵ,

where

dϵ ≡ 1

2

(∇x du+ (∇x du)

T).

is the incremental strain tensor in the current configuration.

Substituting into (2.11) gives

dτ = µdb+ λ trace (dϵ) I3

= 2µ dϵ+ λ trace (dϵ) I3 − 2λ log J dϵ︸︷︷︸F dSFT

+ (∇x du) (µ (b− I3) + λ log JI3)︸︷︷︸τ

+ (µ (b− I3) + λ log JI3)︸︷︷︸τ

(∇x du)T,

(2.12)

where the final expression has been identified according to

dτ = d(FSF T

)= (∇x du) τ + F dSF T + τ (∇x du)

T .

7

Linearize, then push forward

Now we push (2.9) forward via

F dSF T = λ(C−1 :dE

)FC−1F T + 2 (µ− λ log J)FC−1 dEC−1F T

= λ(C−1 :dE

)I3 + 2 (µ− λ log J)F−T dEF−1

= λ trace (∇x du) I3 + 2 (µ− λ log J) dϵ

where we have usedC−1 :dE = F−1F−T :F T dF

= trace(F−1F−TF T dF

)= trace

(F−1 dF

)= trace

(dFF−1

)= trace (∇x du)

and

F−T dEF−1 =1

2F−T

(F T dF + dF TF

)F−1

=1

2

(dFF−1 + F−T dF T

)=

1

2

(∇x du+ (∇x du)

T)≡ dϵ.

2.2.2 Mooney-Rivlin Materials

While the Neo-Hookean model depends on just two scalar invariants, I1 = traceC = 3 + 2 traceE and J ,Mooney-Rivlin models depend on the additional invariant, I2 = 1

2

(I21 −C :C

). A coupled Mooney-Rivlin

strain energy density (cf. Neo-Hookean (2.4)) is [Hol00]

Φ(I⊮, I⊭, J) =λ

2(log J)

2 − (µ1 + 2µ2) log J +µ1

2(I⊮ − 3) +

µ2

2(I⊭ − 3) . (2.13)

We differentiate Φ as in the Neo-Hookean case (2.5) to yield the second Piola-Kirchoff tensor,

S = λ log JC−1 − (µ1 + 2µ2)C−1 + µ1I3 + µ2 (I⊮I3 −C)

= (λ log J − µ1 − 2µ2)C−1 + (µ1 + µ2I1) I3 − µ2C,

(2.14)

where we have used∂I⊮∂E

= 2I3,∂I⊭∂E

= 2I1I3 − 2C,∂ log J

∂E= C−1. (2.15)

This is a common model for vulcanized rubber, with a shear modulus (defined for the small-strain limit) ofµ1 + µ2 that should be significantly smaller than the first Lamé parameter λ.

2.2.2.1 Linearization

Similar to the linearization of the constitutive relationship for Neo-Hookean materials (2.9), we differentiate(2.14) using variational notation,

dS = λ(C−1 :dE

)C−1

+ 2 (µ1 + 2µ2 − λ log J)C−1 dEC−1

+ 2µ2 (trace (dE) I3 − dE) .

(2.16)

Note that this agrees with the linearization of the Neo-Hookean constitutive relationship (2.9) if µ1 = µ, µ2 =0. Moving from Neo-Hookean to Mooney-Rivlin modifies the second term and adds the third.

8

2.2.2.2 Current Configuration

Development of the Mooney-Rivlin model in the current configuration in Ratel is in progress.

2.3 Numerical formulations

Ratel implements three formulations for simulating solid mechanics materials. The hyperelastic formulationsolves the steady-state static momentum balance equations using unstructured high-order finite/spectral el-ement spatial discretizations. The elastodynamics formulation applies time varying boundary conditionsto the hyperelastic formulation. The material point method projects the Lagrangian materials onto a back-ground Eulerian finite element mesh to compute the material derivatives.

2.3.1 Hyperelasticity

Ratel solves the steady-state static momentum balance equations using unstructured high-order fi-nite/spectral element spatial discretizations.

Note: Linear elasticity and small-strain hyperelasticity can both by obtained from the finite-strain hyper-elastic formulation by linearization of geometric and constitutive nonlinearities. The effect of these lin-earizations is sketched in the diagram below, where σ and ϵ are stress and strain, respectively, in the smallstrain regime, while S and E are their finite-strain generalizations (second Piola-Kirchoff tensor and Green-Lagrange strain tensor, respectively) defined in the initial configuration, and C is a linearized constitutivemodel.

Finite Strain Hyperelastic︷︸︸︷S (E)

constitutive−−−−−−−→linearization

St. Venant-Kirchoff︷︸︸︷S = CE

geometricyE→ϵ

S→σE→ϵS→σ

ygeometric

σ (ϵ)︸︷︷︸Small Strain Hyperelastic

constitutive−−−−−−−→linearization

σ = Cϵ︸︷︷︸Linear Elastic

(2.17)

2.3.1.1 Initial configuration

In the total Lagrangian approach for the Neo-Hookean hyperelasticity problem, the discrete equations areformulated with respect to the initial configuration. In this formulation, we solve for displacement u (X)in the reference frame X . The notation for elasticity at finite strain is inspired by [Hol00] to distinguishbetween the current and initial configurations. As explained in the Continuum mechanics section, we denoteby capital letters the reference frame and by small letters the current one.

The strong form of the static balance of linear-momentum at finite strain (total Lagrangian) is given by:

−∇X · P − ρ0g = 0 (2.18)

where the subscript X in ∇X indicates that the gradient is calculated with respect to the initial configurationin the finite strain regime. P and g are the first Piola-Kirchhoff stress tensor and the prescribed forcing function,respectively. ρ0 is known as the initial mass density. The tensor P is not symmetric, living in the currentconfiguration on the left and the initial configuration on the right.

9

P can be decomposed as

P = F S, (2.19)

where S is the second Piola-Kirchhoff stress tensor, a symmetric tensor defined entirely in the initial configura-tion, and F = I3 +∇Xu is the deformation gradient. Different constitutive models can define S, as shownin the Constitutive modeling section.

Weak form

We multiply (2.18) by a test function v and integrate by parts to obtain the weak form for finite-strain hy-perelasticity: find u ∈ V ⊂ H1 (Ω0) such that∫

Ω0

∇Xv :P dV −∫Ω0

v · ρ0g dV −∫∂Ω0

v ·(P · N

)dS = 0, ∀v ∈ V, (2.20)

where P · N |∂Ω is replaced by any prescribed force/traction boundary condition written in terms of theinitial configuration. This equation contains material/constitutive nonlinearities in defining S(E), as wellas geometric nonlinearities through P = F S, E(F ), and the body force g, which must be pulled back fromthe current configuration to the initial configuration. Discretization of (2.20) produces a finite-dimensionalsystem of nonlinear algebraic equations, which we solve using Newton-Raphson methods. One attractivefeature of Galerkin discretization is that we can arrive at the same linear system by discretizing the New-ton linearization of the continuous form; that is, discretization and differentiation (Newton linearization)commute.

Newton linearization

To derive a Newton linearization of (2.20), we begin by expressing the derivative of (2.19) in incrementalform,

dP =∂P

∂F:dF = dF S + F

∂S

∂E:dE︸︷︷︸

dS

(2.21)

where dF = ∇X du.

The linearization of the second Piola-Kirchhoff stress tensor, dS, depends upon the material model.

Note that the Newton linearization of (2.20) may be written as a weak form for linear operators: find du ∈ V0

such that ∫Ω0

∇Xv :dP dV = rhs, ∀v ∈ V0,

where dP is defined by (2.21) and (2.9), and V0 is the homogeneous space corresponding to V .

2.3.1.2 Current configuration

In the preceeding discussion, all equations have been formulated in the initial configuration. This may feelconvenient in that the computational domain is clearly independent of the solution, but there are someadvantages to defining the equations in the current configuration.

1. Body forces (such as gravity), traction, and contact are more easily defined in the current configuration.

2. Mesh quality in the initial configuration can be very bad for large deformation.

10

3. The required storage and numerical representation can be smaller in the current configuration.

Most of the benefit in case 3 can be attained solely by moving the Jacobian representation to the currentconfiguration [DPA+20], though residual evaluation may also be slightly faster in current configuration.There are multiple commuting paths from the nonlinear weak form in initial configuration (2.20) to theJacobian weak form in current configuration (2.26). One may push forward to the current configuration andthen linearize or linearize in initial configuration and then push forward, as summarized below.

Initial Residual︷︸︸︷∇Xv :FS

push forward−−−−−−−−→Current Residual︷︸︸︷

∇xv :τ

linearizey dF=∇X du

dS(dE)d∇xv=−∇xv∇x du

dτ (dϵ)

ylinearize

∇Xv : (dFS + F dS)︸︷︷︸Initial Jacobian

push forward−−−−−−−−→ ∇xv :(dτ − τ (∇x du)

T)

︸︷︷︸Current Jacobian

(2.22)

We will follow both paths for consistency and because both intermediate representations may be useful forimplementation.

Push forward, then linearize

The first term of (2.20) can be rewritten in terms of the symmetric Kirchhoff stress tensor τ = Jσ = PF T =FSF T as

∇Xv :P = ∇Xv :τF−T = ∇XvF−1 :τ = ∇xv :τ

therefore, the weak form in terms of τ and ∇x with integral over Ω0 is∫Ω0

∇xv :τ dV −∫Ω0

v · ρ0g dV −∫∂Ω0

v ·(P · N

)dS = 0, ∀v ∈ V. (2.23)

Linearize in current configuration

To derive a Newton linearization of (2.23), first we define

∇x du = ∇X du F−1 = dFF−1 (2.24)

and τ for Neo-Hookean materials as the push forward of (2.5).

Then by expanding the directional derivative of ∇xv :τ , we arrive at

d (∇xv :τ ) = d (∇xv) :τ +∇xv :dτ . (2.25)

The first term of (2.25) can be written as

d(∇xv) :τ = d(∇XvF−1

):τ =

∇X (dv)︸︷︷︸0

F−1 +∇Xv dF−1

:τ

=(−∇XvF−1 dFF−1

):τ =

(−∇xv dFF−1

):τ

= (−∇xv∇x du) :τ = −∇xv :τ (∇x du)T,

where we have used dF−1 = −F−1 dFF−1 and (2.24). Using this and (2.25) in (2.23) yields the weak formin the current configuration ∫

Ω0

∇xv :(dτ − τ (∇x du)

T)= rhs. (2.26)

11

Collecting terms, we have

dτ − τ (∇x du)T= (∇x du) τ + F dSF T . (2.27)

Linearize, then push forward

We can move the derivatives to the current configuration via

∇Xv :dP = (∇Xv)F−1 :dPF T = ∇xv :dPF T

and expand

dPF T = dFSF T + F dSF T

= dFF−1︸︷︷︸∇x du

FSF T︸︷︷︸τ

+F dSF T .

2.3.2 Elastodynamics

Development of the elastodynamics formulation in Ratel is in progress.

2.3.3 Material point method

Development of the material point method in Ratel is in progress.

3 API Documentation

This section contains the code documentation.

3.1 Matrials

These functions setup the various materials.

3.1.1 Materials

static const char *const field_names[] = ”gradu”

static CeedInt field_sizes[] = 9

MaterialData finite_strain_Mooney_Rivlin_initial = .setup_geo = SetupGeo, .setup_geo_loc = SetupGeo_loc, .geo_data_size = 10, .quadrature_mode = CEED_GAUSS, .residual = ElasFSInitialMRF, .residual_loc = ElasFSInitialMRF_loc, .number_fields_stored = 1, .field_names = field_names, .field_sizes = field_sizes, .jacobian = ElasFSInitialMRdF, .jacobian_loc = ElasFSInitialMRdF_loc, .energy = ElasFSInitialMREnergy, .energy_loc = ElasFSInitialMREnergy_loc, .diagnostic = ElasFSInitialMRDiagnostic, .diagnostic_loc = ElasFSInitialMRDiagnostic_loc,

PetscErrorCode SetupLibceedFineLevel_ElasFSInitialMR(DM dm, DM dm_energy, DMdm_diagnostic, Ceed ceed, AppCtxapp_ctx, CeedQFunctionContextphys_ctx, PetscInt fine_level,PetscInt num_comp_u, PetscIntU_g_size, PetscInt U_loc_size,CeedVector force_ceed, Ceed-Vector neumann_ceed, CeedData*data)

Setup libCEED operators for fine grid non-linear operator and Jacobian for Mooney-Rivlin hyperelas-ticity at finite strain in initial configuration.

12

Parameters

• dm – [in] DM for solution vector

• dm_energy – [in] DM for computing final strain energy

• dm_diagnostic – [in] DM for computing diagnostic data

• ceed – [in] libCEED context

• app_ctx – [in] Application context data

• phys_ctx – [in] Physical parameter context for matriel model

• fine_level – [in] Index of fine level in multigrid hierarchy

• num_comp_u – [in] Number of components in solution vector

• U_g_size – [in] Size of global solution vector

• U_loc_size – [in] Size of local solution vector

• force_ceed – [out] libCEED vector for forcing term

• neumann_ceed – [out] libCEED vector for Neumann boundary conditions

• data – [out] libCEED objects for fine grid

Returns An error code: 0 - success, otherwise - failure

PetscErrorCode SetupLibceedLevel_ElasFSInitialMR(DM dm, Ceed ceed, AppCtx app_ctx,PetscInt level, PetscInt num_comp_u,PetscInt U_g_size, PetscInt U_loc_size,CeedVector fine_mult, CeedData*data)

Setup libCEED operators for multigrid prolongation, restriction, and coarse grid Jacobian evaluationfor Mooney-Rivlin hyperelasticity at finite strain in initial configuration.

Parameters




• material_data – [in] Data and functions for material

• level – [in] Index of level in multigrid hierarchy




• fine_mult – [in] libCEED vector for fine grid multiplicity

• data – [out] libCEED objects for prolongation, restriction, and coarse grid


13

3.2 Boundary Conditions

These functions apply boundary conditions.

3.2.1 Boundary Conditions

PetscErrorCode BCMMS(PetscInt dim, PetscReal load_increment, const PetscReal coords[], PetscIntnum_comp_u, PetscScalar *u, void *ctx)

Boundary function for linear elasticity manufactured solution.

Parameters

• dim – [in] Dimension of the mesh

• load_increment – [in] Current load increment

• coords – [in] Coordinates of point


• u – [out] Solution vector at point

• ctx – [in] Context data


PetscErrorCode BCClamp(PetscInt dim, PetscReal load_increment, const PetscReal coords[], PetscIntnum_comp_u, PetscScalar *u, void *ctx)

Boundary function for affine transformation at fraction of load increment.

Parameters

• dim – [in] Dimension of the mesh

• load_increment – [in] Current load increment

• coords – [in] Coordinates of point


• u – [out] Solution vector at point

• ctx – [in] Context data


M_PI

3.3 Internal Functions

These functions are internal setup and application functions.

14

3.3.1 Internal Functions

forcingData forcing_options [3] = [FORCE_NONE] = .setup_forcing = NULL,.setup_forcing_loc = NULL,[FORCE_CONST] = .setup_forcing =SetupConstantForce,.setup_forcing_loc = SetupConstantForce_loc,[FORCE_MMS] = .setup_forcing =SetupMMSForce,.setup_forcing_loc = SetupMMSForce_loc

PetscErrorCode ProcessCommandLineOptions(MPI_Comm comm, AppCtx app_ctx)Process general command line options.

Parameters

• comm – [in] MPI communication object

• app_ctx – [out] Application context struct to hold data from command line options


PetscErrorCode ApplyLocalCeedOp(Vec X, Vec Y, UserMult user)Apply the local action of a libCEED operator and store result in PETSc vector i.e.

compute A X = Y

Parameters

• X – [in] Input PETSc vector

• Y – [out] Output PETSc vector

• UserMult – [in] User context struct containing libCEED operator data


PetscErrorCode FormResidual_Ceed(SNES snes, Vec X, Vec Y, void *ctx)Compute the non-linear residual for a SNES operator via libCEED.

Parameters

• snes – [in] Nonlinear solver



• ctx – [in] User context struct containing libCEED operator data


PetscErrorCode FormJacobian_Ceed(SNES snes, Vec U, Mat J, Mat J_pre, void *ctx)Assemble Jacobian for each level of multigrid hierarchy.

Parameters

• snes – [in] Non-linear solver

• U – [in] Current non-linear residual

• J – [out] Fine grid Jacobian operator

• J_pre – [out] Fine grid Jacobian operator for preconditioning

• ctx – [out] Jacobian context, holding Jacobian operators for each level of multigridhierarchy


PetscErrorCode ApplyJacobian_Ceed(Mat A, Vec X, Vec Y)Compute the action of the Jacobian for a SNES operator via libCEED.

Parameters


15




PetscErrorCode ApplyJacobianCoarse_Ceed(SNES snes, Vec X, Vec Y, void *ctx)Compute the action of the Jacobian for a coarse level SNES operator via libCEED.

Parameters




• ctx – [in] User context struct containing libCEED operator data


PetscErrorCode Prolong_Ceed(Mat A, Vec X, Vec Y)Compute action of a p-multigrid prolongation operator via libCEED.

Parameters

• A – [in] Prolongation operator MatShell

• X – [in] Input PETSc vector on coarse grid

• Y – [out] Output PETSc vector on fine grid


PetscErrorCode Restrict_Ceed(Mat A, Vec X, Vec Y)Compute action of a p-multigrid restriction operator via libCEED.

Parameters

• A – [in] Restriction operator MatShell

• X – [in] Input PETSc vector on fine grid

• Y – [out] Output PETSc vector on coarse grid


PetscErrorCode GetDiag_Ceed(Mat A, Vec D)Compute the diagonal of an operator via libCEED.

Parameters

• A – [in] Operator MatShell

• D – [out] Vector holding operator diagonal


PetscErrorCode SetupJacobianCtx(MPI_Comm comm, AppCtx app_ctx, DM dm, Vec V_loc, Ceed-Data ceed_data, Ceed ceed, CeedQFunctionContext ctx_phys,CeedQFunctionContext ctx_phys_smoother, UserMult jaco-bian_ctx)

Setup context data for Jacobian evaluation.

Parameters



16

• dm – [in] DM holding solution mesh

• V_loc – [in] Work vector for Jacobian

• ceed_data – [in] libCEED objects

• ceed – [in] libCEED context object

• ctx_phys – [in] Physics context for Jacobian application

• ctx_phys_smoother – [in] Physics context for multigrid smoother

• jacobian_ctx – [out] Context data for Jacobian evaluation


PetscErrorCode SetupProlongRestrictCtx(MPI_Comm comm, AppCtx app_ctx, DM dm_c, DMdm_f, Vec V_loc_c, Vec V_loc_f, CeedData ceed_data_c,CeedData ceed_data_f, Ceed ceed, UserMultProlon-gRestr prolong_restr_ctx)

Setup context data for multigrid prolongation and restriction operator evaluation.

Parameters



• dm_c – [in] DM for coarse grid

• dm_f – [in] DM for fine grid

• V_loc_c – [in] Work vector for coarse grid

• V_loc_f – [in] Work vector for fine grid

• ceed_data_c – [in] libCEED objects for coarse grid

• ceed_data_f – [in] libCEED objects for fine grid


• prolong_restr_ctx – [out] Context data for prolongation and restriction evalu-ation


PetscErrorCode ViewSolution(MPI_Comm comm, AppCtx app_ctx, Vec U, PetscInt increment, Petsc-Scalar load_increment)

Output solution for visualization.

Parameters



• U – [in] Current solution vector

• increment – [in] Load increment index

• load_increment – [in] Current load increment value


PetscErrorCode ViewDiagnosticQuantities(MPI_Comm comm, DM dmU, UserMult user,AppCtx app_ctx, Vec U, CeedElemRestrictionelem_restr_diagnostic)

Output solution for visualization.

17

Parameters


• dmU – [in] DM for solution mesh

• user – [in] User context for non-linear operator


• elem_restr_diagnostic – [in] Current load increment value


PetscErrorCode ComputeStrainEnergy(DM dmEnergy, UserMult user, CeedOperator op_energy,Vec X, PetscReal *energy)

Compute the strain energy in the final solution via libCEED.

Parameters

• dmEnergy – [in] DM holding mesh for computation of strain energy

• user – [in] User context holding libCEED data

• op_energy – [in] libCEED operator to compute strain energy

• X – [in] Final solution vector

• energy – [out] Computed strain energy


PetscErrorCode TestFinalStrainEnergy(AppCtx app_ctx, PetscReal energy)Verify solution final strain energy against expect_final_strain_energy against the relative error toler-ance of 10^-5.

Parameters


• energy – [in] Final strain energy


PetscErrorCode CreateBCLabel(DM dm, const char name[])Create boundary condition label.

Parameters

• dm – [out] DM to create new labeled boundary

• name – [in] Name for new label


PetscErrorCode CreateDistributedDM(MPI_Comm comm, AppCtx app_ctx, DM *dm)Read mesh and distribute DM in parallel.

Parameters



• dm – [out] New distributed DM


18

PetscErrorCode PetscFECreateByDegree(DM dm, PetscInt dim, PetscInt Nc, PetscBool isSimplex,const char prefix[], PetscInt order, PetscFE *fem)

Create FE by degree.

Parameters

• dm – [in] DM to create FE on

• dim – [in] Basis dimension

• Nc – [in] Number of components

• isSimplex – [in] Boolean flag for simplex basis

• prefix – [in] Command line options prefix

• order – [in] Polynomial order of basis

• fem – [out] New FE object


PetscErrorCode SetupDMByDegree(DM dm, AppCtx app_ctx, PetscInt order, PetscBool isDirichlet-Boundary, PetscInt num_comp_u)

Setup DM with FE space of appropriate degree.

Parameters

• dm – [out] DM to setup


• order – [in] Polynomial order of basis

• isDirichletBoundary – [in] Boolean flag for Dirichlet boundary

• num_comp_u – [out] Number of components in solution vector


PetscErrorCode CeedDataDestroy(CeedInt level, CeedData data)Destroy libCEED objects.

Parameters

• level – [in] Multigrid level

• data – [out] libCEED objects struct


PetscInt Involute(PetscInt i)Involute negative indices, essential BC DoFs are encoded in closure indices as -(i+1)

Parameters

• i – [in] DoF index

Returns involuted index value

PetscErrorCode CreateRestrictionFromPlex(Ceed ceed, DM dm, CeedInt P, CeedInt height, DM-Label domain_label, CeedInt value, CeedElemRe-striction *elem_restr)

Create local libCEED restriction from DMPlex.

Parameters


19

• dm – [in] DM holding mesh

• P – [in] Polynomial order of mesh basis

• height – [in] Height of DMPlex topology

• domain_label – [in] Label for DMPlex domain

• value – [in] Stratum value

• elem_restr – [out] libCEED element restriction


PetscErrorCode GetRestrictionForDomain(Ceed ceed, DM dm, CeedInt height, DMLabeldomain_label, PetscInt value, CeedInt P, Ceed-Int Q, CeedInt q_data_size, CeedElemRestriction*elem_restr_q, CeedElemRestriction *elem_restr_x,CeedElemRestriction *elem_restr_qd_i)

Create local libCEED restriction from DMPlex domain.

Parameters


• dm – [in] DM holding mesh

• height – [in] Height of DMPlex topology

• domain_label – [in] Label for DMPlex domain

• value – [in] Stratum value

• P – [in] Polynomial order of mesh basis

• Q – [in] Number of quadrature points

• q_data_size – [in] Size of stored quadrature point data

• elem_restr_q – [out] libCEED element restriction for solution

• elem_restr_x – [out] libCEED element restriction for mesh

• elem_restr_qd_i – [out] libCEED element restriction for quadrature point data


PetscErrorCode SetupLibceedFineLevel(DM dm, DM dm_energy, DM dm_diagnostic, Ceedceed, AppCtx app_ctx, CeedQFunctionContext phys_ctx,MaterialData material_data, PetscInt fine_level, PetscIntnum_comp_u, PetscInt U_g_size, PetscInt U_loc_size,CeedVector force_ceed, CeedVector neumann_ceed, Ceed-Data *data)

Setup libCEED operators for fine grid non-linear operator and Jacobian.

Parameters


• dm_energy – [in] DM for computing final strain energy

• dm_diagnostic – [in] DM for computing diagnostic data



• phys_ctx – [in] Physical parameter context for matriel model

20


• fine_level – [in] Index of fine level in multigrid hierarchy




• force_ceed – [out] libCEED vector for forcing term

• neumann_ceed – [out] libCEED vector for Neumann boundary conditions

• data – [out] libCEED objects for fine grid


PetscErrorCode SetupLibceedLevel(DM dm, Ceed ceed, AppCtx app_ctx, MaterialData ma-terial_data, PetscInt level, PetscInt num_comp_u, PetscIntU_g_size, PetscInt U_loc_size, CeedVector fine_mult, Ceed-Data *data)

Setup libCEED operators for multigrid prolongation, restriction, and coarse grid Jacobian evaluation.

Parameters





• level – [in] Index of level in multigrid hierarchy




• fine_mult – [in] libCEED vector for fine grid multiplicity

• data – [out] libCEED objects for prolongation, restriction, and coarse grid


4 Developer Notes

4.1 Style Guide

Please check your code for style issues by running

make style

In addition to those automatically enforced style rules, Ratel tends to follow the following code style con-ventions:

• Variable names: snake_case

• Strut members: snake_case

• Function names: PascalCase

• Type names: PascalCase

21

• Constant names: CAPS_SNAKE_CASE

Also, documentation files should have one sentence per line to help make git diffs clearer and less disruptive.

4.2 Clang-tidy

Please check your code for common issues by running

make tidy

which uses the clang-tidy utility included in recent releases of Clang. This tool is much slower thanactual compilation (make -j parallelism helps). All issues reported by make tidy should be fixed.

4.3 Header Files

Header inclusion for source files should follow the principal of ‘include what you use’ rather than relyingupon transitive #include to define all symbols.

Every symbol that is used in the source file foo.c should be defined in foo.c, foo.h, or ina header file #include``d in one of these two locations. Please check your code byrunning the tool ``include-what-you-use to see recommendations for changes to your source.Most issues reported by include-what-you-use should be fixed; however this rule is flexible to accountfor differences in header file organization in external libraries.

Header files should be listed in alphabetical order, with installed headers preceding local headers.

#include <ceed.h>#include <petsc.h>#include <stdbool.h>#include <string.h>#include "include/ratel.h"

4.4 restrict semantics

QFunction arguments can be assumed to have restrict semantics. That is, each input and output arraymust reside in distinct memory without overlap.

5 Ratel: How to Contribute

Contributions to Ratel are encouraged.

Please make your commits well-organized and atomic, using git rebase --interactive as needed.Check that tests pass using make prove-all. If adding a new feature, please add or extend a test so thatyour new feature is tested.

In typical development, every commit should compile, be covered by the test suite, and pass all tests. Thisimproves the efficiency of reviewing and facilitates use of git bisect.

Open an issue or RFC (request for comments) pull request to discuss any significant changes before investingtime. It is useful to create a WIP (work in progress) pull request for any long-running development so thatothers can be aware of your work and help to avoid creating merge conflicts.

22

https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention

https://git-scm.com/docs/git-bisect

Write commit messages for a reviewer of your pull request and for a future developer (maybe you) thatbisects and finds that a bug was introduced in your commit. The assumptions that are clear in your mindwhile committing are likely not in the mind of whomever (possibly you) needs to understand it in the future.

Give credit where credit is due using tags such as Reported-by: Helpful User<[email protected]> or Co-authored-by: Snippet Mentor <[email protected]>.Please use a real name and email for your author information (git config user.name and user.email). If your author information or email becomes inconsistent (look at git shortlog -se), pleaseedit .mailmap to obtain your preferred name and email address.

When contributors make a major contribution and support it, their names are included in the automaticallygenerated user-manual documentation.

Please avoid “merging from upstream” (like merging ‘main’ into your feature branch) unless there is a spe-cific reason to do so, in which case you should explain why in the merge commit. Rationale from Junio andLinus.

You can use make style to help conform to coding conventions of the project, but try to avoid mixingwhitespace or formatting changes with content changes (see atomicity above).

By submitting a pull request, you are affirming the following.

5.1 Developer’s Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the opensource license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under anappropriate open source license and I have the right under that license to submit that work with modifica-tions, whether created in whole or in part by me, under the same open source license (unless I am permittedto submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I havenot modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribu-tion (including all personal information I submit with it, including my sign-off) is maintained indefinitelyand may be redistributed consistent with this project or the open source license(s) involved.

5.2 Authorship

Ratel contains components authored by many individuals. It is important that contributors receive ap-propriate recognition through informal and academically-recognized credit systems such as publications.Status as a named author on the users manual and Ratel software publications will be granted for those who

1. make significant contributions to Ratel (in implementation, documentation, conceptualization, review,etc.) and

2. maintain and support those contributions.

Maintainers will do their best to notice when contributions reach this level and add your name to AUTHORS,but please email or create an issue if you believe your contributions have met these criteria and haven’t yetbeen acknowledged.

Authors of publications about Ratel as a whole, including DOI-bearing archives, shall offer co-authorshipto all individuals listed in the AUTHORS file. Authors of publications claiming specific Ratel contributions

23

https://help.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors#creating-co-authored-commits-on-the-command-line

https://lwn.net/Articles/328436/

https://gitster.livejournal.com/42247.html

http://yarchive.net/comp/linux/git_merges_from_upstream.html

shall evaluate those listed in AUTHORS and offer co-authorship to those who made significant intellectualcontributions to the work.

Note that there is no co-authorship expectation for those publishing about use of Ratel (versus creationof new features in Ratel), but see the citing section and use your judgment regarding significance of sup-port/advice you may have received in developing your use case and interpreting results.

6 Ratel Code of Conduct

6.1 Our Pledge

We as members, contributors, and leaders pledge to make participation in our community a harassment-freeexperience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex character-istics, gender identity and expression, level of experience, education, socio-economic status, nationality,personal appearance, race, religion, or sexual identity and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthycommunity.

6.2 Our Standards

Examples of behavior that contributes to a positive environment for our community include:

• Demonstrating empathy and kindness toward other people

• Being respectful of differing opinions, viewpoints, and experiences

• Giving and gracefully accepting constructive feedback

• Accepting responsibility and apologizing to those affected by our mistakes, and learning from theexperience

• Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behavior include:

• The use of sexualized language or imagery, and sexual attention or advances of any kind

• Trolling, insulting or derogatory comments, and personal or political attacks

• Public or private harassment

• Publishing others’ private information, such as a physical or email address, without their explicit per-mission

• Other conduct which could reasonably be considered inappropriate in a professional setting

24

https://libceed.readthedocs.io/en/latest/gettingstarted/#how-to-cite

6.3 Enforcement Responsibilities

Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior andwill take appropriate and fair corrective action in response to any behavior that they deem inappropriate,threatening, offensive, or harmful.

Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code,wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communi-cate reasons for moderation decisions when appropriate.

6.4 Scope

This Code of Conduct applies within all community spaces, and also applies when an individual is officiallyrepresenting the community in public spaces. Examples of representing our community include using anofficial e-mail address, posting via an official social media account, or acting as an appointed representativeat an online or offline event.

6.5 Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the communityleaders responsible for enforcement at [email protected] or jeremy.jeremylt.org. All complaints will be re-viewed and investigated promptly and fairly.

All community leaders are obligated to respect the privacy and security of the reporter of any incident.

6.6 Enforcement Guidelines

Community leaders will follow these Community Impact Guidelines in determining the consequences forany action they deem in violation of this Code of Conduct:

6.6.1 1. Correction

Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwel-come in the community.

Consequence: A private, written warning from community leaders, providing clarity around the natureof the violation and an explanation of why the behavior was inappropriate. A public apology may be re-quested.

6.6.2 2. Warning

Community Impact: A violation through a single incident or series of actions.

Consequence: A warning with consequences for continued behavior. No interaction with the people in-volved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified periodof time. This includes avoiding interactions in community spaces as well as external channels like socialmedia. Violating these terms may lead to a temporary or permanent ban.

25

mailto:[email protected]

http://jeremy.jeremylt.org

6.6.3 3. Temporary Ban

Community Impact: A serious violation of community standards, including sustained inappropriate be-havior.

Consequence: A temporary ban from any sort of interaction or public communication with the communityfor a specified period of time. No public or private interaction with the people involved, including unso-licited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating theseterms may lead to a permanent ban.

6.6.4 4. Permanent Ban

Community Impact: Demonstrating a pattern of violation of community standards, including sustainedinappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes ofindividuals.

Consequence: A permanent ban from any sort of public interaction within the community.

6.7 Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.

Community Impact Guidelines were inspired by Mozilla’s code of conduct enforcement ladder.

For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.

7 Indices and tables

• genindex

• search

References

[DPA+20] Denis Davydov, Jean-Paul Pelteret, Daniel Arndt, Martin Kronbichler, and Paul Stein-mann. A matrix-free approach for finite-strain hyperelastic problems using geometric multi-grid. International Journal for Numerical Methods in Engineering, 121(13):2874–2895, 2020.doi:10.1002/nme.6336.

[Hol00] Gerhard Holzapfel. Nonlinear solid mechanics: a continuum approach for engineering. Wiley, Chich-ester New York, 2000. ISBN 978-0-471-82319-3.

26

https://www.contributor-covenant.org

https://www.contributor-covenant.org/version/2/0/code_of_conduct.html

https://www.contributor-covenant.org/version/2/0/code_of_conduct.html

https://github.com/mozilla/diversity

https://www.contributor-covenant.org/faq

https://www.contributor-covenant.org/faq

https://www.contributor-covenant.org/translations

https://www.contributor-covenant.org/translations

https://doi.org/10.1002/nme.6336

IndexAApplyJacobian_Ceed (C function), 15ApplyJacobianCoarse_Ceed (C function), 16ApplyLocalCeedOp (C function), 15

BBCClamp (C function), 14BCMMS (C function), 14

CCeedDataDestroy (C function), 19ComputeStrainEnergy (C function), 18CreateBCLabel (C function), 18CreateDistributedDM (C function), 18CreateRestrictionFromPlex (C function), 19

Ffield_names (C var), 12field_sizes (C var), 12finite_strain_Mooney_Rivlin_initial (C

var), 12FormJacobian_Ceed (C function), 15FormResidual_Ceed (C function), 15

GGetDiag_Ceed (C function), 16GetRestrictionForDomain (C function), 20

IInvolute (C function), 19

MM_PI (C macro), 14

PPetscFECreateByDegree (C function), 18ProcessCommandLineOptions (C function), 15Prolong_Ceed (C function), 16

RRestrict_Ceed (C function), 16

SSetupDMByDegree (C function), 19SetupJacobianCtx (C function), 16SetupLibceedFineLevel (C function), 20SetupLibceedFineLevel_ElasFSInitialMR

(C function), 12

SetupLibceedLevel (C function), 21SetupLibceedLevel_ElasFSInitialMR (C

function), 13SetupProlongRestrictCtx (C function), 17

TTestFinalStrainEnergy (C function), 18

VViewDiagnosticQuantities (C function), 17ViewSolution (C function), 17

27

ratel user manual

Documents