Example codes
and tutorials
The (Not-so) Quick Guide
List of tutorials/demo codes
Single-Physics Problems
Poisson
Adaptivity illustrated for Poisson
Advection-Diffusion
Unsteady heat equation
Linear wave equation
The Young-Laplace equation
Navier-Stokes
Free-surface Navier-Stokes
Axisymmetric Navier-Stokes
Solid mechanics
Beam structures
Shell structures
Multi-physics Problems
Fluid-structure interaction
Boussinesq convection
Steady thermoelasticity
Methods-based example codes and tutorials
Mesh generation
Linear solvers and preconditioners
Visualisation of the results
Parallel processing
How to write a new element
How to write a new refineable element
Default nonlinear solvers -- the sequence of action functions
...
Documentation
FE theory and top-down discussion of the data structure
The (Not-so) Quick Guide
Comprehensive bottom-up discussion of the data structure
List of available structured and unstructured meshes
Linear solvers and preconditioners
Visualisation of the results
Parallel processing
Coding conventions and C++ style
Creating documentation
Optimisation - robustness vs. "raw speed"
Linear vs. nonlinear problems
Storing shape functions
Changing the default "full" integration scheme
Disabling the ALE formulation of unsteady equations
C vs. C++ output
Different sparse assembly techniques and the STL memory pool
Publications
Publications
Talks
Journal publications
Theses
Picture show
Download
Copyright
Download/installation instructions
Download page
FAQ & Contact
FAQ
Change log
Bugs and other known problems
Completeness of the library & our "To-Do List"
Contact the developers
Get involved

 


Beta release!

Please note that the library has not been "officially" released. While we continue to work on the documentation, these web pages are likely to contain broken links and documents in draft form. Please send an email to

oomph-lib AT maths DOT man DOT ac DOT uk

if you wish to be informed of the library's "official" release.

Class List

Here are the classes, structs, unions and interfaces with brief descriptions:
oomph::AbsCmp< T >
oomph::AdvectionDiffusionEquations< DIM >A class for all elements that solve the Advection Diffusion equations using isoparametric elements.

