December 2015 - moab-dev - mailman3.cels.anl.gov

a bug in Coupler::locate_points
by Huayi Wei 17 Apr '17

17 Apr '17

Hi, Moab Dev, In the following member function, I think it is a bug for line ` tl = new TupleList(3, 0, 0, 0, num_points);`. Here create new TupleList which address will cover the address tl passed by user, and then user can not accsess it. I think it should be ' tl->initialize(3, 0, 0, 0, num_points)`, ```` ErrorCode Coupler::locate_points(double *xyz, unsigned int num_points, double rel_eps, double abs_eps, TupleList *tl, bool store_local) { ....... // Copy into tl if passed in and storing locally if (tl && store_local) { tl = new TupleList(3, 0, 0, 0, num_points); tl->enableWriteAccess(); memcpy(tl->vi_wr, tl_tmp->vi_rd, 3 * tl_tmp->get_n() * sizeof(int)); tl->set_n(tl_tmp->get_n()); tl->disableWriteAccess(); } .... } ``` Best Huayi

4 6

Re: [MOAB-dev] moab-dev Digest, Vol 86, Issue 21
by Andrew Davis 19 Dec '15

19 Dec '15

Hi John Its also not required, you can build without CGM. If you choose to build with CGM then it will pick up the Cubit shared libraries via the CGM dependency. Thanks Andy On Dec 19, 2015 12:00 PM, <moab-dev-request(a)mcs.anl.gov> wrote: > Send moab-dev mailing list submissions to > moab-dev(a)mcs.anl.gov > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.mcs.anl.gov/mailman/listinfo/moab-dev > or, via email, send a message with subject or body 'help' to > moab-dev-request(a)mcs.anl.gov > > You can reach the person managing the list at > moab-dev-owner(a)mcs.anl.gov > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of moab-dev digest..." > > > Today's Topics: > > 1. Is cubit now required by cgma? (JR Cary) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 19 Dec 2015 06:57:17 -0700 > From: JR Cary <cary(a)txcorp.com> > To: moab-dev(a)mcs.anl.gov > Subject: [MOAB-dev] Is cubit now required by cgma? > Message-ID: <5675623D.6000001(a)txcorp.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > I recently updated cgm and tried building it as I had been, configuring > with > > '/opt/contrib-clangcxx11/cmake-3.2.2-ser/bin/cmake' > -DCMAKE_INSTALL_PREFIX:PATH=/opt/volatile-clangcxx11/cgm-master.r1494-ser > -DCMAKE_BUILD_TYPE:STRING=Release > -DCMAKE_COLOR_MAKEFILE:BOOL=FALSE -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE > -DBUILD_WITH_SHARED_RUNTIME:BOOL=TRUE > -DCMAKE_C_COMPILER:FILEPATH='/usr/bin/clang' > -DCMAKE_CXX_COMPILER:FILEPATH='/usr/bin/clang++' > -DCMAKE_Fortran_COMPILER:FILEPATH='/opt/homebrew/bin/gfortran-4.9' > -DCMAKE_C_FLAGS:STRING='-fPIC -pipe' > -DCMAKE_CXX_FLAGS:STRING='-std=c++11 -stdlib=libc++ -fPIC -pipe' > -DCMAKE_Fortran_FLAGS:STRING='-fPIC -pipe' > > -DOCE_DIR:PATH='/opt/volatile-clangcxx11/oce-OCE-0.17-txc.r1462-sersh/OCE.framework/Versions/0.17/Resources' > /sources/projects/composerall/cgm > > The configure worked fine, but the build failed at > > /usr/bin/clang++ -std=c++11 -stdlib=libc++ -fPIC -pipe -O3 -DNDEBUG > -dynamiclib -Wl,-headerpad_max_install_names -o > ../lib/libcubit_util.dylib ... > > Undefined symbols for architecture x86_64: > "CubitColor::CubitColor(unsigned char, unsigned char, unsigned char, > unsigned char)", referenced from: > __GLOBAL__sub_I_GfxDebug.cpp in GfxDebug.cpp.o > "CubitColor::CubitColor()", referenced from: > __GLOBAL__sub_I_GfxDebug.cpp in GfxDebug.cpp.o > "CubitEvent::~CubitEvent()", referenced from: > CubitCoordinateSystem::~CubitCoordinateSystem() in > CubitCoordinateSystem.cpp.o > ... > > Is CUBIT now required? > > Thx...John Cary > > PS - looking at geom/CMakeLists.txt, I see that I needed to add > -DCGM_OCC:BOOL=ON > to pick up OCC/OCE, but that did not help the build..... > > > ------------------------------ > > _______________________________________________ > moab-dev mailing list > moab-dev(a)mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/moab-dev > > > End of moab-dev Digest, Vol 86, Issue 21 > **************************************** >

