[MOAB-dev] commit/MOAB: 11 new changesets
commits-noreply at bitbucket.org
commits-noreply at bitbucket.org
Wed Jul 24 08:31:11 CDT 2013
11 new commits in MOAB:
https://bitbucket.org/fathomteam/moab/commits/71fbdcdc964e/
Changeset: 71fbdcdc964e
Branch: None
User: danwu
Date: 2013-07-02 19:37:19
Summary: Merged fathomteam/moab into master
Affected #: 1 file
diff --git a/src/io/NCHelperMPAS.cpp b/src/io/NCHelperMPAS.cpp
index 0d4573f..9c1f075 100644
--- a/src/io/NCHelperMPAS.cpp
+++ b/src/io/NCHelperMPAS.cpp
@@ -867,6 +867,7 @@ ErrorCode NCHelperMPAS::read_ucd_variable_to_nonset(Ent=
ityHandle file_set, std::
int success;
Range* pLocalGid =3D NULL;
// MPI_offset or size_t?
+ std::vector<int> requests(vdatas.size() * tstep_nums.size()), statuss(vd=
atas.size() * tstep_nums.size());
for (unsigned int i =3D 0; i < vdatas.size(); i++) {
switch (vdatas[i].entLoc) {
case ReadNC::ENTLOCVERT:
@@ -882,10 +883,7 @@ ErrorCode NCHelperMPAS::read_ucd_variable_to_nonset(En=
tityHandle file_set, std::
ERRORR(MB_FAILURE, "Unrecognized entity location type.");
break;
}
- }
=20
- std::vector<int> requests(vdatas.size() * tstep_nums.size()), statuss(vd=
atas.size() * tstep_nums.size());
- for (unsigned int i =3D 0; i < vdatas.size(); i++) {
for (unsigned int t =3D 0; t < tstep_nums.size(); t++) {
std::size_t sz =3D vdatas[i].numLev * vdatas[i].readCounts[t][1];
=20
https://bitbucket.org/fathomteam/moab/commits/3a7a2939e805/
Changeset: 3a7a2939e805
Branch: None
User: danwu
Date: 2013-07-02 20:19:54
Summary: Merged fathomteam/moab into master
Affected #: 1 file
diff --git a/test/io/read_mpas_nc.cpp b/test/io/read_mpas_nc.cpp
index 4ab8568..ffd168b 100644
--- a/test/io/read_mpas_nc.cpp
+++ b/test/io/read_mpas_nc.cpp
@@ -120,7 +120,14 @@ void test_read_all()
rval =3D mb.get_entities_by_type(0, MBPOLYGON, cells);
assert(rval =3D=3D MB_SUCCESS);
CHECK_EQUAL((size_t)642, cells.size());
+#ifdef USE_MPI
+ // If MOAB is compiled parallel, sequence size requested are increased
+ // by a factor of 1.5, to allow for ghosts. This will introduce a gap
+ // between the two face sequences.
CHECK_EQUAL((size_t)2, cells.psize());
+#else
+ CHECK_EQUAL((size_t)1, cells.psize());
+#endif
=20
// Check ke tag values on first pentagon and first hexagon
EntityHandle cell_ents[] =3D {cells[0], cells[12]};
@@ -161,7 +168,7 @@ void test_read_onetimestep()
CHECK_ERR(rval);
=20
opts +=3D std::string(";TIMESTEP=3D1");
- rval =3D mb.load_file( example, NULL, opts.c_str());
+ rval =3D mb.load_file(example, NULL, opts.c_str());
CHECK_ERR(rval);
=20
// Check for proper tags
https://bitbucket.org/fathomteam/moab/commits/005fc982b28c/
Changeset: 005fc982b28c
Branch: None
User: danwu
Date: 2013-07-15 15:48:25
Summary: Merged fathomteam/moab into master
Affected #: 19 files
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3774046..007d501 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -100,7 +100,30 @@ project( MOAB )
# iMesh
option ( MOAB_BUILD_IMESH "Build the iMesh interface?" =
ON )
=20
+ # check for MPI package
+ if ( MOAB_USE_MPI )
+ find_package( MPI )
+ # CMake FindMPI script is sorely lacking:
+ if ( MPI_LIBRARY AND MPI_INCLUDE_PATH )
+ set( MPI_FOUND 1 )
+ endif ( MPI_LIBRARY AND MPI_INCLUDE_PATH )
+
+ if ( MPI_FOUND )
+ set ( MOAB_DEFINES "${MOAB_DEFINES} -DUSE_MPI" )
+ endif ( MPI_FOUND )
+ endif ( MOAB_USE_MPI )
+
+ if ( MOAB_USE_NETCDF )
+ find_package( NetCDF )
+ endif ( MOAB_USE_NETCDF )
+
+ if ( MOAB_USE_HDF )
+ # HDF5
+ find_package( HDF5 )
+ endif ( MOAB_USE_HDF )
+
add_subdirectory( src )
+ add_subdirectory( itaps/imesh )
add_subdirectory( tools )
add_subdirectory( test )
- =20
+
diff --git a/MeshFiles/unittest/Makefile.am b/MeshFiles/unittest/Makefile.am
index f347315..16dc2ed 100644
--- a/MeshFiles/unittest/Makefile.am
+++ b/MeshFiles/unittest/Makefile.am
@@ -21,6 +21,8 @@ EXTRA_DIST =3D 125hex.g \
testtet.g \
ptest.cub \
64bricks_512hex.h5m \
+ 64bricks_1khex.h5m\
+ 64bricks_12ktet.h5m\
partBed.smf \
PB.h5m \
polyPB.txt \
@@ -28,5 +30,7 @@ EXTRA_DIST =3D 125hex.g \
quads.h5m \
SECrop2.h5m \
poly14.txt \
- BedCrop2.h5m
+ BedCrop2.h5m \
+ mpas_p8.h5m \
+ Homme_2pt.h5m
=20
diff --git a/MeshFiles/unittest/io/Makefile.am b/MeshFiles/unittest/io/Make=
file.am
index 8257e5f..fb8a265 100644
--- a/MeshFiles/unittest/io/Makefile.am
+++ b/MeshFiles/unittest/io/Makefile.am
@@ -18,6 +18,7 @@ EXTRA_DIST =3D HommeMapping.nc \
test.nas \
test.unv \
sample.stl \
- three.smf
+ three.smf \
+ mpasx1.642.t.2.nc
=20
=20
diff --git a/examples/DirectAccessNoHoles.cpp b/examples/DirectAccessNoHole=
s.cpp
index 340efae..55ab279 100644
--- a/examples/DirectAccessNoHoles.cpp
+++ b/examples/DirectAccessNoHoles.cpp
@@ -7,13 +7,13 @@
* and vertex to quad adjacency lists. This allows applications to access=
this data directly
* without going through MOAB's API. In cases where the mesh is not chang=
ing (or only mesh
* vertices are moving), this can save significant execution time in appli=
cations.
- *
+ * \verbatim
* ----------------------
* | | | | =20
* | | | | ...
* | | | |
* ----------------------
- *
+ * \endverbatim
* -# Initialize MOAB \n
* -# Create a quad mesh, as depicted above
* -# Create 2 dense tags (tag1, tag2) for avg position to assign to q=
uads, and # verts per quad (tag3)
diff --git a/examples/DirectAccessWithHoles.cpp b/examples/DirectAccessWith=
Holes.cpp
index 524c30f..1917b09 100644
--- a/examples/DirectAccessWithHoles.cpp
+++ b/examples/DirectAccessWithHoles.cpp
@@ -1,14 +1,14 @@
-/** @example DirectAccess.cpp \n
+/** @example DirectAccessWithHoles.cpp \n
* \brief Use direct access to MOAB data to avoid calling through API \n
*
* This example creates a 1d row of quad elements, with a user-specified n=
umber of "holes" (missing quads) in the row:
- *
+ * \verbatim
* ---------------------- ---------------------- --------
* | | | | | | | | | | =20
* | | | |(hole)| | | |(hole)| | ...
* | | | | | | | | | |
* ---------------------- ---------------------- --------
- *
+ * \endverbatim
* This makes (nholes+1) contiguous runs of quad handles in the handle spa=
ce
* This example shows how to use the xxx_iterate functions in MOAB (xxx =
=3D coords, connect, tag, adjacencies) to get=20
* direct pointer access to MOAB internal storage, which can be used witho=
ut calling through the MOAB API.
diff --git a/itaps/imesh/CMakeLists.txt b/itaps/imesh/CMakeLists.txt
index a258e9f..5bba3f0 100644
--- a/itaps/imesh/CMakeLists.txt
+++ b/itaps/imesh/CMakeLists.txt
@@ -1,60 +1,61 @@
=20
# Generate Fortran name mangling headers
-ADD_CUSTOM_COMMAND(=20
+ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/iMesh_protos.h
- COMMAND ${CMAKE_COMMAND}=20
- -Dinput_file:STRING=3D${CMAKE_CURRENT_SOURCE_DIR}/iMesh.h=20
- -Doutput_file:STRING=3D${CMAKE_CURRENT_BINARY_DIR}/iMesh_protos.=
h=20
- -Dprefix:STRING=3DiMesh=20
- -P ${CMAKE_SOURCE_DIR}/cmake/ITAPSFortranMangling.cmake
+ COMMAND ${CMAKE_COMMAND}
+ -Dinput_file:STRING=3D${CMAKE_CURRENT_SOURCE_DIR}/iMesh.h
+ -Doutput_file:STRING=3D${CMAKE_CURRENT_BINARY_DIR}/iMesh_protos.h
+ -Dprefix:STRING=3DiMesh
+ -P ${CMAKE_SOURCE_DIR}/config/ITAPSFortranMangling.cmake
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/iMesh.h
)
-ADD_CUSTOM_COMMAND(=20
+ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/iMesh_extensions_protos.h
- COMMAND ${CMAKE_COMMAND}=20
- -Dinput_file:STRING=3D${CMAKE_CURRENT_SOURCE_DIR}/iMesh_extensio=
ns.h=20
- -Doutput_file:STRING=3D${CMAKE_CURRENT_BINARY_DIR}/iMesh_extensi=
ons_protos.h=20
- -Dprefix:STRING=3DiMesh=20
- -P ${CMAKE_SOURCE_DIR}/cmake/ITAPSFortranMangling.cmake
+ COMMAND ${CMAKE_COMMAND}
+ -Dinput_file:STRING=3D${CMAKE_CURRENT_SOURCE_DIR}/iMesh_extensio=
ns.h
+ -Doutput_file:STRING=3D${CMAKE_CURRENT_BINARY_DIR}/iMesh_extensi=
ons_protos.h
+ -Dprefix:STRING=3DiMesh
+ -P ${CMAKE_SOURCE_DIR}/config/ITAPSFortranMangling.cmake
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/iMesh_extensions.h
)
-ADD_CUSTOM_COMMAND(=20
+ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/iMeshP_protos.h
- COMMAND ${CMAKE_COMMAND}=20
- -Dinput_file:STRING=3D${CMAKE_CURRENT_SOURCE_DIR}/iMeshP.h=20
- -Doutput_file:STRING=3D${CMAKE_CURRENT_BINARY_DIR}/iMeshP_protos=
.h=20
- -Dprefix:STRING=3DiMeshP=20
- -P ${CMAKE_SOURCE_DIR}/cmake/ITAPSFortranMangling.cmake
+ COMMAND ${CMAKE_COMMAND}
+ -Dinput_file:STRING=3D${CMAKE_CURRENT_SOURCE_DIR}/iMeshP.h
+ -Doutput_file:STRING=3D${CMAKE_CURRENT_BINARY_DIR}/iMeshP_protos=
.h
+ -Dprefix:STRING=3DiMeshP
+ -P ${CMAKE_SOURCE_DIR}/config/ITAPSFortranMangling.cmake
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/iMeshP.h
)
=20
-set ( MOAB_IMESH_SRCS=20
+set ( MOAB_IMESH_SRCS
iMesh_MOAB.cpp
${CMAKE_CURRENT_BINARY_DIR}/iMesh_protos.h
${CMAKE_CURRENT_BINARY_DIR}/iMesh_extensions_protos.h
${CMAKE_CURRENT_BINARY_DIR}/iMeshP_protos.h )
=20
+include_directories(
+ ${MOAB_SOURCE_DIR}/src
+ ${MOAB_SOURCE_DIR}/itaps
+ ${MOAB_SOURCE_DIR}/itaps/imesh
+ )
+
if ( MOAB_USE_MPI AND MPI_FOUND )
- LIST ( APPEND MOAB_IMESH_SRCS=20
+ LIST ( APPEND MOAB_IMESH_SRCS
iMeshP_MOAB.cpp
${CMAKE_CURRENT_BINARY_DIR}/iMeshP_protos.h )
+
+ include_directories(
+ ${MOAB_SOURCE_DIR}/src/parallel
+ )
endif ( MOAB_USE_MPI AND MPI_FOUND )
- =20
-
-include_directories( ${CMAKE_SOURCE_DIR}
- ${CMAKE_BINARY_DIR}
- ${CMAKE_SOURCE_DIR}/parallel
- ${CMAKE_BINARY_DIR}/parallel
- ${CMAKE_CURRENT_SOURCE_DIR}
- ${CMAKE_CURRENT_BINARY_DIR}
- )
- =20
-
-set_source_files_properties(
- ${MOAB_IMESH_SRCS}
+
+set_source_files_properties( ${MOAB_IMESH_SRCS}
COMPILE_FLAGS "${MOAB_DEFINES}"
)
=20
add_library( iMesh
${MOAB_IMESH_SRCS}
)
+
+target_link_libraries( iMesh MOAB )
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index a1993c9..c5467e6 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -1,6 +1,6 @@
=20
# MOAB Library
- set ( MOAB_LIB_SRCS
+ set ( MOABCORE_LIB_SRCS
AdaptiveKDTree.cpp
AEntityFactory.cpp
AffineXform.cpp
@@ -31,7 +31,6 @@
PolyElementSeq.cpp
Range.cpp
RangeSeqIntersectIter.cpp
- ReaderWriterSet.cpp
ReadUtil.cpp
ScdElementData.cpp
ScdInterface.cpp
@@ -57,7 +56,13 @@
WriteUtil.cpp
)
=20
- add_subdirectory( io )
+ set ( MOABPTLOC_LIB_SRCS
+ lotte/findpt.c
+ lotte/errmem.c
+ lotte/poly.c
+ lotte/tensor.c
+ )
+
set ( MOABIO_LIB_SRCS
io/IODebugTrack.cpp
io/ExoIIUtil.cpp
@@ -65,6 +70,7 @@
io/GmshUtil.cpp
io/ReadABAQUS.cpp
io/ReadGmsh.cpp
+ io/ReadGCRM.cpp
io/ReadIDEAS.cpp
io/ReadMCNP5.cpp
io/ReadNASTRAN.cpp
@@ -85,97 +91,68 @@
io/WriteSmf.cpp
io/WriteTemplate.cpp
io/WriteVtk.cpp
+ ReaderWriterSet.cpp
)
include_directories(
${MOAB_SOURCE_DIR}/src
${MOAB_SOURCE_DIR}/src/io
${MOAB_SOURCE_DIR}/src/parallel
+ ${MOAB_SOURCE_DIR}/src/moab/point_locater/lotte
)
=20
- if ( MOAB_USE_MPI )
- find_package( MPI )
- # CMake FindMPI script is sorely lacking:
- if ( MPI_LIBRARY AND MPI_INCLUDE_PATH )
- set( MPI_FOUND 1 )
- endif ( MPI_LIBRARY AND MPI_INCLUDE_PATH )
-
- if ( MPI_FOUND )
- set ( MOAB_DEFINES "${MOAB_DEFINES} -DUSE_MPI" )
- include_directories(
- ${MPI_INCLUDE_PATH}
- ${MOAB_SOURCE_DIR}/parallel
- )
- endif ( MPI_FOUND )
- endif ( MOAB_USE_MPI )
+ if ( NetCDF_FOUND )
+ set ( MOAB_DEFINES "${MOAB_DEFINES} -DNETCDF_FILE" )
+ set ( MOABIO_LIB_SRCS
+ ${MOABIO_LIB_SRCS}
+ io/ReadNC.cpp
+ io/ReadNCDF.cpp
+ io/WriteNCDF.cpp
+ io/WriteSLAC.cpp
+ io/NCHelper.cpp
+ io/NCHelperEuler.cpp
+ io/NCHelperFV.cpp
+ io/NCHelperHOMME.cpp
+ SpectralMeshTool.cpp
+ )
+ include_directories(
+ ${NetCDF_INCLUDE_DIRECTORIES}
+ )
+ endif ( NetCDF_FOUND )
+
+ if ( HDF5_FOUND )
+ set ( MOAB_DEFINES "${MOAB_DEFINES} -DHDF5_FILE" )
+ check_function_exists( H5Pset_fapl_mpio MOAB_HDF_HAVE_PARALLEL )
+ set ( MOABIO_LIB_SRCS
+ ${MOABIO_LIB_SRCS}
+ io/HDF5Common.cpp
+ io/ReadHDF5.cpp
+ io/ReadHDF5Dataset.cpp
+ io/ReadHDF5VarLen.cpp
+ io/WriteHDF5.cpp
+ )
+
+ include_directories(
+ ${HDF5_INCLUDE_DIRECTORIES}
+ io/mhdf/include
+ )
+ add_subdirectory( io/mhdf )
+ endif ( HDF5_FOUND )
+
+
+ SET(MOAB_LIB_SRCS ${MOABCORE_LIB_SRCS} ${MOABPTLOC_LIB_SRCS} ${MOABIO_LI=
B_SRCS})
=20
set_source_files_properties( ${MOAB_LIB_SRCS}
COMPILE_FLAGS "-DIS_BUILDING_MB ${MOAB_DEFINES}"
)
-
-# target_link_libraries( MOAB moabio )
- if ( MOAB_USE_NETCDF )
- find_package( NetCDF )
- if ( NetCDF_FOUND )
- set ( MOAB_DEFINES "${MOAB_DEFINES} -DNETCDF_FILE" )
- set ( MOABIO_LIB_SRCS
- ${MOABIO_LIB_SRCS}
- io/ReadNCDF.cpp
- io/WriteNCDF.cpp
- io/WriteSLAC.cpp
- )
- include_directories(
- ${NetCDF_INCLUDE_DIRECTORIES}
- )
- endif ( NetCDF_FOUND )
- endif ( MOAB_USE_NETCDF )
-
- if ( MOAB_USE_HDF )
- # HDF5
- find_package( HDF5 )
- if ( HDF5_FOUND )
- set ( MOAB_DEFINES "${MOAB_DEFINES} -DHDF5_FILE" )
- check_function_exists( H5Pset_fapl_mpio MOAB_HDF_HAVE_PARALLEL )
- set ( MOABIO_LIB_SRCS
- ${MOABIO_LIB_SRCS}
- io/HDF5Common.cpp
- io/ReadHDF5.cpp
- io/ReadHDF5Dataset.cpp
- io/ReadHDF5VarLen.cpp
- io/WriteHDF5.cpp
- )
-
-# if ( MOAB_USE_MPI AND MPI_FOUND )
-# set ( MOABIO_LIB_SRCS
-# ${MOABIO_LIB_SRCS}
-# src/parallel/WriteHDF5Parallel.cpp
-# )
-# endif (MOAB_USE_MPI AND MPI_FOUND)
-
- include_directories(
- ${HDF5_INCLUDE_DIRECTORIES}
- io/mhdf/include
- )
- add_subdirectory( io/mhdf )
- endif ( HDF5_FOUND )
- endif ( MOAB_USE_HDF )
-
- set_source_files_properties( ${MOABIO_LIB_SRCS}
- COMPILE_FLAGS "-DIS_BUILDING_MB ${MOAB_DEFINES}"
- )
-
add_library( MOAB
${MOAB_LIB_SRCS}
- ${MOABIO_LIB_SRCS}
)
=20
if ( MOAB_USE_NETCDF AND NetCDF_FOUND )
- MESSAGE( "Adding NetCDF dependency libraries: ${NetCDF_LIBRARIES}" )
target_link_libraries( MOAB ${NetCDF_LIBRARIES} )
endif ( MOAB_USE_NETCDF AND NetCDF_FOUND )
=20
if ( MOAB_USE_HDF AND HDF5_FOUND )
- MESSAGE( "Adding NetCDF dependency libraries: ${HDF5_LIBRARIES}" )
-# add_dependencies( MOAB mhdf )
target_link_libraries( MOAB mhdf ${HDF5_LIBRARIES} )
endif ( MOAB_USE_HDF AND HDF5_FOUND )
=20
diff --git a/src/Makefile.am b/src/Makefile.am
index d4ac22d..7cebb7c 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -177,6 +177,7 @@ nobase_libMOAB_la_include_HEADERS =3D \
moab/point_locater/lotte/findpt.h \
moab/point_locater/lotte/poly.h \
moab/point_locater/point_locater.hpp \
+ moab/point_locater/parametrizer.hpp \
moab/Matrix3.hpp \
moab/MergeMesh.hpp \
moab/MeshTopoUtil.hpp \
diff --git a/src/io/NCHelper.cpp b/src/io/NCHelper.cpp
index e0eae99..87cc690 100644
--- a/src/io/NCHelper.cpp
+++ b/src/io/NCHelper.cpp
@@ -323,7 +323,9 @@ ErrorCode ScdNCHelper::check_existing_mesh(EntityHandle=
file_set) {
ErrorCode rval =3D mbImpl->get_number_entities_by_dimension(file_set, 0,=
num_verts);
ERRORR(rval, "Trouble getting number of vertices.");
=20
+ /*
// Check against parameters
+ // When ghosting is used, this check might fail (to be updated later)
if (num_verts > 0)
{
int expected_verts =3D (lDims[3] - lDims[0] + 1) * (lDims[4] - lDims[1=
] + 1) * (-1 =3D=3D lDims[2] ? 1 : lDims[5] - lDims[2] + 1);
@@ -331,6 +333,7 @@ ErrorCode ScdNCHelper::check_existing_mesh(EntityHandle=
file_set) {
ERRORR(MB_FAILURE, "Number of vertices doesn't match.");
}
}
+ */
=20
// Check the number of elements too
int num_elems;
@@ -339,6 +342,7 @@ ErrorCode ScdNCHelper::check_existing_mesh(EntityHandle=
file_set) {
=20
/*
// Check against parameters
+ // The expected number of elements calculated below is incorrect (to be =
updated later)
if (num_elems > 0)
{
int expected_elems =3D (lDims[3] - lDims[0]) * (lDims[4] - lDims[1]) *=
(-1 =3D=3D lDims[2] ? 1 : lDims[5] - lDims[2]);
diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
index 3b1d28d..e6c2d94 100644
--- a/test/CMakeLists.txt
+++ b/test/CMakeLists.txt
@@ -43,9 +43,9 @@
=20
if ( MOAB_USE_MPI AND MPI_FOUND )
=20
- add_executable ( mbparallelcomm_test mbparallelcomm_test.cpp )
+ add_executable ( mbparallelcomm_test parallel/mbparallelcomm_test.cpp )
target_link_libraries( mbparallelcomm_test MOAB )
- set_source_files_properties( mbparallelcomm_test.cpp
+ set_source_files_properties( parallel/mbparallelcomm_test.cpp
COMPILE_FLAGS "-DIS_BUILDING_MB ${MOAB_DEFINES}" )
add_test( TestParallelComm-BcastDelete
${MPIEXEC} ${MPIEXEC_NUMPROC_FLAG} 2 ${MPIEXEC_PREFLAGS}
@@ -61,19 +61,22 @@ if ( MOAB_USE_MPI AND MPI_FOUND )
${EXECUTABLE_OUTPUT_PATH}/mbparallelcomm_test ${MPIEXEC_POSTFLAGS} -3 =
${MOAB_SOURCE_DIR}/parallel/ptest.cub )
=20
if ( MOAB_USE_HDF )
- add_executable( mhdf_parallel mhdf_parallel.c )
+ add_executable( mhdf_parallel parallel/mhdf_parallel.c )
+ include_directories(
+ ${MOAB_SOURCE_DIR}/src/io/mhdf/include
+ )
target_link_libraries( mhdf_parallel MOAB MOABpar mhdf )
add_test( TestMHDFParallel ${EXECUTABLE_OUTPUT_PATH}/mhdf_parallel )
- set_source_files_properties( mhdf_parallel.c
+ set_source_files_properties( parallel/mhdf_parallel.c
COMPILE_FLAGS "-DIS_BUILDING_MB ${MOAB_DEFINES}" )
endif ( MOAB_USE_HDF )
=20
- add_executable ( parallel_unit_tests parallel_unit_tests.cpp )
+ add_executable ( parallel_unit_tests parallel/parallel_unit_tests.cpp )
target_link_libraries( parallel_unit_tests MOAB )
add_test( TestParallel
${MPIEXEC} ${MPIEXEC_NUMPROC_FLAG} 2 ${MPIEXEC_PREFLAGS}
${EXECUTABLE_OUTPUT_PATH}/parallel_unit_tests ${MPIEXEC_POSTFLAGS} ${M=
OAB_SOURCE_DIR}/parallel/ptest.cub )
- set_source_files_properties( parallel_unit_tests.cpp
+ set_source_files_properties( parallel/parallel_unit_tests.cpp
COMPILE_FLAGS "-DIS_BUILDING_MB ${MOAB_DEFINES}" )
=20
endif ( MOAB_USE_MPI AND MPI_FOUND )
diff --git a/test/parallel/Makefile.am b/test/parallel/Makefile.am
index 72fb443..cde37b0 100644
--- a/test/parallel/Makefile.am
+++ b/test/parallel/Makefile.am
@@ -103,4 +103,16 @@ if ENABLE_mbcslam
par_intx_sph_LDADD =3D $(LDADD) ../../tools/mbcoupler/libmbcoupler.la ..=
/../tools/mbcslam/libmbcslam.la =20
endif
# Other files to clean up (e.g. output from tests)
-MOSTLYCLEANFILES =3D mhdf_ll.h5m tmp0.h5m tmp1.h5m tmp2.h5m tmp3.h5m
+MOSTLYCLEANFILES =3D mhdf_ll.h5m tmp0.h5m tmp1.h5m tmp2.h5m tmp3.h5m \
+ partial0.vtk \
+ partial1.vtk \
+ partialConvex1.vtk \
+ partialConvex0.vtk \
+ initial0.vtk \
+ intersect1.h5m \
+ intersect0.h5m \
+ test.h5m \
+ initial1.vtk \
+ test_mpas.h5m \
+ dum.h5m
+ =20
diff --git a/test/parallel/par_intx_sph.cpp b/test/parallel/par_intx_sph.cpp
index f5c4b22..dca936e 100644
--- a/test/parallel/par_intx_sph.cpp
+++ b/test/parallel/par_intx_sph.cpp
@@ -169,9 +169,10 @@ void test_intx_in_parallel_elem_based()
std::string example(TestDir + "/" + input_mesh_file);
=20
rval =3D mb.load_file(example.c_str(), &euler_set, opts.c_str());
+ CHECK_ERR(rval);
=20
ParallelComm* pcomm =3D ParallelComm::get_pcomm(&mb, 0);
- CHECK_ERR(rval);
+ CHECK( NULL!=3Dpcomm );
=20
rval =3D pcomm->check_all_shared_handles();
CHECK_ERR(rval);
diff --git a/tools/CMakeLists.txt b/tools/CMakeLists.txt
index 1f30dcf..56e115c 100644
--- a/tools/CMakeLists.txt
+++ b/tools/CMakeLists.txt
@@ -1,4 +1,4 @@
- =20
+
# Documentation
# Optional tools
option ( MOAB_BUILD_MBCONVERT "Build the MOAB mesh converter tool?" =
ON )
@@ -17,8 +17,8 @@
=20
if ( MOAB_USE_MPI AND MPI_FOUND )
add_subdirectory( refiner )
- include_directories( ${MOAB_SOURCE_DIR}/refiner )
- target_link_libraries( MOAB MOABrefiner )
+# include_directories( ${MOAB_SOURCE_DIR}/refiner )
+# target_link_libraries( MOAB MOABrefiner )
endif ( MOAB_USE_MPI AND MPI_FOUND )
=20
=20
@@ -37,5 +37,6 @@
=20
# MBCoupler
if ( MOAB_USE_MPI AND MPI_FOUND AND MOAB_BUILD_MBCOUPLER )
+# if ( MOAB_BUILD_MBCOUPLER )
add_subdirectory( mbcoupler )
endif ( MOAB_USE_MPI AND MPI_FOUND AND MOAB_BUILD_MBCOUPLER )
diff --git a/tools/mbcoupler/CMakeLists.txt b/tools/mbcoupler/CMakeLists.txt
index 93e97d1..9c4279d 100644
--- a/tools/mbcoupler/CMakeLists.txt
+++ b/tools/mbcoupler/CMakeLists.txt
@@ -1,26 +1,29 @@
include_directories(
- ${CMAKE_CURRENT_SOURCE_DIRECTORY}
+ ${MOAB_SOURCE_DIR}/src
+ ${MOAB_SOURCE_DIR}/src/parallel
+ ${MOAB_SOURCE_DIR}/src/moab/point_locater/lotte
+ ${MOAB_SOURCE_DIR}/itaps
+ ${MOAB_SOURCE_DIR}/itaps/imesh
+ ${MOAB_SOURCE_DIR}/tools/mbcoupler
)
=20
set( MBCOUPLER_SRCS
Coupler.cpp
ElemUtil.cpp
- errmem.cpp
- findpt.c
- poly.c
- tensor.c
+)
+
+set_source_files_properties( ${MBCOUPLER_SRCS}
+ COMPILE_FLAGS "${MOAB_DEFINES}"
)
=20
add_library( mbcoupler
${MBCOUPLER_SRCS}
)
-target_link_libraries( mbcoupler MOAB )
+
+target_link_libraries( mbcoupler MOAB iMesh )
if ( MOAB_USE_MPI )
target_link_libraries( mbcoupler MOABpar )
endif ( MOAB_USE_MPI )
-set_source_files_properties( ${MBCOUPLER_SRCS}
- COMPILE_FLAGS "${MOAB_DEFINES}"
-)
=20
enable_testing()
=20
@@ -39,4 +42,10 @@ if ( MOAB_USE_MPI )
COMPILE_FLAGS "${MOAB_DEFINES}" )
target_link_libraries( mbcoupler_test mbcoupler MOAB MOABpar )
add_test( TestMBCoupler ${EXECUTABLE_OUTPUT_PATH}/mbcoupler_test )
+
+ add_executable( ssn_test ssn_test.cpp )
+ set_source_files_properties( ssn_test.cpp
+ COMPILE_FLAGS "${MOAB_DEFINES}" )
+ target_link_libraries( ssn_test mbcoupler MOAB MOABpar )
+ add_test( TestMBCoupler ${EXECUTABLE_OUTPUT_PATH}/ssn_test )
endif ( MOAB_USE_MPI )
diff --git a/tools/mbcslam/CslamUtils.cpp b/tools/mbcslam/CslamUtils.cpp
index 1166a7a..70d81ed 100644
--- a/tools/mbcslam/CslamUtils.cpp
+++ b/tools/mbcslam/CslamUtils.cpp
@@ -11,6 +11,7 @@
// right now, add a dependency to mbcoupler
#include "ElemUtil.hpp"
#include "moab/MergeMesh.hpp"
+#include "moab/ReadUtilIface.hpp"
=20
// this is for sstream
#include <sstream>
@@ -991,5 +992,145 @@ ErrorCode enforce_convexity(Interface * mb, EntityHan=
dle lset)
std::cout << brokenPolys << " concave polygons were decomposed in convex=
ones \n";
return MB_SUCCESS;
}
+ErrorCode create_span_quads(Interface * mb, EntityHandle euler_set, int ra=
nk)
+{
+ // first get all edges adjacent to polygons
+ Tag dpTag =3D 0;
+ std::string tag_name("DP");
+ ErrorCode rval =3D mb->tag_get_handle(tag_name.c_str(), 3, MB_TYPE_DOUBL=
E, dpTag, MB_TAG_DENSE);
+ // if the tag does not exist, get out early
+ if (rval!=3DMB_SUCCESS)
+ return rval;
+ Range polygons;
+ rval =3D mb->get_entities_by_dimension(euler_set, 2, polygons);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+ Range iniEdges;
+ rval =3D mb->get_adjacencies(polygons,
+ 1,
+ false,
+ iniEdges,
+ Interface::UNION);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+ // now create some if missing
+ Range allEdges;
+ rval =3D mb->get_adjacencies(polygons,
+ 1,
+ true,
+ allEdges,
+ Interface::UNION);
+ // create the vertices at the DP points, and the quads after that
+ Range verts;
+ rval =3D mb->get_connectivity(polygons, verts);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+ int num_verts =3D (int) verts.size();
+ // now see the departure points; to what boxes should we send them?
+ std::vector<double> dep_points(3*num_verts);
+ rval =3D mb->tag_get_data(dpTag, verts, (void*)&dep_points[0]);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+
+ // create vertices corresponding to dp locations
+ ReadUtilIface *read_iface;
+ rval =3D mb->query_interface(read_iface);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+ std::vector<double *> coords;
+ EntityHandle start_vert, start_elem, *connect;
+ // create verts, num is 2(nquads+1) because they're in a 1d row; will =
initialize coords in loop over quads later
+ rval =3D read_iface->get_node_coords (3, num_verts, 0, start_vert, coord=
s);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+ // fill it up
+ for (int i=3D0; i<num_verts; i++)
+ {
+ // block from interleaved
+ coords[0][i]=3Ddep_points[3*i];
+ coords[1][i]=3Ddep_points[3*i+1];
+ coords[2][i]=3Ddep_points[3*i+2];
+ }
+ // create quads; one quad for each edge
+ rval =3D read_iface->get_element_connect(allEdges.size(), 4, MBQUAD, 0, =
start_elem, connect);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+
+ const EntityHandle * edge_conn =3D NULL;
+ int quad_index=3D0;
+ EntityHandle firstVertHandle =3D verts[0];// assume vertices are contigu=
ous...
+ for (Range::iterator eit=3DallEdges.begin(); eit!=3DallEdges.end(); eit+=
+, quad_index++)
+ {
+ EntityHandle edge=3D*eit;
+ int num_nodes;
+ rval =3D mb->get_connectivity(edge, edge_conn, num_nodes);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+ connect[quad_index*4] =3D edge_conn[0];
+ connect[quad_index*4+1] =3D edge_conn[1];
=20
+ // maybe some indexing in range?
+ connect[quad_index*4+2] =3D start_vert + edge_conn[1]- firstVertHandle;
+ connect[quad_index*4+3] =3D start_vert + edge_conn[0]- firstVertHandle;
+ }
+
+
+ Range quads(start_elem, start_elem+allEdges.size()-1);
+ EntityHandle outSet;
+ rval =3D mb->create_meshset(MESHSET_SET, outSet);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+ mb->add_entities(outSet, quads);
+
+ Tag colTag;
+ rval =3D mb->tag_get_handle("COLOR_ID", 1, MB_TYPE_INTEGER,
+ colTag, MB_TAG_DENSE|MB_TAG_CREAT);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+ int j=3D1;
+ for (Range::iterator itq=3Dquads.begin(); itq!=3Dquads.end(); itq++, j++)
+ {
+ EntityHandle q=3D*itq;
+ rval =3D mb->tag_set_data(colTag, &q, 1, &j);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+ }
+ std::stringstream outf;
+ outf << "SpanQuads" << rank << ".h5m";
+ rval =3D mb->write_file(outf.str().c_str(), 0, 0, &outSet, 1);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+ EntityHandle outSet2;
+ rval =3D mb->create_meshset(MESHSET_SET, outSet2);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+
+ Range quadEdges;
+ rval =3D mb->get_adjacencies(quads,
+ 1,
+ true,
+ quadEdges,
+ Interface::UNION);
+ mb->add_entities(outSet2, quadEdges);
+
+ std::stringstream outf2;
+ outf2 << "SpanEdges" << rank << ".h5m";
+ rval =3D mb->write_file(outf2.str().c_str(), 0, 0, &outSet2, 1);
+ if (MB_SUCCESS !=3D rval)
+ return rval;
+
+// maybe some clean up
+ mb->delete_entities(&outSet, 1);
+ mb->delete_entities(&outSet2, 1);
+ mb->delete_entities(quads);
+ Range new_edges=3Dsubtract(allEdges, iniEdges);
+ mb->delete_entities(new_edges);
+ new_edges=3Dsubtract(quadEdges, iniEdges);
+ mb->delete_entities(new_edges);
+ Range new_verts(start_vert, start_vert+num_verts);
+ mb->delete_entities(new_verts);
+
+ return MB_SUCCESS;
+
+}
} //namespace moab
diff --git a/tools/mbcslam/CslamUtils.hpp b/tools/mbcslam/CslamUtils.hpp
index c32a264..241fe84 100644
--- a/tools/mbcslam/CslamUtils.hpp
+++ b/tools/mbcslam/CslamUtils.hpp
@@ -130,5 +130,9 @@ void departure_point_case1(CartVect & arrival_point, do=
uble t, double delta_t, C
// maybe radius is not needed;
//
ErrorCode enforce_convexity(Interface * mb, EntityHandle set);
+
+// looking at DP tag, create the spanning quads, write a file (with rank) =
and
+// then delete the new entities (vertices) and the set of quads
+ErrorCode create_span_quads(Interface * mb, EntityHandle euler_set, int ra=
nk);
}
#endif /* CSLAMUTILS_HPP_ */
diff --git a/tools/mbcslam/Makefile.am b/tools/mbcslam/Makefile.am
index 48c122e..68a1812 100644
--- a/tools/mbcslam/Makefile.am
+++ b/tools/mbcslam/Makefile.am
@@ -56,4 +56,21 @@ process_arm_SOURCES =3D process_arm.cpp
=20
cslam_par_test_SOURCES =3D cslam_par_test.cpp
cslam_par_test_LDADD =3D $(LDADD) $(top_builddir)/tools/mbcoupler/libmbcou=
pler.la=20
+EXTRA_DIST =3D lagrangeHomme.vtk \
+ eulerHomme.vtk \
+ m1.vtk \
+ m2.vtk=20
=20
+# Other files to clean up (e.g. output from tests)
+MOSTLYCLEANFILES =3D intersect1.h5m \
+ lagr.h5m \
+ polyWithEdges.vtk \
+ lagr00.h5m \
+ intersect00.h5m \
+ lagrIni.h5m \
+ intx.vtk \
+ spectral.vtk \
+ intx1.vtk \
+ SpanEdges0.h5m \
+ SpanQuads0.h5m=20
+ =20
diff --git a/tools/mbcslam/intx_mpas.cpp b/tools/mbcslam/intx_mpas.cpp
index 4bc742a..827871b 100644
--- a/tools/mbcslam/intx_mpas.cpp
+++ b/tools/mbcslam/intx_mpas.cpp
@@ -112,9 +112,9 @@ ErrorCode manufacture_lagrange_mesh_on_sphere(Interface=
* mb,
ptr_DP[2]=3DnewPos[2];
ptr_DP+=3D3; // increment to the next node
}
-
return rval;
}
+
int main(int argc, char **argv)
{
=20
@@ -170,6 +170,11 @@ int main(int argc, char **argv)
rval =3D manufacture_lagrange_mesh_on_sphere(&mb, euler_set);
if (MB_SUCCESS !=3D rval)
return 1;
+ // create a set with quads corresponding to each initial edge spanned wi=
th the displacement field
+
+ rval =3D create_span_quads(&mb, euler_set, rank);
+ if (MB_SUCCESS !=3D rval)
+ return 1;
=20
EntityHandle covering_lagr_set;
rval =3D mb.create_meshset(MESHSET_SET, covering_lagr_set);
diff --git a/tools/refiner/CMakeLists.txt b/tools/refiner/CMakeLists.txt
index 5c41c27..230b34c 100644
--- a/tools/refiner/CMakeLists.txt
+++ b/tools/refiner/CMakeLists.txt
@@ -1,4 +1,4 @@
-set ( MOAB_REFINER_SRCS=20
+set ( MOAB_REFINER_SRCS
EdgeSizeEvaluator.cpp
EdgeSizeSimpleImplicit.cpp
EntityRefiner.cpp
@@ -11,6 +11,11 @@ set ( MOAB_REFINER_SRCS
SplitVertices.cpp
)
=20
+include_directories(
+ ${MOAB_SOURCE_DIR}/src
+ ${MOAB_SOURCE_DIR}/src/parallel
+)
+
set_source_files_properties(
${MOAB_REFINER_SRCS}
COMPILE_FLAGS "${MOAB_DEFINES}"
@@ -19,6 +24,10 @@ set_source_files_properties(
add_library( MOABrefiner
${MOAB_REFINER_SRCS}
)
+target_link_libraries( MOABrefiner MOAB )
+if ( MOAB_USE_MPI )
+ target_link_libraries( MOABrefiner MOABpar )
+endif ( MOAB_USE_MPI )
=20
enable_testing()
=20
@@ -26,6 +35,7 @@ add_executable( test_mesh_refiner test_mesh_refiner.cpp )
set_source_files_properties( test_mesh_refiner.cpp
COMPILE_FLAGS "-DTEST ${MOAB_DEFINES}" )
target_link_libraries( test_mesh_refiner MOAB MOABrefiner )
+
add_test( TestMeshRefiner
${MPIEXEC} ${MPIEXEC_NUMPROC_FLAG} 4 ${MPIEXEC_PREFLAGS}
${EXECUTABLE_OUTPUT_PATH}/test_mesh_refiner ${MPIEXEC_POSTFLAGS}
https://bitbucket.org/fathomteam/moab/commits/ac77a57b8823/
Changeset: ac77a57b8823
Branch: None
User: danwu
Date: 2013-07-17 20:37:35
Summary: Revision d018f20 has caused some ParGAL tests for Eulerian Spe=
ctral grid to fail. To detect such kind of regressions, MOAB unit test read=
_nc.cpp is updated to check some values of tag T0 read from camEul26x48x96.=
t3.nc. This new test will pass on revisions before d018f20, fail on revisio=
n d018f20, and pass on revisions after f6aef30.
Affected #: 1 file
diff --git a/test/io/read_nc.cpp b/test/io/read_nc.cpp
index 558958c..caff6a4 100644
--- a/test/io/read_nc.cpp
+++ b/test/io/read_nc.cpp
@@ -13,6 +13,7 @@ static const char example_fv[] =3D "/io/fv26x46x72.t.3.nc=
";
=20
#ifdef USE_MPI
#include "moab_mpi.h"
+#include "moab/ParallelComm.hpp"
#endif
=20
// CAM-EUL
@@ -40,7 +41,7 @@ int main(int argc, char* argv[])
if (fail)
return 1;
#else
- argv[0] =3D argv[argc - argc]; // to remove the warnings in serial mode =
about unused variables
+ argv[0] =3D argv[argc - argc]; // To remove the warnings in serial mode =
about unused variables
#endif
=20
result +=3D RUN_TEST(test_read_eul_all);
@@ -58,7 +59,8 @@ int main(int argc, char* argv[])
=20
#ifdef USE_MPI
fail =3D MPI_Finalize();
- if (fail) return 1;
+ if (fail)
+ return 1;
#endif
=20
return result;
@@ -76,7 +78,7 @@ void test_read_eul_all()
rval =3D mb.load_file(example_eul, NULL, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tags
+ // Check for proper tags
Tag Ttag0, Ttag1, coordTag;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_ERR(rval);
@@ -100,13 +102,58 @@ void test_read_eul_onevar()
rval =3D mb.load_file(example_eul, NULL, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tags
+ // Check for proper tags
Tag Ttag0, Ttag1;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_ERR(rval);
=20
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_ERR(rval);
+
+ // Check values of tag T0 (first level) at some strategically chosen pla=
ces below
+ int rank =3D 0;
+ int procs =3D 1;
+#ifdef USE_MPI
+ ParallelComm* pcomm =3D ParallelComm::get_pcomm(&mb, 0);
+ rank =3D pcomm->proc_config().proc_rank();
+ procs =3D pcomm->proc_config().proc_size();
+#endif
+
+ const double eps =3D 0.0001;
+ double val[4 * 26];
+
+ if (1 =3D=3D procs) {
+ Range global_quads;
+ rval =3D mb.get_entities_by_type(0, MBQUAD, global_quads);
+ CHECK_ERR(rval);
+ CHECK_EQUAL((size_t)4608, global_quads.size());
+
+ EntityHandle gloabl_quad_ents[] =3D {global_quads[0], global_quads[455=
9], global_quads[48], global_quads[4607]};
+ rval =3D mb.tag_get_data(Ttag0, &gloabl_quad_ents[0], 4, val);
+
+ CHECK_REAL_EQUAL(252.8529, val[0], eps); // First global quad
+ CHECK_REAL_EQUAL(205.3905, val[26], eps); // 4660th global quad
+ CHECK_REAL_EQUAL(252.7116, val[52], eps); // 49th global quad
+ CHECK_REAL_EQUAL(200.6828, val[78], eps); // Last global quad
+ }
+ else if (2 =3D=3D procs) {
+ Range local_quads;
+ rval =3D mb.get_entities_by_type(0, MBQUAD, local_quads);
+ CHECK_ERR(rval);
+ CHECK_EQUAL((size_t)2304, local_quads.size());
+
+ EntityHandle local_quad_ents[] =3D {local_quads[0], local_quads[2303]};
+ rval =3D mb.tag_get_data(Ttag0, &local_quad_ents[0], 2, val);
+
+ if (0 =3D=3D rank) {
+ CHECK_REAL_EQUAL(252.8529, val[0], eps); // First local quad, first =
global quad
+ CHECK_REAL_EQUAL(205.3905, val[26], eps); // Last local quad, 4660th=
global quad
+ }
+ else if (1 =3D=3D rank) {
+ CHECK_REAL_EQUAL(252.7116, val[0], eps); // First local quad, 49th g=
lobal quad
+ CHECK_REAL_EQUAL(200.6828, val[26], eps); // Last local quad, last g=
lobal quad
+ }
+ }
}
=20
void test_read_eul_onetimestep()
@@ -121,7 +168,7 @@ void test_read_eul_onetimestep()
rval =3D mb.load_file(example_eul, NULL, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tags
+ // Check for proper tags
Tag Ttag0, Ttag1;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_EQUAL(rval, MB_TAG_NOT_FOUND);
@@ -135,7 +182,7 @@ void test_read_eul_nomesh()
Core moab;
Interface& mb =3D moab;
=20
- // need a set for nomesh to work right
+ // Need a set for nomesh to work right
EntityHandle set;
ErrorCode rval =3D mb.create_meshset(MESHSET_SET, set);
CHECK_ERR(rval);
@@ -148,7 +195,7 @@ void test_read_eul_nomesh()
rval =3D mb.load_file(example_eul, &set, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tag
+ // Check for proper tag
Tag Ttag0, Ttag1;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_ERR(rval);
@@ -156,12 +203,12 @@ void test_read_eul_nomesh()
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_EQUAL(rval, MB_TAG_NOT_FOUND);
=20
- // now read 2nd timestep with nomesh option
+ // Now read 2nd timestep with nomesh option
opts =3D orig + std::string(";VARIABLE=3DT;TIMESTEP=3D1;NOMESH");
rval =3D mb.load_file(example_eul, &set, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tag
+ // Check for proper tag
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_ERR(rval);
}
@@ -171,7 +218,7 @@ void test_read_eul_novars()
Core moab;
Interface& mb =3D moab;
=20
- // need a set for nomesh to work right
+ // Need a set for nomesh to work right
EntityHandle set;
ErrorCode rval =3D mb.create_meshset(MESHSET_SET, set);
CHECK_ERR(rval);
@@ -188,7 +235,7 @@ void test_read_eul_novars()
rval =3D mb.load_file(example_eul, &set, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tag
+ // Check for proper tag
Tag Ttag0, Ttag1;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_EQUAL(rval, MB_TAG_NOT_FOUND);
@@ -203,12 +250,12 @@ void test_read_eul_novars()
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_EQUAL(rval, MB_TAG_NOT_FOUND);
=20
- // now read 2nd timestep with nomesh option
+ // Now read 2nd timestep with nomesh option
opts =3D orig + std::string(";VARIABLE=3DT;TIMESTEP=3D1;NOMESH");
rval =3D mb.load_file(example_eul, &set, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tag
+ // Check for proper tag
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_ERR(rval);
}
@@ -225,7 +272,7 @@ void test_read_fv_all()
rval =3D mb.load_file(example_fv, NULL, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tags
+ // Check for proper tags
Tag Ttag0, Ttag1, coordTag;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_ERR(rval);
@@ -233,7 +280,7 @@ void test_read_fv_all()
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_ERR(rval);
=20
- rval=3Dmb.tag_get_handle("COORDS", 3, MB_TYPE_DOUBLE, coordTag);
+ rval =3D mb.tag_get_handle("COORDS", 3, MB_TYPE_DOUBLE, coordTag);
CHECK_ERR(rval);
}
=20
@@ -249,7 +296,7 @@ void test_read_fv_onevar()
rval =3D mb.load_file(example_fv, NULL, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tags
+ // Check for proper tags
Tag Ttag0, Ttag1;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_ERR(rval);
@@ -270,7 +317,7 @@ void test_read_fv_onetimestep()
rval =3D mb.load_file(example_fv, NULL, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tags
+ // Check for proper tags
Tag Ttag0, Ttag1;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_EQUAL(rval, MB_TAG_NOT_FOUND);
@@ -284,7 +331,7 @@ void test_read_fv_nomesh()
Core moab;
Interface& mb =3D moab;
=20
- // need a set for nomesh to work right
+ // Need a set for nomesh to work right
EntityHandle set;
ErrorCode rval =3D mb.create_meshset(MESHSET_SET, set);
CHECK_ERR(rval);
@@ -297,7 +344,7 @@ void test_read_fv_nomesh()
rval =3D mb.load_file(example_fv, &set, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tag
+ // Check for proper tag
Tag Ttag0, Ttag1;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_ERR(rval);
@@ -305,12 +352,12 @@ void test_read_fv_nomesh()
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_EQUAL(rval, MB_TAG_NOT_FOUND);
=20
- // now read 2nd timestep with nomesh option
+ // Now read 2nd timestep with nomesh option
opts =3D orig + std::string(";VARIABLE=3DT;TIMESTEP=3D1;NOMESH");
rval =3D mb.load_file(example_fv, &set, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tag
+ // Check for proper tag
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_ERR(rval);
}
@@ -320,7 +367,7 @@ void test_read_fv_novars()
Core moab;
Interface& mb =3D moab;
=20
- // need a set for nomesh to work right
+ // Need a set for nomesh to work right
EntityHandle set;
ErrorCode rval =3D mb.create_meshset(MESHSET_SET, set);
CHECK_ERR(rval);
@@ -337,7 +384,7 @@ void test_read_fv_novars()
rval =3D mb.load_file(example_fv, &set, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tag
+ // Check for proper tag
Tag Ttag0, Ttag1;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_EQUAL(rval, MB_TAG_NOT_FOUND);
@@ -352,12 +399,12 @@ void test_read_fv_novars()
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_EQUAL(rval, MB_TAG_NOT_FOUND);
=20
- // now read 2nd timestep with nomesh option
+ // Now read 2nd timestep with nomesh option
opts =3D orig + std::string(";VARIABLE=3DT;TIMESTEP=3D1;NOMESH");
rval =3D mb.load_file(example_fv, &set, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tag
+ // Check for proper tag
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_ERR(rval);
}
@@ -365,7 +412,7 @@ void test_read_fv_novars()
ErrorCode get_options(std::string& opts)=20
{
#ifdef USE_MPI
- // use parallel options
+ // Use parallel options
opts =3D std::string(";;PARALLEL=3DREAD_PART;PARTITION_METHOD=3DSQIJ");
return MB_SUCCESS;
#else
https://bitbucket.org/fathomteam/moab/commits/77b01b8f77af/
Changeset: 77b01b8f77af
Branch: None
User: danwu
Date: 2013-07-17 20:50:49
Summary: Merged fathomteam/moab into master
Affected #: 21 files
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 007d501..6b18435 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,3 +1,9 @@
+# check if we are using MPI - reset compilers accordingly
+if ( MOAB_USE_MPI )
+ SET(CMAKE_CXX_COMPILER ${MPI_CXX_COMPILER})
+ SET(CMAKE_C_COMPILER ${MPI_C_COMPILER})
+endif ( MOAB_USE_MPI )
+
project( MOAB )
=20
cmake_minimum_required( VERSION 2.4 )
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/figure1.jpg b/doc/DG/figure1.jpg
new file mode 100644
index 0000000..e102a97
Binary files /dev/null and b/doc/DG/figure1.jpg differ
diff --git a/doc/DG/figure2.jpg b/doc/DG/figure2.jpg
new file mode 100644
index 0000000..7e8b199
Binary files /dev/null and b/doc/DG/figure2.jpg differ
diff --git a/doc/DG/figure3.jpg b/doc/DG/figure3.jpg
new file mode 100644
index 0000000..8810bfc
Binary files /dev/null and b/doc/DG/figure3.jpg differ
diff --git a/doc/DG/moabDG.h b/doc/DG/moabDG.h
index 1091094..51281b1 100644
--- a/doc/DG/moabDG.h
+++ b/doc/DG/moabDG.h
@@ -1,45 +1,22 @@
-/*! \page developerguide Developer's Guide (MOAB 4.6)
-=20
- \subpage dg-contents
-=20
- \subpage dg-figures
-
- \subpage dg-tables
-*/
-
-/*! \page dg-contents Table of Contents
-
- \subpage sequence-info
-
- \subpage meta-data-info
+/*! \page developerguide Developer's Guide (MOAB 4.6)
+=20
+ \subpage dg-contents
+=20
+ \subpage dg-figures
+
*/
-
-/*! \page dg-figures List of Figures
-
- \ref figure1
-
- \ref figure2
-
- \ref figure3
+
+/*! \page dg-figures List of Figures
+
+ \ref figure1
+
+ \ref figure2
+
+ \ref figure3
*/
-
-/*! \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
@@ -52,6 +29,10 @@
\section sequence EntitySequence & SequenceData=20
=20
\subsection figure1 Figure 1: EntitySequences For One SequenceData
+ <img src=3D"../../DG/figure1.jpg">
+
+ \ref dg-figures "List of Figures"
+
The <I>SequenceData</I> class manages as set of arrays of per-entity value=
s. Each
<I>SequenceData</I> has a start and end handle denoting the block of entit=
ies for which
the arrays contain data. The arrays managed by a <I>SequenceData</I> insta=
nce are
@@ -111,7 +92,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
@@ -127,6 +108,9 @@ enforces the following four rules on its contained data:
.
=20
\subsection figure2 Figure 2: SequenceManager and Related Classes
+ <img src=3D"../../DG/figure2.jpg">
+
+ \ref dg-figures "List of Figures"
=20
The first three rules are required for the validity of the data model. The
fourth rule avoids unnecessary inefficiency. It is implemented by merging =
such
@@ -175,920 +159,115 @@ such as allocating the correct <I>EntitySequence</I=
> subtype 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"
-
- \section s-mesh Structured Mesh
-
-Structured mesh storage is implemented using subclasses of <I>SequenceData=
</I>:
-<I>ScdElementData</I> and <I>ScdVertexData</I>. The <I>StructuredElementSe=
q</I> class is
-used to access the structured element connectivity. A standard <I>VertexSe=
quence</I>
-instance is used to access the ScdVertexData because the vertex data stora=
ge
-is the same as for unstructured mesh.
-
- \ref sequence-info "Top"
-
- \section sets Entity Sets
-
-- MeshSetSequence
-
-The <I>MeshSetSequence</I> class is the same as most other subclasses of <=
I>EntitySequence</I>
-in that it utilizes SequenceData to store its data. A single array in the =
<I>SequenceData</I>
-is used to store instances of the MeshSet class, one per allocated <I>Enti=
tyHandle</I>.
-<I>SequenceData</I> allocates all of its managed arrays using malloc and f=
ree as
-simple arrays of bytes. <I>MeshSetSequence</I> does in-place construction =
and de-
-struction of <I>MeshSet</I> instances within that array. This is similar t=
o what is
-done by <I>std::vector</I> and other container classes that may own more s=
torage
-than is required at a given time for contained objects.
-
-- MeshSet
-
- \subsection figure3 Figure 3: SequenceManager and Related Classes
-
-The <I>MeshSet</I> class is used to represent a single entity set instance=
in MOAB.
-The class is optimized to minimize storage (further possible improvements =
in
-storage size are discussed later.)
-
-Figure 3 shows the memory layout of an instance of the <I>MeshSet</I> clas=
s.
-The flags member holds the set creation bit flags: <I>MESHSET_TRACK_OWNER<=
/I>,
-<I>MESHSET_SET</I>, and <I>MESHSET_ORDERED</I>. The presence of the <I>MES=
HSET_TRACK_OWNER</I>
-indicates that reverse links from the contained entities back to the ownin=
g set
-should be maintained in the adjacency list of each entity. The <I>MESHSET_=
SET</I>
-and <I>MESHSET_ORDERED</I> bits are mutually exclusive, and as such most c=
ode only
-tests for the <I>MESHSET_ORDERED</I>, meaning that in practice the <I>MESH=
SET_SET</I> bit is
-ignored. <I>MESHSET_ORDERED</I> indicates that the set may contain duplica=
te handles
-and that the order that the handles are added to the set should be preserv=
ed.
-In practice, such sets are stored as a simple list of handles. <I>MESHSET_=
SET</I> (or in
-practice, the lack of <I>MESHSET_ORDERED</I>) indicates that the order of =
the handles
-need not be preserved and that the set may not contain duplicate handles. =
Such
-sets are stored in a sorted range-compacted format similar to that of the =
Range
-class.
-
-The memory for storing contents, parents, and children are each handled in
-the same way. The data in the class is composed of a 2-bit =E2=80=98size=
=E2=80=99 field and two
-values, where the two values may either be two handles or two pointers. Th=
e size
-bit-fields are grouped together to reduce the required amount of memory. I=
f the
-numerical value of the 2-bit size field is 0 then the corresponding list i=
s empty.
-If the 2-bit size field is either 1 or 2, then the contents of the corresp=
onding list
-are stored directly in the corresponding two data fields of the MeshSet ob=
ject.
-If the 2-bit size field has a value of 3 (11 binary), then the correspondi=
ng two
-data fields store the begin and end pointers of an external array of handl=
es.
-The number of handles in the external array can be obtained by taking the
-difference of the start and end pointers. Note that unlike <I>std::vector<=
/I>, we
-do not store both an allocated and used size. We store only the =E2=80=98u=
sed=E2=80=99 size
-and call std::realloc whenever the used size is modified, thus we rely on =
the
-std::malloc implementation in the standard C library to track =E2=80=98all=
ocated=E2=80=99 size
-for us. In practice this performs well but does not return memory to the =
=E2=80=98system=E2=80=99
-when lists shrink (unless they shrink to zero). This overall scheme could =
exhibit
-poor performance if the size of one of the data lists in the set frequentl=
y changes
-between less than two and more than two handles, as this will result in fr=
equent
-releasing and re-allocating of the memory for the corresponding array.
-
-If the <I>MESHSET_ORDERED</I> flag is not present, then the set contents l=
ist (parent
-and child lists are unaffected) is stored in a range-compacted format. In =
this
-format the number of handles stored in the array is always a multiple of t=
wo.
-Each consecutive pair of handles indicate the start and end, inclusive, of=
a range
-of handles contained in the set. All such handle range pairs are stored in=
sorted
-order and do not overlap. Nor is the end handle of one range ever one less=
than
-the start handle of the next. All such =E2=80=98adjacent=E2=80=99 range pa=
irs are merged into a
-single pair. The code for insertion and removal of handles from range-form=
atted
-set content lists is fairly complex. The implementation will guarantee tha=
t a
-given call to insert entities into a range or remove entities from a range=
is never
-worse than O(ln n) + O(m + n), where =E2=80=98n=E2=80=99 is the number of =
handles to insert
-and =E2=80=98m=E2=80=99 is the number of handles already contained in the =
set. So it is generally
-much more efficient to build Ranges of handles to insert (and remove) and =
call
-MOAB to insert (or remove) the entire list at once rather than making may
-calls to insert (or remove) one or a few handles from the contents of a se=
t.
-The set storage could probably be further minimized by allowing up to six
-handles in one of the lists to be elided. That is, as there are six potent=
ial =E2=80=98slots=E2=80=99
-in the MeshSet object then if two of the lists are empty it should be poss=
ible to store up to six values of the remaining list directly in the MeshSe=
t object.
-However, the additional runtime cost of such complexity could easily outwe=
igh
-any storage advantage. Further investigation into this has not been done b=
ecause
-the primary motivation for the storage optimization was to support binary =
trees.
-
-Another possible optimization of storage would be to remove the <I>MeshSet=
</I>
-object entirely and instead store the data in a =E2=80=98blocked=E2=80=99 =
format. The corre-
-sponding <I>SequenceData</I> would contain four arrays: flags, parents, ch=
ildren, and
-contents instead of a single array of <I>MeshSet</I> objects. If this were=
done then
-no storage need ever be allocated for parent or child links if none of the=
sets
-in a <I>SequenceData</I> has parent or child links. The effectiveness of t=
he storage
-reduction would depend greatly on how sets get grouped into <I>SequenceDat=
as</I>.
-This alternate storage scheme might also allow for better cache utilizatio=
n as it
-would group like data together. It is often the case that application code=
that
-is querying the contents of one set will query the contents of many but ne=
ver
-query the parents or children of any set. Or that an application will quer=
y only
-parent or child links of a set without every querying other set properties=
. The
-downside of this solution is that it makes the implementation a little les=
s 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.
-
- \ref sequence-info "Top"
+ \ref dg-contents "Top"
+
+ \section s-mesh Structured Mesh
+
+Structured mesh storage is implemented using subclasses of <I>SequenceData=
</I>:
+<I>ScdElementData</I> and <I>ScdVertexData</I>. The <I>StructuredElementSe=
q</I> class is
+used to access the structured element connectivity. A standard <I>VertexSe=
quence</I>
+instance is used to access the ScdVertexData because the vertex data stora=
ge
+is the same as for unstructured mesh.
+
+ \ref dg-contents "Top"
+
+ \section sets Entity Sets
+
+- MeshSetSequence
+
+The <I>MeshSetSequence</I> class is the same as most other subclasses of <=
I>EntitySequence</I>
+in that it utilizes SequenceData to store its data. A single array in the =
<I>SequenceData</I>
+is used to store instances of the MeshSet class, one per allocated <I>Enti=
tyHandle</I>.
+<I>SequenceData</I> allocates all of its managed arrays using malloc and f=
ree as
+simple arrays of bytes. <I>MeshSetSequence</I> does in-place construction =
and de-
+struction of <I>MeshSet</I> instances within that array. This is similar t=
o what is
+done by <I>std::vector</I> and other container classes that may own more s=
torage
+than is required at a given time for contained objects.
+
+- MeshSet
+
+ \subsection figure3 Figure 3: SequenceManager and Related Classes
+ <img src=3D"../../DG/figure3.jpg">
+
+ \ref dg-figures "List of Figures"
+
+The <I>MeshSet</I> class is used to represent a single entity set instance=
in MOAB.
+The class is optimized to minimize storage (further possible improvements =
in
+storage size are discussed later.)
+
+Figure 3 shows the memory layout of an instance of the <I>MeshSet</I> clas=
s.
+The flags member holds the set creation bit flags: <I>MESHSET_TRACK_OWNER<=
/I>,
+<I>MESHSET_SET</I>, and <I>MESHSET_ORDERED</I>. The presence of the <I>MES=
HSET_TRACK_OWNER</I>
+indicates that reverse links from the contained entities back to the ownin=
g set
+should be maintained in the adjacency list of each entity. The <I>MESHSET_=
SET</I>
+and <I>MESHSET_ORDERED</I> bits are mutually exclusive, and as such most c=
ode only
+tests for the <I>MESHSET_ORDERED</I>, meaning that in practice the <I>MESH=
SET_SET</I> bit is
+ignored. <I>MESHSET_ORDERED</I> indicates that the set may contain duplica=
te handles
+and that the order that the handles are added to the set should be preserv=
ed.
+In practice, such sets are stored as a simple list of handles. <I>MESHSET_=
SET</I> (or in
+practice, the lack of <I>MESHSET_ORDERED</I>) indicates that the order of =
the handles
+need not be preserved and that the set may not contain duplicate handles. =
Such
+sets are stored in a sorted range-compacted format similar to that of the =
Range
+class.
+
+The memory for storing contents, parents, and children are each handled in
+the same way. The data in the class is composed of a 2-bit =E2=80=98size=
=E2=80=99 field and two
+values, where the two values may either be two handles or two pointers. Th=
e size
+bit-fields are grouped together to reduce the required amount of memory. I=
f the
+numerical value of the 2-bit size field is 0 then the corresponding list i=
s empty.
+If the 2-bit size field is either 1 or 2, then the contents of the corresp=
onding list
+are stored directly in the corresponding two data fields of the MeshSet ob=
ject.
+If the 2-bit size field has a value of 3 (11 binary), then the correspondi=
ng two
+data fields store the begin and end pointers of an external array of handl=
es.
+The number of handles in the external array can be obtained by taking the
+difference of the start and end pointers. Note that unlike <I>std::vector<=
/I>, we
+do not store both an allocated and used size. We store only the =E2=80=98u=
sed=E2=80=99 size
+and call std::realloc whenever the used size is modified, thus we rely on =
the
+std::malloc implementation in the standard C library to track =E2=80=98all=
ocated=E2=80=99 size
+for us. In practice this performs well but does not return memory to the =
=E2=80=98system=E2=80=99
+when lists shrink (unless they shrink to zero). This overall scheme could =
exhibit
+poor performance if the size of one of the data lists in the set frequentl=
y changes
+between less than two and more than two handles, as this will result in fr=
equent
+releasing and re-allocating of the memory for the corresponding array.
+
+If the <I>MESHSET_ORDERED</I> flag is not present, then the set contents l=
ist (parent
+and child lists are unaffected) is stored in a range-compacted format. In =
this
+format the number of handles stored in the array is always a multiple of t=
wo.
+Each consecutive pair of handles indicate the start and end, inclusive, of=
a range
+of handles contained in the set. All such handle range pairs are stored in=
sorted
+order and do not overlap. Nor is the end handle of one range ever one less=
than
+the start handle of the next. All such =E2=80=98adjacent=E2=80=99 range pa=
irs are merged into a
+single pair. The code for insertion and removal of handles from range-form=
atted
+set content lists is fairly complex. The implementation will guarantee tha=
t a
+given call to insert entities into a range or remove entities from a range=
is never
+worse than O(ln n) + O(m + n), where =E2=80=98n=E2=80=99 is the number of =
handles to insert
+and =E2=80=98m=E2=80=99 is the number of handles already contained in the =
set. So it is generally
+much more efficient to build Ranges of handles to insert (and remove) and =
call
+MOAB to insert (or remove) the entire list at once rather than making may
+calls to insert (or remove) one or a few handles from the contents of a se=
t.
+The set storage could probably be further minimized by allowing up to six
+handles in one of the lists to be elided. That is, as there are six potent=
ial =E2=80=98slots=E2=80=99
+in the MeshSet object then if two of the lists are empty it should be poss=
ible to store up to six values of the remaining list directly in the MeshSe=
t object.
+However, the additional runtime cost of such complexity could easily outwe=
igh
+any storage advantage. Further investigation into this has not been done b=
ecause
+the primary motivation for the storage optimization was to support binary =
trees.
+
+Another possible optimization of storage would be to remove the <I>MeshSet=
</I>
+object entirely and instead store the data in a =E2=80=98blocked=E2=80=99 =
format. The corre-
+sponding <I>SequenceData</I> would contain four arrays: flags, parents, ch=
ildren, and
+contents instead of a single array of <I>MeshSet</I> objects. If this were=
done then
+no storage need ever be allocated for parent or child links if none of the=
sets
+in a <I>SequenceData</I> has parent or child links. The effectiveness of t=
he storage
+reduction would depend greatly on how sets get grouped into <I>SequenceDat=
as</I>.
+This alternate storage scheme might also allow for better cache utilizatio=
n as it
+would group like data together. It is often the case that application code=
that
+is querying the contents of one set will query the contents of many but ne=
ver
+query the parents or children of any set. Or that an application will quer=
y only
+parent or child links of a set without every querying other set properties=
. The
+downside of this solution is that it makes the implementation a little les=
s 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.
+
+ \ref dg-contents "Top"
*/
-
-/*! \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.
=20
- \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"
- */
This diff is so big that we needed to truncate the remainder.
https://bitbucket.org/fathomteam/moab/commits/0e517adf3e54/
Changeset: 0e517adf3e54
Branch: None
User: danwu
Date: 2013-07-23 00:30:12
Summary: Merged fathomteam/moab into master
Affected #: 9 files
diff --git a/configure.ac b/configure.ac
index b642189..8a308cb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1207,7 +1207,6 @@ AC_CONFIG_FILES([Makefile
tools/vtkMOABReaderNew/CMakeLists.txt
doc/Makefile
doc/user.dox
- doc/dev.dox
doc/config.tex
MeshFiles/Makefile
MeshFiles/unittest/Makefile
diff --git a/doc/DG/styleguide.h b/doc/DG/styleguide.h
new file mode 100644
index 0000000..e3cf6f9
--- /dev/null
+++ b/doc/DG/styleguide.h
@@ -0,0 +1,91 @@
+/*!
+ \page styleguide Coding Style Guide
+Code developed in %MOAB should follow the coding styles described here. A=
ny deviations from this style
+guide will result in severe berating and other verbal abuse.
+
+\section dirstructure MOAB Directory Structure
+%MOAB source code is organized in the following directory structure: \n
+ - doc: Documentation is put here, along with the input file for Doxygen. =
Most %MOAB documentation is doxygen-processed.
+ - examples: Examples of %MOAB usage, both small and large. These program=
s are not meant to be used as unit tests, but
+ rather as further documentation on %MOAB usage.
+ - src : Mesh related source codes. It includes:
+ - io: %MOAB Input/Output classes.
+ - moab: %MOAB core classes.
+ - lotte: Computational Meshing basics.
+ - parallel: Parallel mesh computation, i/o data processing methods.
+ - test: All unit test programs should go below this directory.
+ Please put the unit tests into their related subdirectories based on th=
e test's
+ purpose if possible.
+If you're designing a new class or other code for %MOAB and are not sure w=
here to put it, try to find something similar
+and put it there. Otherwise, email the %MOAB email list for pointers. <e=
m> In general, you should not need to create new
+subdirectories in the %MOAB source code, except when implementing a new al=
gorithm with more than about 2 files.</em>
+
+\section sourcestyle Source Code Style and Best Practices
+%MOAB code should abide by the following general rules:
+ - Names:
+ - Class names should be in the CamelBack style, e.g. EdgeMesh or Vertex=
Mesher.
+ - Class member variables should be camelBack, e.g. EdgeMesh::schemeType=
; each member variable, e.g. int memberVariable,=20
+ should have set/get functions void member_variable(int newval) and int =
member_variable(), respectively.
+ - Enumeration values should be all captitalized, with underscores avoid=
ed if possible (the enumeration name indicates
+ the general purpose of the enumeration, so e.g. we use EQUAL, not EQU=
AL_MESH)
+ - Source code should not contain tabs or MS-DOS newlines; tabs and other =
indentations should be set to a width of 2 spaces.
+ For general tips on how to set your editor for this, see the %MOAB-dev =
discussion starting with <a href=3D"https://lists.mcs.anl.gov/mailman/priva=
te/moab-dev/2011/000519.html">this message</a>.
+ - Each class header should be fully commented; that includes:
+ - A \\file comment block at the top of the file; DO NOT include things =
like Author and Date blocks; this stuff is available
+ from subversion if we really need to know.
+ - A \\class comment block, formatted like those in the %MOAB core class=
es. THE FIELDS AFTER THE CLASS NAME ARE VERY IMPORTANT,
+ as they tell developers how to include the class declaration in their=
code. This information goes into the "Detailed
+ Description" portion of the class documentation. This block should i=
nclude any features or limitations of the class.
+ Eventually, we'll impose some standard boilerplate that each meshing =
class should use.
+ Until then, please keep this block to around a paragraph.
+ - Each function in both the public and private interfaces should be com=
mented, INCLUDING ANY ARGUMENTS AND RETURN VALUES.
+ See the %MOAB classes for examples of how to format these comments. =
As a rule of thumb, your code should run through
+ Doxygen without generating any warnings; in fact, Doxygen is sometime=
s helpful at pointing out inconsistencies in your
+ class declaration.
+ - Developers should avoid using \#include in header files, as they propag=
ate dependencies more widely than necessary. The only
+ cases where other includes are needed are to import the declaration for=
a parent class, and to declare types used as
+ non-pointer and non-reference function arguments. In most cases, a for=
ward-declaration statement (e.g. 'class MKCore')=20
+ will suffice.
+ - Naming classes and other top-level constructs:
+ - No names should be added to the global namespace. Everything should =
be
+ in the MOAB namespace. An exception can be made for names with a sta=
tic
+ scope declared in a .cpp file, but class member functions never have a
+ static scope.
+ - Names should be kept as private as possible. If declaring a struct o=
r=20
+ utility class that is used internally by some other class, consider=20
+ defining it in the .cpp file of the main class or a separate header=20
+ only included in that .cpp file and using (if necessary) only forward
+ delcarations (e.g. \c struct \c Point3D;) in the header file used
+ by other code. If that is not possible, then consider nesting the
+ definitions such that the scope of the name is limited to that of the
+ class using it.=20
+ - Any names introduced into the top-level MOAB namespace should be
+ sufficiently unique to avoid conflicts with other code. If you must=20
+ introduce a class to the top-level Meshkit namespace, don't choose
+ an overly genereric name like \c Point3D .
+ - Constants and Macros
+ - Don't use a pre-processor macro where a const variable or an inline or
+ template function will suffice.
+ There is absolutely benefit to the former over the later with modern=20
+ compilers. Further, using macros bypasses typechecking that the com=
piler
+ would otherwise do for you and if used in headers, introduce names in=
to
+ the global rather than Meshkit namespace.
+ - Don't define constants that are already provided by standard librarie=
s.
+ For example, use \c M_PI as defined in \c math.h rather than defining
+ your own constant.
+\section commits Making Repository Commits
+As a general rule, developers should update frequently, and commit changes=
often. However, the repository should always remain
+in a state where the code can be compiled. Most of the time, the code sho=
uld also successfully execute "make check" run from the
+top-level directory. If you commit code that violates this principal, it =
should be your first priority to return the repository
+code to a compilable state, and your second priority to make sure "make ch=
eck" runs without errors.
+
+Commits to the repository should also come with a non-trivial, useful, non=
-verbose log message. Oftentimes the best way to generate
+this message is to run 'svn diff > diffs', and edit the diffs file to remo=
ve specific line changes but include a comment on=20
+each file that changed. Many times it is helpful to state that 'make chec=
k runs successfully' at the end of the log message.
+Although it would be possible and many software projects do it, we prefer =
not to force successful execution of the test suite=20
+before every commit. Developers should make every effort to avoid having =
to impose this constraint, by running a make check
+before every commit.
+
+Top: \ref index=20
+ =20
+ */
diff --git a/doc/MetaData/metadata.h b/doc/MetaData/metadata.h
index 5f53ecc..3bcd47e 100644
--- a/doc/MetaData/metadata.h
+++ b/doc/MetaData/metadata.h
@@ -9,23 +9,23 @@
=20
/*! \page md-contents Table of Contents
=20
- \ref meta-introduction
+ \ref meta-introduction
=20
- \ref meta-conventions
+ \ref meta-conventions
=20
- \ref meta-options
+ \ref meta-options
=20
- \ref meta-references
+ \ref meta-references
=20
- \ref appendixA
+ \ref appendixA
=20
- \ref appendixB
+ \ref appendixB
=20
- \ref appendixC
+ \ref appendixC
=20
- \ref appendixD
+ \ref appendixD
=20
- \ref appendixE
+ \ref appendixE
=20
\section meta-introduction Introduction
=20
diff --git a/doc/dev.dox.in b/doc/dev.dox.in
deleted file mode 100644
index ecc27fa..0000000
--- a/doc/dev.dox.in
+++ /dev/null
@@ -1,842 +0,0 @@
- # Doxyfile 1.2.11.1
-
-# This file describes the settings to be used by the documentation system
-# doxygen (www.doxygen.org) for a project
-#
-# All text after a hash (#) is considered a comment and will be ignored
-# The format is:
-# TAG =3D value [value, ...]
-# For lists items can also be appended using:
-# TAG +=3D value [value, ...]
-# Values that contain spaces should be placed between quotes (" ")
-
-#-------------------------------------------------------------------------=
--
-# General configuration options
-#-------------------------------------------------------------------------=
--
-
-# The PROJECT_NAME tag is a single word (or a sequence of words surrounded=20
-# by quotes) that should identify the project.
-
-PROJECT_NAME =3D moab=20
-
-# The PROJECT_NUMBER tag can be used to enter a project or revision number=
.=20
-# This could be handy for archiving the generated documentation or=20
-# if some version control system is used.
-
-PROJECT_NUMBER =3D=20
-
-# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)=20
-# base path where the generated documentation will be put.=20
-# If a relative path is entered, it will be relative to the location=20
-# where doxygen was started. If left blank the current directory will be u=
sed.
-
-OUTPUT_DIRECTORY =3D dev
-
-# The OUTPUT_LANGUAGE tag is used to specify the language in which all=20
-# documentation generated by doxygen is written. Doxygen will use this=20
-# information to generate all constant output in the proper language.=20
-# The default language is English, other supported languages are:=20
-# Brazilian, Chinese, Croatian, Czech, Danish, Dutch, Finnish, French,=20
-# German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish,=20
-# Portuguese, Romanian, Russian, Slovak, Slovene, Spanish and Swedish.
-
-OUTPUT_LANGUAGE =3D English
-
-# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in=20
-# documentation are documented, even if no documentation was available.=20
-# Private class members and static file members will be hidden unless=20
-# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
-
-EXTRACT_ALL =3D YES
-
-# If the EXTRACT_PRIVATE tag is set to YES all private members of a class=20
-# will be included in the documentation.
-
-EXTRACT_PRIVATE =3D YES
-
-# If the EXTRACT_STATIC tag is set to YES all static members of a file=20
-# will be included in the documentation.
-
-EXTRACT_STATIC =3D YES
-
-# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all=20
-# undocumented members of documented classes, files or namespaces.=20
-# If set to NO (the default) these members will be included in the=20
-# various overviews, but no documentation section is generated.=20
-# This option has no effect if EXTRACT_ALL is enabled.
-
-HIDE_UNDOC_MEMBERS =3D NO
-
-# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all=20
-# undocumented classes that are normally visible in the class hierarchy.=20
-# If set to NO (the default) these class will be included in the various=20
-# overviews. This option has no effect if EXTRACT_ALL is enabled.
-
-HIDE_UNDOC_CLASSES =3D NO
-
-# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will=20
-# include brief member descriptions after the members that are listed in=20
-# the file and class documentation (similar to JavaDoc).=20
-# Set to NO to disable this.
-
-BRIEF_MEMBER_DESC =3D YES
-
-# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend=20
-# the brief description of a member or function before the detailed descri=
ption.=20
-# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, th=
e=20
-# brief descriptions will be completely suppressed.
-
-REPEAT_BRIEF =3D YES
-
-# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES the=
n=20
-# Doxygen will generate a detailed section even if there is only a brief=20
-# description.
-
-ALWAYS_DETAILED_SEC =3D YES
-
-# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the f=
ull=20
-# path before files name in the file list and in the header files. If set=20
-# to NO the shortest path that makes the file name unique will be used.
-
-FULL_PATH_NAMES =3D NO
-
-# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag=20
-# can be used to strip a user defined part of the path. Stripping is=20
-# only done if one of the specified strings matches the left-hand part of=20
-# the path. It is allowed to use relative paths in the argument list.
-
-STRIP_FROM_PATH =3D=20
-
-# The INTERNAL_DOCS tag determines if documentation=20
-# that is typed after a \internal command is included. If the tag is set=20
-# to NO (the default) then the documentation will be excluded.=20
-# Set it to YES to include the internal documentation.
-
-INTERNAL_DOCS =3D NO
-
-# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will=20
-# generate a class diagram (in Html and LaTeX) for classes with base or=20
-# super classes. Setting the tag to NO turns the diagrams off.
-
-CLASS_DIAGRAMS =3D YES
-
-# If the SOURCE_BROWSER tag is set to YES then a list of source files will=20
-# be generated. Documented entities will be cross-referenced with these so=
urces.
-
-SOURCE_BROWSER =3D YES
-
-# Setting the INLINE_SOURCES tag to YES will include the body=20
-# of functions and classes directly in the documentation.
-
-INLINE_SOURCES =3D YES
-
-# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct=20
-# doxygen to hide any special comment blocks from generated source code=20
-# fragments. Normal C and C++ comments will always remain visible.
-
-STRIP_CODE_COMMENTS =3D NO
-
-# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate=20
-# file names in lower case letters. If set to YES upper case letters are a=
lso=20
-# allowed. This is useful if you have classes or files whose names only di=
ffer=20
-# in case and if your file system supports case sensitive file names. Wind=
ows=20
-# users are adviced to set this option to NO.
-
-CASE_SENSE_NAMES =3D YES
-
-# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter=20
-# (but less readable) file names. This can be useful is your file systems=20
-# doesn't support long names like on DOS, Mac, or CD-ROM.
-
-SHORT_NAMES =3D NO
-
-# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen=20
-# will show members with their full class and namespace scopes in the=20
-# documentation. If set to YES the scope will be hidden.
-
-HIDE_SCOPE_NAMES =3D NO
-
-# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen=20
-# will generate a verbatim copy of the header file for each class for=20
-# which an include is specified. Set to NO to disable this.
-
-VERBATIM_HEADERS =3D YES
-
-# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen=20
-# will put list of the files that are included by a file in the documentat=
ion=20
-# of that file.
-
-SHOW_INCLUDE_FILES =3D YES
-
-# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen=20
-# will interpret the first line (until the first dot) of a JavaDoc-style=20
-# comment as the brief description. If set to NO, the JavaDoc=20
-# comments will behave just like the Qt-style comments (thus requiring an=20
-# explict @brief command for a brief description.
-
-JAVADOC_AUTOBRIEF =3D NO
-
-# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented=20
-# member inherits the documentation from any documented member that it=20
-# reimplements.
-
-INHERIT_DOCS =3D YES
-
-# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]=20
-# is inserted in the documentation for inline members.
-
-INLINE_INFO =3D YES
-
-# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen=20
-# will sort the (detailed) documentation of file and class members=20
-# alphabetically by member name. If set to NO the members will appear in=20
-# declaration order.
-
-SORT_MEMBER_DOCS =3D YES
-
-# If member grouping is used in the documentation and the DISTRIBUTE_GROUP=
_DOC=20
-# tag is set to YES, then doxygen will reuse the documentation of the firs=
t=20
-# member in the group (if any) for the other members of the group. By defa=
ult=20
-# all members of a group must be documented explicitly.
-
-DISTRIBUTE_GROUP_DOC =3D NO
-
-# The TAB_SIZE tag can be used to set the number of spaces in a tab.=20
-# Doxygen uses this value to replace tabs by spaces in code fragments.
-
-TAB_SIZE =3D 8
-
-# The GENERATE_TODOLIST tag can be used to enable (YES) or=20
-# disable (NO) the todo list. This list is created by putting \todo=20
-# commands in the documentation.
-
-GENERATE_TODOLIST =3D YES
-
-# The GENERATE_TESTLIST tag can be used to enable (YES) or=20
-# disable (NO) the test list. This list is created by putting \test=20
-# commands in the documentation.
-
-GENERATE_TESTLIST =3D YES
-
-# The GENERATE_BUGLIST tag can be used to enable (YES) or=20
-# disable (NO) the bug list. This list is created by putting \bug=20
-# commands in the documentation.
-
-GENERATE_BUGLIST =3D YES
-
-# This tag can be used to specify a number of aliases that acts=20
-# as commands in the documentation. An alias has the form "name=3Dvalue".=20
-# For example adding "sideeffect=3D\par Side Effects:\n" will allow you to=20
-# put the command \sideeffect (or @sideeffect) in the documentation, which=20
-# will result in a user defined paragraph with heading "Side Effects:".=20
-# You can put \n's in the value part of an alias to insert newlines.
-
-ALIASES =3D=20
-
-# The ENABLED_SECTIONS tag can be used to enable conditional=20
-# documentation sections, marked by \if sectionname ... \endif.
-
-ENABLED_SECTIONS =3D=20
-
-# The MAX_INITIALIZER_LINES tag determines the maximum number of lines=20
-# the initial value of a variable or define consist of for it to appear in=20
-# the documentation. If the initializer consists of more lines than specif=
ied=20
-# here it will be hidden. Use a value of 0 to hide initializers completely=
.=20
-# The appearance of the initializer of individual variables and defines in=
the=20
-# documentation can be controlled using \showinitializer or \hideinitializ=
er=20
-# command in the documentation regardless of this setting.
-
-MAX_INITIALIZER_LINES =3D 30
-
-# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C s=
ources=20
-# only. Doxygen will then generate output that is more tailored for C.=20
-# For instance some of the names that are used will be different. The list=20
-# of all members will be omitted, etc.
-
-OPTIMIZE_OUTPUT_FOR_C =3D NO
-
-# Set the SHOW_USED_FILES tag to NO to disable the list of files generated=20
-# at the bottom of the documentation of classes and structs. If set to YES=
the=20
-# list will mention the files that were used to generate the documentation.
-
-SHOW_USED_FILES =3D YES
-
-#-------------------------------------------------------------------------=
--
-# configuration options related to warning and progress messages
-#-------------------------------------------------------------------------=
--
-
-# The QUIET tag can be used to turn on/off the messages that are generated=20
-# by doxygen. Possible values are YES and NO. If left blank NO is used.
-
-QUIET =3D NO
-
-# The WARNINGS tag can be used to turn on/off the warning messages that ar=
e=20
-# generated by doxygen. Possible values are YES and NO. If left blank=20
-# NO is used.
-
-WARNINGS =3D YES
-
-# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnin=
gs=20
-# for undocumented members. If EXTRACT_ALL is set to YES then this flag wi=
ll=20
-# automatically be disabled.
-
-WARN_IF_UNDOCUMENTED =3D YES
-
-# The WARN_FORMAT tag determines the format of the warning messages that=20
-# doxygen can produce. The string should contain the $file, $line, and $te=
xt=20
-# tags, which will be replaced by the file and line number from which the=20
-# warning originated and the warning text.
-
-WARN_FORMAT =3D=20
-
-# The WARN_LOGFILE tag can be used to specify a file to which warning=20
-# and error messages should be written. If left blank the output is writte=
n=20
-# to stderr.
-
-WARN_LOGFILE =3D=20
-
-#-------------------------------------------------------------------------=
--
-# configuration options related to the input files
-#-------------------------------------------------------------------------=
--
-
-# The INPUT tag can be used to specify the files and/or directories that c=
ontain=20
-# documented source files. You may enter file names like "myfile.cpp" or=20
-# directories like "/usr/src/myproject". Separate the files or directories=20
-# with spaces.
-
-INPUT =3D @top_srcdir@/src \
- @top_srcdir@/tools \
- @top_srcdir@/itaps \
- @top_srcdir@/examples
-
-# If the value of the INPUT tag contains directories, you can use the=20
-# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp=20
-# and *.h) to filter out the source-files in the directories. If left=20
-# blank all files are included.
-
-FILE_PATTERNS =3D *.cpp *.hpp *.h *.dox
-#FILE_PATTERNS =3D *.dox
-
-# The RECURSIVE tag can be used to turn specify whether or not subdirector=
ies=20
-# should be searched for input files as well. Possible values are YES and =
NO.=20
-# If left blank NO is used.
-
-RECURSIVE =3D YES
-
-# The EXCLUDE tag can be used to specify files and/or directories that sho=
uld=20
-# excluded from the INPUT source files. This way you can easily exclude a=20
-# subdirectory from a directory tree whose root is specified with the INPU=
T tag.
-
-EXCLUDE =3D=20
-
-# If the value of the INPUT tag contains directories, you can use the=20
-# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude=20
-# certain files from those directories.
-
-EXCLUDE_PATTERNS =3D=20
-
-# The EXAMPLE_PATH tag can be used to specify one or more files or=20
-# directories that contain example code fragments that are included (see=20
-# the \include command).
-
-EXAMPLE_PATH =3D =20
-
-# If the value of the EXAMPLE_PATH tag contains directories, you can use t=
he=20
-# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp=20
-# and *.h) to filter out the source-files in the directories. If left=20
-# blank all files are included.
-
-EXAMPLE_PATTERNS =3D
-
-# The IMAGE_PATH tag can be used to specify one or more files or=20
-# directories that contain image that are included in the documentation (s=
ee=20
-# the \image command).
-
-IMAGE_PATH =3D=20
-
-# The INPUT_FILTER tag can be used to specify a program that doxygen shoul=
d=20
-# invoke to filter for each input file. Doxygen will invoke the filter pro=
gram=20
-# by executing (via popen()) the command <filter><input-file>, where <filt=
er>=20
-# is the value of the INPUT_FILTER tag, and <input-file> is the name of an=20
-# input file. Doxygen will then use the output that the filter program wri=
tes=20
-# to standard output.
-
-INPUT_FILTER =3D=20
-
-# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set u=
sing=20
-# INPUT_FILTER) will be used to filter the input files when producing sour=
ce=20
-# files to browse.
-
-FILTER_SOURCE_FILES =3D NO
-
-#-------------------------------------------------------------------------=
--
-# configuration options related to the alphabetical class index
-#-------------------------------------------------------------------------=
--
-
-# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index=20
-# of all compounds will be generated. Enable this if the project=20
-# contains a lot of classes, structs, unions or interfaces.
-
-ALPHABETICAL_INDEX =3D YES
-
-# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then=20
-# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns=20
-# in which this list will be split (can be a number in the range [1..20])
-
-COLS_IN_ALPHA_INDEX =3D 5
-
-# In case all classes in a project start with a common prefix, all=20
-# classes will be put under the same header in the alphabetical index.=20
-# The IGNORE_PREFIX tag can be used to specify one or more prefixes that=20
-# should be ignored while generating the index headers.
-
-IGNORE_PREFIX =3D=20
-
-#-------------------------------------------------------------------------=
--
-# configuration options related to the HTML output
-#-------------------------------------------------------------------------=
--
-
-# If the GENERATE_HTML tag is set to YES (the default) Doxygen will=20
-# generate HTML output.
-
-GENERATE_HTML =3D YES
-
-# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.=20
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be=20
-# put in front of it. If left blank `html' will be used as the default pat=
h.
-
-HTML_OUTPUT =3D=20
-
-# The HTML_HEADER tag can be used to specify a personal HTML header for=20
-# each generated HTML page. If it is left blank doxygen will generate a=20
-# standard header.
-
-HTML_HEADER =3D=20
-
-# The HTML_FOOTER tag can be used to specify a personal HTML footer for=20
-# each generated HTML page. If it is left blank doxygen will generate a=20
-# standard footer.
-
-HTML_FOOTER =3D=20
-
-# The HTML_STYLESHEET tag can be used to specify a user defined cascading=20
-# style sheet that is used by each HTML page. It can be used to=20
-# fine-tune the look of the HTML output. If the tag is left blank doxygen=20
-# will generate a default style sheet
-
-HTML_STYLESHEET =3D=20
-
-# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,=20
-# files or namespaces will be aligned in HTML using tables. If set to=20
-# NO a bullet list will be used.
-
-HTML_ALIGN_MEMBERS =3D YES
-
-# If the GENERATE_HTMLHELP tag is set to YES, additional index files=20
-# will be generated that can be used as input for tools like the=20
-# Microsoft HTML help workshop to generate a compressed HTML help file (.c=
hm)=20
-# of the generated HTML documentation.
-
-GENERATE_HTMLHELP =3D NO
-
-# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag=20
-# controls if a separate .chi index file is generated (YES) or that=20
-# it should be included in the master .chm file (NO).
-
-GENERATE_CHI =3D NO
-
-# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag=20
-# controls whether a binary table of contents is generated (YES) or a=20
-# normal table of contents (NO) in the .chm file.
-
-BINARY_TOC =3D NO
-
-# The TOC_EXPAND flag can be set to YES to add extra items for group membe=
rs=20
-# to the contents of the Html help documentation and to the tree view.
-
-TOC_EXPAND =3D NO
-
-# The DISABLE_INDEX tag can be used to turn on/off the condensed index at=20
-# top of each HTML page. The value NO (the default) enables the index and=20
-# the value YES disables it.
-
-DISABLE_INDEX =3D NO
-
-# This tag can be used to set the number of enum values (range [1..20])=20
-# that doxygen will group on one line in the generated HTML documentation.
-
-ENUM_VALUES_PER_LINE =3D 4
-
-# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be
-# generated containing a tree-like index structure (just like the one that=20
-# is generated for HTML Help). For this to work a browser that supports=20
-# JavaScript and frames is required (for instance Netscape 4.0+=20
-# or Internet explorer 4.0+).
-
-GENERATE_TREEVIEW =3D YES
-
-# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be=20
-# used to set the initial width (in pixels) of the frame in which the tree=20
-# is shown.
-
-TREEVIEW_WIDTH =3D 250
-
-#-------------------------------------------------------------------------=
--
-# configuration options related to the LaTeX output
-#-------------------------------------------------------------------------=
--
-
-# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will=20
-# generate Latex output.
-
-GENERATE_LATEX =3D NO
-
-# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put=
.=20
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be=20
-# put in front of it. If left blank `latex' will be used as the default pa=
th.
-
-LATEX_OUTPUT =3D=20
-
-# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact=20
-# LaTeX documents. This may be useful for small projects and may help to=20
-# save some trees in general.
-
-COMPACT_LATEX =3D NO
-
-# The PAPER_TYPE tag can be used to set the paper type that is used=20
-# by the printer. Possible values are: a4, a4wide, letter, legal and=20
-# executive. If left blank a4wide will be used.
-
-PAPER_TYPE =3D letter
-
-# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX=20
-# packages that should be included in the LaTeX output.
-
-EXTRA_PACKAGES =3D=20
-
-# The LATEX_HEADER tag can be used to specify a personal LaTeX header for=20
-# the generated latex document. The header should contain everything until=20
-# the first chapter. If it is left blank doxygen will generate a=20
-# standard header. Notice: only use this tag if you know what you are doin=
g!
-
-LATEX_HEADER =3D=20
-
-# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated=20
-# is prepared for conversion to pdf (using ps2pdf). The pdf file will=20
-# contain links (just like the HTML output) instead of page references=20
-# This makes the output suitable for online browsing using a pdf viewer.
-
-PDF_HYPERLINKS =3D NO
-
-# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of=20
-# plain latex in the generated Makefile. Set this option to YES to get a=20
-# higher quality PDF documentation.
-
-USE_PDFLATEX =3D NO
-
-# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmo=
de.=20
-# command to the generated LaTeX files. This will instruct LaTeX to keep=20
-# running if errors occur, instead of asking the user for help.=20
-# This option is also used when generating formulas in HTML.
-
-LATEX_BATCHMODE =3D NO
-
-#-------------------------------------------------------------------------=
--
-# configuration options related to the RTF output
-#-------------------------------------------------------------------------=
--
-
-# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output=20
-# The RTF output is optimised for Word 97 and may not look very pretty wit=
h=20
-# other RTF readers or editors.
-
-GENERATE_RTF =3D NO
-
-# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.=20
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be=20
-# put in front of it. If left blank `rtf' will be used as the default path.
-
-RTF_OUTPUT =3D=20
-
-# If the COMPACT_RTF tag is set to YES Doxygen generates more compact=20
-# RTF documents. This may be useful for small projects and may help to=20
-# save some trees in general.
-
-COMPACT_RTF =3D NO
-
-# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated=20
-# will contain hyperlink fields. The RTF file will=20
-# contain links (just like the HTML output) instead of page references.=20
-# This makes the output suitable for online browsing using WORD or other=20
-# programs which support those fields.=20
-# Note: wordpad (write) and others do not support links.
-
-RTF_HYPERLINKS =3D NO
-
-# Load stylesheet definitions from file. Syntax is similar to doxygen's=20
-# config file, i.e. a series of assigments. You only have to provide=20
-# replacements, missing definitions are set to their default value.
-
-RTF_STYLESHEET_FILE =3D=20
-
-# Set optional variables used in the generation of an rtf document.=20
-# Syntax is similar to doxygen's config file.
-
-RTF_EXTENSIONS_FILE =3D=20
-
-#-------------------------------------------------------------------------=
--
-# configuration options related to the man page output
-#-------------------------------------------------------------------------=
--
-
-# If the GENERATE_MAN tag is set to YES (the default) Doxygen will=20
-# generate man pages
-
-GENERATE_MAN =3D NO
-
-# The MAN_OUTPUT tag is used to specify where the man pages will be put.=20
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be=20
-# put in front of it. If left blank `man' will be used as the default path.
-
-MAN_OUTPUT =3D=20
-
-# The MAN_EXTENSION tag determines the extension that is added to=20
-# the generated man pages (default is the subroutine's section .3)
-
-MAN_EXTENSION =3D=20
-
-# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
-# then it will generate one additional man file for each entity
-# documented in the real man page(s). These additional files
-# only source the real man page, but without them the man command
-# would be unable to find the correct page. The default is NO.
-
-MAN_LINKS =3D NO
-
-#-------------------------------------------------------------------------=
--
-# configuration options related to the XML output
-#-------------------------------------------------------------------------=
--
-
-# If the GENERATE_XML tag is set to YES Doxygen will=20
-# generate an XML file that captures the structure of=20
-# the code including all documentation. Note that this=20
-# feature is still experimental and incomplete at the=20
-# moment.
-
-GENERATE_XML =3D NO
-
-#-------------------------------------------------------------------------=
--
-# Configuration options related to the preprocessor =20
-#-------------------------------------------------------------------------=
--
-
-# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will=20
-# evaluate all C-preprocessor directives found in the sources and include=20
-# files.
-
-ENABLE_PREPROCESSING =3D YES
-
-# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro=20
-# names in the source code. If set to NO (the default) only conditional=20
-# compilation will be performed. Macro expansion can be done in a controll=
ed=20
-# way by setting EXPAND_ONLY_PREDEF to YES.
-
-MACRO_EXPANSION =3D NO
-
-# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES=20
-# then the macro expansion is limited to the macros specified with the=20
-# PREDEFINED and EXPAND_AS_PREDEFINED tags.
-
-EXPAND_ONLY_PREDEF =3D NO
-
-# If the SEARCH_INCLUDES tag is set to YES (the default) the includes file=
s=20
-# in the INCLUDE_PATH (see below) will be search if a #include is found.
-
-SEARCH_INCLUDES =3D YES
-
-# The INCLUDE_PATH tag can be used to specify one or more directories that=20
-# contain include files that are not input files but should be processed b=
y=20
-# the preprocessor.
-
-INCLUDE_PATH =3D=20
-
-# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcar=
d=20
-# patterns (like *.h and *.hpp) to filter out the header-files in the=20
-# directories. If left blank, the patterns specified with FILE_PATTERNS wi=
ll=20
-# be used.
-
-INCLUDE_FILE_PATTERNS =3D=20
-
-# The PREDEFINED tag can be used to specify one or more macro names that=20
-# are defined before the preprocessor is started (similar to the -D option=
of=20
-# gcc). The argument of the tag is a list of macros of the form: name=20
-# or name=3Ddefinition (no spaces). If the definition and the =3D are=20
-# omitted =3D1 is assumed.
-
-PREDEFINED =3D=20
-
-# If the MACRO_EXPANSION and EXPAND_PREDEF_ONLY tags are set to YES then=20
-# this tag can be used to specify a list of macro names that should be exp=
anded.=20
-# The macro definition that is found in the sources will be used.=20
-# Use the PREDEFINED tag if you want to use a different macro definition.
-
-EXPAND_AS_DEFINED =3D=20
-
-# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then=20
-# doxygen's preprocessor will remove all function-like macros that are alo=
ne=20
-# on a line and do not end with a semicolon. Such function macros are typi=
cally=20
-# used for boiler-plate code, and will confuse the parser if not removed.
-
-SKIP_FUNCTION_MACROS =3D YES
-
-#-------------------------------------------------------------------------=
--
-# Configuration::addtions related to external references =20
-#-------------------------------------------------------------------------=
--
-
-# The TAGFILES tag can be used to specify one or more tagfiles.
-
-TAGFILES =3D=20
-
-# When a file name is specified after GENERATE_TAGFILE, doxygen will creat=
e=20
-# a tag file that is based on the input files it reads.
-
-GENERATE_TAGFILE =3D=20
-
-# If the ALLEXTERNALS tag is set to YES all external classes will be liste=
d=20
-# in the class index. If set to NO only the inherited external classes=20
-# will be listed.
-
-ALLEXTERNALS =3D NO
-
-# The PERL_PATH should be the absolute path and name of the perl script=20
-# interpreter (i.e. the result of `which perl').
-
-PERL_PATH =3D=20
-
-#-------------------------------------------------------------------------=
--
-# Configuration options related to the dot tool =20
-#-------------------------------------------------------------------------=
--
-
-# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool=
is=20
-# available from the path. This tool is part of Graphviz, a graph visualiz=
ation=20
-# toolkit from AT&T and Lucent Bell Labs. The other options in this sectio=
n=20
-# have no effect if this option is set to NO (the default)
-
-HAVE_DOT =3D NO
-
-# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen=20
-# will generate a graph for each documented class showing the direct and=20
-# indirect inheritance relations. Setting this tag to YES will force the=20
-# the CLASS_DIAGRAMS tag to NO.
-
-CLASS_GRAPH =3D YES
-
-# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen=20
-# will generate a graph for each documented class showing the direct and=20
-# indirect implementation dependencies (inheritance, containment, and=20
-# class references variables) of the class with other documented classes.
-
-COLLABORATION_GRAPH =3D YES
-
-# If set to YES, the inheritance and collaboration graphs will show the=20
-# relations between templates and their instances.
-
-TEMPLATE_RELATIONS =3D YES
-
-# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DO=
T=20
-# tags are set to YES then doxygen will generate a graph for each document=
ed=20
-# file showing the direct and indirect include dependencies of the file wi=
th=20
-# other documented files.
-
-INCLUDE_GRAPH =3D YES
-
-# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and=20
-# HAVE_DOT tags are set to YES then doxygen will generate a graph for each=20
-# documented header file showing the documented files that directly or=20
-# indirectly include this file.
-
-INCLUDED_BY_GRAPH =3D YES
-
-# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen=20
-# will graphical hierarchy of all classes instead of a textual one.
-
-GRAPHICAL_HIERARCHY =3D YES
-
-# The tag DOT_PATH can be used to specify the path where the dot tool can =
be=20
-# found. If left blank, it is assumed the dot tool can be found on the pat=
h.
-
-DOT_PATH =3D=20
-
-# The DOTFILE_DIRS tag can be used to specify one or more directories that=20
-# contain dot files that are included in the documentation (see the=20
-# \dotfile command).
-
-DOTFILE_DIRS =3D=20
-
-# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width=20
-# (in pixels) of the graphs generated by dot. If a graph becomes larger th=
an=20
-# this value, doxygen will try to truncate the graph, so that it fits with=
in=20
-# the specified constraint. Beware that most browsers cannot cope with ver=
y=20
-# large images.
-
-MAX_DOT_GRAPH_WIDTH =3D 1024
-
-# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows heigh=
t=20
-# (in pixels) of the graphs generated by dot. If a graph becomes larger th=
an=20
-# this value, doxygen will try to truncate the graph, so that it fits with=
in=20
-# the specified constraint. Beware that most browsers cannot cope with ver=
y=20
-# large images.
-
-MAX_DOT_GRAPH_HEIGHT =3D 1024
-
-# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will=20
-# generate a legend page explaining the meaning of the various boxes and=20
-# arrows in the dot generated graphs.
-
-GENERATE_LEGEND =3D YES
-
-# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will=20
-# remove the intermedate dot files that are used to generate=20
-# the various graphs.
-
-DOT_CLEANUP =3D YES
-
-#-------------------------------------------------------------------------=
--
-# Configuration::addtions related to the search engine =20
-#-------------------------------------------------------------------------=
--
-
-# The SEARCHENGINE tag specifies whether or not a search engine should be=20
-# used. If set to NO the values of all tags below this one will be ignored.
-
-SEARCHENGINE =3D NO
-
-# The CGI_NAME tag should be the name of the CGI script that=20
-# starts the search engine (doxysearch) with the correct parameters.=20
-# A script with this name will be generated by doxygen.
-
-CGI_NAME =3D=20
-
-# The CGI_URL tag should be the absolute URL to the directory where the=20
-# cgi binaries are located. See the documentation of your http daemon for=20
-# details.
-
-CGI_URL =3D=20
-
-# The DOC_URL tag should be the absolute URL to the directory where the=20
-# documentation is located. If left blank the absolute path to the=20
-# documentation, with file:// prepended to it, will be used.
-
-DOC_URL =3D=20
-
-# The DOC_ABSPATH tag should be the absolute path to the directory where t=
he=20
-# documentation is located. If left blank the directory on the local machi=
ne=20
-# will be used.
-
-DOC_ABSPATH =3D=20
-
-# The BIN_ABSPATH tag must point to the directory where the doxysearch bin=
ary=20
-# is installed.
-
-BIN_ABSPATH =3D=20
-
-# The EXT_DOC_PATHS tag can be used to specify one or more paths to=20
-# documentation generated for other projects. This allows doxysearch to se=
arch=20
-# the documentation for these projects as well.
-
-EXT_DOC_PATHS =3D=20
diff --git a/src/Core.cpp b/src/Core.cpp
index b556858..dfb9cf2 100644
--- a/src/Core.cpp
+++ b/src/Core.cpp
@@ -44,6 +44,7 @@
#include "moab/WriterIface.hpp"
#include "moab/ScdInterface.hpp"
#include "moab/SetIterator.hpp"
+#include "moab/Util.hpp"
=20
#include "BitTag.hpp"
#include "DenseTag.hpp"
@@ -609,6 +610,14 @@ ErrorCode Core::serial_load_file( const char* file_nam=
e,
Range new_ents;
get_entities_by_handle( 0, new_ents );
new_ents =3D subtract( new_ents, initial_ents );
+
+ // The gather set entities should be excluded from the file set
+ EntityHandle gather_set;
+ Range gather_ents;
+ rval =3D Util::gather_set_entities( this, gather_set, gather_ents );
+ if (MB_SUCCESS =3D=3D rval)
+ new_ents =3D subtract( new_ents, gather_ents );
+
rval =3D add_entities( *file_set, new_ents );
}
=20
diff --git a/src/io/NCHelperEuler.cpp b/src/io/NCHelperEuler.cpp
index 146227c..7336fa9 100644
--- a/src/io/NCHelperEuler.cpp
+++ b/src/io/NCHelperEuler.cpp
@@ -129,13 +129,13 @@ ErrorCode NCHelperEuler::init_mesh_vals(const FileOpt=
ions& opts, EntityHandle fi
gDims[2] =3D -1;
gDims[5] =3D -1;
=20
- // look for time dimensions
+ // Look for time dimension
if ((vit =3D std::find(dimNames.begin(), dimNames.end(), "time")) !=3D d=
imNames.end())
idx =3D vit - dimNames.begin();
else if ((vit =3D std::find(dimNames.begin(), dimNames.end(), "t")) !=3D=
dimNames.end())
idx =3D vit - dimNames.begin();
else {
- ERRORR(MB_FAILURE, "Couldn't find time variable.");
+ ERRORR(MB_FAILURE, "Couldn't find time dimension.");
}
tDim =3D idx;
tMax =3D dimVals[idx] - 1;
@@ -323,13 +323,16 @@ ErrorCode NCHelperEuler::init_mesh_vals(const FileOpt=
ions& opts, EntityHandle fi
}
}
=20
+ // Store time coordinate values in tVals
if (tMin !=3D -1) {
if ((vmit =3D varInfo.find(tName)) !=3D varInfo.end() && (*vmit).secon=
d.varDims.size() =3D=3D 1) {
rval =3D _readNC->read_coordinate(tName.c_str(), tMin, tMax, tVals);
ERRORR(rval, "Trouble reading time variable.");
}
else {
- ERRORR(MB_FAILURE, "Couldn't find time coordinate.");
+ // If expected time variable is not available, set dummy time coordi=
nate values to tVals
+ for (int t =3D tMin; t <=3D tMax; t++)
+ tVals.push_back((double)t);
}
}
=20
diff --git a/src/io/NCHelperFV.cpp b/src/io/NCHelperFV.cpp
index 9141938..cb6229e 100644
--- a/src/io/NCHelperFV.cpp
+++ b/src/io/NCHelperFV.cpp
@@ -143,10 +143,11 @@ ErrorCode NCHelperFV::init_mesh_vals(const FileOption=
s& opts, EntityHandle file_
gCDims[1] =3D 0;
jCName =3D dimNames[idx];
=20
+ // Look for time dimension
if ((vit =3D std::find(dimNames.begin(), dimNames.end(), "time")) !=3D d=
imNames.end())
idx =3D vit - dimNames.begin();
else {
- ERRORR(MB_FAILURE, "Couldn't find time variable.");
+ ERRORR(MB_FAILURE, "Couldn't find time dimension.");
}
tDim =3D idx;
tMax =3D dimVals[idx] - 1;
@@ -313,13 +314,16 @@ ErrorCode NCHelperFV::init_mesh_vals(const FileOption=
s& opts, EntityHandle file_
}
}
=20
+ // Store time coordinate values in tVals
if (tMin !=3D -1) {
if ((vmit =3D varInfo.find(tName)) !=3D varInfo.end() && (*vmit).secon=
d.varDims.size() =3D=3D 1) {
rval =3D _readNC->read_coordinate(tName.c_str(), tMin, tMax, tVals);
ERRORR(rval, "Trouble reading time variable.");
}
else {
- ERRORR(MB_FAILURE, "Couldn't find time coordinate.");
+ // If expected time variable is not available, set dummy time coordi=
nate values to tVals
+ for (int t =3D tMin; t <=3D tMax; t++)
+ tVals.push_back((double)t);
}
}
=20
diff --git a/src/io/NCHelperHOMME.cpp b/src/io/NCHelperHOMME.cpp
index 95605fe..e320e57 100644
--- a/src/io/NCHelperHOMME.cpp
+++ b/src/io/NCHelperHOMME.cpp
@@ -79,12 +79,14 @@ ErrorCode NCHelperHOMME::init_mesh_vals(const FileOptio=
ns& opts, EntityHandle fi
ErrorCode rval;
unsigned int idx;
std::vector<std::string>::iterator vit;
+
+ // Look for time dimension
if ((vit =3D std::find(dimNames.begin(), dimNames.end(), "time")) !=3D d=
imNames.end())
idx =3D vit - dimNames.begin();
else if ((vit =3D std::find(dimNames.begin(), dimNames.end(), "t")) !=3D=
dimNames.end())
idx =3D vit - dimNames.begin();
else {
- ERRORR(MB_FAILURE, "Couldn't find time variable.");
+ ERRORR(MB_FAILURE, "Couldn't find time dimension.");
}
tDim =3D idx;
tMax =3D dimVals[idx] - 1;
@@ -156,24 +158,19 @@ ErrorCode NCHelperHOMME::init_mesh_vals(const FileOpt=
ions& opts, EntityHandle fi
}
}
=20
+ // Store time coordinate values in tVals
if (tMin !=3D -1) {
if ((vmit =3D varInfo.find(tName)) !=3D varInfo.end() && (*vmit).secon=
d.varDims.size() =3D=3D 1) {
rval =3D _readNC->read_coordinate(tName.c_str(), tMin, tMax, tVals);
ERRORR(rval, "Trouble reading time variable.");
}
else {
- ERRORR(MB_FAILURE, "Couldn't find time coordinate.");
+ // If expected time variable is not available, set dummy time coordi=
nate values to tVals
+ for (int t =3D tMin; t <=3D tMax; t++)
+ tVals.push_back((double)t);
}
}
=20
- if ((vmit =3D varInfo.find(tName)) !=3D varInfo.end() && (*vmit).second.=
varDims.size() =3D=3D 1) {
- rval =3D _readNC->read_coordinate(tName.c_str(), tMin, tMax, tVals);
- ERRORR(rval, "Trouble reading time variable.");
- }
- else {
- ERRORR(MB_FAILURE, "Couldn't find time coordinate.");
- }
-
// determine the entity location type of a variable
std::map<std::string, ReadNC::VarData>::iterator mit;
for (mit =3D varInfo.begin(); mit !=3D varInfo.end(); ++mit) {
diff --git a/src/io/NCHelperMPAS.cpp b/src/io/NCHelperMPAS.cpp
index d7f61af..24b7241 100644
--- a/src/io/NCHelperMPAS.cpp
+++ b/src/io/NCHelperMPAS.cpp
@@ -60,10 +60,11 @@ ErrorCode NCHelperMPAS::init_mesh_vals(const FileOption=
s& opts, EntityHandle fil
}
}
=20
+ // Look for time dimension
if ((vit =3D std::find(dimNames.begin(), dimNames.end(), "Time")) !=3D d=
imNames.end())
idx =3D vit - dimNames.begin();
else {
- ERRORR(MB_FAILURE, "Couldn't find time variable.");
+ ERRORR(MB_FAILURE, "Couldn't find time dimension.");
}
tDim =3D idx;
tMax =3D dimVals[idx] - 1;
@@ -137,13 +138,16 @@ ErrorCode NCHelperMPAS::init_mesh_vals(const FileOpti=
ons& opts, EntityHandle fil
ERRORR(MB_FAILURE, "Couldn't find z coordinate.");
}
=20
+ // Store time coordinate values in tVals
if (tMin !=3D -1) {
if ((vmit =3D varInfo.find(tName)) !=3D varInfo.end() && (*vmit).secon=
d.varDims.size() =3D=3D 1) {
rval =3D _readNC->read_coordinate(tName.c_str(), tMin, tMax, tVals);
ERRORR(rval, "Trouble reading time variable.");
}
else {
- ERRORR(MB_FAILURE, "Couldn't find time coordinate.");
+ // If expected time variable is not available, set dummy time coordi=
nate values to tVals
+ for (int t =3D tMin; t <=3D tMax; t++)
+ tVals.push_back((double)t);
}
}
=20
https://bitbucket.org/fathomteam/moab/commits/08d19d1033a3/
Changeset: 08d19d1033a3
Branch: None
User: jeffdaily
Date: 2013-07-23 18:47:46
Summary: ReadNC::read_coordinate for NC_FLOAT bugfix
Affected #: 1 file
diff --git a/src/io/ReadNC.cpp b/src/io/ReadNC.cpp
index 78c3fbc..cf301df 100644
--- a/src/io/ReadNC.cpp
+++ b/src/io/ReadNC.cpp
@@ -449,6 +449,7 @@ ErrorCode ReadNC::read_coordinate(const char* var_name,=
int lmin, int lmax, std:
fail =3D NCFUNCA(get_vars_float)(fileId, (*vmit).second.varId, &tmin, =
&tcount, &dum_stride, &tcvals[0]);
if (fail)
ERRORS(MB_FAILURE, "Failed to get coordinate values.");
+ cvals.resize(tcount);
std::copy(tcvals.begin(), tcvals.end(), cvals.begin());
}
else ERRORR(MB_FAILURE, "Wrong data type for coordinate variable.");
https://bitbucket.org/fathomteam/moab/commits/44774cf94115/
Changeset: 44774cf94115
Branch: None
User: danwu
Date: 2013-07-23 20:02:47
Summary: Merged fathomteam/moab into master
Affected #: 6 files
diff --git a/src/io/ReadHDF5.cpp b/src/io/ReadHDF5.cpp
index 5e90822..916b69a 100644
--- a/src/io/ReadHDF5.cpp
+++ b/src/io/ReadHDF5.cpp
@@ -842,7 +842,7 @@ ErrorCode ReadHDF5::load_file_partial( const ReaderIfac=
e::IDTag* subset_list,
dbgOut.printf( 2, "Partition with num_parts =3D %d and part_number =3D=
%d\n",=20
num_parts, part_number );
=20
- dbgOut.tprint( 1, "RETREIVING TAGGED ENTITIES\n" );
+ dbgOut.tprint( 1, "RETRIEVING TAGGED ENTITIES\n" );
=20
Range file_ids;
ErrorCode rval =3D get_subset_ids( subset_list, subset_list_length, file=
_ids );
@@ -964,7 +964,6 @@ ErrorCode ReadHDF5::load_file_partial( const ReaderIfac=
e::IDTag* subset_list,
=20
Range subset;
intersect( fileInfo->elems[i].desc, file_ids, subset );
- =20
mpe_event.start( "reading connectivity for ", fileInfo->elems[i].handl=
e );
=20
// If dimension is max_dim, then we can create the elements now
@@ -1544,7 +1543,8 @@ ErrorCode ReadHDF5::read_elems( const mhdf_ElemDesc& =
elems, const Range& file_id
=20
EntityHandle handle;
EntityHandle* array =3D 0;
- rval =3D readUtil->get_element_connect( count, nodes_per_elem, type,
+ if (count>0)
+ rval =3D readUtil->get_element_connect( count, nodes_per_elem, type,
0, handle, array );
if (MB_SUCCESS !=3D rval)
return error(rval);
diff --git a/test/parallel/par_intx_sph.cpp b/test/parallel/par_intx_sph.cpp
index dca936e..a6721a2 100644
--- a/test/parallel/par_intx_sph.cpp
+++ b/test/parallel/par_intx_sph.cpp
@@ -280,7 +280,7 @@ void test_intx_mpas()
std::stringstream ss;
ss<<"partial" << rank<<".vtk";
mb.write_file(ss.str().c_str(), 0, 0, &covering_lagr_set, 1);
- rval =3D enforce_convexity(&mb, covering_lagr_set);
+ rval =3D enforce_convexity(&mb, covering_lagr_set, rank);
CHECK_ERR(rval);
std::stringstream ss2;
ss2<<"partialConvex" << rank<<".vtk";
diff --git a/tools/mbcslam/CslamUtils.cpp b/tools/mbcslam/CslamUtils.cpp
index 70d81ed..ad30c9d 100644
--- a/tools/mbcslam/CslamUtils.cpp
+++ b/tools/mbcslam/CslamUtils.cpp
@@ -864,7 +864,7 @@ void departure_point_case1(CartVect & arrival_point, do=
uble t, double delta_t, C
// break the nonconvex quads into triangles; remove the quad from the set?=
yes.
// maybe radius is not needed;
//
-ErrorCode enforce_convexity(Interface * mb, EntityHandle lset)
+ErrorCode enforce_convexity(Interface * mb, EntityHandle lset, int my_rank)
{
// look at each quad; compute all 4 angles; if one is reflex, break alon=
g that diagonal
// replace it with 2 triangles, and remove from set;
@@ -989,7 +989,7 @@ ErrorCode enforce_convexity(Interface * mb, EntityHandl=
e lset)
}
}
}
- std::cout << brokenPolys << " concave polygons were decomposed in convex=
ones \n";
+ std::cout << "on rank " << my_rank << " " << brokenPolys << " concave p=
olygons were decomposed in convex ones \n";
return MB_SUCCESS;
}
ErrorCode create_span_quads(Interface * mb, EntityHandle euler_set, int ra=
nk)
diff --git a/tools/mbcslam/CslamUtils.hpp b/tools/mbcslam/CslamUtils.hpp
index 241fe84..e039d96 100644
--- a/tools/mbcslam/CslamUtils.hpp
+++ b/tools/mbcslam/CslamUtils.hpp
@@ -129,7 +129,7 @@ void departure_point_case1(CartVect & arrival_point, do=
uble t, double delta_t, C
// break the nonconvex quads into triangles; remove the quad from the set?=
yes.
// maybe radius is not needed;
//
-ErrorCode enforce_convexity(Interface * mb, EntityHandle set);
+ErrorCode enforce_convexity(Interface * mb, EntityHandle set, int rank =3D=
0);
=20
// looking at DP tag, create the spanning quads, write a file (with rank) =
and
// then delete the new entities (vertices) and the set of quads
diff --git a/tools/mbcslam/Intx2Mesh.cpp b/tools/mbcslam/Intx2Mesh.cpp
index fadbaa3..6ddadfb 100644
--- a/tools/mbcslam/Intx2Mesh.cpp
+++ b/tools/mbcslam/Intx2Mesh.cpp
@@ -1268,8 +1268,10 @@ ErrorCode Intx2Mesh::create_departure_mesh_2nd_alg(E=
ntityHandle & euler_set, Ent
globalID_to_handle[globalId]=3D new_vert;
}
}
- // now, all dep points should be at their place
- // look in the local list of q for this proc, and create all those q=
uads and vertices if needed
+
+ // now, all dep points should be at their place
+ // look in the local list of q for this proc, and create all those quads=
and vertices if needed
+ // it may be an overkill, but because it does not involve communication,=
we do it anyway
Range & local=3DRto[my_rank];
Range local_q =3D local.subset_by_dimension(2);
// the local should have all the vertices in local_verts
diff --git a/tools/mbcslam/intx_mpas.cpp b/tools/mbcslam/intx_mpas.cpp
index 827871b..679bd03 100644
--- a/tools/mbcslam/intx_mpas.cpp
+++ b/tools/mbcslam/intx_mpas.cpp
@@ -39,9 +39,9 @@ using namespace moab;
// some input data
double gtol =3D 1.e-9; // this is for geometry tolerance
=20
-// radius is always 1?
-//double CubeSide =3D 6.; // the above file starts with cube side 6; radiu=
s depends on cube side
-double t =3D 0.1, delta_t =3D 0.1; // check the script
+double radius =3D 1.;// in m: 6371220.
+
+double t =3D 0.1, delta_t =3D 0.05; // check the script
=20
ErrorCode manufacture_lagrange_mesh_on_sphere(Interface * mb,
EntityHandle euler_set)
@@ -50,10 +50,9 @@ ErrorCode manufacture_lagrange_mesh_on_sphere(Interface =
* mb,
=20
/*
* get all plys first, then vertices, then move them on the surface of t=
he sphere
- * radius is 1., always
+ * radius is 1., most of the time
*
*/
- double radius =3D 1.;
Range polygons;
rval =3D mb->get_entities_by_dimension(euler_set, 2, polygons);
if (MB_SUCCESS !=3D rval)
@@ -82,8 +81,8 @@ ErrorCode manufacture_lagrange_mesh_on_sphere(Interface *=
mb,
=20
// now put the vertices in the right place....
//int vix=3D0; // vertex index in new array
- double t=3D0.1, T=3D5;// check the script
- double time =3D0.05;
+ double T=3D5;// check the script
+
double rot=3D M_PI/10;
for (Range::iterator vit=3DconnecVerts.begin();vit!=3DconnecVerts.end();=
vit++ )
{
@@ -95,12 +94,12 @@ ErrorCode manufacture_lagrange_mesh_on_sphere(Interface=
* mb,
SphereCoords sphCoord =3D cart_to_spherical(posi);
double lat1 =3D sphCoord.lat-2*M_PI*t/T; // 0.1/5
double uu =3D 3*radius/ T * pow(sin(lat1), 2)*sin(2*sphCoord.lon)*cos(=
M_PI*t/T);
- uu+=3D2*M_PI*cos(sphCoord.lon)/T;
+ uu+=3D2*radius*M_PI*cos(sphCoord.lon)/T;
double vv =3D 3*radius/T*(sin(2*lat1))*cos(sphCoord.lon)*cos(M_PI*t/T);
double vx =3D -uu*sin(sphCoord.lon)-vv*sin(sphCoord.lat)*cos(sphCoord.=
lon);
double vy =3D -uu*cos(sphCoord.lon)-vv*sin(sphCoord.lat)*sin(sphCoord.=
lon);
double vz =3D vv*cos(sphCoord.lat);
- posi =3D posi + time * CartVect(vx, vy, vz);
+ posi =3D posi + delta_t * CartVect(vx, vy, vz);
double x2=3D posi[0]*cos(rot)-posi[1]*sin(rot);
double y2=3D posi[0]*sin(rot) + posi[1]*cos(rot);
CartVect newPos(x2, y2, posi[2]);
@@ -120,6 +119,7 @@ int main(int argc, char **argv)
=20
MPI_Init(&argc, &argv);
=20
+ std::string extra_read_opts;
std::string fileN=3D TestDir + "/mpas_p8.h5m";
const char *filename_mesh1 =3D fileN.c_str();
if (argc > 1)
@@ -139,12 +139,21 @@ int main(int argc, char **argv)
{
filename_mesh1 =3D argv[++index];
}
+ if (!strcmp(argv[index], "-R"))
+ {
+ radius =3D atof(argv[++index]);
+ }
+ if (!strcmp(argv[index], "-O"))
+ {
+ extra_read_opts =3D std::string(argv[++index]);
+ }
+
index++;
}
}
// start copy
std::string opts =3D std::string("PARALLEL=3DREAD_PART;PARTITION=3DPARAL=
LEL_PARTITION")+
- std::string(";PARALLEL_RESOLVE_SHARED_ENTS");
+ std::string(";PARALLEL_RESOLVE_SHARED_ENTS")+extra_read_opts;
Core moab;
Interface & mb =3D moab;
EntityHandle euler_set;
@@ -165,7 +174,7 @@ int main(int argc, char **argv)
=20
if (0=3D=3Drank)
std::cout << " case 1: use -gtol " << gtol << " -dt " << delta_t <<
- " -input " << filename_mesh1 << "\n";
+ " -R " << radius << " -input " << filename_mesh1 << "\n";
=20
rval =3D manufacture_lagrange_mesh_on_sphere(&mb, euler_set);
if (MB_SUCCESS !=3D rval)
@@ -181,7 +190,7 @@ int main(int argc, char **argv)
CHECK_ERR(rval);
Intx2MeshOnSphere worker(&mb);
=20
- double radius =3D 1.; // input
+ //double radius =3D 1.; // input
=20
worker.SetRadius(radius);
=20
@@ -189,7 +198,11 @@ int main(int argc, char **argv)
rval =3D worker.create_departure_mesh_2nd_alg(euler_set, covering_lagr_s=
et);
CHECK_ERR(rval);
=20
- rval =3D enforce_convexity(&mb, covering_lagr_set);
+ std::stringstream lagrIni;
+ lagrIni<<"def0" << rank<<".h5m";
+ rval =3D mb.write_file(lagrIni.str().c_str(), 0, 0, &covering_lagr_set, =
1);
+
+ rval =3D enforce_convexity(&mb, covering_lagr_set, rank);
if (MB_SUCCESS !=3D rval)
return 1;
=20
https://bitbucket.org/fathomteam/moab/commits/a97c979236b9/
Changeset: a97c979236b9
Branch: None
User: danwu
Date: 2013-07-23 20:11:41
Summary: Merged in jeffdaily/moab/hotfix-ReadNC (pull request #1)
ReadNC::read_coordinate for NC_FLOAT bugfix
Affected #: 1 file
diff --git a/src/io/ReadNC.cpp b/src/io/ReadNC.cpp
index 78c3fbc..cf301df 100644
--- a/src/io/ReadNC.cpp
+++ b/src/io/ReadNC.cpp
@@ -449,6 +449,7 @@ ErrorCode ReadNC::read_coordinate(const char* var_name,=
int lmin, int lmax, std:
fail =3D NCFUNCA(get_vars_float)(fileId, (*vmit).second.varId, &tmin, =
&tcount, &dum_stride, &tcvals[0]);
if (fail)
ERRORS(MB_FAILURE, "Failed to get coordinate values.");
+ cvals.resize(tcount);
std::copy(tcvals.begin(), tcvals.end(), cvals.begin());
}
else ERRORR(MB_FAILURE, "Wrong data type for coordinate variable.");
https://bitbucket.org/fathomteam/moab/commits/ca702d29b642/
Changeset: ca702d29b642
Branch: None
User: danwu
Date: 2013-07-23 21:26:16
Summary: Merged fathomteam/moab into master
Affected #: 2 files
diff --git a/test/io/read_ucd_nc.cpp b/test/io/read_ucd_nc.cpp
index 4678540..a468ad2 100644
--- a/test/io/read_ucd_nc.cpp
+++ b/test/io/read_ucd_nc.cpp
@@ -1,5 +1,6 @@
#include "TestUtil.hpp"
#include "moab/Core.hpp"
+#include "moab/Util.hpp"
=20
using namespace moab;
=20
@@ -11,42 +12,44 @@ static const char example[] =3D "/io/homme26x3458.t.3.n=
c";
=20
#ifdef USE_MPI
#include "moab_mpi.h"
+#include "moab/ParallelComm.hpp"
#endif
=20
-void read_file( Interface& moab, const char* input_file );
void test_read_all();
void test_read_onevar();
void test_read_onetimestep();
void test_read_nomesh();
void test_read_novars();
-ErrorCode get_options(std::string &opts);
=20
-int main(int argc, char *argv[])
+ErrorCode get_options(std::string& opts);
+
+int main(int argc, char* argv[])
{
int result =3D 0;
=20
#ifdef USE_MPI
int fail =3D MPI_Init(&argc, &argv);
- if (fail) return 1;
+ if (fail)
+ return 1;
#else
- argv[0]=3Dargv[argc-argc];// to remove the warnings in serial mode about=
unused variables
+ argv[0] =3D argv[argc - argc]; // To remove the warnings in serial mode =
about unused variables
#endif
- =20
+
result +=3D RUN_TEST(test_read_all);
result +=3D RUN_TEST(test_read_onevar);
result +=3D RUN_TEST(test_read_onetimestep);
result +=3D RUN_TEST(test_read_nomesh);
result +=3D RUN_TEST(test_read_novars);
- =20
+
#ifdef USE_MPI
fail =3D MPI_Finalize();
- if (fail) return 1;
+ if (fail)
+ return 1;
#endif
- =20
+
return result;
}
=20
-
void test_read_all()
{
Core moab;
@@ -55,15 +58,15 @@ void test_read_all()
std::string opts;
ErrorCode rval =3D get_options(opts);
CHECK_ERR(rval);
- =20
- rval =3D mb.load_file( example, NULL, opts.c_str());
+
+ rval =3D mb.load_file(example, NULL, opts.c_str());
CHECK_ERR(rval);
- =20
- // check for proper tags
+
+ // Check for proper tags
Tag Ttag0, Ttag1;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_ERR(rval);
- =20
+
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_ERR(rval);
}
@@ -77,16 +80,52 @@ void test_read_onevar()
CHECK_ERR(rval);
=20
opts +=3D std::string(";VARIABLE=3DT");
- rval =3D mb.load_file( example, NULL, opts.c_str());
+ rval =3D mb.load_file(example, NULL, opts.c_str());
CHECK_ERR(rval);
- =20
- // check for proper tags
+
+ // Check for proper tags
Tag Ttag0, Ttag1;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_ERR(rval);
- =20
+
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_ERR(rval);
+
+ // Check values of tag T0 (first level) at some strategically chosen pla=
ces below
+ int procs =3D 1;
+#ifdef USE_MPI
+ ParallelComm* pcomm =3D ParallelComm::get_pcomm(&mb, 0);
+ procs =3D pcomm->proc_config().proc_size();
+#endif
+
+ // Make check runs this test in one processor
+ if (1 =3D=3D procs) {
+ Range verts;
+ rval =3D mb.get_entities_by_type(0, MBVERTEX, verts);
+ CHECK_ERR(rval);
+ CHECK_EQUAL((size_t)6916, verts.size());
+
+ // Remove from vertices the gather set entities
+ EntityHandle gather_set;
+ Range gather_ents;
+ rval =3D Util::gather_set_entities(&mb, gather_set, gather_ents);
+ CHECK_ERR(rval);
+ verts =3D subtract(verts, gather_ents);
+ CHECK_EQUAL((size_t)3458, verts.size());
+
+ int count;
+ void* Tbuf;
+ rval =3D mb.tag_iterate(Ttag0, verts.begin(), verts.end(), count, Tbuf=
);
+ CHECK_ERR(rval);
+ CHECK_EQUAL((size_t)count, verts.size());
+
+ const double eps =3D 0.0001;
+ double* data =3D (double*) Tbuf;
+ CHECK_REAL_EQUAL(233.1136, data[0 * 26], eps); // First vert
+ CHECK_REAL_EQUAL(236.1505, data[1728 * 26], eps); // Median vert
+ CHECK_REAL_EQUAL(235.7722, data[1729 * 26], eps); // Median vert
+ CHECK_REAL_EQUAL(234.0416, data[3457 * 26], eps); // Last vert
+ }
}
=20
void test_read_onetimestep()
@@ -98,14 +137,14 @@ void test_read_onetimestep()
CHECK_ERR(rval);
=20
opts +=3D std::string(";TIMESTEP=3D1");
- rval =3D mb.load_file( example, NULL, opts.c_str() );
+ rval =3D mb.load_file(example, NULL, opts.c_str());
CHECK_ERR(rval);
- =20
- // check for proper tags
+
+ // Check for proper tags
Tag Ttag0, Ttag1;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_EQUAL(rval, MB_TAG_NOT_FOUND);
- =20
+
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_ERR(rval);
}
@@ -115,33 +154,33 @@ void test_read_nomesh()
Core moab;
Interface& mb =3D moab;
=20
- // need a set for nomesh to work right
+ // Need a set for nomesh to work right
EntityHandle set;
ErrorCode rval =3D mb.create_meshset(MESHSET_SET, set);
CHECK_ERR(rval);
- =20
+
std::string orig, opts;
rval =3D get_options(orig);
CHECK_ERR(rval);
=20
opts =3D orig + std::string(";TIMESTEP=3D0");
- rval =3D mb.load_file( example, &set, opts.c_str() );
+ rval =3D mb.load_file(example, &set, opts.c_str());
CHECK_ERR(rval);
- =20
- // check for proper tag
+
+ // Check for proper tag
Tag Ttag0, Ttag1;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_ERR(rval);
- =20
+
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_EQUAL(rval, MB_TAG_NOT_FOUND);
=20
- // now read 2nd timestep with nomesh option
+ // Now read 2nd timestep with nomesh option
opts =3D orig + std::string(";TIMESTEP=3D1;NOMESH");
- rval =3D mb.load_file( example, &set, opts.c_str() );
+ rval =3D mb.load_file(example, &set, opts.c_str());
CHECK_ERR(rval);
- =20
- // check for proper tag
+
+ // Check for proper tag
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_ERR(rval);
}
@@ -151,7 +190,7 @@ void test_read_novars()
Core moab;
Interface& mb =3D moab;
=20
- // need a set for nomesh to work right
+ // Need a set for nomesh to work right
EntityHandle set;
ErrorCode rval =3D mb.create_meshset(MESHSET_SET, set);
CHECK_ERR(rval);
@@ -161,20 +200,20 @@ void test_read_novars()
CHECK_ERR(rval);
=20
opts =3D orig + std::string(";NOMESH;VARIABLE=3D");
- rval =3D mb.load_file( example, &set, opts.c_str() );
+ rval =3D mb.load_file(example, &set, opts.c_str());
CHECK_ERR(rval);
=20
opts =3D orig + std::string(";VARIABLE=3D;TIMESTEP=3D0");
- rval =3D mb.load_file( example, &set, opts.c_str() );
+ rval =3D mb.load_file(example, &set, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tag
+ // Check for proper tag
Tag Ttag0, Ttag1;
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
CHECK_EQUAL(rval, MB_TAG_NOT_FOUND);
=20
opts =3D orig + std::string(";VARIABLE=3DT;TIMESTEP=3D0;NOMESH");
- rval =3D mb.load_file( example, &set, opts.c_str() );
+ rval =3D mb.load_file(example, &set, opts.c_str());
CHECK_ERR(rval);
=20
rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0);
@@ -183,20 +222,20 @@ void test_read_novars()
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_EQUAL(rval, MB_TAG_NOT_FOUND);
=20
- // now read 2nd timestep with nomesh option
+ // Now read 2nd timestep with nomesh option
opts =3D orig + std::string(";TIMESTEP=3D1;NOMESH");
- rval =3D mb.load_file( example, &set, opts.c_str() );
+ rval =3D mb.load_file(example, &set, opts.c_str());
CHECK_ERR(rval);
=20
- // check for proper tag
+ // Check for proper tag
rval =3D mb.tag_get_handle("T1", 26, MB_TYPE_DOUBLE, Ttag1);
CHECK_ERR(rval);
}
=20
-ErrorCode get_options(std::string &opts)=20
+ErrorCode get_options(std::string& opts)
{
#ifdef USE_MPI
- // use parallel options
+ // Use parallel options
opts =3D std::string(";;PARALLEL=3DREAD_PART;PARTITION_METHOD=3DTRIVIAL_=
PARTITION");
return MB_SUCCESS;
#else
diff --git a/test/parallel/ucdtrvpart.cpp b/test/parallel/ucdtrvpart.cpp
index 3f54e5f..abf52c5 100644
--- a/test/parallel/ucdtrvpart.cpp
+++ b/test/parallel/ucdtrvpart.cpp
@@ -19,7 +19,7 @@ void test_multiple_loads_of_same_file();
=20
std::string partition_method;
=20
-int main(int argc, char **argv)
+int main(int argc, char* argv[])
{
MPI_Init(&argc, &argv);
int result =3D 0;
@@ -32,12 +32,11 @@ int main(int argc, char **argv)
return result;
}
=20
-
void test_read_parallel_ucd_trivial()
{
- // disable spectral mesh for the time being, it is not ready yet
- partition_method =3D std::string(";PARTITION_METHOD=3DTRIVIAL_PARTITION;=
PARALLEL_RESOLVE_SHARED_ENTS");
+ // Disable spectral mesh for the time being, it is not ready yet
//partition_method =3D std::string(";PARTITION_METHOD=3DTRIVIAL_PARTITIO=
N;SPECTRAL_MESH;PARALLEL_RESOLVE_SHARED_ENTS");
+ partition_method =3D std::string(";PARTITION_METHOD=3DTRIVIAL_PARTITION;=
PARALLEL_RESOLVE_SHARED_ENTS");
test_read_parallel(3458, true);
}
=20
@@ -56,8 +55,7 @@ void test_read_parallel(int num_verts, bool test_nb_nodes)
rval =3D mb.create_meshset(MESHSET_SET, file_set);
CHECK_ERR(rval);
=20
- std::string opt =3D std::string("PARALLEL=3DREAD_PART") +
- partition_method;
+ std::string opt =3D std::string("PARALLEL=3DREAD_PART") + partition_meth=
od;
rval =3D mb.load_file(example, &file_set, opt.c_str());
CHECK_ERR(rval);
=20
@@ -66,34 +64,35 @@ void test_read_parallel(int num_verts, bool test_nb_nod=
es)
rval =3D pcomm->check_all_shared_handles();
CHECK_ERR(rval);
=20
- // get the total # owned verts
+ // Get the total # owned verts
Range verts;
rval =3D mb.get_entities_by_type(0, MBVERTEX, verts);
CHECK_ERR(rval);
rval =3D pcomm->filter_pstatus(verts, PSTATUS_NOT_OWNED, PSTATUS_NOT);
CHECK_ERR(rval);
- int proc=3Dpcomm->proc_config().proc_rank();
- if (0=3D=3Dproc)
- {
- // remove from verts the gather set ents
+
+ int rank =3D pcomm->proc_config().proc_rank();
+ if (0 =3D=3D rank) {
+ // Remove from verts the gather set ents
EntityHandle gather_set;
Range gth_ents;
rval =3D Util::gather_set_entities(&mb, gather_set, gth_ents);
CHECK_ERR(rval);
verts =3D subtract(verts, gth_ents);
}
+
int my_num =3D verts.size(), total_verts;
- std::cout<<"proc: " << pcomm->proc_config().proc_rank() << " verts:" << =
my_num << "\n";
+ std::cout << "proc: " << rank << " verts:" << my_num << "\n";
MPI_Reduce(&my_num, &total_verts, 1, MPI_INTEGER, MPI_SUM, 0, pcomm->pro=
c_config().proc_comm());
=20
- if (0 =3D=3D pcomm->proc_config().proc_rank())
- {
- std::cout<<"total vertices: " << total_verts << "\n";
+ if (0 =3D=3D rank) {
+ std::cout << "total vertices: " << total_verts << "\n";
if (test_nb_nodes)
CHECK_EQUAL(total_verts, num_verts);
}
+
std::string write_options("PARALLEL=3DWRITE_PART;");
- mb.write_file( "test.h5m", NULL, write_options.c_str() );
+ mb.write_file("test.h5m", NULL, write_options.c_str());
}
=20
void test_multiple_loads_of_same_file()
@@ -105,7 +104,7 @@ void test_multiple_loads_of_same_file()
rval =3D mb.create_meshset(MESHSET_SET, file_set);
CHECK_ERR(rval);
=20
- // read first only header information, no mesh, no variable
+ // Read first only header information, no mesh, no variable
std::string opts("PARALLEL=3DREAD_PART;PARTITION;NOMESH;VARIABLE=3D;PART=
ITION_METHOD=3DTRIVIAL_PARTITION");
rval =3D mb.load_file(example, &file_set, opts.c_str());
CHECK_ERR(rval);
@@ -114,8 +113,53 @@ void test_multiple_loads_of_same_file()
rval =3D mb.load_file(example, &file_set, opts.c_str());
CHECK_ERR(rval);
=20
-
opts =3D "PARALLEL=3DREAD_PART;PARTITION;PARTITION_METHOD=3DTRIVIAL_PART=
ITION;NOMESH;VARIABLE=3DT;TIMESTEP=3D0";
rval =3D mb.load_file(example, &file_set, opts.c_str());
CHECK_ERR(rval);
+
+ // Check values of tag T0 (first level) at some strategically chosen pla=
ces below
+ ParallelComm* pcomm =3D ParallelComm::get_pcomm(&mb, 0);
+ int procs =3D pcomm->proc_config().proc_size();
+
+ // Make check runs this test in two processors
+ if (2 =3D=3D procs) {
+ Range verts;
+ rval =3D mb.get_entities_by_type(0, MBVERTEX, verts);
+ CHECK_ERR(rval);
+
+ int rank =3D pcomm->proc_config().proc_rank();
+ if (0 =3D=3D rank) {
+ // Remove from verts the gather set ents
+ EntityHandle gather_set;
+ Range gth_ents;
+ rval =3D Util::gather_set_entities(&mb, gather_set, gth_ents);
+ CHECK_ERR(rval);
+ verts =3D subtract(verts, gth_ents);
+ }
+ CHECK_EQUAL((size_t)1825, verts.size());
+
+ Tag Ttag0;
+ rval =3D mb.tag_get_handle("T0", 26, MB_TYPE_DOUBLE, Ttag0, MB_TAG_DEN=
SE);
+ CHECK_ERR(rval);
+
+ int count;
+ void* Tbuf;
+ rval =3D mb.tag_iterate(Ttag0, verts.begin(), verts.end(), count, Tbuf=
);
+ CHECK_ERR(rval);
+ CHECK_EQUAL((size_t)count, verts.size());
+
+ const double eps =3D 0.0001;
+ double* data =3D (double*) Tbuf;
+
+ if (0 =3D=3D rank) {
+ CHECK_REAL_EQUAL(233.1136, data[0 * 26], eps); // First vert
+ CHECK_REAL_EQUAL(237.1977, data[912 * 26], eps); // Median vert
+ CHECK_REAL_EQUAL(234.9711, data[1824 * 26], eps); // Last vert
+ }
+ else if (1 =3D=3D rank) {
+ CHECK_REAL_EQUAL(233.1136, data[0 * 26], eps); // First vert
+ CHECK_REAL_EQUAL(231.0446, data[912 * 26], eps); // Median vert
+ CHECK_REAL_EQUAL(234.0416, data[1824 * 26], eps); // Last vert
+ }
+ }
}
https://bitbucket.org/fathomteam/moab/commits/0425e75d91a6/
Changeset: 0425e75d91a6
Branch: master
User: iulian07
Date: 2013-07-24 15:30:45
Summary: Merged in danwu/moab (pull request #8)
Fix from Jeff
Affected #: 1 file
diff --git a/src/io/ReadNC.cpp b/src/io/ReadNC.cpp
index 78c3fbc..cf301df 100644
--- a/src/io/ReadNC.cpp
+++ b/src/io/ReadNC.cpp
@@ -449,6 +449,7 @@ ErrorCode ReadNC::read_coordinate(const char* var_name,=
int lmin, int lmax, std:
fail =3D NCFUNCA(get_vars_float)(fileId, (*vmit).second.varId, &tmin, =
&tcount, &dum_stride, &tcvals[0]);
if (fail)
ERRORS(MB_FAILURE, "Failed to get coordinate values.");
+ cvals.resize(tcount);
std::copy(tcvals.begin(), tcvals.end(), cvals.begin());
}
else ERRORR(MB_FAILURE, "Wrong data type for coordinate variable.");
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