- moab-announce - mailman3.cels.anl.gov

MSC Software seeks MOAB expertise
by Johnny Prewitt 30 Nov '11

30 Nov '11

Pioneers and market leaders in FEA/FEM based simulations products MSC Software continues to innovate. We are seeking a Data Architect and Software Engineers with background in MOAB to design and build out a ³Persistent Framework² for a new, break through CAE product. These are Santa Ana, California based career opportunties to join and elite Software Engineering organization and shape the future of virtual prototyping and simulation. For more information visit www.mscsoftware.com call 415-608-4442 or juts forward your resume to johnny.prewitt(a)mscsoftware.com. Johnny Prewitt Senior Recruiter MSC Software Corporation 2 MacArthur Place, Santa Ana, CA. 92707 Tel. 415-608-4442 skype:johnny.prewitt www.mscsoftware.com ³to learn more² link under construction. Use this link www.nastran.mscsoftware.com MSC Software is the worldwide leader in multidiscipline simulation solutions that help companies improve quality, save time and reduce costs associated with designing and testing manufactured products. MSC Software partners with hundreds of companies worldwide to develop better products faster by applying our tools and services. MSC Software is a global company with 1,000 employees and offices in 20 countries. These are exciting times for MSC Software. Now in the second year of a five year turnaround we are profitable again.

1 0

MSC Software..Seeking expertise in MOAB
by Johnny Prewitt 30 Nov '11

30 Nov '11

MSC Software, pioneers in FEA/FEM based simulations is seeking a Data Architect , and SW Engineers with experience in MOAB. This is an opportunity to join and elite product development team in design and build out of a breakthrough CAE product. For more information go to www.mscsoftware.com or call Johnny Prewitt, Sr. Recruiter, MSC Software. Johnny Prewitt Senior Recruiter MSC Software Corporation 2 MacArthur Place, Santa Ana, CA. 92707 Tel. 415-608-4442 skype:johnny.prewitt www.mscsoftware.com ³to learn more² link under construction. Use this link www.nastran.mscsoftware.com MSC Software is the worldwide leader in multidiscipline simulation solutions that help companies improve quality, save time and reduce costs associated with designing and testing manufactured products. MSC Software partners with hundreds of companies worldwide to develop better products faster by applying our tools and services. MSC Software is a global company with 1,000 employees and offices in 20 countries. These are exciting times for MSC Software. Now in the second year of a five year turnaround we are profitable again.

2 1

mbcn_test fail while doing "make check"
by Tiantian Xu 11 Oct '11

11 Oct '11

Hi, I was trying to build moab but met with the "mbcn_test fail" during make check. The commands I used to build the library were: ./configure LFLAGS=-static --with-mpi=/home/tiantian/ITL/mpich2-1.4.1p1/gcc --with-hdf5=/home/tiantian/hdf5 --with-netcdf=/home/tiantian/ITL/netcdf-4.1.3/gcc --with-zlib=/home/tiantian/ITL/zlib-1.2.5/gcc --with-szip=/home/tiantian/ITL/szip-2.1/gcc --prefix=/home/tiantian/ITL/moab 2>&1 | tee configure.log make 2>&1 | make.log make check 2>&1 | tee make.check.log Looks like the mbcn_test is about query on entities, I don't know why this went wrong. Later I ignored the make check errors and did "make install". I tried to perform parallel read/write and found mbconvert went wrong too: $mpiexec -np 2 ./mbconvert -O PARALLEL=READ_PART -O PARTITION=MATERIAL_SET -O PARALLEL_RESOLVE_SHARED_ENTS -O PARALLEL_GHOSTS=3.0.1 -o PARALLEL=WRITE_PART ./64bricks_512hex.h5m dummy.h5m Read "./64bricks_512hex.h5m" ===================================================================================== = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES = EXIT CODE: 139 = CLEANING UP REMAINING PROCESSES = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES ===================================================================================== APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault (signal 11) I suspect some fundamental functions in moab were not properly made? I had attached the log files. Please take a look. Thanks a lot for your help! Best, Tiantian

