[MOAB-dev] commit/MOAB: janehu: Minor update for the metadata info.
commits-noreply at bitbucket.org
commits-noreply at bitbucket.org
Tue Jul 16 15:10:23 CDT 2013
1 new commit in MOAB:
https://bitbucket.org/fathomteam/moab/commits/713ca3906360/
Changeset: 713ca3906360
Branch: master
User: janehu
Date: 2013-07-16 22:09:19
Summary: Minor update for the metadata info.
Affected #: 3 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/MetaData/metadata.h b/doc/MetaData/metadata.h
index 0822485..5f53ecc 100644
--- a/doc/MetaData/metadata.h
+++ b/doc/MetaData/metadata.h
@@ -44,7 +44,7 @@ The MOAB data model consists of the following basic types:
=20
The following section describes each meta-data tag convention in detail; t=
hese conventions are also summarized in Table 1.
=20
-\ref meta-data-info "Top"
+\ref md-contents "Top"
=20
\section meta-conventions Meta-Data Conventions
=20
@@ -100,7 +100,7 @@ In the geometric model, each FACE is bounded by zero or=
more EDGEs; other topolo
=20
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.
=20
-<H3> >ense </H3>
+<H3> Sense </H3>
=20
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).
=20
@@ -180,7 +180,7 @@ The Spectral Element Method (SEM) is a high-order metho=
d, using a polynomial Leg
=20
.
=20
-\ref meta-data-info "Top"
+\ref md-contents "Top"
=20
\section meta-options Reader/Writer Options
=20
@@ -198,7 +198,7 @@ Indicates that no mesh should be read from the file. T=
his option is used in con
=20
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.
=20
-\ref meta-data-info "Top"
+\ref md-contents "Top"
=20
\section meta-references References
=20
@@ -206,7 +206,7 @@ Read the time step number whose time value is equal to =
or greater than the speci
=20
[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.
=20
-\ref meta-data-info "Top"
+\ref md-contents "Top"
=20
\section appendixA Appendix A: Summary
=20
@@ -395,7 +395,7 @@ GEOM_SENSE_N_SENSES/I*N</td></tr></table>
=20
-\ref meta-data-info "Top"
+\ref md-contents "Top"
=20
\section appendixB Appendix B: CCMIO (Star-CD, Star-CCM+) Reader/Writer =
Conventions
=20
@@ -494,7 +494,7 @@ GEOM_SENSE_N_SENSES/I*N</td>
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.
=20
-\ref meta-data-info "Top"
+\ref md-contents "Top"
=20
\section appendixC Appendix C: ExodusII Reader/Writer Conventions=20
=20
@@ -560,7 +560,7 @@ whether the right-hand normal points into or out of the=
element. Forward-sense f
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.
.
=20
- \ref meta-data-info "Top"
+ \ref md-contents "Top"
=20
\section appendixD Appendix D: NC (Climate Data) Reader/Writer Conventio=
ns
=20
@@ -722,7 +722,7 @@ __<var_name>_ATTRIBS tags
</tr></table>
=20
- \ref meta-data-info "Top"
+ \ref md-contents "Top"
=20
\section appendixE Appendix E: Nek5000 Reader/Writer Conventions
=20
@@ -815,7 +815,7 @@ nx*ny*nz values)
</td></tr></table>
- \ref meta-data-info "Top"
+ \ref md-contents "Top"
*/
=20
/*! \page md-tables List of Tables
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
*/
-
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