\[ /// \frac{\partial^2 u}{\partial x_i^2} = /// Pe w_i(x_k) \frac{\partial u}{\partial x_i} + f(x_j) /// \]

This contains the generic maths. Shape functions, geometric mapping etc. must get implemented in derived class

oomph::AdvectionDiffusionFluxElement< ELEMENT >A class for elements that allow the imposition of an applied flux on the boundaries of Advection Diffusion elements. The element geometry is obtained from the FaceGeometry<ELEMENT> policy class
oomph::AdvectionDiffusionReactionEquations< NREAGENT, DIM >A class for all elements that solve the Advection Diffusion Reaction equations using isoparametric elements.

\[ /// \tau_{i} \frac{\partial C_{i}}{\partial t} /// + w_{j} \frac{\partial C_{i}}{\partial x_{j}} = /// D_{i}\frac{\partial^2 C_{i}}{\partial x_j^2} = /// - R_{i}(C_{i}) + f_{i} /// \]

This contains the generic maths. Shape functions, geometric mapping etc. must get implemented in derived class

oomph::AlgebraicChannelWithLeafletMesh< ELEMENT >
oomph::AlgebraicCollapsibleChannelMesh< ELEMENT >Collapsible channel mesh with algebraic node update
oomph::AlgebraicCylinderWithFlagMesh< ELEMENT >Algebraic version of CylinderWithFlagMesh
oomph::AlgebraicElement< ELEMENT >
oomph::AlgebraicElementBase
oomph::AlgebraicFishMesh< ELEMENT >Fish shaped mesh with algebraic node update function for nodes
oomph::AlgebraicFSIDrivenCavityMesh< ELEMENT >
oomph::AlgebraicMesh
oomph::AlgebraicNode
oomph::AlgebraicRefineableFishMesh< ELEMENT >Refineable fish shaped mesh with algebraic node update function
oomph::AlgebraicRefineableQuarterCircleSectorMesh< ELEMENT >
oomph::AlgebraicRefineableQuarterTubeMesh< ELEMENT >AlgebraicMesh version of RefineableQuarterTubeMesh Algebraic 3D quarter tube mesh class.
The mesh boundaries are numbered as follows:
  • Boundary 0: "Inflow" cross section; located along the line parametrised by $ \xi_0 = \xi_0^{lo} $ on the geometric object that specifies the wall.
  • Boundary 1: Plane x=0
  • Boundary 2: Plane y=0
  • Boundary 3: The curved wall - specified by the GeomObject passed to the mesh constructor.
  • Boundary 4: "Outflow" cross section; located along the line parametrised by $ \xi_0 = \xi_0^{hi} $ on the geometric object that specifies the wall
oomph::ARPACKClass for the ARPACK eigensolver
oomph::AssemblyHandler
oomph::AugmentedBlockFoldLinearSolver
oomph::AugmentedBlockPitchForkLinearSolver
oomph::Axisym2x6TwoLayerSpineMesh< ELEMENT, INTERFACE_ELEMENT >Axisymmetric-Two-layer spine mesh class derived from standard Two-Layer spine mesh. This creates a finer mesh around boundaries 0, 1 and 2 (bottom, right and top) and also around the interface. This mesh was designed for use with the spin-up and spin-over problems in an axisymmetric domain. Using the same spacing fractions in the both the upper and lower fluids
oomph::Axisym3x6TwoLayerSpineMesh< ELEMENT, INTERFACE_ELEMENT >Axisymmetric-Two-layer spine mesh class derived from standard Two-Layer spine mesh. This creates a finer mesh around boundaries 0, 1, 2 and 3 and also around the interface. This mesh was designed for use with the spin-up and spin-over problems in an axisymmetric domain. Using the same spacing fractions in the both the upper and lower fluids
oomph::Axisym3x8TwoLayerSpineMesh< ELEMENT, INTERFACE_ELEMENT >
oomph::AxisymDiagHermitePVDElement
oomph::AxisymmetricFluidInterfaceElement
oomph::AxisymmetricNavierStokesEquations
oomph::AxisymmetricPVDEquations
oomph::AxisymmetricPVDEquationsWithPressure
oomph::AxisymmetricQCrouzeixRaviartElement
oomph::AxisymmetricQTaylorHoodElement
oomph::AxisymmetricSolidTractionElement< ELEMENT >
oomph::AxisymQPVDElement
oomph::AxisymQPVDElementWithPressure
oomph::TriangleBoundaryHelper::BCInfoStructure for Boundary Informations
oomph::BDF< NSTEPS >Templated class for BDF-type time-steppers with fixed or variable timestep. 1st time derivative recovered directly from the previous function values. Template parameter represents the number of previous timesteps stored, so that BDF<1> is the classical first order backward Euler scheme. Need to reset weights after every change in timestep
oomph::BiCGStab< MATRIX >The conjugate gradient method
oomph::BlockDiagonalPreconditioner< MATRIX >Block diagonal preconditioner. By default SuperLU is used to solve the subsidiary systems, but other preconditioners can be used by setting them using passing a pointer to a function of type SubsidiaryPreconditionerFctPt to the method subsidiary_preconditioner_function_pt()
oomph::BlockHopfLinearSolver
oomph::BlockPitchForkLinearSolver
oomph::BlockPreconditioner< MATRIX >
oomph::BlockTriangularPreconditioner< MATRIX >General purpose block triangular preconditioner
By default this is Upper triangular.
By default SuperLUPreconditioner (or SuperLUDistPreconditioner) is used to solve the subsidiary systems, but other preconditioners can be used by setting them using passing a pointer to a function of type SubsidiaryPreconditionerFctPt to the method subsidiary_preconditioner_function_pt()
oomph::BoundaryNode< NODE_TYPE >A template Class for BoundaryNodes; that is Nodes that MAY live on the boundary of a Mesh. The class is formed by a simple composition of the template parameter NODE_TYPE, which must be a Node class and the BoundaryNodeBase class. Final overloading of functions is always in favour of the BoundaryNodeBase implementation; i.e. these nodes can live on boundaries
oomph::BoundaryNodeBaseA class that contains the information required by Nodes that are located on Mesh boundaries. A BoundaryNode of a particular type is obtained by combining a given Node with this class. By differentiating between Nodes and BoundaryNodes we avoid a lot of un-necessary storage in the bulk Nodes
oomph::BrethertonSpineMesh< ELEMENT, INTERFACE_ELEMENT >
oomph::BrickElementBaseBase class for all brick elements
oomph::BrickMeshBaseBase class for brick meshes (meshes made of 3D brick elements)
oomph::CCComplexMatrixA class for compressed column matrices that store doubles
oomph::CCDoubleMatrixA class for compressed column matrices that store doubles
oomph::CCMatrix< T >A class for compressed column matrices: a sparse matrix format The class is passed as the MATRIX_TYPE paramater so that the base class can use the specific access functions in the round-bracket operator
oomph::CG< MATRIX >The conjugate gradient method
oomph::ChannelSpineMesh< ELEMENT >
oomph::ChannelWithLeafletDomain
oomph::ChannelWithLeafletMesh< ELEMENT >Channel with leaflet mesh
oomph::CircleCircle in 2D space.

\[ x = X_c + R \cos(\zeta) \]

\[ y = Y_c + R \sin(\zeta) \]

oomph::CircularCylindricalShellMesh< ELEMENT >
oomph::ClampedHermiteShellBoundaryConditionElement
oomph::ClampedSlidingHermiteBeamBoundaryConditionElement
oomph::CollapsibleChannelDomainCollapsible channel domain
oomph::CollapsibleChannelMesh< ELEMENT >Basic collapsible channel mesh. The mesh is derived from the SimpleRectangularQuadMesh so it's node and element numbering scheme is the same as in that mesh. Only the boundaries are numbered differently to allow the easy identification of the "collapsible" segment. Boundary coordinates are set up for all nodes located on boundary 3 (the collapsible segment). The curvilinear ("collapsible") segment is defined by a GeomObject
oomph::FSI_functions::CompareBoundaryCoordinate< ELEMENT >A class to do comparison of the elements by lexicographic ordering, based on the boundary coordinates at the element's first node
oomph::ComplexMatrixBaseAbstract base class for matrices of complex doubles -- adds abstract interfaces for solving, LU decomposition and multiplication by vectors
oomph::CompressedMatrixCoefficientClass for a compressed-matrix coefficent (for either CC or CR matrices). Contains the (row or column) index and value of a coefficient in a compressed row or column. Currently only used in ILU(0) for CCDoubleMatrices to allow the coefficients in each compressed column [row] to be sorted by their row [column] index
oomph::ConstitutiveLaw
oomph::CopiedDataCustom Data class that is used when making a shallow copy of a data object. The class contains a copy of an entire other Data object
oomph::CRComplexMatrixA class for compressed row matrices
oomph::CRDoubleMatrixA class for compressed row matrices. This is a distributable object
oomph::CRMatrix< T >A class for compressed row matrices, a sparse storage format Once again the recursive template trick is used to inform that base class that is should use the access functions provided in the CRMatrix class
oomph::CylinderWithFlagDomainDomain for cylinder with flag as in Turek benchmark
oomph::CylinderWithFlagMesh< ELEMENT >
oomph::DampedOscillatoryFittingFunctionObject
oomph::DataA class that represents a collection of data; each Data object may contain many different individual values, as would be natural in non-scalar problems. Data provides storage for auxiliary `history' values that are used by TimeStepper objects to calculate the time derivatives of the stored data and also stores a pointer to the appropriate TimeStepper object. In addition, an associated (global) equation number is stored for each value
oomph::DenseComplexMatrixClass of matrices containing double complex, and stored as a DenseMatrix<complex<double> >, but with solving functionality inherited from the abstract ComplexMatrix class
oomph::DenseDoubleMatrixClass of matrices containing doubles, and stored as a DenseMatrix<double>, but with solving functionality inherited from the abstract DoubleMatrix class
oomph::DenseLUDense LU decomposition-based solve of full assembled linear system. VERY inefficient but useful to illustrate the principle.
Only suitable for use with Serial matrices and vectors.
This solver will only work with non-distributed matrices and vectors (note: DenseDoubleMatrix is not distributable)
oomph::DenseMatrix< T >Class for dense matrices, storing all the values of the matrix as a pointer to a pointer with assorted output functions inherited from Matrix<T>. The curious recursive template pattern is used here to pass the specific class to the base class so that round bracket access can be inlined
oomph::DGElementA Base class for DGElements
oomph::DGFaceElementBase class for Discontinuous Galerkin Faces. These are responsible for calculating the normal fluxes that provide the communication between the discontinuous elements
oomph::DGMesh
oomph::DiagHermiteShellElement
oomph::DiagQHermiteElement< DIM >
oomph::DisplacementControlElementDisplacement control element: In the "normal" formulation of solid mechanics problems, the external load is given and the displacement throughout the solid body is computed. For highly nonlinear problems it is sometimes helpful to re-formulate the problem by prescribing the position of a selected control point and treating the (scalar) load level required to achieve this deformation as an unknown.

As an example consider the buckling of pressure-loaded, thin-walled elastic shells. The load-displacement characteristics of such structures tend to be highly nonlinear and bifurcations from the structure's pre-buckling state often occur via sub-critical bifurcations. If we have some a-priori knowledge of the expected deformation (for example, during the non-axisymmetric buckling of a circular cylindrical shell certain material points will be displaced radially inwards), it is advantageous to prescribe the radial displacement of a carefully selected control point and treat the external pressure as an unknown.

DisplacementControlElements facilitate the use of such methods. They require the specification of
  • the control point at which the displacement is prescribed. This is done by specifying:
  • the coordinate direction. controlled_direction. in which the displacement is controlled.
  • a pointer to a double, control_position_value_pt, that specifies the desired value of the prescribed coordinate after the deformation (i.e. if controlled_direction=1 then *control_position_value_pt specifies the $ x_1 $ coordinate of the control point in the deformed configuration.)
The DisplacementControlElement has two constructors:
  • In the first version, we pass the pointer to the Data object whose one-and-only value contains the scalar load level that is "traded" for the displacement constraint. This is appropriate if the load Data has already been created (and is included in the overall equation numbering procedure) by some other element. In that case the DisplacementControlElement treats the (already existing) Data object external Data.
  • In the second version, a Data object (with a single value) is created by the constructor of the DisplacementControlElement and stored in its internal Data. Once the DisplacementControlElement has been included in one of the Problem's meshes, it is therefore automatically included in the equation numbering procedure. The (pointer to) the newly created Data is accessible via the access function displacement_control_load_pt(). It can be used to make make the unknown load level accessible to the load function that drives the deformation.
Note: The element inherits from the BlockPreconditionableElementBase and can be used in the block-preconditioning context. The element is "in charge" of the control load (if it's been created internally) and classifies it as its one-and-only "block type"
oomph::DistributableLinearAlgebraObjectBase class for any linear algebra object that is distributable. Just contains storage for the LinearAlgebraDistribution object and access functions
oomph::DocInfoInformation for documentation of results: Directory and file number to enable output in the form RESLT/filename11.dat, say. Documentation can be switched on and off
oomph::DomainBase class for Domains with curvilinear and/or time-dependent boundaries. Domain boundaries are typically represented by GeomObject s and the Domain itself is decomposed into a number of MacroElement s as shown in this 2D example:
oomph::DoubleMatrixBaseAbstract base class for matrices of doubles -- adds abstract interfaces for solving, LU decomposition and multiplication by vectors
oomph::DoubleVectorA vector in the mathematical sense, initially developed for linear algebra type applications.
If MPI then this vector can be distributed - its distribution is described by the LinearAlgebraDistribution object at Distribution_pt.
Data is stored in a C-style pointer vector (double*)
oomph::DShape
oomph::DummyAlgebraicMeshDummy algebraic mesh -- used for default assignements
oomph::DummyFaceElement< ELEMENT >
oomph::DummyMeshDummy mesh that can be created and deleted in SolidICProblem
oomph::TriangleBoundaryHelper::EdgeEdge class
oomph::EigenProblemHandler
oomph::EigenSolver
oomph::EighthSphereDomainEighth sphere as domain. Domain is parametrised by four macro elements
oomph::EighthSphereMesh< ELEMENT >
oomph::ElasticAxisymmetricFluidInterfaceElement< ELEMENT >
oomph::ElasticityTensor
oomph::ElasticLineFluidInterfaceEdgeElement< ELEMENT >Elastic free surface stuff
oomph::ElasticLineFluidInterfaceElement< ELEMENT >
oomph::ElasticPointFluidInterfaceEdgeElement< ELEMENT >Elastic free surface stuff
oomph::ElasticRectangularQuadMesh< ELEMENT >
oomph::ElasticRefineableRectangularQuadMesh< ELEMENT >
oomph::ElasticSurfaceFluidInterfaceElement< ELEMENT >
ELEMENT
oomph::ElementWithExternalElement
oomph::ElementWithMovingNodesA policy class that serves to establish the common interfaces for elements that contain moving nodes. This class provides storage for the geometric data that affect the update of all the nodes of the element, i.e. USUALLY all data that are using during a call to the Element's node_update() function. In some cases (e.g. FluidInterfaceEdge elements), node_update() is overloaded to perform an update of the bulk element, in which case the additional bulk geometric data become external data of the element and the function GeneralisedElement::update_in_external_fd(i) is overloaded to also perform the bulk node update. The storage is populated during the assignment of the equation numbers via the complete_setup_of_dependencies() function and then local equations numbers are assigned to these data, accessible via geometric_data_local_eqn(n,i). Finally, a function is provided that calculates the terms in the jacobian matrix by due to these geometric data by finite differences
oomph::ElementWithSpecificMovingNodes< ELEMENT, NODE_TYPE >
oomph::ElementWithZ2ErrorEstimatorBase class for finite elements that can compute the quantities that are required for the Z2 error estimator
oomph::EllipseSteady ellipse with half axes A and B as geometric object:

\[ x = A \cos(\zeta) \]

\[ y = B \sin(\zeta) \]

oomph::EllipticalTubeElliptical tube with half axes a and b
oomph::ErrorEstimatorBase class for spatial error estimators
oomph::Euler
oomph::ExactBlockPreconditioner< MATRIX >
oomph::ExplicitTimeStepHandler
oomph::ExplicitTimeSteppableObject
oomph::ExplicitTimeStepperA Base class for explicit timesteppers
oomph::FaceElement
oomph::FaceElementAsGeomObject< ELEMENT >
oomph::FaceGeometry< ELEMENT >
oomph::FaceGeometry< AlgebraicElement< ELEMENT > >Explicit definition of the face geometry of algebraic elements: the same as the face geometry of the underlying element
oomph::FaceGeometry< AxisymDiagHermitePVDElement >Explicit definition of the face geometry for the
oomph::FaceGeometry< AxisymmetricQCrouzeixRaviartElement >Face geometry of the Axisymmetric Crouzeix_Raviart elements
oomph::FaceGeometry< AxisymmetricQTaylorHoodElement >Face geometry of the Axisymmetric Taylor_Hood elements
oomph::FaceGeometry< AxisymQPVDElement >
oomph::FaceGeometry< AxisymQPVDElementWithPressure >
oomph::FaceGeometry< FaceGeometry< AxisymmetricQCrouzeixRaviartElement > >Face geometry of face geometry of the Axisymmetric Crouzeix_Raviart elements
oomph::FaceGeometry< FaceGeometry< AxisymmetricQTaylorHoodElement > >Face geometry of the face geometry of the Axisymmetric Taylor_Hood elements
oomph::FaceGeometry< FaceGeometry< Hijacked< ELEMENT > > >Explicit definition of the face geometry of hijacked elements: the same as the face geometry of the underlying element
oomph::FaceGeometry< FaceGeometry< PseudoSolidNodeUpdateElement< BASIC, SOLID > > >Explicit definition of the face geometry of these elements
oomph::FaceGeometry< FaceGeometry< QCrouzeixRaviartElement< 2 > > >Face geometry of the FaceGeometry of the 2D Crouzeix_Raviart elements
oomph::FaceGeometry< FaceGeometry< QCrouzeixRaviartElement< 3 > > >Face geometry of the FaceGeometry of the 3D Crouzeix_Raviart elements
oomph::FaceGeometry< FaceGeometry< QPVDElement< 2, NNODE_1D > > >FaceGeometry of the FaceGeometry of the 2D QPVDElement
oomph::FaceGeometry< FaceGeometry< QPVDElement< 3, NNODE_1D > > >FaceGeometry of FaceGeometry of a 3D QPVDElement element
oomph::FaceGeometry< FaceGeometry< QPVDElementWithContinuousPressure< 2 > > >
oomph::FaceGeometry< FaceGeometry< QPVDElementWithPressure< 2 > > >FaceGeometry of FaceGeometry of 2D QPVDElementWithPressure
oomph::FaceGeometry< FaceGeometry< QTaylorHoodElement< 2 > > >Face geometry of the FaceGeometry of the 2D Taylor Hoodelements
oomph::FaceGeometry< FaceGeometry< QTaylorHoodElement< 3 > > >Face geometry of the FaceGeometry of the 3D Taylor_Hood elements
oomph::FaceGeometry< FaceGeometry< RefineableAxisymmetricQCrouzeixRaviartElement > >Face geometry of the RefineableQuadQCrouzeixRaviartElements
oomph::FaceGeometry< FaceGeometry< RefineableAxisymmetricQTaylorHoodElement > >Face geometry of the RefineableQuadQTaylorHoodElements
oomph::FaceGeometry< FaceGeometry< RefineablePseudoSolidNodeUpdateElement< BASIC, SOLID > > >Explicit definition of the face geometry of these elements
oomph::FaceGeometry< FaceGeometry< RefineableQCrouzeixRaviartElement< DIM > > >Face geometry of the face geometry of the RefineableQCrouzeixRaviartElements is the same as the Face geometry of the Face geometry of QCrouzeixRaviartElements
oomph::FaceGeometry< FaceGeometry< RefineableQLinearElasticityElement< 2, NNODE_1D > > >FaceGeometry of the FaceGeometry of the 2D RefineableQLinearElasticityElement
oomph::FaceGeometry< FaceGeometry< RefineableQLinearElasticityElement< 3, NNODE_1D > > >FaceGeometry of the FaceGeometry of the 3D RefineableQLinearElasticityElement
oomph::FaceGeometry< FaceGeometry< RefineableQPVDElement< 2, NNODE_1D > > >FaceGeometry of the FaceGeometry of the 2D RefineableQPVDElement
oomph::FaceGeometry< FaceGeometry< RefineableQPVDElement< 3, NNODE_1D > > >FaceGeometry of the FaceGeometry of the 3D RefineableQPVDElement
oomph::FaceGeometry< FaceGeometry< RefineableQPVDElementWithContinuousPressure< 2 > > >
oomph::FaceGeometry< FaceGeometry< RefineableQPVDElementWithContinuousPressure< 3 > > >
oomph::FaceGeometry< FaceGeometry< RefineableQPVDElementWithPressure< 2 > > >FaceGeometry of the FaceGeometry of the 2D RefineableQPVDElementWithPressure
oomph::FaceGeometry< FaceGeometry< RefineableQPVDElementWithPressure< 3 > > >FaceGeometry of the FaceGeometry of the 3D RefineableQPVDElementWithPressure
oomph::FaceGeometry< FaceGeometry< RefineableQTaylorHoodElement< DIM > > >Face geometry of the face geometry of the RefineableQTaylorHoodElements is the same as the Face geometry of the Face geometry of QTaylorHoodElements
oomph::FaceGeometry< FaceGeometry< SpineElement< ELEMENT > > >Explicit definition of the face geometry for spine elements: The same as the face geometry of the underlying element
oomph::FaceGeometry< FaceGeometry< TPVDElement< 2, NNODE_1D > > >FaceGeometry of the FaceGeometry of the 2D TPVDElement
oomph::FaceGeometry< FaceGeometry< TPVDElement< 3, NNODE_1D > > >FaceGeometry of FaceGeometry of a 3D TPVDElement element
oomph::FaceGeometry< HermiteBeamElement >Face geometry for the HermiteBeam elements: Solid point element
oomph::FaceGeometry< HermiteShellElement >Face geometry for the HermiteShell elements: 1D SolidQHermiteElement
oomph::FaceGeometry< Hijacked< ELEMENT > >Explicit definition of the face geometry of hijacked elements: the same as the face geometry of the underlying element
oomph::FaceGeometry< Hijacked< FaceGeometry< ELEMENT > > >Explicit definition of the face geometry of hijacked elements: the same as the face geometry of the underlying element
oomph::FaceGeometry< MacroElementNodeUpdateElement< ELEMENT > >
oomph::FaceGeometry< PseudoSolidNodeUpdateElement< BASIC, SOLID > >Explicit definition of the face geometry of these elements
oomph::FaceGeometry< QAdvectionDiffusionElement< 1, NNODE_1D > >Face geometry for the 1D QAdvectionDiffusion elements: Point elements
oomph::FaceGeometry< QAdvectionDiffusionElement< DIM, NNODE_1D > >Face geometry for the QAdvectionDiffusionElement elements: The spatial dimension of the face elements is one lower than that of the bulk element but they have the same number of points along their 1D edges
oomph::FaceGeometry< QAdvectionDiffusionReactionElement< NREAGENT, 1, NNODE_1D > >Face geometry for the 1D QAdvectionDiffusionReaction elements: Point elements
oomph::FaceGeometry< QAdvectionDiffusionReactionElement< NREAGENT, DIM, NNODE_1D > >Face geometry for the QAdvectionDiffusionReactionElement elements: The spatial dimension of the face elements is one lower than that of the bulk element but they have the same number of points along their 1D edges
oomph::FaceGeometry< QCrouzeixRaviartElement< 2 > >Face geometry of the 2D Crouzeix_Raviart elements
oomph::FaceGeometry< QCrouzeixRaviartElement< 3 > >Face geometry of the 3D Crouzeix_Raviart elements
oomph::FaceGeometry< QGeneralisedAdvectionDiffusionElement< 1, NNODE_1D > >Face geometry for the 1D QGeneralisedAdvectionDiffusion elements: Point elements
oomph::FaceGeometry< QGeneralisedAdvectionDiffusionElement< DIM, NNODE_1D > >Face geometry for the QGeneralisedAdvectionDiffusionElement elements: The spatial dimension of the face elements is one lower than that of the bulk element but they have the same number of points along their 1D edges
oomph::FaceGeometry< QLinearElasticityElement< 2, 2 > >FaceGeometry of a linear 2D QLinearElasticityElement element
oomph::FaceGeometry< QLinearElasticityElement< 2, 3 > >FaceGeometry of a quadratic 2D QLinearElasticityElement element
oomph::FaceGeometry< QLinearElasticityElement< 2, 4 > >FaceGeometry of a cubic 2D QLinearElasticityElement element
oomph::FaceGeometry< QLinearElasticityElement< 3, 2 > >FaceGeometry of a linear 3D QLinearElasticityElement element
oomph::FaceGeometry< QLinearElasticityElement< 3, 3 > >FaceGeometry of a quadratic 3D QLinearElasticityElement element
oomph::FaceGeometry< QLinearElasticityElement< 3, 4 > >FaceGeometry of a cubic 3D QLinearElasticityElement element
oomph::FaceGeometry< QLinearWaveElement< 1, NNODE_1D > >Face geometry for the 1D QLinearWaveElement elements: Point elements
oomph::FaceGeometry< QLinearWaveElement< DIM, NNODE_1D > >
oomph::FaceGeometry< QPoissonElement< 1, NNODE_1D > >Face geometry for the 1D QPoissonElement elements: Point elements
oomph::FaceGeometry< QPoissonElement< DIM, NNODE_1D > >
oomph::FaceGeometry< QPVDElement< 2, NNODE_1D > >FaceGeometry of a 2D QPVDElement element
oomph::FaceGeometry< QPVDElement< 3, NNODE_1D > >FaceGeometry of a 3D QPVDElement element
oomph::FaceGeometry< QPVDElementWithContinuousPressure< 2 > >FaceGeometry for 2D QPVDElementWithContinuousPressure element
oomph::FaceGeometry< QPVDElementWithPressure< 2 > >FaceGeometry of 2D QPVDElementWithPressure
oomph::FaceGeometry< QSpectralPoissonElement< 1, NNODE_1D > >Face geometry for the 1D QPoissonElement elements: Point elements
oomph::FaceGeometry< QSpectralPoissonElement< DIM, NNODE_1D > >
oomph::FaceGeometry< QTaylorHoodElement< 2 > >Face geometry of the 2D Taylor_Hood elements
oomph::FaceGeometry< QTaylorHoodElement< 3 > >Face geometry of the 3D Taylor_Hood elements
oomph::FaceGeometry< QUnsteadyHeatElement< 1, NNODE_1D > >Face geometry for the 1D QUnsteadyHeatElement elements: Point elements
oomph::FaceGeometry< QUnsteadyHeatElement< DIM, NNODE_1D > >
oomph::FaceGeometry< QWomersleyElement< 1, NNODE_1D > >Face geometry for the 1D QWomersleyElement elements: Point elements
oomph::FaceGeometry< QWomersleyElement< DIM, NNODE_1D > >
oomph::FaceGeometry< RefineableAxisymmetricQCrouzeixRaviartElement >Face geometry of the RefineableQuadQCrouzeixRaviartElements
oomph::FaceGeometry< RefineableAxisymmetricQTaylorHoodElement >Face geometry of the RefineableQuadQTaylorHoodElements
oomph::FaceGeometry< RefineablePseudoSolidNodeUpdateElement< BASIC, SOLID > >Explicit definition of the face geometry of these elements
oomph::FaceGeometry< RefineableQAdvectionDiffusionElement< DIM, NNODE_1D > >
oomph::FaceGeometry< RefineableQAdvectionDiffusionReactionElement< NREAGENT, DIM, NNODE_1D > >
oomph::FaceGeometry< RefineableQCrouzeixRaviartElement< DIM > >Face geometry of the RefineableQuadQCrouzeixRaviartElements
oomph::FaceGeometry< RefineableQGeneralisedAdvectionDiffusionElement< DIM, NNODE_1D > >
oomph::FaceGeometry< RefineableQLinearElasticityElement< 2, NNODE_1D > >FaceGeometry of the 2D RefineableQLinearElasticityElement elements
oomph::FaceGeometry< RefineableQLinearElasticityElement< 3, NNODE_1D > >FaceGeometry of the 3D RefineableQLinearElasticityElement elements
oomph::FaceGeometry< RefineableQLinearWaveElement< DIM, NNODE_1D > >
oomph::FaceGeometry< RefineableQPoissonElement< DIM, NNODE_1D > >
oomph::FaceGeometry< RefineableQPVDElement< 2, NNODE_1D > >FaceGeometry of the 2D RefineableQPVDElement elements
oomph::FaceGeometry< RefineableQPVDElement< 3, NNODE_1D > >FaceGeometry of the 3D RefineableQPVDElement elements
oomph::FaceGeometry< RefineableQPVDElementWithContinuousPressure< 2 > >FaceGeometry of the 2D RefineableQPVDElementWithContinuousPressure elements
oomph::FaceGeometry< RefineableQPVDElementWithContinuousPressure< 3 > >FaceGeometry of the 3D RefineableQPVDElementWithContinuousPressure
oomph::FaceGeometry< RefineableQPVDElementWithPressure< 2 > >FaceGeometry of the 2D RefineableQPVDElementWithPressure
oomph::FaceGeometry< RefineableQPVDElementWithPressure< 3 > >FaceGeometry of the 3D RefineableQPVDElementWithPressure
oomph::FaceGeometry< RefineableQSpectralPoissonElement< DIM, NNODE_1D > >
oomph::FaceGeometry< RefineableQTaylorHoodElement< DIM > >Face geometry of the RefineableQTaylorHoodElements is the same as the Face geometry of the QTaylorHoodElements
oomph::FaceGeometry< RefineableQUnsteadyHeatElement< DIM, NNODE_1D > >
oomph::FaceGeometry< SpineElement< ELEMENT > >Explicit definition of the face geometry for spine elements: The same as the face geometry of the underlying element
oomph::FaceGeometry< SpineElement< FaceGeometry< ELEMENT > > >Explicit definition of the face geometry for spine elements: The same as the face geometry of the underlying element
oomph::FaceGeometry< TLinearElasticityElement< 1, NNODE_1D > >Face geometry for the 1D TLinearElasticityElement elements: Point elements
oomph::FaceGeometry< TLinearElasticityElement< DIM, NNODE_1D > >
oomph::FaceGeometry< TPoissonElement< 1, NNODE_1D > >Face geometry for the 1D TPoissonElement elements: Point elements
oomph::FaceGeometry< TPoissonElement< DIM, NNODE_1D > >
oomph::FaceGeometry< TPVDElement< 2, NNODE_1D > >FaceGeometry of a 2D TPVDElement element
oomph::FaceGeometry< TPVDElement< 3, NNODE_1D > >FaceGeometry of a 3D TPVDElement element
oomph::FaceGeometry< TTaylorHoodElement< 2 > >Face geometry of the 2D Taylor_Hood elements
oomph::FaceGeometry< TTaylorHoodElement< 3 > >Face geometry of the 3D Taylor_Hood elements
factors_t
oomph::FD_LUDense LU decomposition-based solve of linear system assembled via finite differencing of the residuals Vector. Even more inefficient than DenseLU but excellent sanity check!
oomph::FiniteElementA general Finite Element class
oomph::FishDomainFish shaped domain, represented by four MacroElements. Shape is parametrised by GeomObject that represents the fish's back:
oomph::FishMesh< ELEMENT >Fish shaped mesh. The geometry is defined by the Domain object FishDomain:
oomph::FluidInterfaceEdgeElement
oomph::FluidInterfaceElement
oomph::FoldHandler
oomph::FSIDiagHermiteShellElement
oomph::FSIDrivenCavityMesh< ELEMENT >Mesh for W. Wall's FSI driven cavity problem. The mesh is derived from the SimpleRectangularQuadMesh so it's node and element numbering scheme is the same as in that mesh. Only the boundaries are numbered differently to allow the easy identification of the "collapsible" segment. Boundary coordinates are set up for all nodes located on boundary 3 (the collapsible segment). The curvilinear ("collapsible") segment is defined by a GeomObject.
  • Boundary 0 is the moving lid.
  • Boundary 1 is the gap above the moving lid on the right wall
  • Boundary 2 is the rigid part of the right wall
  • Boundary 3 is the moving (elastic) wall
  • Boundary 4 is the rigid part of the left wall
  • Boundary 5 is the gap above the moving lid on the left wall
oomph::FSIFluidElementThe FSIFluidElement class is a base class for all fluid finite elements that apply a load (traction) onto an adjacent SolidFiniteElement
oomph::FSIHermiteBeamElement
oomph::FSIPreconditionerFSI preconditioner. This extracts upper/lower triangular blocks in the 3x3 overall block matrix structure arising from the monolithic discretisation of FSI problems with algebraic node updates. Dofs are decomposed into fluid velocity, pressure and solid unknowns. NavierStokesLSCPreconditioner is used as the inexact solver for the fluid block; SuperLU (in its incarnation as an "exact" preconditioner) is used for the solid block. By default we retain the fluid on solid off diagonal blocks
oomph::FSISolidTractionElement< ELEMENT, DIM >
oomph::FSIWallElementThis is a base class for all SolidFiniteElements that participate in FSI computations. These elements provide interfaces and generic funcionality for the two additional roles that SolidFiniteElements play in FSI problems:
  1. They parameterise the domain boundary for the fluid domain. To allow them to play this role, FSIWallElements are derived from the SolidFiniteElement and the GeomObject class, indicating that the every specific FSIWallElement must implement the pure virtual function GeomObject::position(...) which should compute the position vector to a point in the SolidFiniteElement, parametrised by its local coordinates.
  2. In FSI problems fluid exerts a traction onto the wall and this traction must be added to any other load terms (such as an external pressure acting on an elastic pipe) that are already applied to the SolidFiniteElements by other means.

The fluid-traction on the SolidFiniteElements depends on the fluid variables (velocities and pressures) in those fluid elements that are adjacent to the SolidFiniteElements' Gauss points. In an FSI problem these velocities and pressures are unknowns in the overall problem and the dependency of the SolidFiniteElement's residual vector on these unknowns must be taken into account when computing the element's Jacobian matrix.
For each Gauss point in the FSIWallElement, we therefore store:
  • [a] pointer[s] to the FSIFluidElement[s] that is [are] "adjacent" to the Gauss point in the FSIWallElement.
  • the vector[s] of the local coordinates (in the fluid element[s]) that identify the point in the fluid element that is (deemed to be) "opposite" that Gauss point. (Note that we do not require the discretisations of the fluid and solid domains to match exactly, therefore, small "gaps" may occur between fluid and solid elements.)

By default, each FSIWallElement is assumed to be exposed to fluid loading only on one of its faces. For elements that are immersed into fluid, so that a fluid traction is "exerted from both sides", the element can store pointers to multiple adjacent fluid elements (and local coordindates in these). This capability must be enabled by a call to FSIWallElement::enable_fluid_loading_on_both_sides().
Since the fluid traction can involve derivatives of the velocity (think of Newtonian fluids), the traction is also affected by changes in the nodal positions of the adjacent fluid elements. Since fluid and solid discretisations are not required to match, the nodal positions in an adjacent fluid element can be affected by the positional variables in another FSIWallElement. To capture this influence, we provide the function FSIWallElement::node_update_adjacent_fluid_elements() which does exactly what it says....

Finally, since oomph-lib's fluid and solid elements tend to employ different non-dimensionalisations for the stresses, the fluid traction (computed by the adjacent fluid element, on the fluid stress-scale) may have to be scaled by the ratio $ Q $ of the stresses used to non-dimensionalise the two sets of stresses. For instance, for a fluid stress non-dimensionalisation based on the viscous scale $ \mu U / L$ (as in oomph-lib's Navier-Stokes elements) and a non-dimensionalisation of the solid mechanics stresses, based on a Young's modulus $ E $, as in oomph-lib's KirchhoffLoveBeamElements, the stress ratio is given by

\[ Q=\frac{\mu U}{LE} \]

For other wall/fluid element combinations the definition of $ Q $ will differ -- check the documentation and/or implementation to see which parameters are used to non-dimensionalise the stresses in the respective elements!

The function FSIWallElement::fluid_load_vector(...) computes the fluid traction on the wall on the wall stress-scale. This function may be called in the get_load (say) function of a specific FSIWallElement to add the fluid load to the other tractions that may already be applied to the element by other means. By default a stress-ratio of $ Q = 1 $ is used but this may be overwritten with the access function FSIWallElement::q_pt()

oomph::Gauss< DIM, NPTS_1D >
oomph::Gauss< 1, 2 >
oomph::Gauss< 1, 3 >
oomph::Gauss< 1, 4 >
oomph::Gauss< 2, 2 >
oomph::Gauss< 2, 3 >
oomph::Gauss< 2, 4 >
oomph::Gauss< 3, 2 >
oomph::Gauss< 3, 3 >
oomph::Gauss< 3, 4 >
oomph::Gauss_Rescaled< DIM, NPTS_1D >Class for multidimensional Gaussian integration rules, over intervals other than -1 to 1, all intervals are rescaled in this case
oomph::GaussLobattoLegendre< DIM, NPTS_1D >
oomph::GaussLobattoLegendre< 1, NPTS_1D >1D Gauss Lobatto Legendre integration class
oomph::GaussLobattoLegendre< 2, NPTS_1D >2D Gauss Lobatto Legendre integration class
oomph::GaussLobattoLegendre< 3, NPTS_1D >3D Gauss Lobatto Legendre integration class
oomph::GeneralisedAdvectionDiffusionEquations< DIM >A class for all elements that solve the Advection Diffusion equations in conservative form using isoparametric elements.

\[ /// \frac{\partial}{\partial x_{i}\left( /// Pe w_{i}(x_{k}) u - D_{ij}(x_{k})\frac{\partial u}{\partial x_{j}}\right) /// = f(x_{j}) /// \]

This contains the generic maths. Shape functions, geometric mapping etc. must get implemented in derived class

oomph::GeneralisedElementA Generalised Element class
oomph::GeneralisedHookean
oomph::GeneralisedMooneyRivlinGeneralisation of Mooney Rivlin constitutive law to compressible media as suggested on p. 553 of Fung, Y.C. & Tong, P. "Classical and Computational Solid Mechanics" World Scientific (2001). Input parameters are Young's modulus E, Poisson ratio nu and the Mooney-Rivlin constant C1. In the small-deformation-limit the behaviour becomes equivalent to that of linear elasticity with the same E and nu
oomph::GeneralPurposeBlockPreconditioner< MATRIX >Helper base class for general purpose block preconditioners
oomph::GeomObject
oomph::GeompackQuadMesh< ELEMENT >
oomph::GeompackQuadScaffoldMeshMesh that is based on input files generated by the quadrilateral mesh generator Geompack
oomph::GMRES< MATRIX >The GMRES method
oomph::GS< MATRIX >The Gauss Seidel method
oomph::HangInfoClass that contains data for hanging nodes
oomph::HermiteBeamElementHermite Kirchhoff Love beam. Implements KirchhoffLoveBeamEquations using 2-node Hermite elements as the underlying geometrical elements
oomph::HermitePVDElement< DIM >
oomph::HermiteQuadMesh< ELEMENT >A two dimensional Hermite bicubic element quadrilateral mesh for a topologically rectangular domain. The geometry of the problem must be prescribed using the TopologicallyRectangularDomain. Non uniform node spacing can be prescribed using a function pointer
oomph::HermiteShellElement
oomph::Hijacked< ELEMENT >Hijacked elements are elements in which one or more Data values that affect the element's residuals, are determined by another element -- the data values are then said to have been hijacked by another element. The main functionality added by the Hijacked element class is that it wipes out those entries in the element's residual vector and those rows in the element's Jacobian matrix that are determined by the "other" elements that have hijacked the values. Note that for continuation in homotopy parameters, it may be desriable to multiply the residuals and corresponding jacobian entries by a "homotopy parameter". The value of this parameter can be set by assigning residual_multiplier_pt() which has a default value of zero. Note: it would be possible to extend the functionality so that different residuals are multiplied by different values, but will this ever be required?
oomph::HijackedDataCustom Data class that is used when HijackingData. The class always contains a single value that is copied from another Data object
oomph::HijackedElementBase
oomph::HopfHandler
oomph::HSL_MA42
oomph::HypreInterface
oomph::HyprePreconditioner
oomph::HypreSolver
oomph::IdentityPreconditionerThe Identity Preconditioner
oomph::ILUZeroPreconditioner< MATRIX >ILU(0) Preconditioner
oomph::ILUZeroPreconditioner< CCDoubleMatrix >ILU(0) Preconditioner for matrices of CCDoubleMatrix Format
oomph::ILUZeroPreconditioner< CRDoubleMatrix >ILU(0) Preconditioner for matrices of CRDoubleMatrix Format
oomph::ImposeDisplacementByLagrangeMultiplierElement< ELEMENT >
oomph::ImposeFluxForWomersleyElement< DIM >Element to impose volume flux through collection of Womersley elements, in exchange for treating the pressure gradient as an unknown. The pressure gradient is created (as a single-valued Data item) in the constructor for this element which also takes a pointer to the Mesh containing the Womersley elements whose total flux is being controlled. While doing this we tell them that their pressure gradient is now an unknown and must be treated as external Data
oomph::ImposeParallelOutflowElement< ELEMENT >ImposeParallelOutflowElement are elements that coincide with the faces of higher-dimensional "bulk" elements. They are used on boundaries where we would like to impose parallel outflow and impose pressure
oomph::InnerIterationPreconditioner< SOLVER, PRECONDITIONER >A preconditioner for performing inner iteration preconditioner solves. The template argument SOLVER specifies the inner iteration solver (which must be derived from IterativeLinearSolver) and the template argument PRECONDITIONER specifies the preconditioner for the inner iteration iterative solver.
Note: For no preconditioning use the IdentityPreconditioner
oomph::Integral
oomph::IsotropicElasticityTensorAn isotropic elasticity tensor using the Lame moduli
oomph::IsotropicStrainEnergyFunctionConstitutiveLaw
oomph::IterativeLinearSolverBase class for all linear iterative solvers. This merely defines standard interfaces for linear iterative solvers, so that different solvers can be used in a clean and transparent manner
oomph::KirchhoffLoveBeamEquations
oomph::KirchhoffLoveShellEquations
oomph::LAPACK_QZClass for the LAPACK eigensolver
oomph::LevenbergMarquardtFitter
oomph::LevenbergMarquardtFittingFunctionObject
oomph::LinearAlgebraDistributionDescribes the distribution of a distributable linear algebra type object. Typically this is a container (such as a DoubleVector) or an operator (e.g Preconditioner or LinearSolver).
This object is used in both serial and parallel implementations. In the serial context (no MPI) this just contains an integer indicating the number of rows.
In parallel either each processor holds a subset of the set of global rows. (each processor contains only a single continuous block of rows - parametised with variables denoting the first row and the number of local rows) or, all rows are be duplicated across all processors.
In parallel this object also contains an OomphCommunicator object which primarily contains the MPI_Comm communicator associated with this object
oomph::LinearElasticityEquations< DIM >
oomph::LinearElasticityEquationsBase< DIM >
oomph::LinearElasticityTractionElement< ELEMENT >
oomph::LinearSolver
oomph::LinearWaveEquations< DIM >
oomph::LinearWaveFluxElement< ELEMENT >A class for elements that allow the imposition of an applied flux on the boundaries of LinearWave elements. The element geometry is obtained from the FaceGeometry<ELEMENT> policy class
oomph::LineFluidInterfaceEdgeElementSpecialisation of the edge constraint to a line
oomph::LineFluidInterfaceElement
oomph::LowStorageRungeKutta< ORDER >
oomph::MacroElement
oomph::MacroElementNodeUpdateChannelWithLeafletMesh< ELEMENT >
oomph::MacroElementNodeUpdateCollapsibleChannelMesh< ELEMENT >
oomph::MacroElementNodeUpdateElement< ELEMENT >
oomph::MacroElementNodeUpdateElementBaseBase class for elements that allow MacroElement-based node update
oomph::MacroElementNodeUpdateMesh
oomph::MacroElementNodeUpdateNode
oomph::MacroElementNodeUpdateRefineableChannelWithLeafletMesh< ELEMENT >Refineable mesh with MacroElement-based node update
oomph::MacroElementNodeUpdateRefineableCollapsibleChannelMesh< ELEMENT >
oomph::MacroElementNodeUpdateRefineableFishMesh< ELEMENT >
oomph::MacroElementNodeUpdateRefineableQuarterCircleSectorMesh< ELEMENT >
oomph::MacroElementNodeUpdateRefineableQuarterTubeMesh< ELEMENT >MacroElementNodeUpdate version of RefineableQuarterTubeMesh
oomph::MapMatrix< KEY_TYPE, VALUE_TYPE >
oomph::MapMatrixMixed< KEY_TYPE_ROW, KEY_TYPE_COL, VALUE_TYPE >
oomph::Matrix< T, MATRIX_TYPE >Abstract base class for matrices, templated by the type of object that is stored in them and the type of matrix. The MATRIX_TYPE template argument is used as part of the Curiously Recurring Template Pattern, see http://en.wikipedia.org/wiki/Curiously_Recurring_Template_Pattern The pattern is used to force the inlining of the round bracket access functions by ensuring that they are NOT virtual functions
oomph::MatrixBasedDiagPreconditionerMatrix-based diagonal preconditioner
oomph::MatrixBasedLumpedPreconditioner< MATRIX >Matrix-based lumped preconditioner
oomph::MatrixVectorProductMatrix vector product helper class - primarily a wrapper to Trilinos's Epetra matrix vector product methods. This allows the epetra matrix to be assembled once and the matrix vector product to be performed many times
oomph::MeshA general mesh class
oomph::MeshAsGeomObject< DIM_LAGRANGIAN, DIM_EULERIAN, ELEMENT >
oomph::MinModLimiter
oomph::MooneyRivlinMooneyRivlin strain-energy function. with constitutive parameters C1 and C2:

\[ /// W = C_1 (I_0 - 3) + C_2 (I_1 - 3) /// \]

where incompressibility ($ I_2 \equiv 1$) is assumed

oomph::MumpsPreconditionerAn interface to allow Mumps to be used as an (exact) Preconditioner
oomph::MumpsSolverWrapper to Mumps solver
oomph::NavierStokesEquations< DIM >
oomph::NavierStokesExactPreconditioner< MATRIX >The exact Navier Stokes preconditioner. This extracts 2x2 blocks (corresponding to the velocity and pressure unknowns) and uses these to build a single preconditioner matrix for testing purposes. Iterative solvers should converge in a single step if this is used. If it doesn't something is wrong in the setup of the block matrices
oomph::NavierStokesFluxControlElement< ELEMENT >
oomph::NavierStokesImpedanceTractionElement< BULK_NAVIER_STOKES_ELEMENT, WOMERSLEY_ELEMENT, DIM >
oomph::NavierStokesImpedanceTractionElementBase
oomph::NavierStokesLSCPreconditionerThe least-squares commutator (LSC; formerly BFBT) Navier Stokes preconditioner. It uses blocks corresponding to the velocity and pressure unknowns, i.e. there are a total of 2x2 blocks, and all velocity components are treated as a single block of unknowns.

Here are the details: An "ideal" Navier-Stokes preconditioner would solve the system

\[ /// \left( /// \begin{array}{cc} /// {\bf F} & {\bf G} \\ {\bf D} & {\bf 0} /// \end{array} /// \right) /// \left( /// \begin{array}{c} /// {\bf z}_u \\ {\bf z}_p /// \end{array} /// \right) = /// \left( /// \begin{array}{c} /// {\bf r}_u \\ {\bf r}_p /// \end{array} /// \right) /// \]

where $ {\bf F}$ is the momentum block, $ {\bf G} $ the discrete gradient operator, and $ {\bf D}$ the discrete divergence operator. (For unstabilised elements, we have $ {\bf D} = {\bf G}^T $ and in much of the literature the divergence matrix is denoted by $ {\bf B} $ .) The use of this preconditioner would ensure the convergence of any iterative linear solver in a single iteration but its application is, of course, exactly as expensive as a direct solve. The LSC/BFBT preconditioner replaces the exact Jacobian by a block-triangular approximation

\[ /// \left( /// \begin{array}{cc} /// {\bf F} & {\bf G} \\ {\bf 0} & -{\bf M}_s /// \end{array} /// \right) /// \left( /// \begin{array}{c} /// {\bf z}_u \\ {\bf z}_p /// \end{array} /// \right) = /// \left( /// \begin{array}{c} /// {\bf r}_u \\ {\bf r}_p /// \end{array} /// \right), /// \]

where ${\bf M}_s$ is an approximation to the pressure Schur-complement $ {\bf S} = {\bf D} {\bf F}^{-1}{\bf G}. $ This system can be solved in two steps:

  1. Solve the second row for $ {\bf z}_p$ via

    \[ /// {\bf z}_p = - {\bf M}_s^{-1} {\bf r}_p /// \]

  2. Given $ {\bf z}_p $ , solve the first row for $ {\bf z}_u$ via

    \[ /// {\bf z}_u = {\bf F}^{-1} \big( {\bf r}_u - {\bf G} {\bf z}_p \big) /// \]

In the LSC/BFBT preconditioner, the action of the inverse pressure Schur complement

\[ /// {\bf z}_p = - {\bf M}_s^{-1} {\bf r}_p /// \]

is approximated by

\[ /// {\bf z}_p = - /// \big({\bf D} \widehat{\bf Q}^{-1}{\bf G} \big)^{-1} /// \big({\bf D} \widehat{\bf Q}^{-1}{\bf F} \widehat{\bf Q}^{-1}{\bf G}\big) /// \big({\bf D} \widehat{\bf Q}^{-1}{\bf G} \big)^{-1} /// {\bf r}_p, /// \]

where $ \widehat{\bf Q} $ is the diagonal of the velocity mass matrix. The evaluation of this expression involves two linear solves involving the matrix

\[ /// {\bf P} = \big({\bf D} \widehat{\bf Q}^{-1}{\bf G} \big) /// \]

which has the character of a matrix arising from the discretisation of a Poisson problem on the pressure space. We also have to evaluate matrix-vector products with the matrix

\[ /// {\bf E}={\bf D}\widehat{\bf Q}^{-1}{\bf F}\widehat{\bf Q}^{-1}{\bf G} /// \]

Details of the theory can be found in "Finite Elements and Fast Iterative Solvers with Applications in Incompressible Fluid Dynamics" by Howard C. Elman, David J. Silvester, and Andrew J. Wathen, published by Oxford University Press, 2006.

In our implementation of the preconditioner, the linear systems can either be solved "exactly", using SuperLU (in its incarnation as an exact preconditioner; this is the default) or by any other Preconditioner (inexact solver) specified via the access functions

oomph::NavierStokesSurfacePowerElement< ELEMENT >
oomph::NavierStokesTractionElement< ELEMENT >
oomph::NavierStokesWomersleyPressureControlElement
oomph::NetFluxControlElement
oomph::NetFluxControlElementForWomersleyPressureControl
oomph::Newmark< NSTEPS >Newmark scheme for second time deriv. Stored data represents
  • t=0: value at at present time, Time_pt->time()
  • t=1: value at previous time, Time_pt->time()-dt
  • ...
  • t=NSTEPS: value at previous time, Time_pt->time()-NSTEPS*dt
  • t=NSTEPS+1: 1st time deriv (= "velocity") at previous time, Time_pt->time()-dt
  • t=NSTEPS+2: 2nd time deriv (= "acceleration") at previous time, Time_pt->time()-dt
oomph::NewmarkBDF< NSTEPS >Newmark scheme for second time deriv with first derivatives calculated using BDF. . Stored data represents
  • t=0: value at at present time, Time_pt->time()
  • t=1: value at previous time, Time_pt->time()-dt
  • ...
  • t=NSTEPS: value at previous time, Time_pt->time()-NSTEPS*dt
  • t=NSTEPS+1: 1st time deriv (= "velocity") at previous time, Time_pt->time()-dt
  • t=NSTEPS+2: 2nd time deriv (= "acceleration") at previous time, Time_pt->time()-dt
oomph::NewtonSolverErrorA class to handle errors in the Newton solver
oomph::NodeNodes are derived from Data, but, in addition, have a definite (Eulerian) position in a space of a given dimension.

The nodal coordinates are used in the elements' mapping between local and global coordinates and in the simplest case (stationary nodes in Lagrange-type elements) this mapping is given by

\[ x_i = \sum_{j=1}^{N_{node}} X_{ij} \psi_{j}(s_k) \]

so we need only access to the nodal coordinates $ X_{ij}\ (i=1..DIM) $ of all nodes $ j $ : provided by the Node member function

oomph::NonRefineableElementWithHangingNodes
oomph::NullstreamA small nullstream class that throws away everything sent to it
oomph::OcTree
oomph::OcTreeForest
oomph::OcTreeRoot
oomph::OneDimensionalLegendreDShape< NNODE_1D >
oomph::OneDimensionalLegendreShape< NNODE_1D >Class that returns the shape functions associated with legendre
oomph::OneDLagrangianMesh< ELEMENT >
oomph::OneDLegendreDShapeParam
oomph::OneDLegendreShapeParamClass that returns the shape functions associated with legendre
oomph::OneDMesh< ELEMENT >
oomph::OomphCommunicatorAn oomph-lib wrapper to the MPI_Comm communicator object. Just contains an MPI_Comm object (which is a pointer) and wrappers to the MPI_... methods
oomph::OomphInfo
oomph::OomphLibError
oomph::OomphLibException
oomph::OomphLibPreconditionerEpetraOperatorAn Epetra_Operator class for oomph-lib preconditioners. A helper class for TrilinosOomphLibPreconditioner to allow an oomph-lib preconditioner (i.e. one derived from Preconditioner) to be used with a trilinos solver (TrilinosAztecOOSolver)
oomph::OomphLibWarning
oomph::OutputModifier
oomph::PicardConvergenceDataObject that collates convergence data of Picard iteration
oomph::PitchForkHandler
oomph::PointElement
oomph::PointFluidInterfaceEdgeElementSpecialisation of the edge constraint to a point
oomph::PointIntegral
oomph::PoissonEquations< DIM >
oomph::PoissonFluxElement< ELEMENT >A class for elements that allow the imposition of an applied flux on the boundaries of Poisson elements. The element geometry is obtained from the FaceGeometry<ELEMENT> policy class
oomph::PreconditionerPreconditioner base class. This is a base class for all oomph-lib preconditioners and primarily contains the method definitions. All preconditioners should be derived from this class
oomph::PreconditionerArrayPreconditionerArray - NOTE - first implementation, a number of assumptions / simplifications were made: 1. Only works with CRDoubleMatrices
2. The number of processors must be greater than the number of preconditioners
3. Currently only very crude load balancing - each preconditioner will be setup and applied with the same number of processors (or as near to as possible to the same number of processors)
4. This class will, at the appropriate time, delete the all the Preconditioners passed setup_preconditioners(...)
5. (but) Deletion of matrices passed to setup_preconditioners(...) is NOT performed by this class
6. It is assumed that preconditioners do not require access to matrix once setup(...) is called
7. The matrix on the subset of processors will be the same type (distributed or global) as the matrix passed to setup_preconditioners(...)
8. If the matrix is a distributed matrix - it will be assembled with a uniform distribution on the subset of processors
oomph::ProblemThe Problem class
oomph::PseudoBucklingRingPseudo buckling ring: Circular ring deformed by the N-th buckling mode of a thin-wall elastic ring.

\[ /// x = R_0 \cos(\zeta) + /// \epsilon \left( \cos(N \zeta) \cos(\zeta) - A \sin(N \zeta) \sin(\zeta) /// \right) sin(2 \pi t/T) /// \]

\[ /// y = R_0 \sin(\zeta) + /// \epsilon \left( \cos(N \zeta) \sin(\zeta) + A \sin(N \zeta) \cos(\zeta) /// \right) sin(2 \pi t/T) /// \]

where A is the ratio of the aziumuthal to the radial buckling amplitude (A=-1/N for statically buckling rings) and epsilon is the buckling amplitude

oomph::PseudoBucklingRingElementPseudo buckling ring: Circular ring deformed by the N-th buckling mode of a thin-wall elastic ring.

\[ /// x = R_0 \cos(\zeta) + /// \epsilon \left( \cos(N \zeta) \cos(\zeta) - A \sin(N \zeta) \sin(\zeta) /// \right) sin(2 \pi t/T) /// \]

\[ /// y = R_0 \sin(\zeta) + /// \epsilon \left( \cos(N \zeta) \sin(\zeta) + A \sin(N \zeta) \cos(\zeta) /// \right) sin(2 \pi t/T) /// \]

where A is the ratio of the aziumuthal to the radial buckling amplitude (A=-1/N for statically buckling rings) and epsilon is the buckling amplitude. Scale R_0 is adjusted to ensure conservation of (computational) volume/area. This is implemented by a pseudo-elasticity approach: The governing equation for $ R_0 $ is:

\[ /// p_{ref} = R_0 - 1.0 /// \]

The pointer to the reference pressure needs to be set with reference_pressure_pt()

oomph::PseudoSolidNodeUpdateElement< BASIC, SOLID >
oomph::PVDEquations< DIM >
oomph::PVDEquationsBase< DIM >
oomph::PVDEquationsWithPressure< DIM >
oomph::QAdvectionDiffusionElement< DIM, NNODE_1D >QAdvectionDiffusionElement elements are linear/quadrilateral/brick-shaped Advection Diffusion elements with isoparametric interpolation for the function
oomph::QAdvectionDiffusionReactionElement< NREAGENT, DIM, NNODE_1D >QAdvectionDiffusionReactionElement elements are linear/quadrilateral/brick-shaped Advection Diffusion elements with isoparametric interpolation for the function
oomph::QCrouzeixRaviartElement< DIM >
oomph::QElement< DIM, NNODE_1D >
oomph::QElement< 1, NNODE_1D >General QElement class specialised to one spatial dimension
oomph::QElement< 2, NNODE_1D >General QElement class specialised to two spatial dimensions
oomph::QElement< 3, NNODE_1D >General QElement class specialised to three spatial dimensions
oomph::QElementBaseBase class for Qelements
oomph::QGeneralisedAdvectionDiffusionElement< DIM, NNODE_1D >QGeneralisedAdvectionDiffusionElement elements are linear/quadrilateral/brick-shaped Advection Diffusion elements with isoparametric interpolation for the function
oomph::QHermiteElement< DIM >
oomph::QLinearElasticityElement< DIM, NNODE_1D >
oomph::QLinearWaveElement< DIM, NNODE_1D >
oomph::QMacroElement< DIM >
oomph::QMacroElement< 2 >
oomph::QMacroElement< 3 >
oomph::QPoissonElement< DIM, NNODE_1D >
oomph::QPVDElement< DIM, NNODE_1D >
oomph::QPVDElementWithContinuousPressure< DIM >
oomph::QPVDElementWithPressure< DIM >
oomph::QSolidElementBaseBase class for Solid Qelements
oomph::QSpectralElement< DIM, NNODE_1D >
oomph::QSpectralElement< 1, NNODE_1D >General QSpectralElement class specialised to one spatial dimension
oomph::QSpectralElement< 2, NNODE_1D >General QSpectralElement class specialised to two spatial dimensions
oomph::QSpectralElement< 3, NNODE_1D >General QSpectralElement class specialised to three spatial dimensions
oomph::QSpectralPoissonElement< DIM, NNODE_1D >
oomph::QSUPGAdvectionDiffusionElement< DIM, NNODE_1D >QSUPGAdvectionDiffusionElement<DIM,NNODE_1D> elements are SUPG-stabilised Advection Diffusion elements with NNODE_1D nodal points in each coordinate direction. Inherits from QAdvectionDiffusionElement and overwrites their test functions
oomph::QTaylorHoodElement< DIM >
oomph::QuadElementBaseBase class for all quad elements
oomph::QuadMeshBaseBase class for quad meshes (meshes made of 2D quad elements)
oomph::QuadTree
oomph::QuadTreeForest
oomph::QuadTreeRoot
oomph::QuarterCircleSectorDomainCircular sector as domain. Domain is bounded by curved boundary which is represented by a GeomObject. Domain is parametrised by three macro elements as shown here:
oomph::QuarterCircleSectorMesh< ELEMENT >
oomph::QuarterTubeDomainQuarter tube as domain. Domain is bounded by curved boundary which is represented by a GeomObject. Domain is parametrised by three macro elements in each of the nlayer slices
oomph::QuarterTubeMesh< ELEMENT >3D quarter tube mesh class. The domain is specified by the GeomObject that identifies boundary 3. Non-refineable base version!
The mesh boundaries are numbered as follows:
  • Boundary 0: "Inflow" cross section; located along the line parametrised by $ \xi_0 = \xi_0^{lo} $ on the geometric object that specifies the wall.
  • Boundary 1: Plane x=0
  • Boundary 2: Plane y=0
  • Boundary 3: The curved wall
  • Boundary 4: "Outflow" cross section; located along the line parametrised by $ \xi_0 = \xi_0^{hi} $ on the geometric object that specifies the wall
oomph::QUnsteadyHeatElement< DIM, NNODE_1D >
oomph::QWomersleyElement< DIM, NNODE_1D >
oomph::RankFiveTensor< T >A Rank 5 Tensor class
oomph::RankFourTensor< T >A Rank 4 Tensor class
oomph::RankThreeTensor< T >A Rank 3 Tensor class
oomph::RectangularQuadMesh< ELEMENT >
oomph::RefineableAdvectionDiffusionEquations< DIM >A version of the Advection Diffusion equations that can be used with non-uniform mesh refinement. In essence, the class overloads the fill_in_generic_residual_contribution_adv_diff() function so that contributions from hanging nodes (or alternatively in-compatible function values) are taken into account
oomph::RefineableAdvectionDiffusionReactionEquations< NREAGENT, DIM >A version of the Advection Diffusion Reaction equations that can be used with non-uniform mesh refinement. In essence, the class overloads the fill_in_generic_residual_contribution_adv_diff_react() function so that contributions from hanging nodes (or alternatively in-compatible function values) are taken into account
oomph::RefineableAlgebraicChannelWithLeafletMesh< ELEMENT >Refineable version of algebraic ChannelWithLeafletMesh
oomph::RefineableAlgebraicCollapsibleChannelMesh< ELEMENT >
oomph::RefineableAlgebraicCylinderWithFlagMesh< ELEMENT >Refineable version of AlgebraicCylinderWithFlagMesh
oomph::RefineableAlgebraicFSIDrivenCavityMesh< ELEMENT >
oomph::RefineableAxisymmetricNavierStokesEquationsRefineable version of the Axisymmetric Navier--Stokes equations
oomph::RefineableAxisymmetricQCrouzeixRaviartElement
oomph::RefineableAxisymmetricQTaylorHoodElement
oomph::RefineableBrickMesh< ELEMENT >
oomph::RefineableChannelWithLeafletMesh< ELEMENT >Refineable version of ChannelWithLeafletMesh
oomph::RefineableCollapsibleChannelMesh< ELEMENT >
oomph::RefineableCylinderWithFlagMesh< ELEMENT >Refineable version of CylinderWithFlagMesh
oomph::RefineableEighthSphereMesh< ELEMENT >
oomph::RefineableElement
oomph::RefineableFishMesh< ELEMENT >
oomph::RefineableFSIDrivenCavityMesh< ELEMENT >
oomph::RefineableGeneralisedAdvectionDiffusionEquations< DIM >A version of the GeneralisedAdvection Diffusion equations that can be used with non-uniform mesh refinement. In essence, the class overloads the fill_in_generic_residual_contribution_cons_adv_diff() function so that contributions from hanging nodes (or alternatively in-compatible function values) are taken into account
oomph::RefineableLinearElasticityEquations< DIM >Class for Refineable LinearElasticity equations
oomph::RefineableLinearWaveEquations< DIM >Refineable version of LinearWave equations
oomph::RefineableMesh< ELEMENT >
oomph::RefineableMeshBase
oomph::RefineableNavierStokesEquations< DIM >
oomph::RefineableNavierStokesFluxControlElement< ELEMENT >
oomph::RefineablePoissonEquations< DIM >
oomph::RefineablePseudoSolidNodeUpdateElement< BASIC, SOLID >Refineable version of the PseudoSolidNodeUpdateELement
oomph::RefineablePVDEquations< DIM >Class for Refineable PVD equations
oomph::RefineablePVDEquationsWithPressure< DIM >
oomph::RefineableQAdvectionDiffusionElement< DIM, NNODE_1D >Refineable version of QAdvectionDiffusionElement. Inherit from the standard QAdvectionDiffusionElement and the appropriate refineable geometric element and the refineable equations
oomph::RefineableQAdvectionDiffusionReactionElement< NREAGENT, DIM, NNODE_1D >Refineable version of QAdvectionDiffusionReactionElement. Inherit from the standard QAdvectionDiffusionReactionElement and the appropriate refineable geometric element and the refineable equations
oomph::RefineableQCrouzeixRaviartElement< DIM >Refineable version of Crouzeix Raviart elements. Generic class definitions
oomph::RefineableQElement< DIM >
oomph::RefineableQElement< 2 >
oomph::RefineableQElement< 3 >
oomph::RefineableQGeneralisedAdvectionDiffusionElement< DIM, NNODE_1D >Refineable version of QGeneralisedAdvectionDiffusionElement. Inherit from the standard QGeneralisedAdvectionDiffusionElement and the appropriate refineable geometric element and the refineable equations
oomph::RefineableQLinearElasticityElement< DIM, NNODE_1D >Class for refineable QLinearElasticityElement elements
oomph::RefineableQLinearWaveElement< DIM, NNODE_1D >
oomph::RefineableQPoissonElement< DIM, NNODE_1D >
oomph::RefineableQPVDElement< DIM, NNODE_1D >Class for refineable QPVDElement elements
oomph::RefineableQPVDElementWithContinuousPressure< DIM >
oomph::RefineableQPVDElementWithPressure< DIM >
oomph::RefineableQSpectralElement< DIM >
oomph::RefineableQSpectralElement< 2 >
oomph::RefineableQSpectralElement< 3 >
oomph::RefineableQSpectralPoissonElement< DIM, NNODE_1D >
oomph::RefineableQSUPGAdvectionDiffusionElement< DIM, NNODE_1D >Refineable version of QSUPGAdvectionDiffusionElement. Inherit from the standard QSUPGAdvectionDiffusionElement and the appropriate refineable geometric element and the refineable equations
oomph::RefineableQTaylorHoodElement< DIM >
oomph::RefineableQuadMesh< ELEMENT >
oomph::RefineableQuarterCircleSectorMesh< ELEMENT >
oomph::RefineableQuarterTubeMesh< ELEMENT >
oomph::RefineableQUnsteadyHeatElement< DIM, NNODE_1D >
oomph::RefineableRectangularQuadMesh< ELEMENT >
oomph::RefineableSimpleCubicMesh< ELEMENT >Refineable version of simple cubic 3D Brick mesh class
oomph::RefineableSolidElement
oomph::RefineableSolidQElement< DIM >
oomph::RefineableSolidQElement< 2 >Refineable version of Solid quad elements
oomph::RefineableSolidQElement< 3 >Refineable version of Solid brick elements
oomph::RefineableTubeMesh< ELEMENT >
oomph::RefineableUnsteadyHeatEquations< DIM >
oomph::RungeKutta< ORDER >
oomph::SegregatableFSIProblem
oomph::SegregatedSolverErrorA class to handle errors in the Segregated solver
oomph::Shape
oomph::SimpleCubicMesh< ELEMENT >Simple cubic 3D Brick mesh class
oomph::SimpleCubicScaffoldTetMeshScaffold mesh for cubic tet mesh
oomph::SimpleCubicTetMesh< ELEMENT >MySimple 3D triangular mesh for TElements
oomph::SimpleFSIPreconditioner< MATRIX >FSI preconditioner. This extracts upper/lower triangular blocks in the 3x3 overall block matrix structure arising from the monolithic discretisation of FSI problems with algebraic node updates. Dofs are decomposed into fluid velocity, pressure and solid unknowns. Blocks are then re-assembled into one global matrix and solved with a direct solver (SuperLU in its incarnation as an exact preconditioner). By default we retain the fluid on solid off diagonal blocks
oomph::SimpleRectangularQuadMesh< ELEMENT >
oomph::SimpleRectangularTriMesh< ELEMENT >Simple 2D triangular mesh for TElements
oomph::SingleLayerCubicSpineMesh< ELEMENT, INTERFACE_ELEMENT >
oomph::SingleLayerSpineMesh< ELEMENT, INTERFACE_ELEMENT >
oomph::SlopeLimiterBase class for slope limiters
oomph::SolidDiagQHermiteElement< DIM >
oomph::SolidFaceElement
oomph::SolidFiniteElementSolidFiniteElement class.

Solid elements are elements whose nodal positions are unknowns in the problem -- their nodes are SolidNodes. In such elements, the nodes not only have a variable (Eulerian) but also a fixed (Lagrangian) position. The positional variables have their own local equation numbering scheme which is set up with
oomph::SolidICProblemIC problem for an elastic body discretised on a given (sub)-mesh. We switch the elements' residuals and Jacobians to the system of equations that forces the wall shape to become that of a specified "initial condition object".

Boundary conditions for all data items associated with the mesh's elements' are temporarily overwritten so that all positional dofs (and only those!) become free while all other data (nodal data and the element's internal and external data) are either pinned (for nodal and internal data) or completely removed (for pointers to external data). The complete removal of the (pointers to the) external data is necessary because in FSI problems, positional data of certain elements can feature as external data of others. Hence pinning them in their incarnation as external data would also pin them in their incarnation as positional data.

All data and its pinned-status are restored at the end of the call to setup_ic()
oomph::SolidInitialConditionA class to specify the initial conditions for a solid body. Solid bodies are often discretised with Hermite-type elements, for which the assignment of the generalised nodal values is nontrivial since they represent derivatives w.r.t. to the local coordinates. A SolidInitialCondition object specifies initial position (i.e. shape), velocity and acceleration of the structure with a geometric object. An integer specifies which time-derivative derivative is currently assigned. See example codes for a demonstration of its use
oomph::SolidMeshGeneral SolidMesh class
oomph::SolidNodeA Class for nodes that deform elastically (i.e. position is an unknown in the problem). The idea is that the Eulerian positions are stored in a Data object and the Lagrangian coordinates are stored in addition. The pointer that addresses the Eulerian positions is set to the pointer to Value in the Data object. Hence, SolidNode uses knowledge of the internal structure of Data and must be a friend of the Data class. In order to allow a mesh to deform via an elastic-style equation in deforming-domain problems, the positions are stored separately from the values, so that elastic problems may be combined with any other type of problem
oomph::SolidPointElementSolid point element
oomph::SolidQElement< DIM, NNODE_1D >
oomph::SolidQElement< 1, NNODE_1D >SolidQElement elements, specialised to one spatial dimension
oomph::SolidQElement< 2, NNODE_1D >SolidQElement elements, specialised to two spatial dimensions
oomph::SolidQElement< 3, NNODE_1D >SolidQElement elements, specialised to three spatial dimensions
oomph::SolidQHermiteElement< DIM >
oomph::SolidTElement< DIM, NNODE_1D >
oomph::SolidTElement< 1, NNODE_1D >SolidTElement elements, specialised to one spatial dimension
oomph::SolidTElement< 2, NNODE_1D >SolidTElement elements, specialised to two spatial dimensions
oomph::SolidTElement< 3, NNODE_1D >SolidTElement elements, specialised to three spatial dimensions
oomph::SolidTractionElement< ELEMENT >
oomph::SparseMatrix< T, MATRIX_TYPE >
oomph::SpectralElement
oomph::Spine
oomph::SpineAxisymmetricFluidInterfaceElement< ELEMENT >
oomph::SpineElement< ELEMENT >The SpineElement<ELEMENT> class takes an existing element as a template parameter and adds the necessary additional functionality to allow the element to be update using the Method of Spines. A vector of pointers to spines and storage for the local equation numbers associated with the spines are added to the element
oomph::SpineFiniteElementA policy class that serves only to establish the interface for assigning the spine equation numbers
oomph::SpineLineFluidInterfaceEdgeElement< ELEMENT >
oomph::SpineLineFluidInterfaceElement< ELEMENT >
oomph::SpineMesh
oomph::SpineNode
oomph::SpinePointFluidInterfaceEdgeElement< ELEMENT >Spine version of the PointInterfaceEdgeElement
oomph::SpineSurfaceFluidInterfaceElement< ELEMENT >
oomph::Steady< NSTEPS >
oomph::StorableShapeElement< ELEMENT >
oomph::StorableShapeElementBase
oomph::StorableShapeSolidElement< ELEMENT >
oomph::StorableShapeSolidElementBase
oomph::StraightLine
oomph::StrainEnergyFunctionBase class for strain energy functions to be used in solid mechanics computations
superlu_dist_data
oomph::SuperLUPreconditionerAn interface to allow SuperLU to be used as an (exact) Preconditioner
oomph::SuperLUSolver. SuperLU Project Solver class. This is a combined wrapper for both SuperLU and SuperLU Dist. See http://crd.lbl.gov/~xiaoye/SuperLU/ Default Behaviour: If this solver is distributed over more than one processor then SuperLU Dist is used.
Member data naming convention: member data associated with the SuperLU Dist solver begins Dist_... and member data associated with the serial SuperLU solver begins Serial_... .
oomph::SurfaceFluidInterfaceElement
oomph::TElement< DIM, NNODE_1D >
oomph::TElement< 1, NNODE_1D >
oomph::TElement< 2, NNODE_1D >
oomph::TElement< 3, NNODE_1D >
oomph::TElementBase
oomph::TElementShape< DIM, NNODE_1D >
oomph::TElementShape< 1, 2 >
oomph::TElementShape< 1, 3 >
oomph::TElementShape< 1, 4 >
oomph::TElementShape< 2, 2 >
oomph::TElementShape< 2, 3 >
oomph::TElementShape< 2, 4 >
oomph::TElementShape< 3, 2 >Return local coordinates of node j
oomph::TElementShape< 3, 3 >Return local coordinates of node j
oomph::TemplateFreeNavierStokesFluxControlElementBase
oomph::TemplateFreeWomersleyImpedanceTubeBase
oomph::TetgenMesh< ELEMENT >Unstructured tet mesh based on output from Tetgen: http://tetgen.berlios.de/
oomph::TetgenScaffoldMeshMesh that is based on input files generated by the tetrahedra mesh generator tetgen
oomph::TetMeshBaseBase class for triangle meshes (meshes made of 3D tet elements)
oomph::TGauss< DIM, NPTS_1D >
oomph::TGauss< 1, 2 >
oomph::TGauss< 1, 3 >
oomph::TGauss< 1, 4 >
oomph::TGauss< 2, 2 >
oomph::TGauss< 2, 3 >
oomph::TGauss< 2, 4 >
oomph::TGauss< 3, 2 >
oomph::TGauss< 3, 3 >
oomph::TimeClass to keep track of discrete/continous time. It is essential to have a single Time object when using multiple time-stepping schemes; e.g., in fluid-structure interaction problems, it is common to use different schemes for the fluid and solid domains. Storage is allocated for the current value of the (continuous) time and a limited history of previous timesteps. The number of previous timesteps must be equal to the number required by the "highest order" scheme
oomph::TimerTimer
oomph::TimeStepperBase class for time-stepping schemes. Timestepper provides an approximation of the temporal derivatives of Data such that the i-th derivative of the j-th value in Data is represented as
oomph::TLinearElasticityElement< DIM, NNODE_1D >
oomph::TopologicallyRectangularDomainTopologically Rectangular Domain - a domain dexcribing a topologically rectangular problem - primarily contains functions to access the position of the global boundary relative to the macro element boundary, as well as first and second derivates of the global boundary wrt the macro element boundary NOTE : suitable for HermiteElementQuadMesh
oomph::TPoissonElement< DIM, NNODE_1D >
oomph::TPVDElement< DIM, NNODE_1D >
oomph::Tree
oomph::TreeForest
oomph::TreeRoot
oomph::TriangleMesh< ELEMENT >
oomph::TriangleMeshBaseBase class for triangle meshes (meshes made of 2D triangle elements)
oomph::TriangleScaffoldMeshTriangle Mesh that is based on input files generated by the triangle mesh generator Triangle
oomph::triangulateio
oomph::TrilinosAztecOOSolverAn interface to the Trilinos AztecOO classes allowing it to be used as an Oomph-lib LinearSolver.
The AztecOO solver is a Krylov Subspace solver; the solver type (either CG, GMRES or BiCGStab) can be set using solver_type().
This solver can be preconditioned with Trilinos Preconditioners (derived from TrilinosPreconditionerBase) or Oomph-lib preconditioners (derived from Preconditioner). Preconditioners are set using preconditioner_pt()
oomph::TrilinosIFPACKPreconditionerAn interface to the Trilinos IFPACK class- provides a function to construct an IFPACK object, and functions to modify some of the IFPACK paramaters
oomph::TrilinosMLPreconditionerAn interface to the Trilinos ML class - provides a function to construct a serial ML object, and functions to modify some of the ML paramaters
oomph::TrilinosPreconditionerBaseBase class for Trilinos preconditioners as oomph-lib preconditioner.
oomph::TSolidElementBaseBase class for Solid Telements
oomph::TTaylorHoodElement< DIM >
oomph::TubeDomainTube as a domain. The entire domain must be defined by a GeomObject with the following convention: zeta[0] is the coordinate along the centreline, zeta[1] is the theta coordinate around the tube wall and zeta[2] is the radial coordinate. The outer boundary must lie at zeta[2] = 1
oomph::TubeMesh< ELEMENT >3D tube mesh class. The domain is specified by the GeomObject that identifies the entire volume. Non-refineable base version!
The mesh boundaries are numbered as follows:
  • Boundary 0: "Inflow" cross section; located along the line parametrised by $ \xi_0 = \xi_0^{lo} $.
  • Boundary 1: The outer wall, represetned by $\xi_2 = 1$.
  • Boundary 2: The out flow, represented by $\xi_0 = \xi_0^{hi}$
oomph::TwoLayerSpineMesh< ELEMENT, INTERFACE_ELEMENT >
oomph::UnsteadyHeatEquations< DIM >
oomph::UnsteadyHeatFluxElement< ELEMENT >A class for elements that allow the imposition of an applied flux on the boundaries of UnsteadyHeat elements. The element geometry is obtained from the FaceGeometry<ELEMENT> policy class
oomph::Vector< _Tp >
vector
oomph::Vector< bool >A Vector of bools cannot be created because the is no compiler-independent implementation of the bit manipulators. Making all the constructors private should lead to compile-time errors
oomph::WarpedCubeDomainWarped cube as domain which is parametrised by a single macro element
oomph::WomersleyEquations< DIM >
oomph::WomersleyImpedanceTubeBase< ELEMENT, DIM >
oomph::WomersleyMesh< WOMERSLEY_ELEMENT >
oomph::WomersleyOutflowImpedanceTube< ELEMENT, DIM >
oomph::WomersleyProblem< ELEMENT, DIM >Womersley problem
oomph::Z2ErrorEstimator

Generated on Mon Aug 10 11:23:53 2009 by  doxygen 1.4.7