2 1

Parallel test fail when building MOAB
by Tiantian Xu 30 Sep '11

30 Sep '11

Hi, I was trying to build MOAB with parallel support but met some problems. The prerequisites were successfully built, including MPI, HDF5, SZIP, ZLIB, NETCDF. HDF5 and NETCDF were both configured with parallel support. Here are the commands I had used: [tiantian@vis-pc2 trunk]$ ./configure --prefix=/home/tiantian/ITL_MOAB/trunk/gcc --with-mpi=/home/tiantian/mpich2-install --with-netcdf=/home/tiantian/ITL_MOAB/netcdf-4.1.3/gcc --with-hdf5=/home/tiantian/ITL_MOAB/hdf5-1.8.7/gcc --with-zlib=/home/tiantian/zlib-1.2.5 --with-szip=/home/tiantian/szip-2.1 --disable-debug 2>&1 | tee configure.log [tiantian@vis-pc2 trunk]$ make 2>&1 | tee make.log tiantian@vis-pc2 trunk]$ make check 2>&1 | tee make.check.log The error during make check is: make check-TESTS make[3]: Entering directory `/home/tiantian/ITL_MOAB/trunk/test/parallel' make[4]: Entering directory `/home/tiantian/ITL_MOAB/trunk/test/parallel' PASS: pcomm_unit FAIL: parallel_unit_tests PASS: uber_parallel_test FAIL: scdtest PASS: pcomm_serial FAIL: parallel_hdf5_test PASS: mhdf_parallel PASS: parallel_write_test ================================ 3 of 8 tests failed See test/parallel/test-suite.log ================================ configure log, make log, make check log and test-suite.log are all attached. Please take a look and point to me where went wrong. btw. I had configured MOAB with no mpi support, the make check and make install succeeded. Is it possible the error with parallel test occur because my machine does not have parallel hardware? I was hoping MOAB could perform simulation to parallel read/write. Thank you very much. I appreciate your help! Tiantian

1 0

MOAB API changed relating to tags
by Jason Kraftcheck 06 Jun '11

06 Jun '11

The following is a list of upcoming changes to the subset of the MOAB API that operates on tags. The primary focus of this set of changes is to provide better type safety for tag data and to transition from working with tag sizes specified as the number of bytes to tag sizes specified as the number of values. However, some other minor changes have also been included. Changes to be included in MOAB 4.1: 1. MOAB will now print a warning if a NULL handle array is passed to tag_get/set_handle. It will still accept the NULL handle array as a means of indicating the tag value on the MOAB instance. However, the preferred method is to pass an actual handle with a zero value, consistent with the way the MOAB instance is indicated in other calls such as get_entities_by_type. That is: mb.tag_get_data( tag, 0, 0, &value ); should now be: const EntityHandle root = 0; mb.tag_get_data( tag, &root, 1, &value ); 2. MOAB contains a new tag_get_handle function that will replace the previous tag_get_handle function as well as both variations of tag_create and tag_create_variable_length. All the functionality of all of those functions is available through the new tag_get_handle function. The new function provides the added benefits of a) allowing an application to specify that it is fine with either creating a new tag or getting an existing one, such that the function either succeeds or fails (no checking of MB_ALREADY_ALLOCATED), b) it works with sizes as the number of values of the specified type rather than the number of bytes and c) it does some type checking for the application when retrieving an existing tag handle. For example, this call: mb.tag_get_handle( GLOBAL_ID_TAG_NAME, tag ); becomes this: mb.tag_get_handle( GLOBAL_ID_TAG_NAME, 1, MB_TYPE_INTEGER, tag ); where an error will be returned if the tag exists but does not contain 1 integer value for each instance of the tag on an entity. Changes to be included in the next MOAB release (and in the current SVN trunk): 1. The change in 1. for 4.1 will be extended such that MOAB returns an error rather than printing a warning when tag_get/set_data are passed a NULL handle array. 2. All functions replaced by the new tag_get_handle in 2. above are marked as deprecated in the documentation and with a gcc/g++ attribute. 3. tag_get_size will be marked as deprecated and two new replacements will be added: tag_get_bytes() and tag_get_length(). The former will work the same as the deprecated tag_get_size() except in the case of bit tags, for which it will always return 1 (the amount of memory that must be allocated per entity when requesting tag data.) The latter will return the number of values of the base data type (e.g. number of int or double). It will behave the same as the old tag_get_size and tag_get_bytes for opaque tags. 4. The overloaded variants of tag_get_data and tag_set_data that work with an array of pointers and an optional array of sizes will be marked as deprecated, and replacements named tag_get_by_ptr and tag_set_by_ptr will be added. The new functions will behave similar to the deprecated ones with the exception that the size of each tag value is interpreted as the number of values rather than the number of bytes. Also, renaming the functions will avoid accidental matches to the non-pointer-array function variants when the optional size array is not passed. 5. The optional size argument to the functions: tag_clear_data and tag_get_default_value will be interpreted as the number of values of the tag data type rather than the number of bytes. No deprecation, warning, or renaming will provided for these functions as it is unlikely that they are used anywhere outside of MOAB at this time. All deprecated functions mentioned above will be removed in some future MOAB release.

