[MOAB-dev] commit/MOAB: 2 new changesets
commits-noreply at bitbucket.org
commits-noreply at bitbucket.org
Tue Jul 16 15:37:16 CDT 2013
2 new commits in MOAB:
https://bitbucket.org/fathomteam/moab/commits/f6aef30b0580/
Changeset: f6aef30b0580
Branch: None
User: danwu
Date: 2013-07-16 22:36:24
Summary: VarData:sz is now used by convert_variable(). However, this si=
ze indicator is not calculated for scd mesh yet, and the default value 0 ha=
s caused ParGAL test cases for Eulerian Spectral grid to fail.
Affected #: 1 file
diff --git a/src/io/NCHelper.cpp b/src/io/NCHelper.cpp
index 7b6216c..7d1a6c3 100644
--- a/src/io/NCHelper.cpp
+++ b/src/io/NCHelper.cpp
@@ -240,6 +240,7 @@ ErrorCode NCHelper::convert_variable(ReadNC::VarData& v=
ar_data, int tstep_num)
=20
// Get variable size
std::size_t sz =3D var_data.sz;
+ assert(sz > 0);
=20
// Finally, read into that space
int success =3D 0;
@@ -701,6 +702,12 @@ ErrorCode ScdNCHelper::read_scd_variable_to_nonset_all=
ocate(EntityHandle file_se
assert((unsigned)count =3D=3D range->size());
vdatas[i].varDatas[t] =3D data;
}
+
+ // Calculate variable size
+ std::size_t sz =3D 1;
+ for (std::size_t idx =3D 0; idx !=3D vdatas[i].readCounts[0].size(); i=
dx++)
+ sz *=3D vdatas[i].readCounts[0][idx];
+ vdatas[i].sz =3D sz;
}
=20
return rval;
https://bitbucket.org/fathomteam/moab/commits/fc9f0c4e8f51/
Changeset: fc9f0c4e8f51
Branch: master
User: danwu
Date: 2013-07-16 22:36:59
Summary: Merge branch 'master' of https://bitbucket.org/fathomteam/moab
Affected #: 5 files
diff --git a/configure.ac b/configure.ac
index 130e4a9..b642189 100644
--- a/configure.ac
+++ b/configure.ac
@@ -450,22 +450,20 @@ AC_SUBST(PNETCDF_LIBS)
##########################################################################=
#######
# Documentation
##########################################################################=
#######
-AC_ARG_ENABLE([doxygen],
-[AC_HELP_STRING([[--enable-doxygen@<:@=3DDIR@:>@]],[Specify directory wher=
e Doxygen program is installed])
-AC_HELP_STRING([--disable-doxygen],[Do not generate API documentation (def=
ault)])],
- [ENABLE_DOXYGEN=3D"$enableval"],[ENABLE_DOXYGEN=3D=
no] )
-if test "x$ENABLE_DOXYGEN" =3D "xyes"; then
+AC_ARG_ENABLE([docs],
+[AC_HELP_STRING([--enable-docs],[Specify directory where Doxygen program i=
s installed])
+AC_HELP_STRING([--disable-docs],[Do not generate API documentation (defaul=
t)])],
+ [ENABLE_DOCS=3D"$enableval"],[ENABLE_DOCS=3Dno] )
+if test "x$ENABLE_DOCS" !=3D "xno"; then
AC_PATH_PROG( [DOXYGEN], [doxygen], [no] )
-elif test "x$ENABLE_DOXYGEN" !=3D "xno"; then
- AC_PATH_PROG( [DOXYGEN], [doxygen], [no], [$ENABLE_DOXYGEN] )
fi
-if test "x$ENABLE_DOXYGEN" !=3D "xno"; then
+if test "x$ENABLE_DOCS" !=3D "xno"; then
if test "x$DOXYGEN" =3D "xno"; then
AC_MSG_ERROR("Doxygen executable not found.")
fi
fi
AC_SUBST([DOXYGEN])
-AM_CONDITIONAL([ENABLE_DOXYGEN],[test "x$ENABLE_DOXYGEN" !=3D "xno"])
+AM_CONDITIONAL([ENABLE_DOCS],[test "x$ENABLE_DOCS" !=3D "xno"])
=20
=20
##########################################################################=
######
diff --git a/doc/DG/moabDG.h b/doc/DG/moabDG.h
index 1091094..1724436 100644
--- a/doc/DG/moabDG.h
+++ b/doc/DG/moabDG.h
@@ -4,14 +4,6 @@
=20
\subpage dg-figures
=20
- \subpage dg-tables
-*/
-
-/*! \page dg-contents Table of Contents
-
- \subpage sequence-info
-
- \subpage meta-data-info
*/
=20
/*! \page dg-figures List of Figures
@@ -23,23 +15,8 @@
\ref figure3
*/
=20
-/*! \page dg-tables List of Tables
-
- \ref table1
-
- \ref table2
-
- \ref table3
-
- \ref table4
-
- \ref table5
-
- \ref table6
-
-*/
=20
-/*! \page sequence-info Sequence Info
+/*! \page dg-contents Table of Contents
=20
\ref sequence
=20
@@ -111,7 +88,7 @@ a feature. Sequences for which the corresponding data ca=
nnot be used to store
new entities (e.g. structured mesh discussed in a later section) will retu=
rn -1 or
some other invalid value.
=20
- \ref sequence-info "Top"
+ \ref dg-contents "Top"
=20
\section manager TypeSequenceManager & SequenceManager=20
=20
@@ -175,7 +152,7 @@ such as allocating the correct <I>EntitySequence</I> su=
btype for a given <I>Enti
=20
<sup>2</sup>Given rule four for the data managed by a <I>TypeSequenceManag=
er</I>, any <I>SequenceData</I> for which all handles are allocated will be=
referenced by exactly one <I>EntitySequence</I>.
=20
- \ref sequence-info "Top"
+ \ref dg-contents "Top"
=20
\section s-mesh Structured Mesh
=20
@@ -185,7 +162,7 @@ used to access the structured element connectivity. A s=
tandard <I>VertexSequence
instance is used to access the ScdVertexData because the vertex data stora=
ge
is the same as for unstructured mesh.
=20
- \ref sequence-info "Top"
+ \ref dg-contents "Top"
=20
\section sets Entity Sets
=20
@@ -281,814 +258,6 @@ downside of this solution is that it makes the implem=
entation a little less mod-
ular and maintainable because the existing logic contained in the <I>MeshS=
et</I> class
would need to be spread throughout the <I>MeshSetSequence</I> class.
=20
- \ref sequence-info "Top"
+ \ref dg-contents "Top"
*/
=20
-/*! \page meta-data-info I/O and Meta-Data Storage Conventions in MOAB
-
- <Center><H3> Timothy J. Tautges </H3></Center>
-
- \ref meta-introduction
-
- \ref meta-conventions
-
- \ref meta-options
-
- \ref meta-references
-
- \ref appendixA
-
- \ref appendixB
-
- \ref appendixC
-
- \ref appendixD
-
- \ref appendixE
-
- \section meta-introduction Introduction
-
-The Mesh-Oriented datABase (MOAB) is a library for representing finite ele=
ment and other types of mesh data [1]. Various types of meta-data are ofte=
n used in conjunction with a mesh. Examples include boundary condition gro=
upings, material types, and provenance information for the mesh. Because t=
he data model used in MOAB is so abstract, conventions are useful for descr=
ibing how meta-data is stored into that data model. This document describe=
s those conventions for several types of data commonly found in meshes stor=
ed in MOAB. Because the data models used by MOAB and iMesh, the ITAPS mesh=
interface [2], are so similar, the conventions described here apply almost=
unmodified to iMesh as well as to MOAB.
-
-The meshes represented in MOAB originate in a variety of forms, including =
mesh read from files of various formats (e.g. CUBIT =E2=80=9C.cub=E2=80=9D =
file, VTK, etc.) as well as mesh written into MOAB directly by various soft=
ware libraries (e.g. MeshKit). Although there is no standard for naming or=
storing meta-data with a mesh, there is a great deal of commonality in the=
types of meta-data typically found with mesh data. This document describe=
s conventions that have been established for commonly encountered meta-data=
. Various mesh readers implemented in MOAB attempt to read meta-data from =
a file and write it into the MOAB data model using these conventions. Alth=
ough there is no requirement to store a given type of meta-data in the form=
described here, a number of services have been written to handle meta-data=
using these conventions, no matter the source of the meta-data being proce=
ssed.
-
-Several specific tools are often used in concert with MOAB and bear specia=
l mention here. The CUBIT toolkit generates finite element meshes, and sav=
es them to a native save file (referred to as a =E2=80=9C.cub=E2=80=9D file=
) which MOAB is able to read. Reading CUBIT meshes into MOAB through the .=
cub file format is preferred over other formats, since most other mesh form=
ats written by CUBIT do not save most meta-data. The MeshKit library also =
generates mesh using CGM and MOAB, and uses the same conventions for storin=
g meshes into MOAB. Finally, MOAB includes a CGM reader which can read a g=
eometric model into a faceted representation in MOAB. Meta-data from all t=
hese tools are stored in MOAB using the conventions described here.=20
-
-The MOAB data model consists of the following basic types:
-- <B>Entity</B>: The basic elements of topology, e.g. vertex, edge, triang=
le, tetrahedron, etc. MOAB represents all types in the finite element zoo,=
plus polygons and polyhedra.
-- <B>Entity Set</B>: An arbitrary collection of entities and other sets. =
Sets can have parent/child relations with other sets, and these relations a=
re distinct from =E2=80=9Ccontains=E2=80=9D relations.
-- <B>Interface</B>: The interface object through which other entities are =
accessed, in the sense of object-oriented-programming. iMesh refers to the=
interface as the =E2=80=9Croot=E2=80=9D set.
-- <B>Tag</B>: A piece of data that can be assigned a distinct value to eac=
h entity and entity set, and to the interface itself. Tags have a prescrib=
ed name, size in bytes, and data type; allowed data types are integer, doub=
le, entity handle, and byte or opaque.
-.
-
-The following section describes each meta-data tag convention in detail; t=
hese conventions are also summarized in Table 1.
-
- \ref meta-data-info "Top"
-
- \section meta-conventions Meta-Data Conventions
-
-Meta-data is stored in MOAB and iMesh in the form of tags applied to eithe=
r entities or entity sets. For meta-data represented as entity sets, the c=
ontents of those sets are determined by the convention, with tags on those =
sets identifying them with the convention and adding any other semantic dat=
a.
-
-Each meta-data convention is described in a subsection below. Each conven=
tion begins with a short description of:
-- Whether tags associated with the convention are assigned to entities or =
entity sets
-- The tag(s) associated with the convention; information for each tag incl=
udes the name, the data type (I=3Dinteger, D=3Ddouble, C=3Dcharacter, H=3Dh=
andle), and the tag length. Tag lengths are specified after an asterisk (*=
); for example, C*32 implies a tag with character type and length 32. Unsp=
ecified lengths correspond to length one.
-.
-
-<H3>Name</H3>
-
-(Data: Entity sets, entities; Tag(s): NAME/C*32)
-
-Character strings are used in many different contexts in applications. MO=
AB uses the =E2=80=9CNAME=E2=80=9D tag to store character strings used to n=
ame entities. This tag is of byte-type and is of length 32 bytes. Note th=
at the string stored in this tag may or may not be terminated with a NULL c=
haracter. It is always prudent account for missing NULL terminator, to avo=
id buffer overflow errors in the application. Applications are free to def=
ine their own version of the NAME tag with a longer length, though this def=
inition may conflict with other services attempting to use this tag with th=
e conventional size. Applications needing a string tag with a longer or va=
riable length can also use MOAB=E2=80=99s variable-length tag type, though =
this will not be compatible with iMesh.
-
-<H3>Title </H3>
-
-(Data: Entity sets (file or instance); Tag(s): TITLE/C*strlen)
-
-The title tag is meant to hold the overall identifier of a mesh, written a=
t generation time or read from a file generated with a non-MOAB tool. The =
tag length is variable, and is set by the application directly (by calling =
the tag_create function) or indirectly (by embedding the title in a file re=
ad by MOAB).
-
-<H3> Global Identifier </H3>
-
-(Data: Entity sets, entities; Tag(s): GLOBAL_ID/I)
-
-Global identifiers are used in many different contexts in applications. G=
eometric model entities are identified by dimension and id, e.g. =E2=80=9CV=
olume 1=E2=80=9D. Mesh vertices and elements are identified similarly in m=
esh generation codes. Boundary conditions and material types are identifie=
d similarly. This tag is used to store such information. This tag is curr=
ently stored in a 32-byte integer, though this may change in the future.
-
-<H3> Geometric Model Information </H3>
-
-(Data: Entity sets; Tag(s): GEOM_DIMENSION/I, GLOBAL_ID/I, NAME/C*32, CATE=
GORY/C*32, GEOM_SENSE_2(EH[2]), GEOM_SENSE_N_ENTS(EH*N), GEOM_SENSE_N_SENSE=
S(I*N))
-
-Mesh generation is often performed starting from a geometric model, repres=
ented in some form of CAD engine. Many of the meshes used by MOAB are gene=
rated based on the CGM library. Geometric models contain both topological =
information (the topological entities in the geometric model) and shape inf=
ormation (the geometric shape of those entities), as well as other meta-dat=
a written to the entities in a model. When a mesh is read from a CUBIT .cu=
b file, meta-data from the geometric model is read and represented in the M=
OAB data model, as described below. <B> Note that although MOAB reads and r=
epresents meta-data associated with the geometric model, it does not repres=
ent the geometric model itself.</B> Therefore, shape-related information, =
e.g. the arc length of an edge or surface normal at a given point, can be r=
etrieved only from the model represented in CGM or another geometric modeli=
ng engine.
-
-The information contained in a geometric model, read into and represented =
in MOAB, consists of:
-- Model entities (vertex, edge, face, volume)
-- Topological relationships between model entities
-- Groups of model entities
-- Model entity/group ids
-- Model entity/group names
-.
-The storage of this information into MOAB's data model is described for ea=
ch type is described below.
-
-- <B>Entities </B>
-
-Entities in the geometric model (VERTEX, EDGE, FACE, VOLUME) are each repr=
esented by an entity set<sup>1</sup>. These sets are tagged with the =E2=
=80=9CGEOM_DIMENSION=E2=80=9D tag, with integer value equal to the topologi=
cal dimension of the entity (VERTEX =3D 0, EDGE =3D 1, etc.) These sets co=
ntain the mesh owned by the corresponding entity in the geometric model. N=
ote this does not include mesh owned by bounding entities; thus, the set fo=
r a FACE will not contain the mesh vertices owned by bounding EDGEs in the =
geometric model. These sets may or may not contain mesh entities of interm=
ediate dimension, e.g. mesh edges owned by a FACE or faces owned by a VOLUM=
E, depending on the application generating the mesh or the file from which =
the mesh was read. These sets are all set-types, i.e. the order of entitie=
s in the sets is not significant, except in the case of EDGE sets, where or=
der of the mesh vertices and edges corresponds to the relative order of ver=
tices and edges at the time of mesh generation. In MOAB, these sets are no=
n-tracking by default, i.e. entities do not have knowledge of which geometr=
y sets they are members of.
-
-<sup>1</sup>Body-type entities from CUBIT are not explicitly represented i=
n MOAB.
-
-- <B> Topological Relationships </B>
-
-In the geometric model, each FACE is bounded by zero or more EDGEs; other =
topological relationships between geometric entities exist in a similar man=
ner. These relationships are embedded in the data model using parent/child=
relations between entity sets. For example, the entity set corresponding =
to a FACE will have child sets, each corresponding to a bounding EDGE, and =
parent sets, each corresponding to a VOLUME bounded by that FACE. The rela=
tive order of sets in those parent/child lists is not significant, thus, =
=E2=80=9Cloops=E2=80=9D bounding a FACE cannot reliably be inferred from th=
is data.
-
-- <B> Groups </B>
-
-Geometric entities are sometimes assigned to application-specific groups. =
These groups are represented using entity sets, tagged with a =E2=80=9CGRO=
UP=E2=80=9D tag whose value equals the group id. Group sets are =E2=80=9Cs=
et=E2=80=9D-type, and are not tracking sets. These sets contain the sets c=
orresponding to geometric entities contained in the groups in the geometric=
model, as well as any mesh entities assigned to the group.
-
-<H4> Sense </H4>
-
-A geometric face has a natural orientation, indicated by the direction of =
the normal to the face; similarly, edges have a natural orientation determi=
ned by the direction of the tangent. When faces bound regions, or edges bo=
und faces, they do so with a sense; if a region includes a face with forwar=
d sense, that means the face's natural normal direction points out of the v=
olume. If a face includes an edge with forward sense, that means that if o=
ne moves along the edge in the direction of its tangent, the material of th=
e face is on the left hand side. The sense of a face (edge) with respect t=
o a region (face) it bounds is stored using tags on the face (edge).
-
-Most models allow a face to be part of only two regions. Therefore, to st=
ore the sense of a face with respect to regions including it, a tag with tw=
o values is used. This tag is named GEOM_SENSE_2, and has 2 EntityHandle v=
alues. The first value corresponds to the entity set for the region for wh=
ich that face has a forward sense, and the second to the region for which t=
hat face has a reverse sense.
-
-Edges can bound more than two faces. Therefore, two variable-length tags =
are used, one to store the EntityHandles of the faces the edge bounds, and =
the other to store the sense with which the edge bounds the corresponding f=
ace. These tags are named GEOM_SENSE_N_ENTS and GEOM_SENSE_N_SENSES, respe=
ctively. These are stored as variable-length tags; see the MOAB user's gui=
de for information on how to work with tags of this type.=20
-
-The following sense values are used:
-- 0: forward
-- 1: reverse
-- -1: unnknown
-
-<H3> Material Type </H3>
-
-(Data: Entity sets; Tag(s): MATERIAL_SET/I)
-
-Most finite element and other PDE-based analysis codes require a material =
type for each cell or element in the simulation. MOAB uses entity sets to =
store this information, in the form of entity sets. The MATERIAL_SET tag i=
s used to identify these sets. The value of this tag is conventionally an =
integer; in most cases this stores a user-assigned identifier associated wi=
th that material.=20
-
-CUBIT assigns material types using what it calls =E2=80=9Celement blocks=
=E2=80=9D, with each element block given a user-assigned id number and opti=
onally a name. The CUBIT and Exodus file readers in MOAB read element bloc=
ks into MATERIAL_SET sets. =20
-
-In CUBIT, materials are typically assigned by assigning geometric volumes =
to element blocks. Therefore, material sets often contain entity sets corr=
esponding to those volumes. Thus, a materrial set in MOAB is unlikely to c=
ontain mesh entities directly; rather, that set contains other sets which c=
ontain mesh entities. In these cases, mesh entities can be retrieved by pa=
ssing a =E2=80=9Crecursive=E2=80=9D flag to the appropriate function (MOAB)=
, or by calling the getEntitiesRec extension function (iMesh) provided by M=
OAB.
-
-<H3> Boundary Conditions (Dirichlet, Neumann)</H3>
-
-Data: Entity sets; Tag(s): DIRICHLET_SET/I, NEUMANN_SET/I)
-
-Boundary conditions are often specified in terms of geometric model entiti=
es, similar to material types. MOAB uses entity sets to store this informa=
tion as well. The DIRICHLET_SET and NEUMANN_SET tags are used to represent=
Dirichlet- and Neumann-type boundary condition sets, resp. By convention,=
Neumann sets usually contain (indirectly) intermediate-dimension entities =
like edges in a 2D mesh or faces in a 3D mesh, while Dirichlet sets usually=
contain vertices. In addition, Neumann sets are represented as sets of fa=
ces, rather than as sides of elements. Faces can be ordered =E2=80=9Cforwa=
rd=E2=80=9D or =E2=80=9Creverse=E2=80=9D with respect to one of the boundin=
g elements, depending on whether the right-hand normal points into or out o=
f the element. Forward-sense faces are added to the Neumann set. Reverse-=
sense faces are put into a separate set; that set is tagged with the NEUSET=
_SENSE tag, with value =3D -1; and that reverse set is added to the Neumman=
n set.
-
-<H3> Parallel Mesh Constructs </H3>
-
-(Data: Entity sets, entities; Tag(s): PARALLEL_PART/I, PARALLEL_PARTITION/=
I, PSTATUS/C*1, PARALLEL_SHARED_PROC/I, PARALLEL/SHARED_HANDLE/H, PARALLEL_=
SHARED_PROCS/I*NP, PARALLEL_SHARED_HANDLES/H*NP)
-
-On a parallel computer, MOAB can represent the mesh on each processor as w=
ell as information about entities shared with neighboring processors. Some=
of this information is also relevant even when the mesh is represented on =
a serial machine. MOAB uses several tag and set conventions to describe th=
e parallel nature of a mesh. This information is summarized here; for a mo=
re complete description of MOAB=E2=80=99s parallel mesh representation and =
functionality, see [ref-moabpar].
-
-- <B> Parallel partition, parts </B>
-
-Most parallel mesh applications use a domain decomposition approach, where=
each processor solves for a subset of the domain. The set of entities sol=
ved by a given processor is referred to as a part, and the collection of pa=
rts together is called the partition. MOAB stores each part in an entity s=
et, marked with the PARALLEL_PART tag, whose value is the rank of the proce=
ssor assigned that part; an entity set which contains all part sets is give=
n the PARALLEL_PARTITION tag, whose value is currently meaningless. The MB=
Zoltan tool included as a tool in MOAB can partition a mesh for parallel so=
lution, and writes the partition to the mesh in the form of parts and parti=
tions. Both these types of sets can be accessed in a serial mesh, e.g. for=
visualization.
-
-- <B> Part interfaces </B>
-
-When a partitioned mesh has been loaded on a parallel computer, the part o=
n a given processor may share portions of its boundary with parts on other =
processors. These shared regions are called part interfaces, and are also =
represented using entity sets. These sets are marked with the PARALLEL_INT=
ERFACE tag, whose value is currently meaningless.
-
-- <B> Shared processor and handle </B>
-
-For entities shared between processors, it is helpful to know locally whic=
h other processor shares an entity, and what the entity=E2=80=99s handle is=
on the remote processor. There are two cases which are useful to distingu=
ish, first where an entity is shared with only one other processor (referre=
d to as shared), and second when a processor is shared by more than one oth=
er processor (referred to as multi-shared). Shared entities are given the=
PARALLEL_SHARED_PROC and PARALLEL_SHARED_HANDLE tags, which store the rank=
of the sharing processor and the handle of the entity on that processor, r=
espectively. Multi-shared entities are marked with the PARALLEL_SHARED_PRO=
CS and PARALLEL_SHARED_HANDLES tags; these tags have a length NP assigned a=
t compile time in MOAB, with default values of -1 for processor rank and ze=
ro for handle (which are each invalid values for the corresponding data). =
The processors/handles sharing a given entity are then written on the front=
of the arrays. So, for example, an entity on processor rank 0, shared by =
processors 1 and 2, would have a PARALLEL_SHARED_PROCS tag whose values wou=
ld be [1, 2, -1, -1, =E2=80=A6], with PARALLEL_SHARED_HANDLES values of [m,=
n, 0, 0, =E2=80=A6], where m and n would be the handles of that entity on =
processors 1 and 2. The shared versions of these tags are =E2=80=9Cdense=
=E2=80=9D, with default values which denote unshared entities. The multi-s=
hared tags are sparse tags in MOAB, with no default value.
-
-- <B> Parallel status </B>
-
-In addition to the tags above, MOAB also defines the PSTATUS tag, whose bi=
ts contain information about the parallel status of a given entity. Starti=
ng with least significant bit, these bits represent whether an entity is 1)=
not owned, 2) shared, 3) multi-shared, 4) interface, 5) a ghost entity. T=
he first bit being set indicates =E2=80=9Cnot owned=E2=80=9D so that the de=
fault value for this tag, of zero, corresponds to an owned, unshared entity=
, which will be the state of most entities on a given processor.
-
-<H3>Structured Mesh Parameters </H3>
-
-MOAB has a structured mesh interface for creating structured mesh (see =E2=
=80=9CScdInterface.hpp=E2=80=9D header file in MOAB source code). Along wi=
th an internal representation that is more memory-efficient (since it does =
not need to store connectivity), MOAB also creates and tags entity sets wit=
h structured mesh parameters, which can be accessed through the normal tag =
and set interface. The following tags are used:
-- <B>BOX_DIMS</B>: This tag stores the ijk coordinates of the lower and up=
per corner of the structured mesh box(es).
-- <B>GLOBAL_BOX_DIMS</B>: If specified when the structured mesh is created=
, a tag with this name stores the global box dimensions (which may be diffe=
rent than the local box dimensions).
-- <B>BOX_PERIODIC</B>: Stores whether the box is periodic in the i (BOX_PE=
RIODIC[0]) and j (BOX_PERIODIC[1]) directions.
-- <B>__BOX_SET</B>: Pointer to the ScdBox instance corresponding to this e=
ntity set.<sup>2</sup>
-.
-Although the structured mesh is not saved as such in HDF5-format files, th=
e entity sets and corresponding tags will be saved and restored.
-
-<sup>2</sup>The double-underscore in the tag name implies that this tag wi=
ll not be saved in a file, in this case because the ScdBox instances are no=
t preserved in a file.
-
-<H3>Spectral Mesh Constructs </H3>
-
-The Spectral Element Method (SEM) is a high-order method, using a polynomi=
al Legendre interpolation basis with Gauss-Lobatto quadrature points, in co=
ntrast to the Lagrange basis used in (linear) finite elements. A spectral =
mesh with order O contains quadrilateral or hexahedral elements comprised o=
f (O+1)d vertices. Spectral meshes are usually represented in one of two w=
ays, either as coarse elements which point to an array of higher-order vert=
ices (and with corner vertices represented in the normal manner), or as lin=
ear quads/hexes formed from the higher-order vertices, with each original c=
oarse quad/hex represented by Od fine quads/hexes. Similarly, the spectral=
variables, which are normally computed at fine vertex positions, are store=
d either on those vertices, or in lexicographically-ordered arrays on eleme=
nts (with tag values repeated on neighboring elements). MOAB can read spec=
tral meshes from a variety of formats (at this time, including CAM-SE, HOMM=
E, and Nek5000). Which of the above two representations are controlled by =
read options and are indicated by certain tags:
-- SPECTRAL_MESH: read option indicating that spectral elements should be r=
epresented as coarse linear quads/hexes and each element containing an arra=
y of lexicographically-ordered vertex handles
-- TAG_SPECTRAL_ELEMENTS: read option; if given, spectral variables are rep=
resented as lexicographically-ordered arrays on elements
-- TAG_SPECTRAL_VERTICES: read option; if given, spectral variables are rep=
resented as tags on vertices
-- CONN=3D<filename>: in CAM-SE, the connectivity of the spectral mesh is s=
tored by default in a file named =E2=80=9CHommeMapping.nc=E2=80=9D; this op=
tion can be given to read the connectivity from a different file
-- SPECTRAL_VERTICES: tag name for array of vertex handles
-- SPECTRAL_ORDER: tag name for spectral order, written to file set or (if =
no file set given) to interface after a spectral mesh is read
-.
-
- \ref meta-data-info "Top"
-
- \section meta-options Reader/Writer Options
-
-All mesh file readers and writers in MOAB take an option string as an argu=
ment. By default, the semicolon (=E2=80=9C;=E2=80=9D) delimits individual =
options in the option string. Options used in multiple readers are describ=
ed in this section; the options enabled in specific readers/writers are des=
cribed in the corresponding appendix at the end of this document.
-
-<H3>variable=3D<var_name>[,...]</H3>
-
-By default, all field data stored with the mesh is read with the mesh, and=
stored as tags on the associated mesh entities. This option lists specifi=
c variables that should be read along with the mesh (note also the =E2=80=
=9Cnomesh=E2=80=9D option, described elsewhere in this document). The vari=
able name listed will be read into a tag with the same name. For time-depe=
ndent variables, the time step number will be appended to the variable name=
to form the tag name. If no =E2=80=9Ctimestep=E2=80=9D or =E2=80=9Ctimeva=
l=E2=80=9D option is given, all time steps will be read, resulting in sever=
al tags being created. If the =E2=80=9Cnomesh=E2=80=9D option is given, th=
e application must pass the entity set resulting from the original mesh rea=
d in to the function, that this set must contain the mesh read only from th=
at file. The mesh in the file is checked against the mesh in the set to ve=
rify that the two correspond. The special name =E2=80=9CMOAB_ALL_VARIABLES=
=E2=80=9D can be used to indicate that all variables should be read. Multi=
ple variable names can be specified, separated from each other by commas.
-
-<H3>nomesh </H3>
-
-Indicates that no mesh should be read from the file. This option is used =
in conjunction with the =E2=80=9Cvariable=3D=E2=80=9D option, to read varia=
bles and assign them as tags to a previously-read mesh. If this option is =
used, applications should pass an entity set to the read function, which sh=
ould contain the mesh previously read from the file.
-
-<H3>timestep=3D<step_number>[, ...] </H3>
-
-Read the time step number whose time value is equal to or greater than the=
specified time value, for the specified variable(s). Tag names for the va=
riable(s) will be formed by appending the time step number to the variable =
name. Multiple time step values can be specified, separated from each othe=
r by commas.
-
- \ref meta-data-info "Top"
-
- \section meta-references References
-
-[1] T.J. Tautges, R. Meyers, K. Merkley, C. Stimpson, and C. Ernst, MOAB: =
A Mesh-Oriented Database, Sandia National Laboratories, 2004.
-
-[2] L. Diachin, A. Bauer, B. Fix, J. Kraftcheck, K. Jansen, X. Luo, M. Mil=
ler, C. Ollivier-Gooch, M.S. Shephard, T. Tautges, and H. Trease, =E2=80=9C=
Interoperable mesh and geometry tools for advanced petascale simulations,=
=E2=80=9D Journal of Physics: Conference Series, vol. 78, 2007, p. 012015.
-
-\ref meta-data-info "Top"
-
- \section appendixA Appendix A: Summary
-
- \subsection table1 Table 1: Summary of MOAB meta-data conventions.
-
-<table border=3D"1">
-<tr>
-<th>Convention</th>
-<th>Applies to (E=3Dent, S=3Dset)</th>
-<th>Tag(s) (type/length)</th>
-<th>Description</th>
-</tr>
-<tr>
-<td>Name</td>
-<td>E, S</td>
-<td>NAME/C*32</td>
-<td></td>
-</tr>
-<tr>
-<td>Title</td>
-<td>S</td>
-<td>TITLE/C*strlen</td>
-<td>Title of mesh</td>
-</tr>
-<tr>
-<td>Global identifier</td>
-<td>E, S</td>
-<td>GLOBAL_ID/I</td>
-<td></td>
-</tr>
-<tr>
-<td>Geometric topology</td>
-<td>S</td>
-<td>GEOM_DIMENSION/I, GLOBAL_ID/I,
-NAME/C*32,
-CATEGORY/C*32.
-GEOM_SENSE_2/EH[2],
-GEOM_SENSE_N_ENTS/EH*N,
-GEOM_SENSE_N_SENSES/I*N</td>
-<td>Sets contain mesh owned by that entity; parent/child links to bounded/=
bounding entities in geometric model</td>
-</tr>
-<tr>
-<td>Material type</td>
-<td>S</td>
-<td>MATERIAL_SET/I</td>
-<td>Set contains entities or sets assigned a common material type</td>
-</tr>
-<tr>
-<td>Boundary condition</td>
-<td>S</td>
-<td>DIRICHLET_SET/I, NEUMANN_SET/I</td>
-<td>Set contains entities or sets assigned a particular boundary condition=
; neumann sets usually contain edges (2D) or faces (3D)</td>
-</tr>
-<tr>
-<td>Parallel mesh constructs</td>
-<td>E, S</td>
-<td>PARALLEL_PART/I, PARALLEL_PARTITION/I, PSTATUS/C*1, PARALLEL_SHARED_PR=
OC/I, PARALLEL/SHARED_HANDLE/H, PARALLEL_SHARED_PROCS/I*NP, PARALLEL_SHARED=
_HANDLES/H*NP</td>
-<td> Data which describes parallel mesh</td>
-</tr>
-<tr>
-<td>Structured mesh constructs</td>
-<td>S</td>
-<td>BOX_DIMS/I*6, GLOBAL_BOX_DIMS/I*6, BOX_PERIODIC/2*I, __BOX_SET/O</td>
-<td>Data describing structured mesh </td>
-</tr>
-<tr>
-<td>Spectral mesh constructs </td>
-<td>E, S</td>
-<td>SPECTRAL_ORDER/I, SPECTRAL_VERTICES/I*(O+1)^2</td>
-<td>Data marking spectral mesh constructs</td>
-</tr>
-</table>
-=20
- \ref meta-introduction "Back to Introduction"
-
- \subsection table2 Table 2: Summary of MOAB conventional tag names, type=
s, and purposes. Data types are I=3Dinteger, D=3Ddouble, C=3Dcharacter, H=
=3Dentity handle,O=3Dopaque. Data type with *x denote length of x elements=
of that data type.
-
-<Table border=3D"1">
-<tr>
-<th>Tag name</th>
-<th>Data type</th>
-<th>Applies to (E=3Dentity, S=3Dset)</th>
-<th>Purpose</th>
-</tr>
-<tr>
-<td>BOX_DIMS</td>
-<td>I*6</td>
-<td>S</td>
-<td>Lower and upper ijk dimensions of box, ordered (ilo, jlo, klo, ihi, jh=
i, khi)</td>
-</tr>
-<tr>
-<td>BOX_PERIODIC</td>
-<td>I*2</td>
-<td>S</td>
-<td>Indicates whether box is periodic in i (BOX_PERIODIC[0]) or j (BOX_PER=
IODIC[1])</td>
-</tr>
-<tr>
-<td>__BOX_SET</td>
-<td>O</td>
-<td>S</td>
-<td>Pointer to corresponding ScdBox instance</td>
-</tr>
-<tr>
-<td>CATEGORY</td>
-<td>C*32</td>
-<td>S</td>
-<td>String describing purpose of set; examples include =E2=80=9Cgroup=E2=
=80=9D, =E2=80=9Cvertex=E2=80=9D, =E2=80=9Cedge=E2=80=9D, =E2=80=9Csurface=
=E2=80=9D, =E2=80=9Cvolume=E2=80=9D</td>
-</tr>
-<tr>
-<td>DIRICHLET_SET </td>
-<td>I</td>
-<td>SO</td>
-<td>Entities or sets with common boundary condition</td>
-</tr>
-<tr>
-<td>GEOM_DIMENSION</td>
-<td>I</td>
-<td>S</td>
-<td>Identifies mesh entities resolving a given geometric model entity</td>
-</tr>
-<tr>
-<td>GEOM_SENSE_2</td>
-<td>EH*2</td>
-<td>S</td>
-<td> Stored on face-type geometric topology sets, values store regions hav=
ing forward and reverse sense</td>
-</tr>
-<tr>
-<td>GEOM_SENSE_N_ENTS</td>
-<td>EH*N</td>
-<td>S</td>
-<td>Stored on edge-type geometric topology sets, values store faces whose =
senses are stored in GEOM_SENSE_N_SENSES.</td>
-</tr>
-<tr>
-<td>GEOM_SENSE_N_SENSES</td>
-<td>I*N</td>
-<td>S</td>
-<td>Stored on edge-type geometric topology sets, values store senses of th=
e edge with respect to faces stored in GEOM_SENSE_N_ENTS.</td>
-</tr>
-<tr>
-<td>GLOBAL_ID</td>
-<td>I</td>
-<td>E,S</td>
-<td>Application-specific entity id</td>
-</tr>
-<tr>
-<td>MATERIAL_SET</td>
-<td>I</td>
-<td>S</td>
-<td>Entities or sets grouped by material type</td>
-</tr>
-<tr>
-<td>NAME</td>
-<td>C*32</td>
-<td>E, S</td>
-<td>User-assigned entity name(s); multiple names delimited with ?</td>
-</tr>
-<tr>
-<td>NEUMANN_SET</td>
-<td>I</td>
-<td>S</td>
-<td>Entities or sets with common boundary condition </td>
-</tr>
-<tr>
-<td>PARALLEL_PART </td>
-<td>I</td>
-<td>S</td>
-<td>Represent a part in a partition</td>
-</tr>
-<tr>
-<td>PARALLEL_PARTITION</td>
-<td>I</td>
-<td>S</td>
-<td>Represents a partition of the mesh for parallel solution, which is a c=
ollection of parts</td>
-</tr>
-<tr>
-<td>__PARALLEL_SHARED_HANDLEd</td>
-<td>H</td>
-<td>E, S</td>
-<td> Handle of this entity/set on sharing processor</td>
-</tr>
-<tr>
-<td>__PARALLEL_SHARED_PROC</td>
-<td>I</td>
-<td>E,S</td>
-<td>Rank of other processor sharing this entity/set </td>
-</tr>
-</table>
-
-\ref meta-data-info "Top"
-
- \section appendixB Appendix B: CCMIO (Star-CD, Star-CCM+) Reader/Writer =
Conventions
-
- \subsection table3 Table 3: Translation between CCMIO options and MOAB t=
ags.
-<Table border=3D"1">
-<tr>
-<th> Set Type</th>
-<th>CCMIO Construct</th>
-<th>MOAB Tag Name, Type</th>
-</tr>
-<tr>
-<td rowspan=3D"2">File set / Interface</td>
-<td>Title (option)</td>
-<td>=E2=80=9CTitle=E2=80=9D (C*32)</td>
-</tr>
-<tr>
-<td>CreatingProgram</td>
-<td>=E2=80=9CCreatingProgram=E2=80=9D (C*32)</td>
-</tr>
-<tr>
-<td rowspan=3D"13">Material sets</td>
-<td>Index</td>
-<td>MATERIAL_SET</td>
-</tr>
-<tr>
-<td>Label<sup>1</sup></td>
-<td>NAME</td>
-</tr>
-<tr>
-<td>MaterialId</td>
-<td>=E2=80=9CMaterialId=E2=80=9D (I)</td>
-</tr>
-<tr>
-<td>Radiation</td>
-<td>=E2=80=9CRadiation=E2=80=9D (I)</td>
-</tr>
-<tr>
-<td>PorosityId</td>
-<td>=E2=80=9CPorosityId=E2=80=9D (I)</td>
-</tr>
-<tr>
-<td>SpinId</td>
-<td>=E2=80=9CSpinId=E2=80=9D (I)</td>
-</tr>
-<tr>
-<td>GroupId</td>
-<td>=E2=80=9CGroupId=E2=80=9D (I)</td>
-</tr>
-<tr>
-<td>ColorIdx</td>
-<td>=E2=80=9CColorIdx=E2=80=9D (I)</td>
-</tr>
-<tr>
-<td>ProcessorId</td>
-<td>=E2=80=9CProcessorId=E2=80=9D (I)</td>
-</tr>
-<tr>
-<td>LightMaterial</td>
-<td>=E2=80=9CLightMaterial=E2=80=9D (I)</td>
-</tr>
-<tr>
-<td>FreeSurfaceMaterial</td>
-<td>=E2=80=9CThickness=E2=80=9D (F)</td>
-</tr>
-<tr>
-<td>Thickness</td>
-<td>=E2=80=9CThickness=E2=80=9D (F)</td>
-</tr>
-<tr>
-<td>MaterialType</td>
-<td>=E2=80=9CMaterialType=E2=80=9D (C*32)</td>
-</tr>
-<tr>
-<td rowspan=3D"5">Neumann sets</td>
-<td>Index</td>
-<td>NEUMANN_SET</td>
-</tr>
-<tr>
-<td>Label</td>
-<td>NEUMANN_SET</td>
-</tr>
-<tr>
-<td>BoundaryName</td>
-<td>NAME</td>
-</tr>
-<tr>
-<td>BoundaryType</td>
-<td>=E2=80=9CBoundaryType=E2=80=9D (C*32)</td>
-</tr>
-<tr>
-<td>ProstarRegionNumber</td>
-<td>=E2=80=9CProstarRegionNumber=E2=80=9D (I)</td>
-</tr>
-</table>
-
-Notes:
-1. If no name is present, labels the material group with =E2=80=9CMaterial=
X=E2=80=9D, where X is the index of that group.
-
-\ref meta-data-info "Top"
-
- \section appendixC Appendix C: ExodusII Reader/Writer Conventions=20
-
- \subsection table4 Table 4: Translation between ExodusII constructs and =
MOAB tags.
-<Table border=3D"1">
-<tr>
-<th> Data Type</th>
-<th>ExodusII Construct</th>
-<th>MOAB Tag Name, Type</th>
-</tr>
-<tr>
-<td></td>
-<td>QA records</td>
-<td>=E2=80=9CqaRecord=E2=80=9D (C*(v))<sup>2</sup></td>
-</tr>
-<tr>
-<td rowspan=3D"2">Material sets</td>
-<td>Block number</td>
-<td>MATERIAL_SET</td>
-</tr>
-<tr>
-<td>Block element type</td>
-<td>Entity type, # vertices per entity</td>
-</tr>
-<tr>
-<td rowspan=3D"2">Dirichlet sets<sup>3</sup></td>
-<td>Nodeset number</td>
-<td>DIRICHLET_SET</td>
-</tr>
-<tr>
-<td>Distribution factors</td>
-<td>=E2=80=9CdistFactor=E2=80=9D (D*(v))<sup>1</sup></td>
-</tr>
-<tr>
-<td>Neumann sets</td>
-<td>Sideset number</td>
-<td>NEUMANN_SET</td>
-</tr>
-<tr>
-<td rowspan=3D"2">Neumann sets, reverse faces3<sup>3</sup></td>
-<td>Distribution factors</td>
-<td>=E2=80=9CdistFactor=E2=80=9D (D*(v))<sup>1</sup></td>
-</tr>
-<tr>
-<td>Sides</td>
-<td>SENSE</td>
-</tr>
-<tr>
-<td>Nodes, elements</td>
-<td>node_num_map, elem_map</td>
-<td>GLOBAL_ID on nodes/elements</td>
-</tr>
-</table>
-
-Notes:
--# Variable-length tag used for distribution factors; length for each set =
is the number of entities in
-each set, such that there is one distribution factor for each entity in th=
e set.
--# QA records are stored as variable-length tags on file set specified on =
read. Tag is a
-concatenation of QA record strings into a single string, with '\0' used to=
delimit lines.
--# MOAB represents sidesets as sets of faces, rather than as sides of elem=
ents. Faces can be
-ordered =E2=80=9Cforward=E2=80=9D or =E2=80=9Creverse=E2=80=9D with respec=
t to one of the bounding elements, depending on
-whether the right-hand normal points into or out of the element. Forward-s=
ense faces are added
-to the Neumann set. Reverse-sense faces are put into a separate set; that =
set is tagged with the SENSE tag, with value =3D -1; and that reverse set i=
s added to the Neummann set.
-.
-
- \ref meta-data-info "Top"
-
- \section appendixD Appendix D: NC (Climate Data) Reader/Writer Conventio=
ns
-
-The climate data reader in MOAB reads files with the '.nc' filename extens=
ion. By default, this reader
-reads the whole mesh in the file and creates it as structured mesh in MOAB=
, with the mesh accessible
-through MOAB's structured mesh interface. By default, all variables and ti=
mesteps are read from the
-file, and written as tags on the mesh vertices from that file. This behavi=
or is controlled by the
-=E2=80=9Cvariable=E2=80=9D, =E2=80=9Cnomesh=E2=80=9D, =E2=80=9Ctimestep=E2=
=80=9D, and =E2=80=9Ctimeval=E2=80=9D options described earlier in this doc=
ument. If MOAB
-is compiled for parallel execution and configured with a pnetcdf reader, t=
he mesh is read in parallel,
-with a 1D or 2D decomposition designed to balance read performance and com=
munication interface
-size (for details on the partitioning method used, see the src/io/ReadNC.c=
pp source file).
-
-Mesh is put into the entity set provided to the load_file function. This e=
ntity set is also annotated with
-various tags representing information read from the file. These tags are d=
escribed in Table 5.
-
-Several other things to note about reading climate data files into MOAB:
-- Time-dependent variables: MOAB currently has no mechanism for time-depen=
dent tags. Therefore, time-dependent variables are represented using one ta=
g per timestep, with the tag name set as the variable name plus the timeste=
p index. Thus, the first few timesteps for the variable TEMPERATURE would b=
e represented in tags named TEMPERATURE0, TEMPERATURE1, etc.
-- Cell- and face-centered variables: The climate data reader currently doe=
s not do cell- and face-
-centered variables correctly.
-.
- \subsection table5 Table 5: Summary of MOAB conventional tag names, type=
s, and purposes. Data types are I=3Dinteger, D=3Ddouble, C=3Dcharacter, H=
=3Dentity handle. Data type with *x denote length of x elements of that dat=
a type; data type with *var denote variable-length tag. Tag names with two =
underscores prepended (=E2=80=9C__=E2=80=9D) denote tags not written to a f=
ile by MOAB.
-
-<Table border=3D"1">
-<tr>
-<th> Tag name </th>
-<th>Data type </th>
-<th> Applies to (E=3Dentity, S=3Dset) </th>
-<th>Purpose </th>
-</tr>
-<tr>
-<td>__NUM_DIMS </td>
-<td>I</td>
-<td>S</td>
-<td>The number of dimensions in the netcdf file.</td>
-</tr>
-<tr>
-<td>__NUM_VARS</td>=20
-<td>I</td>
-<td>S</td>
-<td>The number of variables in the netcdf file.</td>
-</tr>
-<tr>
-<td>__DIM_NAMES </td>
-<td>C*var </td>
-<td>S </td>
-<td>The dimension names, concatenated into a
-character string, with '\0' terminating each name.
- </td>
-</tr>
-<tr>
-<td>__DIM_NAMES=20
-</td>
-<td>C*var</td>
-<td>S</td>
-<td>The variable names, concatenated into a character
-string, with '\0' terminating each name.
-</td>
-</tr>
-<tr>
-<td><dim_name>=20
-</td>
-<td>(I or=20
-D)*va=20
-</td>
-<td>S</td>
-<td>For each dimension, the values for the dimension.
-The data type for this tag corresponds to that in the
-netcdf file. The length of this tag is the number of
-values stored for the dimension in the netcdf file.</td>
-</tr>
-<tr>
-<td>__<dim_name>_LOC_MIN MAX</td>=20
-<td>2*(I or D)</td>
-<td>S</td>
-<td>The indices (0-based) of the local min and max
-values of dimension stored locally. For spatial
-dimensions like lon or lat, this will store the
-minimum and maximum indices in the loca</td>
-</tr>
-<tr>
-<td >__<dim_name>_LOC_VAL </td>=20
-<td>(I or D)*var </td>
-<td>S</td>
-<td>The indices (0-based) of the dimension stored
-locally. This tag only makes sense for dimensions
-that can be read in multiple pieces, such as time.
-Only one of __<dim_name>_LOC_VALS and
-_LOC_MIN_MAX can be used for a given
-dimension.
-</tr>
-<tr>
-<td>__<var_name>_DIMS=20
-</td>
-<td>C*n=20
-</td>
-<td>S</td>
-<td>For each variable, the tag handles for the
-dimensions defining this variable, in netcdf
-ordering (last dimension varying fastest). The
-length of this tag, n, is # dimensions for the
-variable * sizeof(TagHandle).
-</td>
-</tr>
-<tr>
-<td><var_name><timestep_ind>=20
-</td>
-<td>(data type)</td>
-<td>E</td>
-<td>Values of the variable for timestep <timestep_ind>
-for vertices. The data type of this tag corresponds
-to that of the variable from the netcdf file.
-Timestep index is 0-based.
-</td>
-</tr>
-<tr>
-<td>__GLOBAL_ATTRIBS=20
-</td>
-<td>C*Var=20
-</td>
-<td>S</td>
-<td>The global attributes, concatenated into a character
-string, with =E2=80=98\0=E2=80=99 terminating each attribute name, =E2=80=
=98;=E2=80=99
- separating the data type and value, and =E2=80=98;=E2=80=99
- separating one name/data type/value from the next.
-</td>
-</tr>
-<tr>
-<td>__GLOBAL_ATTRIBS_LEN=20
-</td>
-<td>I*Var=20
-</td>
-<td>S</td>
-<td>A vector of integers, marking the end position of
-each attribute (name/data type/value) in __GLOBAL_ATTRIBS tag.
-</td>
-</tr>
-<tr>
-<td>__<var_name>_ATTRIBS=20
-</td>
-<td>C*Var
-</td>
-<td>S</td>
-<td>The variable attributes, concatenated into a
-character string, with =E2=80=98\0=E2=80=99 terminating each attribute
- name, =E2=80=98;=E2=80=99 separating the data type and value, and =E2=
=80=98;=E2=80=99
- separating one name/data type/value from the next.
-</td>
-</tr>
-<tr>
-<td>__<var_name>_ATTRIBS_LEN=20
-</td>
-<td>I*Var
-</td>
-<td>S</td>
-<td>A vector of integers, marking the end position of
-each attribute (name/data type/value) in
-__<var_name>_ATTRIBS tags
-</td>
-</tr>
-</table>
-
- \ref meta-data-info "Top"
-
- \section appendixE Appendix E: Nek5000 Reader/Writer Conventions
-
-Nek5000, or Nek, is a code that uses the spectral element method to model =
fluid, heat transfer,
-electromagnetics, and other physics. Nek uses unstructured hexahedral mesh=
es, with each hex element
-resolved by a structured grid of =E2=80=9CGauss Lebato Legendre=E2=80=9D (=
GLL) points. Nek can read meshes through
-MOAB, and can output physics variables and GLL points through MOAB as well.
-
-Since fluid is a single material in Nek, no material sets are needed. Boun=
dary conditions are mapped to
-Nek's cbc array using Neumann sets and a user-provided =E2=80=9Cusr_moab2n=
ek=E2=80=9D subroutine (for an example
-of this subroutine, see examples/moab/pipe.usr in the Nek source code). GL=
L point locations and fluid
-variables on those points are stored in tags on the hex elements. All hex =
elements have the same
-number of GLL points. The number of GLL points in each direction is stored=
in a tag on the mesh
-instance. These tags are described in Table 6.
-
-GLL point locations and fluid variables are stored in lexicographic order,=
similar to their storage order
-inside the Nek code.
-
- \subsection table6 Table 6: Summary of MOAB conventional tag names, type=
s, and purposes for Nek. Data types are I=3Dinteger, D=3Ddouble, C=3Dcharac=
ter, H=3Dentity handle. Data type with *x denote length of x elements of th=
at data type; data type with *var denote variable-length tag. Tag names wit=
h two underscores prepended (=E2=80=9C__=E2=80=9D) denote tags not written =
to a file by MOAB.
-<Table border=3D"1">
-<tr>
-<th> Tag name </th>
-<th> Data Type</th>
-<th>Applies to (E=3Dentity, S=3Dset)</th>
-<th>Purpose</th>
-</tr>
-<tr>
-<td>SEM_DIMS</td>
-<td>I*3</td>
-<td>S</td>
-<td>The dimensions of the GLL mesh in each hex
-element.
-</td>
-</tr>
-<tr>
-<td>SEM_X</td>
-<td>D*nx*ny*nz</td>
-<td>E</td>
-<td>X position of GLL points (having nx*ny*nz
-values)
-</td>
-</tr>
-<tr>
-<td>SEM_Y</td>
-<td>D*nx*ny*nz</td>
-<td>E</td>
-<td>Y position of GLL points (having nx*ny*nz values)</td>
-</tr>
-<tr>
-<td>SEM_Z</td>
-<td>D*nx*ny*nz</td>
-<td>E</td>
-<td>Z position of GLL points (having nx*ny*nz values)</td>
-</tr>
-<tr>
-<td>VEL_X</td>
-<td>D*nx*ny*nz</td>
-<td>E</td>
-<td>Fluid velocities in the x direction for GLL point
-array (having nx*ny*nz values)</td>
-</tr>
-<tr>
-<td>VEL_Y</td>
-<td>D*nx*ny*nz</td>
-<td>E</td>
-<td>Fluid velocities in the y direction for GLL point
-array (having nx*ny*nz values)</td>
-</tr>
-<tr>
-<td>VEL_Z</td>
-<td>D*nx*ny*nz</td>
-<td>E</td>
-<td>Fluid velocities in the z direction for GLL point
-array (having nx*ny*nz values)</td>
-</tr>
-<tr>
-<td>TEMP</td>
-<td>D*nx*ny*nz</td>
-<td>E</td>
-<td>Fluid temperature for GLL point array (having
-nx*ny*nz values)
-</td>
-</tr>
-<tr>
-<td>PRESS</td>
-<td>D*nx*ny*nz</td>
-<td>E</td>
-<td>Fluid pressure for GLL point array (having
-nx*ny*nz values)
-</td>
-</tr>
-</table>
- \ref meta-data-info "Top"
- */
diff --git a/doc/MetaData/metadata.h b/doc/MetaData/metadata.h
new file mode 100644
index 0000000..5f53ecc
--- /dev/null
+++ b/doc/MetaData/metadata.h
@@ -0,0 +1,835 @@
+/*! \page metadata I/O and Meta-Data Storage Conventions in MOAB
+
+ <Center><H3> Timothy J. Tautges </H3></Center>
+
+ \subpage md-contents
+
+ \subpage md-tables
+*/
+
+/*! \page md-contents Table of Contents
+
+ \ref meta-introduction
+
+ \ref meta-conventions
+
+ \ref meta-options
+
+ \ref meta-references
+
+ \ref appendixA
+
+ \ref appendixB
+
+ \ref appendixC
+
+ \ref appendixD
+
+ \ref appendixE
+
+ \section meta-introduction Introduction
+
+The Mesh-Oriented datABase (MOAB) is a library for representing finite ele=
ment and other types of mesh data [1]. Various types of meta-data are ofte=
n used in conjunction with a mesh. Examples include boundary condition gro=
upings, material types, and provenance information for the mesh. Because t=
he data model used in MOAB is so abstract, conventions are useful for descr=
ibing how meta-data is stored into that data model. This document describe=
s those conventions for several types of data commonly found in meshes stor=
ed in MOAB. Because the data models used by MOAB and iMesh, the ITAPS mesh=
interface [2], are so similar, the conventions described here apply almost=
unmodified to iMesh as well as to MOAB.
+
+The meshes represented in MOAB originate in a variety of forms, including =
mesh read from files of various formats (e.g. CUBIT =E2=80=9C.cub=E2=80=9D =
file, VTK, etc.) as well as mesh written into MOAB directly by various soft=
ware libraries (e.g. MeshKit). Although there is no standard for naming or=
storing meta-data with a mesh, there is a great deal of commonality in the=
types of meta-data typically found with mesh data. This document describe=
s conventions that have been established for commonly encountered meta-data=
. Various mesh readers implemented in MOAB attempt to read meta-data from =
a file and write it into the MOAB data model using these conventions. Alth=
ough there is no requirement to store a given type of meta-data in the form=
described here, a number of services have been written to handle meta-data=
using these conventions, no matter the source of the meta-data being proce=
ssed.
+
+Several specific tools are often used in concert with MOAB and bear specia=
l mention here. The CUBIT toolkit generates finite element meshes, and sav=
es them to a native save file (referred to as a =E2=80=9C.cub=E2=80=9D file=
) which MOAB is able to read. Reading CUBIT meshes into MOAB through the .=
cub file format is preferred over other formats, since most other mesh form=
ats written by CUBIT do not save most meta-data. The MeshKit library also =
generates mesh using CGM and MOAB, and uses the same conventions for storin=
g meshes into MOAB. Finally, MOAB includes a CGM reader which can read a g=
eometric model into a faceted representation in MOAB. Meta-data from all t=
hese tools are stored in MOAB using the conventions described here.
+
+The MOAB data model consists of the following basic types:
+- <B>Entity</B>: The basic elements of topology, e.g. vertex, edge, triang=
le, tetrahedron, etc. MOAB represents all types in the finite element zoo,=
plus polygons and polyhedra.
+- <B>Entity Set</B>: An arbitrary collection of entities and other sets. =
Sets can have parent/child relations with other sets, and these relations a=
re distinct from =E2=80=9Ccontains=E2=80=9D relations.
+- <B>Interface</B>: The interface object through which other entities are =
accessed, in the sense of object-oriented-programming. iMesh refers to the=
interface as the =E2=80=9Croot=E2=80=9D set.
+- <B>Tag</B>: A piece of data that can be assigned a distinct value to eac=
h entity and entity set, and to the interface itself. Tags have a prescrib=
ed name, size in bytes, and data type; allowed data types are integer, doub=
le, entity handle, and byte or opaque.
+.
+
+The following section describes each meta-data tag convention in detail; t=
hese conventions are also summarized in Table 1.
+
+\ref md-contents "Top"
+
+ \section meta-conventions Meta-Data Conventions
+
+Meta-data is stored in MOAB and iMesh in the form of tags applied to eithe=
r entities or entity sets. For meta-data represented as entity sets, the c=
ontents of those sets are determined by the convention, with tags on those =
sets identifying them with the convention and adding any other semantic dat=
a.
+
+Each meta-data convention is described in a subsection below. Each conven=
tion begins with a short description of:
+
+- Whether tags associated with the convention are assigned to entities or =
entity sets
+- The tag(s) associated with the convention; information for each tag incl=
udes the name, the data type (I=3Dinteger, D=3Ddouble, C=3Dcharacter, H=3Dh=
andle), and the tag length. Tag lengths are specified after an asterisk (*=
); for example, C*32 implies a tag with character type and length 32. Unsp=
ecified lengths correspond to length one.
+.
+
+<H3>Name</H3>
+(Data: Entity sets, entities; Tag(s): NAME/C*32)
+
+Character strings are used in many different contexts in applications. MO=
AB uses the =E2=80=9CNAME=E2=80=9D tag to store character strings used to n=
ame entities. This tag is of byte-type and is of length 32 bytes. Note th=
at the string stored in this tag may or may not be terminated with a NULL c=
haracter. It is always prudent account for missing NULL terminator, to avo=
id buffer overflow errors in the application. Applications are free to def=
ine their own version of the NAME tag with a longer length, though this def=
inition may conflict with other services attempting to use this tag with th=
e conventional size. Applications needing a string tag with a longer or va=
riable length can also use MOAB=E2=80=99s variable-length tag type, though =
this will not be compatible with iMesh.
+
+<H3>Title </H3>
+(Data: Entity sets (file or instance); Tag(s): TITLE/C*strlen)
+
+The title tag is meant to hold the overall identifier of a mesh, written a=
t generation time or read from a file generated with a non-MOAB tool. The =
tag length is variable, and is set by the application directly (by calling =
the tag_create function) or indirectly (by embedding the title in a file re=
ad by MOAB).
+
+<H3> Global Identifier </H3>
+(Data: Entity sets, entities; Tag(s): GLOBAL_ID/I)
+
+Global identifiers are used in many different contexts in applications. G=
eometric model entities are identified by dimension and id, e.g. =E2=80=9CV=
olume 1=E2=80=9D. Mesh vertices and elements are identified similarly in m=
esh generation codes. Boundary conditions and material types are identifie=
d similarly. This tag is used to store such information. This tag is curr=
ently stored in a 32-byte integer, though this may change in the future.
+
+<H3> Geometric Model Information </H3>
+(Data: Entity sets; Tag(s): GEOM_DIMENSION/I, GLOBAL_ID/I, NAME/C*32, CATE=
GORY/C*32, GEOM_SENSE_2(EH[2]), GEOM_SENSE_N_ENTS(EH*N), GEOM_SENSE_N_SENSE=
S(I*N))
+
+Mesh generation is often performed starting from a geometric model, repres=
ented in some form of CAD engine. Many of the meshes used by MOAB are gene=
rated based on the CGM library. Geometric models contain both topological =
information (the topological entities in the geometric model) and shape inf=
ormation (the geometric shape of those entities), as well as other meta-dat=
a written to the entities in a model. When a mesh is read from a CUBIT .cu=
b file, meta-data from the geometric model is read and represented in the M=
OAB data model, as described below. <B> Note that although MOAB reads and r=
epresents meta-data associated with the geometric model, it does not repres=
ent the geometric model itself.</B> Therefore, shape-related information, =
e.g. the arc length of an edge or surface normal at a given point, can be r=
etrieved only from the model represented in CGM or another geometric modeli=
ng engine.
+
+The information contained in a geometric model, read into and represented =
in MOAB, consists of:
+- Model entities (vertex, edge, face, volume)
+- Topological relationships between model entities
+- Groups of model entities
+- Model entity/group ids
+- Model entity/group names
+.
+
+The storage of this information into MOAB's data model is described for ea=
ch type is described below.
+
+- <B>Entities </B>
+
+ in the geometric model (VERTEX, EDGE, FACE, VOLUME) are each represented =
by an entity set<sup>1</sup>. These sets are tagged with the =E2=80=9CGEOM=
_DIMENSION=E2=80=9D tag, with integer value equal to the topological dimens=
ion of the entity (VERTEX =3D 0, EDGE =3D 1, etc.) These sets contain the =
mesh owned by the corresponding entity in the geometric model. Note this d=
oes not include mesh owned by bounding entities; thus, the set for a FACE w=
ill not contain the mesh vertices owned by bounding EDGEs in the geometric =
model. These sets may or may not contain mesh entities of intermediate dim=
ension, e.g. mesh edges owned by a FACE or faces owned by a VOLUME, dependi=
ng on the application generating the mesh or the file from which the mesh w=
as read. These sets are all set-types, i.e. the order of entities in the s=
ets is not significant, except in the case of EDGE sets, where order of the=
mesh vertices and edges corresponds to the relative order of vertices and =
edges at the time of mesh generation. In MOAB, these sets are non-tracking=
by default, i.e. entities do not have knowledge of which geometry sets the=
y are members of.
+
+<sup>1</sup>Body-type entities from CUBIT are not explicitly represented i=
n MOAB.
+
+- <B> Topological Relationships </B>
+
+In the geometric model, each FACE is bounded by zero or more EDGEs; other =
topological relationships between geometric entities exist in a similar man=
ner. These relationships are embedded in the data model using parent/child=
relations between entity sets. For example, the entity set corresponding =
to a FACE will have child sets, each corresponding to a bounding EDGE, and =
parent sets, each corresponding to a VOLUME bounded by that FACE. The rela=
tive order of sets in those parent/child lists is not significant, thus, =
=E2=80=9Cloops=E2=80=9D bounding a FACE cannot reliably be inferred from th=
is data.
+
+- <B> Groups </B>
+
+Geometric entities are sometimes assigned to application-specific groups. =
These groups are represented using entity sets, tagged with a =E2=80=9CGRO=
UP=E2=80=9D tag whose value equals the group id. Group sets are =E2=80=9Cs=
et=E2=80=9D-type, and are not tracking sets. These sets contain the sets c=
orresponding to geometric entities contained in the groups in the geometric=
model, as well as any mesh entities assigned to the group.
+
+<H3> Sense </H3>
+
+A geometric face has a natural orientation, indicated by the direction of =
the normal to the face; similarly, edges have a natural orientation determi=
ned by the direction of the tangent. When faces bound regions, or edges bo=
und faces, they do so with a sense; if a region includes a face with forwar=
d sense, that means the face's natural normal direction points out of the v=
olume. If a face includes an edge with forward sense, that means that if o=
ne moves along the edge in the direction of its tangent, the material of th=
e face is on the left hand side. The sense of a face (edge) with respect t=
o a region (face) it bounds is stored using tags on the face (edge).
+
+Most models allow a face to be part of only two regions. Therefore, to st=
ore the sense of a face with respect to regions including it, a tag with tw=
o values is used. This tag is named GEOM_SENSE_2, and has 2 EntityHandle v=
alues. The first value corresponds to the entity set for the region for wh=
ich that face has a forward sense, and the second to the region for which t=
hat face has a reverse sense.
+
+Edges can bound more than two faces. Therefore, two variable-length tags =
are used, one to store the EntityHandles of the faces the edge bounds, and =
the other to store the sense with which the edge bounds the corresponding f=
ace. These tags are named GEOM_SENSE_N_ENTS and GEOM_SENSE_N_SENSES, respe=
ctively. These are stored as variable-length tags; see the MOAB user's gui=
de for information on how to work with tags of this type.
+
+The following sense values are used:
+- 0: forward
+- 1: reverse
+- -1: unnknown
+.
+
+<H3> Material Type </H3>
+(Data: Entity sets; Tag(s): MATERIAL_SET/I)
+
+Most finite element and other PDE-based analysis codes require a material =
type for each cell or element in the simulation. MOAB uses entity sets to =
store this information, in the form of entity sets. The MATERIAL_SET tag i=
s used to identify these sets. The value of this tag is conventionally an =
integer; in most cases this stores a user-assigned identifier associated wi=
th that material.
+
+CUBIT assigns material types using what it calls =E2=80=9Celement blocks=
=E2=80=9D, with each element block given a user-assigned id number and opti=
onally a name. The CUBIT and Exodus file readers in MOAB read element bloc=
ks into MATERIAL_SET sets.
+
+In CUBIT, materials are typically assigned by assigning geometric volumes =
to element blocks. Therefore, material sets often contain entity sets corr=
esponding to those volumes. Thus, a materrial set in MOAB is unlikely to c=
ontain mesh entities directly; rather, that set contains other sets which c=
ontain mesh entities. In these cases, mesh entities can be retrieved by pa=
ssing a =E2=80=9Crecursive=E2=80=9D flag to the appropriate function (MOAB)=
, or by calling the getEntitiesRec extension function (iMesh) provided by M=
OAB.
+
+<H3> Boundary Conditions (Dirichlet, Neumann)</H3>
+Data: Entity sets; Tag(s): DIRICHLET_SET/I, NEUMANN_SET/I)
+
+Boundary conditions are often specified in terms of geometric model entiti=
es, similar to material types. MOAB uses entity sets to store this informa=
tion as well. The DIRICHLET_SET and NEUMANN_SET tags are used to represent=
Dirichlet- and Neumann-type boundary condition sets, resp. By convention,=
Neumann sets usually contain (indirectly) intermediate-dimension entities =
like edges in a 2D mesh or faces in a 3D mesh, while Dirichlet sets usually=
contain vertices. In addition, Neumann sets are represented as sets of fa=
ces, rather than as sides of elements. Faces can be ordered =E2=80=9Cforwa=
rd=E2=80=9D or =E2=80=9Creverse=E2=80=9D with respect to one of the boundin=
g elements, depending on whether the right-hand normal points into or out o=
f the element. Forward-sense faces are added to the Neumann set. Reverse-=
sense faces are put into a separate set; that set is tagged with the NEUSET=
_SENSE tag, with value =3D -1; and that reverse set is added to the Neumman=
n set.
+
+<H3> Parallel Mesh Constructs </H3>
+(Data: Entity sets, entities; Tag(s): PARALLEL_PART/I, PARALLEL_PARTITION/=
I, PSTATUS/C*1, PARALLEL_SHARED_PROC/I, PARALLEL/SHARED_HANDLE/H, PARALLEL_=
SHARED_PROCS/I*NP, PARALLEL_SHARED_HANDLES/H*NP)
+
+On a parallel computer, MOAB can represent the mesh on each processor as w=
ell as information about entities shared with neighboring processors. Some=
of this information is also relevant even when the mesh is represented on =
a serial machine. MOAB uses several tag and set conventions to describe th=
e parallel nature of a mesh. This information is summarized here; for a mo=
re complete description of MOAB=E2=80=99s parallel mesh representation and =
functionality, see [ref-moabpar].
+
+- <B> Parallel partition, parts </B>
+
+Most parallel mesh applications use a domain decomposition approach, where=
each processor solves for a subset of the domain. The set of entities sol=
ved by a given processor is referred to as a part, and the collection of pa=
rts together is called the partition. MOAB stores each part in an entity s=
et, marked with the PARALLEL_PART tag, whose value is the rank of the proce=
ssor assigned that part; an entity set which contains all part sets is give=
n the PARALLEL_PARTITION tag, whose value is currently meaningless. The MB=
Zoltan tool included as a tool in MOAB can partition a mesh for parallel so=
lution, and writes the partition to the mesh in the form of parts and parti=
tions. Both these types of sets can be accessed in a serial mesh, e.g. for=
visualization.
+
+- <B> Part interfaces </B>
+
+When a partitioned mesh has been loaded on a parallel computer, the part o=
n a given processor may share portions of its boundary with parts on other =
processors. These shared regions are called part interfaces, and are also =
represented using entity sets. These sets are marked with the PARALLEL_INT=
ERFACE tag, whose value is currently meaningless.
+
+- <B> Shared processor and handle </B>
+
+For entities shared between processors, it is helpful to know locally whic=
h other processor shares an entity, and what the entity=E2=80=99s handle is=
on the remote processor. There are two cases which are useful to distingu=
ish, first where an entity is shared with only one other processor (referre=
d to as shared), and second when a processor is shared by more than one oth=
er processor (referred to as multi-shared). Shared entities are given the=
PARALLEL_SHARED_PROC and PARALLEL_SHARED_HANDLE tags, which store the rank=
of the sharing processor and the handle of the entity on that processor, r=
espectively. Multi-shared entities are marked with the PARALLEL_SHARED_PRO=
CS and PARALLEL_SHARED_HANDLES tags; these tags have a length NP assigned a=
t compile time in MOAB, with default values of -1 for processor rank and ze=
ro for handle (which are each invalid values for the corresponding data). =
The processors/handles sharing a given entity are then written on the front=
of the arrays. So, for example, an entity on processor rank 0, shared by =
processors 1 and 2, would have a PARALLEL_SHARED_PROCS tag whose values wou=
ld be [1, 2, -1, -1, =E2=80=A6], with PARALLEL_SHARED_HANDLES values of [m,=
n, 0, 0, =E2=80=A6], where m and n would be the handles of that entity on =
processors 1 and 2. The shared versions of these tags are =E2=80=9Cdense=
=E2=80=9D, with default values which denote unshared entities. The multi-s=
hared tags are sparse tags in MOAB, with no default value.
+
+- <B> Parallel status </B>
+
+In addition to the tags above, MOAB also defines the PSTATUS tag, whose bi=
ts contain information about the parallel status of a given entity. Starti=
ng with least significant bit, these bits represent whether an entity is 1)=
not owned, 2) shared, 3) multi-shared, 4) interface, 5) a ghost entity. T=
he first bit being set indicates =E2=80=9Cnot owned=E2=80=9D so that the de=
fault value for this tag, of zero, corresponds to an owned, unshared entity=
, which will be the state of most entities on a given processor.
+
+<H3>Structured Mesh Parameters </H3>
+
+MOAB has a structured mesh interface for creating structured mesh (see =E2=
=80=9CScdInterface.hpp=E2=80=9D header file in MOAB source code). Along wi=
th an internal representation that is more memory-efficient (since it does =
not need to store connectivity), MOAB also creates and tags entity sets wit=
h structured mesh parameters, which can be accessed through the normal tag =
and set interface. The following tags are used:
+
+- <B>BOX_DIMS</B>: This tag stores the ijk coordinates of the lower and up=
per corner of the structured mesh box(es).
+- <B>GLOBAL_BOX_DIMS</B>: If specified when the structured mesh is created=
, a tag with this name stores the global box dimensions (which may be diffe=
rent than the local box dimensions).
+- <B>BOX_PERIODIC</B>: Stores whether the box is periodic in the i (BOX_PE=
RIODIC[0]) and j (BOX_PERIODIC[1]) directions.
+- <B>__BOX_SET</B>: Pointer to the ScdBox instance corresponding to this e=
ntity set.<sup>2</sup>
+.
+Although the structured mesh is not saved as such in HDF5-format files, th=
e entity sets and corresponding tags will be saved and restored.
+
+<sup>2</sup>The double-underscore in the tag name implies that this tag wi=
ll not be saved in a file, in this case because the ScdBox instances are no=
t preserved in a file.
+
+<H3>Spectral Mesh Constructs </H3>
+
+The Spectral Element Method (SEM) is a high-order method, using a polynomi=
al Legendre interpolation basis with Gauss-Lobatto quadrature points, in co=
ntrast to the Lagrange basis used in (linear) finite elements. A spectral =
mesh with order O contains quadrilateral or hexahedral elements comprised o=
f (O+1)d vertices. Spectral meshes are usually represented in one of two w=
ays, either as coarse elements which point to an array of higher-order vert=
ices (and with corner vertices represented in the normal manner), or as lin=
ear quads/hexes formed from the higher-order vertices, with each original c=
oarse quad/hex represented by Od fine quads/hexes. Similarly, the spectral=
variables, which are normally computed at fine vertex positions, are store=
d either on those vertices, or in lexicographically-ordered arrays on eleme=
nts (with tag values repeated on neighboring elements). MOAB can read spec=
tral meshes from a variety of formats (at this time, including CAM-SE, HOMM=
E, and Nek5000). Which of the above two representations are controlled by =
read options and are indicated by certain tags:
+
+- SPECTRAL_MESH: read option indicating that spectral elements should be r=
epresented as coarse linear quads/hexes and each element containing an arra=
y of lexicographically-ordered vertex handles
+
+- TAG_SPECTRAL_ELEMENTS: read option; if given, spectral variables are rep=
resented as lexicographically-ordered arrays on elements
+
+- TAG_SPECTRAL_VERTICES: read option; if given, spectral variables are rep=
resented as tags on vertices
+
+- CONN=3D<filename>: in CAM-SE, the connectivity of the spectral mesh is s=
tored by default in a file named =E2=80=9CHommeMapping.nc=E2=80=9D; this op=
tion can be given to read the connectivity from a different file
+
+- SPECTRAL_VERTICES: tag name for array of vertex handles
+
+- SPECTRAL_ORDER: tag name for spectral order, written to file set or (if =
no file set given) to interface after a spectral mesh is read
+
+.
+
+\ref md-contents "Top"
+
+ \section meta-options Reader/Writer Options
+
+All mesh file readers and writers in MOAB take an option string as an argu=
ment. By default, the semicolon (=E2=80=9C;=E2=80=9D) delimits individual =
options in the option string. Options used in multiple readers are describ=
ed in this section; the options enabled in specific readers/writers are des=
cribed in the corresponding appendix at the end of this document.
+
+<H3>variable=3D<var_name>[,...]</H3>
+
+By default, all field data stored with the mesh is read with the mesh, and=
stored as tags on the associated mesh entities. This option lists specifi=
c variables that should be read along with the mesh (note also the =E2=80=
=9Cnomesh=E2=80=9D option, described elsewhere in this document). The vari=
able name listed will be read into a tag with the same name. For time-depe=
ndent variables, the time step number will be appended to the variable name=
to form the tag name. If no =E2=80=9Ctimestep=E2=80=9D or =E2=80=9Ctimeva=
l=E2=80=9D option is given, all time steps will be read, resulting in sever=
al tags being created. If the =E2=80=9Cnomesh=E2=80=9D option is given, th=
e application must pass the entity set resulting from the original mesh rea=
d in to the function, that this set must contain the mesh read only from th=
at file. The mesh in the file is checked against the mesh in the set to ve=
rify that the two correspond. The special name =E2=80=9CMOAB_ALL_VARIABLES=
=E2=80=9D can be used to indicate that all variables should be read. Multi=
ple variable names can be specified, separated from each other by commas.
+
+<H3>nomesh </H3>
+
+Indicates that no mesh should be read from the file. This option is used =
in conjunction with the =E2=80=9Cvariable=3D=E2=80=9D option, to read varia=
bles and assign them as tags to a previously-read mesh. If this option is =
used, applications should pass an entity set to the read function, which sh=
ould contain the mesh previously read from the file.
+
+<H3>timestep=3D<step_number>[, ...] </H3>
+
+Read the time step number whose time value is equal to or greater than the=
specified time value, for the specified variable(s). Tag names for the va=
riable(s) will be formed by appending the time step number to the variable =
name. Multiple time step values can be specified, separated from each othe=
r by commas.
+
+\ref md-contents "Top"
+
+ \section meta-references References
+
+[1] T.J. Tautges, R. Meyers, K. Merkley, C. Stimpson, and C. Ernst, MO=
AB: A Mesh-Oriented Database, Sandia National Laboratories, 2004.
+
+[2] L. Diachin, A. Bauer, B. Fix, J. Kraftcheck, K. Jansen, X. Luo, M.=
Miller, C. Ollivier-Gooch, M.S. Shephard, T. Tautges, and H. Trease, =E2=
=80=9CInteroperable mesh and geometry tools for advanced petascale simulati=
ons,=E2=80=9D Journal of Physics: Conference Series, vol. 78, 2007, p. 012=
015.
+
+\ref md-contents "Top"
+
+ \section appendixA Appendix A: Summary
+
+\subsection table1 Table 1: Summary of MOAB meta-data conventions.
+
+<table border=3D"1">
+<tr>
+<th>Convention</th>
+<th>Applies to (E=3Dent, S=3Dset)</th>
+<th>Tag(s) (type/length)</th>
+<th>Description</th>
+</tr>
+<tr>
+<td>Name</td>
+<td>E, S</td>
+<td>NAME/C*32</td>
+<td></td>
+</tr>
+<tr>
+<td>Title</td>
+<td>S</td>
+<td>TITLE/C*strlen</td>
+<td>Title of mesh</td>
+</tr>
+<tr>
+<td>Global identifier</td>
+<td>E, S</td>
+<td>GLOBAL_ID/I</td>
+<td></td>
+</tr>
+<tr>
+<td>Geometric topology</td>
+<td>S</td>
+<td>GEOM_DIMENSION/I, GLOBAL_ID/I,^
+NAME/C*32,
+CATEGORY/C*32.
+GEOM_SENSE_2/EH[2],
+GEOM_SENSE_N_ENTS/EH*N,
+GEOM_SENSE_N_SENSES/I*N</td>
+<td>Sets contain mesh owned by that entity; parent/child links to bounded/=
bounding entities in geometric model</td>
+</tr>
+<tr>
+<td>Material type</td>
+<td>S</td>
+<td>MATERIAL_SET/I</td>
+<td>Set contains entities or sets assigned a common material type</td>
+</tr>
+<tr>
+<td>Boundary condition</td>
+<td>S</td>
+<td>DIRICHLET_SET/I, NEUMANN_SET/I</td>
+<td>Set contains entities or sets assigned a particular boundary condition=
; neumann sets usually contain edges (2D) or faces (3D)</td>
+</tr>
+<tr>
+<td>Parallel mesh constructs</td>
+<td>E, S</td>
+<td>PARALLEL_PART/I, PARALLEL_PARTITION/I, PSTATUS/C*1, PARALLEL_SHARED_PR=
OC/I, PARALLEL/SHARED_HANDLE/H, PARALLEL_SHARED_PROCS/I*NP, PARALLEL_SHARED=
_HANDLES/H*NP</td>
+<td> Data which describes parallel mesh</td>
+</tr>
+<tr>
+<td>Structured mesh constructs</td>
+<td>S</td>
+<td>BOX_DIMS/I*6, GLOBAL_BOX_DIMS/I*6, BOX_PERIODIC/2*I, __BOX_SET/O</td>
+<td>Data describing structured mesh </td>
+</tr>
+<tr>
+<td>Spectral mesh constructs </td>
+<td>E, S</td>
+<td>SPECTRAL_ORDER/I, SPECTRAL_VERTICES/I*(O+1)^2</td>
+<td>Data marking spectral mesh constructs</td>
+</tr>
+</table>
+=20
+ \ref meta-introduction "Back to Introduction"
+
+ \subsection table2 Table 2: Summary of MOAB conventional tag names, type=
s, and purposes. Data types are I=3Dinteger, D=3Ddouble, C=3Dcharacter, H=
=3Dentity handle,O=3Dopaque. Data type with *x denote length of x elements=
of that data type.
+
+<Table border=3D"1">
+<tr>
+<th>Tag name</th>
+<th>Data type</th>
+<th>Applies to (E=3Dentity, S=3Dset)</th>
+<th>Purpose</th>
+</tr>
+<tr>
+<td>BOX_DIMS</td>
+<td>I*6</td>
+<td>S</td>
+<td>Lower and upper ijk dimensions of box, ordered (ilo, jlo, klo, ihi, jh=
i, khi)</td>
+</tr>
+<tr>
+<td>BOX_PERIODIC</td>
+<td>I*2</td>
+<td>S</td>
+<td>Indicates whether box is periodic in i (BOX_PERIODIC[0]) or j (BOX_PER=
IODIC[1])</td>
+</tr>
+<tr>
+<td>__BOX_SET</td>
+<td>O</td>
+<td>S</td>
+<td>Pointer to corresponding ScdBox instance</td>
+</tr>
+<tr>
+<td>CATEGORY</td>
+<td>C*32</td>
+<td>S</td>
+<td>String describing purpose of set; examples include =E2=80=9Cgroup=E2=
=80=9D, =E2=80=9Cvertex=E2=80=9D, =E2=80=9Cedge=E2=80=9D, =E2=80=9Csurface=
=E2=80=9D, =E2=80=9Cvolume=E2=80=9D</td>
+</tr>
+<tr>
+<td>DIRICHLET_SET </td>
+<td>I</td>
+<td>SO</td>
+<td>Entities or sets with common boundary condition</td>
+</tr>
+<tr>
+<td>GEOM_DIMENSION</td>
+<td>I</td>
+<td>S</td>
+<td>Identifies mesh entities resolving a given geometric model entity</td>
+</tr>
+<tr>
+<td>GEOM_SENSE_2</td>
+<td>EH*2</td>
+<td>S</td>
+<td> Stored on face-type geometric topology sets, values store regions hav=
ing forward and reverse sense</td>
+</tr>
+<tr>
+<td>GEOM_SENSE_N_ENTS</td>
+<td>EH*N</td>
+<td>S</td>
+<td>Stored on edge-type geometric topology sets, values store faces whose =
senses are stored in GEOM_SENSE_N_SENSES.</td>
+</tr>
+<tr>
+<td>GEOM_SENSE_N_SENSES</td>
+<td>I*N</td>
+<td>S</td>
+<td>Stored on edge-type geometric topology sets, values store senses of th=
e edge with respect to faces stored in GEOM_SENSE_N_ENTS.</td>
+</tr>
+<tr>
+<td>GLOBAL_ID</td>
+<td>I</td>
+<td>E,S</td>
+<td>Application-specific entity id</td>
+</tr>
+<tr>
+<td>MATERIAL_SET</td>
+<td>I</td>
+<td>S</td>
+<td>Entities or sets grouped by material type</td>
+</tr>
+<tr>
+<td>NAME</td>
+<td>C*32</td>
+<td>E, S</td>
+<td>User-assigned entity name(s); multiple names delimited with ?</td>
+</tr>
+<tr>
+<td>NEUMANN_SET</td>
+<td>I</td>
+<td>S</td>
+<td>Entities or sets with common boundary condition </td>
+</tr>
+<tr>
+<td>PARALLEL_PART </td>
+<td>I</td>
+<td>S</td>
+<td>Represent a part in a partition</td>
+</tr>
+<tr>
+<td>PARALLEL_PARTITION</td>
+<td>I</td>
+<td>S</td>
+<td>Represents a partition of the mesh for parallel solution, which is a c=
ollection of parts</td>
+</tr>
+<tr>
+<td>__PARALLEL_SHARED_HANDLEd</td>
+<td>H</td>
+<td>E, S</td>
+<td> Handle of this entity/set on sharing processor</td>
+</tr>
+<tr>
+<td>__PARALLEL_SHARED_PROC</td>
+<td>I</td>
+<td>E,S</td>
+<td>Rank of other processor sharing this entity/set </td>
+</tr>
+</table>
+
+\ref md-contents "Top"
+
+ \section appendixB Appendix B: CCMIO (Star-CD, Star-CCM+) Reader/Writer =
Conventions
+
+ \subsection table3 Table 3: Translation between CCMIO options and MOAB t=
ags.
+<Table border=3D"1">
+<tr>
+<th> Set Type</th>
+<th>CCMIO Construct</th>
+<th>MOAB Tag Name, Type</th>
+</tr>
+<tr>
+<td rowspan=3D"2">File set / Interface</td>
+<td>Title (option)</td>
+<td>=E2=80=9CTitle=E2=80=9D (C*32)</td>
+</tr>
+<tr>
+<td>CreatingProgram</td>
+<td>=E2=80=9CCreatingProgram=E2=80=9D (C*32)</td>
+</tr>
+<tr>
+<td rowspan=3D"13">Material sets</td>
+<td>Index</td>
+<td>MATERIAL_SET</td>
+</tr>
+<tr>
+<td>Label<sup>1</sup></td>
+<td>NAME</td>
+</tr>
+<tr>
+<td>MaterialId</td>
+<td>=E2=80=9CMaterialId=E2=80=9D (I)</td>
+</tr>
+<tr>
+<td>Radiation</td>
+<td>=E2=80=9CRadiation=E2=80=9D (I)</td>
+</tr>
+<tr>
+<td>PorosityId</td>
+<td>=E2=80=9CPorosityId=E2=80=9D (I)</td>
+</tr>
+<tr>
+<td>SpinId</td>
+<td>=E2=80=9CSpinId=E2=80=9D (I)</td>
+</tr>
+<tr>
+<td>GroupId</td>
+<td>=E2=80=9CGroupId=E2=80=9D (I)</td>
+</tr>
+<tr>
+<td>ColorIdx</td>
+<td>=E2=80=9CColorIdx=E2=80=9D (I)</td>
+</tr>
+<tr>
+<td>ProcessorId</td>
+<td>=E2=80=9CProcessorId=E2=80=9D (I)</td>
+</tr>
+<tr>
+<td>LightMaterial</td>
+<td>=E2=80=9CLightMaterial=E2=80=9D (I)</td>
+</tr>
+<tr>
+<td>FreeSurfaceMaterial</td>
+<td>=E2=80=9CThickness=E2=80=9D (F)</td>
+</tr>
+<tr>
+<td>Thickness</td>
+<td>=E2=80=9CThickness=E2=80=9D (F)</td>
+</tr>
+<tr>
+<td>MaterialType</td>
+<td>=E2=80=9CMaterialType=E2=80=9D (C*32)</td>
+</tr>
+<tr>
+<td rowspan=3D"5">Neumann sets</td>
+<td>Index</td>
+<td>NEUMANN_SET</td>
+</tr>
+<tr>
+<td>Label</td>
+<td>NEUMANN_SET</td>
+</tr>
+<tr>
+<td>BoundaryName</td>
+<td>NAME</td>
+</tr>
+<tr>
+<td>BoundaryType</td>
+<td>=E2=80=9CBoundaryType=E2=80=9D (C*32)</td>
+</tr>
+<tr>
+<td>ProstarRegionNumber</td>
+<td>=E2=80=9CProstarRegionNumber=E2=80=9D (I)</td>
+</tr>
+</table>
+
+Notes:
+1. If no name is present, labels the material group with =E2=80=9CMaterial=
X=E2=80=9D, where X is the index of that group.
+
+\ref md-contents "Top"
+
+ \section appendixC Appendix C: ExodusII Reader/Writer Conventions=20
+
+ \subsection table4 Table 4: Translation between ExodusII constructs and =
MOAB tags.
+<Table border=3D"1">
+<tr>
+<th> Data Type</th>
+<th>ExodusII Construct</th>
+<th>MOAB Tag Name, Type</th>
+</tr>
+<tr>
+<td></td>
+<td>QA records</td>
+<td>=E2=80=9CqaRecord=E2=80=9D (C*(v))<sup>2</sup></td>
+</tr>
+<tr>
+<td rowspan=3D"2">Material sets</td>
+<td>Block number</td>
+<td>MATERIAL_SET</td>
+</tr>
+<tr>
+<td>Block element type</td>
+<td>Entity type, # vertices per entity</td>
+</tr>
+<tr>
+<td rowspan=3D"2">Dirichlet sets<sup>3</sup></td>
+<td>Nodeset number</td>
+<td>DIRICHLET_SET</td>
+</tr>
+<tr>
+<td>Distribution factors</td>
+<td>=E2=80=9CdistFactor=E2=80=9D (D*(v))<sup>1</sup></td>
+</tr>
+<tr>
+<td>Neumann sets</td>
+<td>Sideset number</td>
+<td>NEUMANN_SET</td>
+</tr>
+<tr>
+<td rowspan=3D"2">Neumann sets, reverse faces3<sup>3</sup></td>
+<td>Distribution factors</td>
+<td>=E2=80=9CdistFactor=E2=80=9D (D*(v))<sup>1</sup></td>
+</tr>
+<tr>
+<td>Sides</td>
+<td>SENSE</td>
+</tr>
+<tr>
+<td>Nodes, elements</td>
+<td>node_num_map, elem_map</td>
+<td>GLOBAL_ID on nodes/elements</td>
+</tr>
+</table>
+
+Notes:
+-# Variable-length tag used for distribution factors; length for each set =
is the number of entities in
+each set, such that there is one distribution factor for each entity in th=
e set.
+-# QA records are stored as variable-length tags on file set specified on =
read. Tag is a
+concatenation of QA record strings into a single string, with '\0' used to=
delimit lines.
+-# MOAB represents sidesets as sets of faces, rather than as sides of elem=
ents. Faces can be
+ordered =E2=80=9Cforward=E2=80=9D or =E2=80=9Creverse=E2=80=9D with respec=
t to one of the bounding elements, depending on
+whether the right-hand normal points into or out of the element. Forward-s=
ense faces are added
+to the Neumann set. Reverse-sense faces are put into a separate set; that =
set is tagged with the SENSE tag, with value =3D -1; and that reverse set i=
s added to the Neummann set.
+.
+
+ \ref md-contents "Top"
+
+ \section appendixD Appendix D: NC (Climate Data) Reader/Writer Conventio=
ns
+
+The climate data reader in MOAB reads files with the '.nc' filename extens=
ion. By default, this reader
+reads the whole mesh in the file and creates it as structured mesh in MOAB=
, with the mesh accessible
+through MOAB's structured mesh interface. By default, all variables and ti=
mesteps are read from the
+file, and written as tags on the mesh vertices from that file. This behavi=
or is controlled by the
+=E2=80=9Cvariable=E2=80=9D, =E2=80=9Cnomesh=E2=80=9D, =E2=80=9Ctimestep=E2=
=80=9D, and =E2=80=9Ctimeval=E2=80=9D options described earlier in this doc=
ument. If MOAB
+is compiled for parallel execution and configured with a pnetcdf reader, t=
he mesh is read in parallel,
+with a 1D or 2D decomposition designed to balance read performance and com=
munication interface
+size (for details on the partitioning method used, see the src/io/ReadNC.c=
pp source file).
+
+Mesh is put into the entity set provided to the load_file function. This e=
ntity set is also annotated with
+various tags representing information read from the file. These tags are d=
escribed in Table 5.
+
+Several other things to note about reading climate data files into MOAB:
+- Time-dependent variables: MOAB currently has no mechanism for time-depen=
dent tags. Therefore, time-dependent variables are represented using one ta=
g per timestep, with the tag name set as the variable name plus the timeste=
p index. Thus, the first few timesteps for the variable TEMPERATURE would b=
e represented in tags named TEMPERATURE0, TEMPERATURE1, etc.
+- Cell- and face-centered variables: The climate data reader currently doe=
s not do cell- and face-
+centered variables correctly.
+.
+ \subsection table5 Table 5: Summary of MOAB conventional tag names, type=
s, and purposes. Data types are I=3Dinteger, D=3Ddouble, C=3Dcharacter, H=
=3Dentity handle. Data type with *x denote length of x elements of that dat=
a type; data type with *var denote variable-length tag. Tag names with two =
underscores prepended (=E2=80=9C__=E2=80=9D) denote tags not written to a f=
ile by MOAB.
+
+<Table border=3D"1">
+<tr>
+<th> Tag name </th>
+<th>Data type </th>
+<th> Applies to (E=3Dentity, S=3Dset) </th>
+<th>Purpose </th>
+</tr>
+<tr>
+<td>__NUM_DIMS </td>
+<td>I</td>
+<td>S</td>
+<td>The number of dimensions in the netcdf file.</td>
+</tr>
+<tr>
+<td>__NUM_VARS</td>=20
+<td>I</td>
+<td>S</td>
+<td>The number of variables in the netcdf file.</td>
+</tr>
+<tr>
+<td>__DIM_NAMES </td>
+<td>C*var </td>
+<td>S </td>
+<td>The dimension names, concatenated into a
+character string, with '\0' terminating each name.
+ </td>
+</tr>
+<tr>
+<td>__DIM_NAMES=20
+</td>
+<td>C*var</td>
+<td>S</td>
+<td>The variable names, concatenated into a character
+string, with '\0' terminating each name.
+</td>
+</tr>
+<tr>
+<td><dim_name>=20
+</td>
+<td>(I or=20
+D)*va=20
+</td>
+<td>S</td>
+<td>For each dimension, the values for the dimension.
+The data type for this tag corresponds to that in the
+netcdf file. The length of this tag is the number of
+values stored for the dimension in the netcdf file.</td>
+</tr>
+<tr>
+<td>__<dim_name>_LOC_MIN MAX</td>=20
+<td>2*(I or D)</td>
+<td>S</td>
+<td>The indices (0-based) of the local min and max
+values of dimension stored locally. For spatial
+dimensions like lon or lat, this will store the
+minimum and maximum indices in the loca</td>
+</tr>
+<tr>
+<td >__<dim_name>_LOC_VAL </td>=20
+<td>(I or D)*var </td>
+<td>S</td>
+<td>The indices (0-based) of the dimension stored
+locally. This tag only makes sense for dimensions
+that can be read in multiple pieces, such as time.
+Only one of __<dim_name>_LOC_VALS and
+_LOC_MIN_MAX can be used for a given
+dimension.
+</tr>
+<tr>
+<td>__<var_name>_DIMS=20
+</td>
+<td>C*n=20
+</td>
+<td>S</td>
+<td>For each variable, the tag handles for the
+dimensions defining this variable, in netcdf
+ordering (last dimension varying fastest). The
+length of this tag, n, is # dimensions for the
+variable * sizeof(TagHandle).
+</td>
+</tr>
+<tr>
+<td><var_name><timestep_ind>=20
+</td>
+<td>(data type)</td>
+<td>E</td>
+<td>Values of the variable for timestep <timestep_ind>
+for vertices. The data type of this tag corresponds
+to that of the variable from the netcdf file.
+Timestep index is 0-based.
+</td>
+</tr>
+<tr>
+<td>__GLOBAL_ATTRIBS=20
+</td>
+<td>C*Var=20
+</td>
+<td>S</td>
+<td>The global attributes, concatenated into a character
+string, with =E2=80=98\0=E2=80=99 terminating each attribute name, =E2=80=
=98;=E2=80=99
+ separating the data type and value, and =E2=80=98;=E2=80=99
+ separating one name/data type/value from the next.
+</td>
+</tr>
+<tr>
+<td>__GLOBAL_ATTRIBS_LEN=20
+</td>
+<td>I*Var=20
+</td>
+<td>S</td>
+<td>A vector of integers, marking the end position of
+each attribute (name/data type/value) in __GLOBAL_ATTRIBS tag.
+</td>
+</tr>
+<tr>
+<td>__<var_name>_ATTRIBS=20
+</td>
+<td>C*Var
+</td>
+<td>S</td>
+<td>The variable attributes, concatenated into a
+character string, with =E2=80=98\0=E2=80=99 terminating each attribute
+ name, =E2=80=98;=E2=80=99 separating the data type and value, and =E2=
=80=98;=E2=80=99
+ separating one name/data type/value from the next.
+</td>
+</tr>
+<tr>
+<td>__<var_name>_ATTRIBS_LEN=20
+</td>
+<td>I*Var
+</td>
+<td>S</td>
+<td>A vector of integers, marking the end position of
+each attribute (name/data type/value) in
+__<var_name>_ATTRIBS tags
+</td>
+</tr>
+</table>
+
+ \ref md-contents "Top"
+
+ \section appendixE Appendix E: Nek5000 Reader/Writer Conventions
+
+Nek5000, or Nek, is a code that uses the spectral element method to model =
fluid, heat transfer,
+electromagnetics, and other physics. Nek uses unstructured hexahedral mesh=
es, with each hex element
+resolved by a structured grid of =E2=80=9CGauss Lebato Legendre=E2=80=9D (=
GLL) points. Nek can read meshes through
+MOAB, and can output physics variables and GLL points through MOAB as well.
+
+Since fluid is a single material in Nek, no material sets are needed. Boun=
dary conditions are mapped to
+Nek's cbc array using Neumann sets and a user-provided =E2=80=9Cusr_moab2n=
ek=E2=80=9D subroutine (for an example
+of this subroutine, see examples/moab/pipe.usr in the Nek source code). GL=
L point locations and fluid
+variables on those points are stored in tags on the hex elements. All hex =
elements have the same
+number of GLL points. The number of GLL points in each direction is stored=
in a tag on the mesh
+instance. These tags are described in Table 6.
+
+GLL point locations and fluid variables are stored in lexicographic order,=
similar to their storage order
+inside the Nek code.
+
+ \subsection table6 Table 6: Summary of MOAB conventional tag names, type=
s, and purposes for Nek. Data types are I=3Dinteger, D=3Ddouble, C=3Dcharac=
ter, H=3Dentity handle. Data type with *x denote length of x elements of th=
at data type; data type with *var denote variable-length tag. Tag names wit=
h two underscores prepended (=E2=80=9C__=E2=80=9D) denote tags not written =
to a file by MOAB.
+<Table border=3D"1">
+<tr>
+<th> Tag name </th>
+<th> Data Type</th>
+<th>Applies to (E=3Dentity, S=3Dset)</th>
+<th>Purpose</th>
+</tr>
+<tr>
+<td>SEM_DIMS</td>
+<td>I*3</td>
+<td>S</td>
+<td>The dimensions of the GLL mesh in each hex
+element.
+</td>
+</tr>
+<tr>
+<td>SEM_X</td>
+<td>D*nx*ny*nz</td>
+<td>E</td>
+<td>X position of GLL points (having nx*ny*nz
+values)
+</td>
+</tr>
+<tr>
+<td>SEM_Y</td>
+<td>D*nx*ny*nz</td>
+<td>E</td>
+<td>Y position of GLL points (having nx*ny*nz values)</td>
+</tr>
+<tr>
+<td>SEM_Z</td>
+<td>D*nx*ny*nz</td>
+<td>E</td>
+<td>Z position of GLL points (having nx*ny*nz values)</td>
+</tr>
+<tr>
+<td>VEL_X</td>
+<td>D*nx*ny*nz</td>
+<td>E</td>
+<td>Fluid velocities in the x direction for GLL point
+array (having nx*ny*nz values)</td>
+</tr>
+<tr>
+<td>VEL_Y</td>
+<td>D*nx*ny*nz</td>
+<td>E</td>
+<td>Fluid velocities in the y direction for GLL point
+array (having nx*ny*nz values)</td>
+</tr>
+<tr>
+<td>VEL_Z</td>
+<td>D*nx*ny*nz</td>
+<td>E</td>
+<td>Fluid velocities in the z direction for GLL point
+array (having nx*ny*nz values)</td>
+</tr>
+<tr>
+<td>TEMP</td>
+<td>D*nx*ny*nz</td>
+<td>E</td>
+<td>Fluid temperature for GLL point array (having
+nx*ny*nz values)
+</td>
+</tr>
+<tr>
+<td>PRESS</td>
+<td>D*nx*ny*nz</td>
+<td>E</td>
+<td>Fluid pressure for GLL point array (having
+nx*ny*nz values)
+</td>
+</tr>
+</table>
+ \ref md-contents "Top"
+ */
+
+/*! \page md-tables List of Tables
+ \ref table1
+
+ \ref table2
+
+ \ref table3
+
+ \ref table4
+
+ \ref table5
+
+ \ref table6
+
+*/
+
diff --git a/doc/UG/moabUG.h b/doc/UG/moabUG.h
index cea942d..f3f186d 100644
--- a/doc/UG/moabUG.h
+++ b/doc/UG/moabUG.h
@@ -34,13 +34,13 @@
=20
\ref interface =20
=20
- \ref twoone =20
+ \ref twoone =20
=20
- \ref twotwo =20
+ \ref twotwo =20
=20
- \ref twothree =20
+ \ref twothree =20
=20
- \ref twofour =20
+ \ref twofour =20
=20
\ref api =20
=20
@@ -88,7 +88,7 @@
=20
\ref references=20
=20
- \section introduction 1. Introduction
+ \section introduction 1.Introduction
=20
In scientific computing, systems of partial differential equations (PDEs) =
are solved on computers. One of the most widely used methods to solve PDEs=
numerically is to solve over discrete neighborhoods or =E2=80=9Celements=
=E2=80=9D of the domain. Popular discretization methods include Finite Dif=
ference (FD), Finite Element (FE), and Finite Volume (FV). These methods r=
equire the decomposition of the domain into a discretized representation, w=
hich is referred to as a =E2=80=9Cmesh=E2=80=9D. The mesh is one of the fu=
ndamental types of data linking the various tools in the analysis process (=
mesh generation, analysis, visualization, etc.). Thus, the representation =
of mesh data and operations on those data play a very important role in PDE=
-based simulations.
=20
@@ -110,12 +110,14 @@ Several other sources of information about MOAB may a=
lso be of interest to reade
=20
\ref contents
=20
- \section interface 2. MOAB Data Model
+ \section interface 2.MOAB Data Model
The MOAB data model describes the basic types used in MOAB and the languag=
e used to communicate that data to applications. This chapter describes th=
at data model, along with some of the reasons for some of the design choice=
s in MOAB.
=20
\ref contents
=20
- \subsection twoone 2.1. MOAB Interface
+<tab>
+ \subsection twoone 2.1. MOAB Interface=20
+</tab>
MOAB is written in C++. The primary interface with applications is throug=
h member functions of the abstract base class Interface. The MOAB library =
is created by instantiating Core, which implements the Interface API. Mult=
iple instances of MOAB can exist concurrently in the same application; mesh=
entities are not shared between these instancesi<sup>2</sup>. MOAB is mos=
t easily viewed as a database of mesh objects accessed through the instance=
. No other assumptions explicitly made about the nature of the mesh stored=
there; for example, there is no fundamental requirement that elements fill=
space or do not overlap each other geometrically.
=20
<sup>2</sup> One exception to this statement is when the parallel interfac=
e to MOAB is used; in this case, entity sharing between instances is handle=
d explicitly using message passing. This is described in more detail in Se=
ction 5 of this document.
@@ -261,7 +263,7 @@ The semantic meaning of a tag is determined by applicat=
ions using it. However,
=20
\ref contents
=20
- \section api 3. MOAB API Design Philosophy and Summary
+ \section api 3.MOAB API Design Philosophy and Summary
=20
This section describes the design philosophy behind MOAB, and summarizes t=
he functions, data types and enumerated variables in the MOAB API. A compl=
ete description of the MOAB API is available in online documentation in the=
MOAB distribution [8].
=20
@@ -406,7 +408,7 @@ Table 3 lists the various groups of functions that comp=
rise the MOAB API. This
=20
\ref contents
=20
- \section services 4. Related Mesh Services
+ \section services 4.Related Mesh Services
=20
A number of mesh-based services are often used in conjunction with a mesh =
library. For example, parallel applications often need to visualize the me=
sh and associated data. Other services, like spatial interpolation or find=
ing the faces on the =E2=80=9Cskin=E2=80=9D of a 3D mesh, can be implemente=
d more efficiently using knowledge of specific data structures in MOAB. Se=
veral of these services provided with MOAB are described in this chapter.
=20
@@ -600,7 +602,7 @@ The Common Geometry Module (CGM) [17] is a library for =
representing solid model
=20
\ref contents
=20
- \section parallel 5. Parallel Mesh Representation and Query
+ \section parallel 5.Parallel Mesh Representation and Query
=20
A parallel mesh representation must strike a careful balance between provi=
ding an interface to mesh similar to that of a serial mesh, while also allo=
wing the discovery of parallel aspects of the mesh and performance of paral=
lel mesh-based operations efficiently. MOAB supports a spatial domain-deco=
mposed view of a parallel mesh, where each subdomain is assigned to a proce=
ssor, lower-dimensional entities on interfaces between subdomains are share=
d between processors, and ghost entities can be exchanged with neighboring =
processors. Locally, each subdomain, along with any locally-represented gh=
ost entities, are accessed through a local MOAB instance. Parallel aspects=
of the mesh, e.g. whether entities are shared, on an interface, or ghost e=
ntities, are embedded in the same data model (entities, sets, tags, interfa=
ce) used in the rest of MOAB. MOAB provides a suite of parallel functions =
for initializing and communicating with a parallel mesh, along with functio=
ns to query the parallel aspects of the mesh.
=20
@@ -821,7 +823,7 @@ Once a parallel mesh has been initialized, applications=
can call the ParallelCom
=20
\ref contents
=20
- \section applications 6. Building MOAB-Based Applications
+ \section applications 6.Building MOAB-Based Applications
=20
There are two primary mechanisms supported by MOAB for building applicatio=
ns, one based on MOAB-defined make variables, and the other based on the us=
e of libtool and autoconf. Both assume the use of a =E2=80=9Cmake=E2=80=9D=
-based build system. =20
=20
@@ -851,7 +853,7 @@ The second method for incorporating MOAB into an applic=
ation=E2=80=99s build system is
=20
\ref contents
=20
- \section implementation 7. iMesh (ITAPS Mesh Interface) Implementation =
in MOAB
+ \section implementation 7.iMesh (ITAPS Mesh Interface) Implementation i=
n MOAB
=20
iMesh is a common API to mesh data developed as part of the Interoperable =
Tools for Advanced Petascale Simulations (ITAPS) project [18]. Application=
s using the iMesh interface can operate on any implementation of that inter=
face, including MOAB. MOAB-based applications can take advantage of other =
services implemented on top of iMesh, including the MESQUITE mesh improveme=
nt toolkit [19] and the GRUMMP mesh improvement library [20].
=20
@@ -890,7 +892,7 @@ Note that using the iMesh interface from Fortran-based =
applications requires a c
=20
\ref contents
=20
- \section representation 8. Structured Mesh Representation
+ \section representation 8.Structured Mesh Representation
=20
A structured mesh is defined as a D-dimensional mesh whose interior vertic=
es have 2D connected edges. Structured mesh can be stored without connect=
ivity, if certain information is kept about the parametric space of each st=
ructured block of mesh. MOAB can represent structured mesh with implicit c=
onnectivity, saving approximately 57% of the storage cost compared to an un=
structured representation<sup>7</sup>. Since connectivity must be computed=
on the fly, these queries execute a bit slower than those for unstructured=
mesh. More information on the theory behind MOAB's structured mesh repres=
entation can be found in=20
=20
@@ -900,7 +902,7 @@ Currently, MOAB's structured mesh representation can on=
ly be used by creating st
=20
\ref contents
=20
- \section element 9. Spectral Element Meshes
+ \section element 9.Spectral Element Meshes
=20
The Spectral Element Method (SEM) is a high-order method, using a polynomi=
al Legendre interpolation basis with Gauss-Lobatto quadrature points, in co=
ntrast to the Lagrange basis used in (linear) finite elements [20]. SEM ob=
tains exponential convergence with decreasing mesh characteristic sizes, an=
d codes implementing this method typically have high floating-point intensi=
ty, making the method highly efficient on modern CPUs. Most Nth-order SEM =
codes require tensor product cuboid (quad/hex) meshes, with each d-dimensio=
nal element containing (N+1)d degrees of freedom (DOFs). There are various=
methods for representing SEM meshes and solution fields on them; this docu=
ment discusses these methods and the tradeoffs between them. The mesh part=
s of this discussion are given in terms of the iMesh mesh interface and its=
implementation by the MOAB mesh library [21].
=20
@@ -942,7 +944,7 @@ In brief, we propose to represent elements using the li=
near, FE-ordered connecti
=20
\ref contents
=20
- \section performance 10. Performance and Using MOAB Efficiently from App=
lications
+ \section performance 10.Performance and Using MOAB Efficiently from Appl=
ications
=20
MOAB is designed to operate efficiently on groups of entities and for larg=
e meshes. Applications will be most efficient when they operate on entitie=
s in groups, especially groups which are close in their order of creation. =
The MOAB API is structured to encourage operations on groups of entities. =
Conversely, MOAB will not perform as well as other libraries if there are =
frequent deletion and creation of entities. For those types of application=
s, a mesh library using a C++ object-based representation is more appropria=
te. In this section, performance of MOAB when executing a variety of tasks=
is described, and compared to that of other representations. Of course, t=
hese metrics are based on the particular models and environments where they=
are run, and may or may not be representative of other application types.
=20
@@ -957,7 +959,7 @@ This test can be run on your system to determine the ru=
ntime and memory performa
=20
\ref contents
=20
- \section conclusions 11. Conclusions and Future Plans
+ \section conclusions 11.Conclusions and Future Plans
=20
MOAB, a Mesh-Oriented datABase, provides a simple but powerful data abstra=
ction to structured and unstructured mesh, and makes that abstraction avail=
able through a function API. MOAB provides the mesh representation for the=
VERDE mesh verification tool, which demonstrates some of the powerful mesh=
metadata representation capabilities in MOAB. MOAB includes modules that =
import mesh in the ExodusII, CUBIT .cub and Vtk file formats, as well as th=
e capability to write mesh to ExodusII, all without licensing restrictions =
normally found in ExodusII-based applications. MOAB also has the capabilit=
y to represent and query structured mesh in a way that optimizes storage sp=
ace using the parametric space of a structured mesh; see Ref. [17] for deta=
ils.
=20
@@ -965,7 +967,7 @@ Initial results have demonstrated that the data abstrac=
tion provided by MOAB is
=20
\ref contents
=20
- \section references 12. References
+ \section references 12.References
=20
[1] M. Fatenejad and G.A. Moses, =E2=80=9CCooper radiation hydrodynamics c=
ode..=E2=80=9D
=20
@@ -1061,4 +1063,3 @@ Initial results have demonstrated that the data abstr=
action provided by MOAB is
These steps are sufficient for building MOAB against HDF5 and netCDF. By =
default, a small number of standard MOAB-based applications are also built,=
including mbconvert (a utility for reading and writing files), mbsize (for=
querying basic information about a mesh), and the iMesh interface (see Sec=
tion 7). Other utilities can be enabled using various other options to the=
configure script; for a complete list of build options, execute =E2=80=9C.=
/configure =E2=80=93help=E2=80=9D.
=20
*/
-
diff --git a/doc/user.dox.in b/doc/user.dox.in
index ed65208..b9f7e0c 100644
--- a/doc/user.dox.in
+++ b/doc/user.dox.in
@@ -305,8 +305,9 @@ WARN_LOGFILE =3D
# with spaces.
=20
INPUT =3D @top_srcdir@/src @top_srcdir@/src/moab \
- @top_srcdir@/doc/UG/moabUG.h \
+ @top_srcdir@/doc/UG \
@top_srcdir@/doc/DG \
+ @top_srcdir@/doc/MetaData \
@top_srcdir@/src/parallel/moab \
@top_srcdir@/src/MBTagConventions.hpp \
@top_srcdir@/src/MBCN.h \
Repository URL: https://bitbucket.org/fathomteam/moab/
--
This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.
More information about the moab-dev
mailing list