3 4

Re: [MOAB-dev] moab-dev Digest, Vol 86, Issue 21
by Andrew Davis 19 Dec '15

19 Dec '15

Hi John I've found that on Linux if you at the cubit/bin directory to your LD_LIBRARY_PATH that fixes that. Try adding the equivalent to the DYLD_LIBRARY_PATH. Thanks Andy On Dec 19, 2015 12:00 PM, <moab-dev-request(a)mcs.anl.gov> wrote: > Send moab-dev mailing list submissions to > moab-dev(a)mcs.anl.gov > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.mcs.anl.gov/mailman/listinfo/moab-dev > or, via email, send a message with subject or body 'help' to > moab-dev-request(a)mcs.anl.gov > > You can reach the person managing the list at > moab-dev-owner(a)mcs.anl.gov > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of moab-dev digest..." > > > Today's Topics: > > 1. Is cubit now required by cgma? (JR Cary) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 19 Dec 2015 06:57:17 -0700 > From: JR Cary <cary(a)txcorp.com> > To: moab-dev(a)mcs.anl.gov > Subject: [MOAB-dev] Is cubit now required by cgma? > Message-ID: <5675623D.6000001(a)txcorp.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > I recently updated cgm and tried building it as I had been, configuring > with > > '/opt/contrib-clangcxx11/cmake-3.2.2-ser/bin/cmake' > -DCMAKE_INSTALL_PREFIX:PATH=/opt/volatile-clangcxx11/cgm-master.r1494-ser > -DCMAKE_BUILD_TYPE:STRING=Release > -DCMAKE_COLOR_MAKEFILE:BOOL=FALSE -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE > -DBUILD_WITH_SHARED_RUNTIME:BOOL=TRUE > -DCMAKE_C_COMPILER:FILEPATH='/usr/bin/clang' > -DCMAKE_CXX_COMPILER:FILEPATH='/usr/bin/clang++' > -DCMAKE_Fortran_COMPILER:FILEPATH='/opt/homebrew/bin/gfortran-4.9' > -DCMAKE_C_FLAGS:STRING='-fPIC -pipe' > -DCMAKE_CXX_FLAGS:STRING='-std=c++11 -stdlib=libc++ -fPIC -pipe' > -DCMAKE_Fortran_FLAGS:STRING='-fPIC -pipe' > > -DOCE_DIR:PATH='/opt/volatile-clangcxx11/oce-OCE-0.17-txc.r1462-sersh/OCE.framework/Versions/0.17/Resources' > /sources/projects/composerall/cgm > > The configure worked fine, but the build failed at > > /usr/bin/clang++ -std=c++11 -stdlib=libc++ -fPIC -pipe -O3 -DNDEBUG > -dynamiclib -Wl,-headerpad_max_install_names -o > ../lib/libcubit_util.dylib ... > > Undefined symbols for architecture x86_64: > "CubitColor::CubitColor(unsigned char, unsigned char, unsigned char, > unsigned char)", referenced from: > __GLOBAL__sub_I_GfxDebug.cpp in GfxDebug.cpp.o > "CubitColor::CubitColor()", referenced from: > __GLOBAL__sub_I_GfxDebug.cpp in GfxDebug.cpp.o > "CubitEvent::~CubitEvent()", referenced from: > CubitCoordinateSystem::~CubitCoordinateSystem() in > CubitCoordinateSystem.cpp.o > ... > > Is CUBIT now required? > > Thx...John Cary > > PS - looking at geom/CMakeLists.txt, I see that I needed to add > -DCGM_OCC:BOOL=ON > to pick up OCC/OCE, but that did not help the build..... > > > ------------------------------ > > _______________________________________________ > moab-dev mailing list > moab-dev(a)mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/moab-dev > > > End of moab-dev Digest, Vol 86, Issue 21 > **************************************** >

1 0

Is cubit now required by cgma?
by JR Cary 19 Dec '15

19 Dec '15