1 0

Fwd: [MOAB-dev] r4877 - in MOAB/trunk: itaps/imesh src src/io src/parallel test test/h5file test/obb tools/dagmc
by Tim Tautges 25 May '11

25 May '11

FYI to those using MOAB, this is changed in the trunk version of MOAB and will be in the next release. - tim -------- Original Message -------- Subject: [MOAB-dev] r4877 - in MOAB/trunk: itaps/imesh src src/io src/parallel test test/h5file test/obb tools/dagmc Date: Wed, 25 May 2011 11:26:49 -0500 (CDT) From: kraftche(a)cae.wisc.edu Reply-To: moab-dev(a)mcs.anl.gov To: moab-dev(a)mcs.anl.gov Author: kraftche Date: 2011-05-25 11:26:49 -0500 (Wed, 25 May 2011) New Revision: 4877 Modified: MOAB/trunk/itaps/imesh/iMesh_MOAB.cpp MOAB/trunk/src/AdaptiveKDTree.cpp MOAB/trunk/src/Core.cpp MOAB/trunk/src/io/ReadCCMIO.cpp MOAB/trunk/src/io/ReadCGM.cpp MOAB/trunk/src/io/ReadHDF5.cpp MOAB/trunk/src/io/Tqdcfr.cpp MOAB/trunk/src/io/WriteCCMIO.cpp MOAB/trunk/src/io/WriteHDF5.cpp MOAB/trunk/src/io/WriteNCDF.cpp MOAB/trunk/src/io/WriteSLAC.cpp MOAB/trunk/src/io/WriteTemplate.cpp MOAB/trunk/src/parallel/ParallelComm.cpp MOAB/trunk/test/TagTest.cpp MOAB/trunk/test/h5file/h5file_test.cpp MOAB/trunk/test/h5file/h5portable.cpp MOAB/trunk/test/h5file/h5varlen.cpp MOAB/trunk/test/obb/obb_test.cpp MOAB/trunk/test/obb/obb_time.cpp MOAB/trunk/test/obb/obb_tree_tool.cpp MOAB/trunk/tools/dagmc/DagMC.cpp Log: o Change all MOAB code to pass zero-valued handle rather than NULL entity handle array to get/set tag data on the mesh. o Print warning when NULL handle array is passed to tag get/set functions. o Add #ifdef'd out logic for future transition to disallowing NULL handle array in tag get/set functions Detailed description: MOAB originally interpreted a NULL handle array and a zero handle count to mean that tag get/set functions should operate on the global/mesh value of the tag. For example: int meshval; moab->tag_get_data( tag, 0, 0, &meshval ); For compatibility with ITAPS I changed MOAB to also accept a zero-valued handle to get the mesh value. For example: int meshval; EntityHandle root = 0; moab->tag_get_data( tag, &root, 1, &meshval ); The latter is better than the former for several reasons: 1) It is consistent with other API functions that use a zero-valued handle to indicate the mesh (e.g. get_entities_by_type) 2) It allows retrieval of the mesh value with other values in a single call. 3) It is more efficient because it eliminates a special case in the primary code path for getting/setting tag data. (The special case is moved into an error handling path for invalid handles for dense tags and is eliminated entirely for sparse and bit tags.) 4) It avoids accidental segfaults if the caller asks for no entities. For example, the code below will currently segfault if the entity set happens to be empty: std::vector<EntityHandle> handles; moab->get_entities_by_handle( set, handles ); std::vector<int> data(handles.size() * ints_per_tag); moab->tag_get_data( tag, &handles[0], handles.size(), &data[0] ); because MOAB tries to write the global/mesh value into the unallocated 'data' vector. So we want to transition to accepting only the latter method of operating on the global/mesh tag value. This checkin is the first of a three phase process to implement this transition: 1) Print warning when tag functions are passed a NULL array, but otherwise continue to return the global/mesh value of the tag. 2) Print error and abort when tag functions are passed a NULL array. This is an intermediate stage intended to trap the last few uses of the old method. 3) Remove check for NULL handle array. This final state will allow the example in 4) above to correctly return nothing. This checkin contains all three of the above phases, where the behavior is selected via #defines near the beginning of Core.cpp. Modified: MOAB/trunk/itaps/imesh/iMesh_MOAB.cpp =================================================================== --- MOAB/trunk/itaps/imesh/iMesh_MOAB.cpp 2011-05-25 05:40:11 UTC (rev 4876) +++ MOAB/trunk/itaps/imesh/iMesh_MOAB.cpp 2011-05-25 16:26:49 UTC (rev 4877) @@ -1637,7 +1637,8 @@ } // check if tag value is set on mesh const void* data_ptr; - result = MOABI->tag_get_data( this_tag, 0, 0, &data_ptr ); + EntityHandle root = 0; + result = MOABI->tag_get_data( this_tag, &root, 1, &data_ptr ); if (MB_SUCCESS == result) ERROR(iBase_TAG_IN_USE, "iMesh_destroyTag: forced=false and mesh" " is still assigned this tag."); @@ -1775,15 +1776,8 @@ { ErrorCode result; - if (entity_set_handle == 0) - // set the tag data on this entity set - result = MOABI->tag_set_data(TAG_HANDLE(tag_handle), - NULL, 0, tag_value); - else { - EntityHandle set = ENTITY_HANDLE(entity_set_handle); - result = MOABI->tag_set_data(TAG_HANDLE(tag_handle), &set, 1, tag_value); - } - + EntityHandle set = ENTITY_HANDLE(entity_set_handle); + result = MOABI->tag_set_data(TAG_HANDLE(tag_handle), &set, 1, tag_value); CHKERR(result, "iMesh_setEntSetData: error"); RETURN(iBase_SUCCESS); @@ -1851,12 +1845,8 @@ ALLOC_CHECK_TAG_ARRAY(tag_value, tag_size); - if (eh == 0) - result = MOABI->tag_get_data(tag, NULL, 0, - *static_cast<void**>(tag_value)); - else - result = MOABI->tag_get_data(tag, &eh, 1, - *static_cast<void**>(tag_value)); + result = MOABI->tag_get_data(tag, &eh, 1, + *static_cast<void**>(tag_value)); CHKERR(result, "iMesh_getEntSetData didn't succeed."); KEEP_ARRAY(tag_value); @@ -1937,11 +1927,6 @@ /*in*/ iBase_EntitySetHandle entity_set_handle, /*in*/ const iBase_TagHandle tag_handle, int *err) {

1 0

MOAB 4.0.1 released
by James Porter 29 Mar '11

29 Mar '11

MOAB 4.0.1 final is now available: <http://gnep.mcs.anl.gov:8010/moab-4.0.1.tar.gz>. This version fixes a build issue with IBM compilers, but is otherwise identical to 4.0.1RC2. Release notes are available here: <https://trac.mcs.anl.gov/projects/ITAPS/wiki/ReleaseNotes4.0.1> - Jim

1 0