In GEOS, the mesh structure consists of a hierarchy of classes intended to encapsulate data and functionality for each topological type. Each class in the mesh hierarchy represents a distinct topological object, such as a nodes, edges, faces, elements, etc. The mesh data structure is illustrated in an object instantiation hierarchy. The object instantiation hierarchy differs from a “class hierarchy” in that it shows how instantiations of each class relate to each other in the data hierarchy rather than how each class type relates to each other in an inheritance diagram.
To illustrate the mesh hierarchy, we propose to present it along with a model with two regions (Top and Bottom) (Fig. 87).
MeshObjectInstantiationHierarchy the top level object
a partition of the decomposed physical domain.
At this time there is a unique
DomainPartition for every MPI rank.
there may be more than one
DomainPartition in cases where the ranks are overloaded.
Currently GEOS does not support overloading multiple
DomainPartition’s onto a rank, although
this may be a future option if its use is properly motivated.
For instance, the model presented as example can be split into two different domains (Fig. 88).
MeshBody represents a topologically distinct mesh body.
For instance if a simulation of two separate spheres was required, then one option would be to have
both spheres as part of a single mesh body, while another option would be to have each sphere be
a individual body.
While not currently utilized in GEOS, the intent is to have the ability to handle the bodies
in a multi-body mesh on an individual basis.
For instance, when conducting high resolution crush simulations of granular materials (i.e. sand),
it may be advantagous to represent each particle as a
MeshLevel is intended to facilitate the representation of a multi-level discretization of a
In current practice, the code utilizes a single
MeshLevel until such time as we
implement a proper multi-level mesh capability.
MeshLevel contains the main components that compose a discretized mesh in GEOS.
Topological Mesh Objects
Each of the “Manager” objects are responsible for holding child objects, data, and providing functionality
specific to a single topological object.
Each topological object that is used to define a discretized mesh has a “Manager” to allow for simple
traversal over the hierarchy, and to provide modular access to data.
As such, the
NodeManager manages data for the “nodes”, the
EdgeManager manages data for the edges, the
FaceManager holds data for the faces and the
the physical groups within the
MeshLevel ( regions, fractures, wells etc…).
Additionally each manager contains index maps to the other types objects that are connected to the
objects in that manager.
For instance, the
FaceManager contains a downward pointing map that gives the nodes that comprise each
face in the mesh.
FaceManager contains an upward pointing map that gives the elements that are connected
to a face.
The element data structure is significantly more complicated than the other Managers.
While the other managers are “flat” across the
MeshLevel, the element data structure seeks to provide
a hierarchy in order to define groupings of the physical problem, as well as collecting discretization of
At the top of the element branch of the hierarchy is the
ElementRegionManager holds a collection of instantiations of
ElementRegion are used to defined regions of the problem domain where a
PhysicsSolver will be applied.
CellElementRegionis related to all the polyhedra
FaceElementRegionis related to all the faces that have physical meaning in the domain, such as fractures and faults. This object should not be mistaken with the
FaceManagerhandles all the faces of the mesh, not only the faces of interest.
WellElementRegionis related to the well geometry.
ElementRegion also has a list of materials allocated at each quadrature point across the entire
One example of the utility of the
ElementRegion is the case of the simulation of the mechanics
and flow within subsurface reservoir with an overburden.
We could choose to have two
ElementRegion, one being the reservoir, and one for the
The mechanics solver would be applied to the entire problem, while the flow problem would be applied only
to the reservoir region.
ElementRegion holds some number of
ElementSubRegion is meant to hold all the element topologies present in an
in their own groups.
For instance, for a
CellElementRegion, there may be one
CellElementSubRegion for all
tetrahedra, one for all hexahedra, one for all wedges and one for all the pyramids (Fig. 89).