I recently updated cgm and tried building it as I had been, configuring with '/opt/contrib-clangcxx11/cmake-3.2.2-ser/bin/cmake' -DCMAKE_INSTALL_PREFIX:PATH=/opt/volatile-clangcxx11/cgm-master.r1494-ser -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_COLOR_MAKEFILE:BOOL=FALSE -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE -DBUILD_WITH_SHARED_RUNTIME:BOOL=TRUE -DCMAKE_C_COMPILER:FILEPATH='/usr/bin/clang' -DCMAKE_CXX_COMPILER:FILEPATH='/usr/bin/clang++' -DCMAKE_Fortran_COMPILER:FILEPATH='/opt/homebrew/bin/gfortran-4.9' -DCMAKE_C_FLAGS:STRING='-fPIC -pipe' -DCMAKE_CXX_FLAGS:STRING='-std=c++11 -stdlib=libc++ -fPIC -pipe' -DCMAKE_Fortran_FLAGS:STRING='-fPIC -pipe' -DOCE_DIR:PATH='/opt/volatile-clangcxx11/oce-OCE-0.17-txc.r1462-sersh/OCE.framework/Versions/0.17/Resources' /sources/projects/composerall/cgm The configure worked fine, but the build failed at /usr/bin/clang++ -std=c++11 -stdlib=libc++ -fPIC -pipe -O3 -DNDEBUG -dynamiclib -Wl,-headerpad_max_install_names -o ../lib/libcubit_util.dylib ... Undefined symbols for architecture x86_64: "CubitColor::CubitColor(unsigned char, unsigned char, unsigned char, unsigned char)", referenced from: __GLOBAL__sub_I_GfxDebug.cpp in GfxDebug.cpp.o "CubitColor::CubitColor()", referenced from: __GLOBAL__sub_I_GfxDebug.cpp in GfxDebug.cpp.o "CubitEvent::~CubitEvent()", referenced from: CubitCoordinateSystem::~CubitCoordinateSystem() in CubitCoordinateSystem.cpp.o ... Is CUBIT now required? Thx...John Cary PS - looking at geom/CMakeLists.txt, I see that I needed to add -DCGM_OCC:BOOL=ON to pick up OCC/OCE, but that did not help the build.....

1 0

Building moab with cgm?
by JR Cary 17 Dec '15

17 Dec '15

I've just created a fresh branch of develop of CGM and configured it with cmake, then built and installed it. I also have a fresh branch of develop of MOAB. I configure it with cmake, then try to build it. It fails at /home/research/cary/projects/composerall/moab/src/io/ReadCGM.cpp: In member function ‘moab::ErrorCode moab::ReadCGM::store_surface_senses(std::map<RefEntity*, long unsigned int>&, std::map<RefEntity*, long unsigned int>&)’: /home/research/cary/projects/composerall/moab/src/io/ReadCGM.cpp:256:11: error: ‘cout’ is not a member of ‘std’ std::cout << "Surface " << face->id() << " has reverse sense " << I fixed those by including <iostream>, but then I get errors like /home/research/cary/projects/composerall/moab/src/io/ReadCGM.cpp:689:11: error: ‘ModelEntity’ was not declared in this scope DLIList<ModelEntity*> me_list; At this point I see that there exists ModelEntity.hpp in the CGM source but not in the installation. I tried adding it to the installation, but then CGM fails to compile. Is this something that should be fixed in cgm? Or am I doing something different from how you get moab to compile? Thx.....John

2 4

DMMoabLoadFromFile() - parallel performance issue
by WARNER, JAMES E. (LARC-D309) 15 Dec '15

15 Dec '15

Hi Vijay & Iulian, Hope you are doing well! I have a question regarding some strange behavior we’re seeing with the DMMoabLoadFromFile() function… After doing some recent profiling of our MOAB-based finite element code, we noticed that we are spending a disproportionate amount of CPU time within the DMMoabLoadFromFile() function, which gets slower / remains constant as we increase the number of processors. We also recently attempted a scalability test with ~30M FEM nodes on 500 processors which hung in DMMoabLoadFromFile() for about 45 minutes before we killed the job. We then re-ran the test on one processor and it made it through successfully in several seconds. To reproduce the problem we’re seeing, we wrote a test case (attached here) that simply loads a smaller mesh with approximately 16K nodes and prints the run time. When I run the code on an increasing number of processors, I get something like: NP=1: Time to read file: 0.0416839 [sec.] NP=2: Time to read file: 1.42497 [sec.] NP=4: Time to read file: 1.13678 [sec.] NP=8: Time to read file: 1.0475 [sec.] … If it is relevant/helpful – we are using the mbpart tool to partition the mesh. Do you have any ideas why we are not seeing scalability here? Any thoughts/tips would be appreciated! Let me know if you would like any more information. Thanks, Jim

3 4

GLOBAL_IDs, building map from moab mesh
by Nico Schlömer 07 Dec '15

07 Dec '15

Hi everyone, To build a map for multi-process meshes, I need to be able to identify that node N on proc 0 is the same as node M on proc 1. For this, I'm using the GLOBAL_ID property. I know that this list isn't necessarily contiguous or 1-based, but that's fine. I now bumped into a bug in serial execution. I noticed that the output of `mbconvert somefile.vtk somefile.h5m` generates GLOBAL_ID list full of 0s, as opposed to the nice list of 1, 2, 3,... as generated by `mbpart`. Apparently you're not supposed to rely on GLOBAL_ID after all? Is there a better approach that also works in serial? Cheers, Nico

3 9

get uniquely owned vertices
by Nico Schlömer 07 Dec '15

07 Dec '15

Hi everyone, When reading a mesh in parallel, I would like to get the vertices such that every vertex belong to exactly one process. When reading with ``` moab::Range verts; ierr = mb->get_entities_by_dimension(0, 0, verts); ``` the vertices along the process interfaces will be shared, i.e., they appear on two processes. I used to believe the above does the right thing and I have to use get the shared entities separately ``` moab::Range shared; ierr = mcomm_->get_shared_entities(-1, shared, 0); all.merge(shared); ``` but it seems I'm on the wrong track. Any hints? Cheers, Nico

3 5

Re: [MOAB-dev] problem with pcomm
by jain＠mcs.anl.gov 03 Dec '15

03 Dec '15

Do you have Fortran enabled? If so, how do you get gfortran? Also, do you use open-mpi or mpich?Does your make check pass? Rajeev On Thu, 3 Dec, 2015 at 10:45, Lorenzo Alessio Botti<bottilorenzo(a)gmail.com> wrote: 636 Clang:*) 637 FATHOM_CXX_SPECIAL="$EXTRA_GNU_FLAGS -stdlib=libc++" 638 FATHOM_CXX_32BIT=-m32 639 FATHOM_CXX_64BIT=-m64 640 ;; 641 SunWorkshop:i?86|SunWorkshop:x86_64) 642 FATHOM_CXX_32BIT=-m32 643 FATHOM_CXX_64BIT=-m64 644 ;; 645 *) 646 ;; 647 esac 648 AC_MSG_RESULT([$cxx_compiler:$host_os:$host_cpu]) 649 650 # Check for specific overrides 651 CXX_LDFLAGS="" 652 if (test "$cxx_compiler:${host_os:0:6}" == "Clang:darwin"); then 653 CXX_LDFLAGS="$CXX_LDFLAGS -stdlib=libc++" 654 LIBS="$LIBS -lc++” I changed lines 637 and 653 of compilers.m4 as you suggested (libc++ instead of libstdc++).My code runs fine (I’m on Mavericks with latests clang). As opposite to the previous build make check now get suck at dual_test. The other tests runs fine. Thanks everybody for help! As Vijay pointed out I thinks this is the way to go since it allows to use c++11. Thanks again.Bests.Lorenzo

3 3

problem with pcomm
by Lorenzo Alessio Botti 03 Dec '15

03 Dec '15

> 636 Clang:*) > 637 FATHOM_CXX_SPECIAL="$EXTRA_GNU_FLAGS -stdlib=libc++" > 638 FATHOM_CXX_32BIT=-m32 > 639 FATHOM_CXX_64BIT=-m64 > 640 ;; > 641 SunWorkshop:i?86|SunWorkshop:x86_64) > 642 FATHOM_CXX_32BIT=-m32 > 643 FATHOM_CXX_64BIT=-m64 > 644 ;; > 645 *) > 646 ;; > 647 esac > 648 AC_MSG_RESULT([$cxx_compiler:$host_os:$host_cpu]) > 649 > 650 # Check for specific overrides > 651 CXX_LDFLAGS="" > 652 if (test "$cxx_compiler:${host_os:0:6}" == "Clang:darwin"); then > 653 CXX_LDFLAGS="$CXX_LDFLAGS -stdlib=libc++" > 654 LIBS="$LIBS -lc++” I changed lines 637 and 653 of compilers.m4 as you suggested (libc++ instead of libstdc++). My code runs fine (I’m on Mavericks with latests clang). As opposite to the previous build make check now get suck at dual_test. The other tests runs fine. Thanks everybody for help! As Vijay pointed out I thinks this is the way to go since it allows to use c++11. Thanks again. Bests. Lorenzo

2 2