October 2011 - moab-dev - mailman3.cels.anl.gov

r5193 - MOAB/trunk/src
by iulian＠mcs.anl.gov 13 Oct '11

13 Oct '11

Author: iulian Date: 2011-10-13 10:51:48 -0500 (Thu, 13 Oct 2011) New Revision: 5193 Modified: MOAB/trunk/src/FBEngine.cpp Log: implement method createTag, which will be called by FBiGeom::createTag in meshkit, similar to iGeom_createTag() Modified: MOAB/trunk/src/FBEngine.cpp =================================================================== --- MOAB/trunk/src/FBEngine.cpp 2011-10-13 14:43:58 UTC (rev 5192) +++ MOAB/trunk/src/FBEngine.cpp 2011-10-13 15:51:48 UTC (rev 5193) @@ -826,19 +826,45 @@ return MB_SUCCESS; } -/*// new methods needed - ErrorCode FBEngine::getTagHandle( const char* name, moab::Tag & handle_out ) - { - return _mbImpl->tag_get_handle(name, handle_out); - }*/ +// so far, this one is +// used only for __MKModelEntityGeo tag -ErrorCode FBEngine::createTag(const char* /*tag_name*/, int /*tag_num_type_values*/, - int /*tag_type*/, Tag & /*tag_handle_out*/) +ErrorCode FBEngine::createTag(const char* tag_name, int tag_size, int tag_type, + Tag & tag_handle_out) { - // not implemented yet, some mapping needed for tag type - return MB_FAILURE; + // this is copied from iMesh_MOAB.cpp; different name to not have trouble + // with it + // also, we do not want to depend on iMesh.h... + // iMesh is more complicated, because of the options passed + + DataType mb_data_type_table2[] = { MB_TYPE_OPAQUE, MB_TYPE_INTEGER, + MB_TYPE_DOUBLE, MB_TYPE_HANDLE, MB_TYPE_HANDLE }; + moab::TagType storage = MB_TAG_SPARSE; + ErrorCode result; + + result = MBI->tag_get_handle(tag_name, tag_size, + mb_data_type_table2[tag_type], tag_handle_out, storage | MB_TAG_EXCL); + + if (MB_SUCCESS != result) { + std::string msg("iMesh_createTag: "); + if (MB_ALREADY_ALLOCATED == result) { + msg += "Tag already exists with name: \""; + msg += tag_name; + std::cout<<msg << "\n"; + } + else + { + std::cout<< "Failed to create tag with name: " << tag_name << "\n"; + return MB_FAILURE; + } + + } +

1 0

r5192 - MOAB/trunk/src
by tautges＠mcs.anl.gov 13 Oct '11

13 Oct '11

Author: tautges Date: 2011-10-13 09:43:58 -0500 (Thu, 13 Oct 2011) New Revision: 5192 Modified: MOAB/trunk/src/DebugOutput.cpp Log: Adding include to re-enable pgi compile. Modified: MOAB/trunk/src/DebugOutput.cpp =================================================================== --- MOAB/trunk/src/DebugOutput.cpp 2011-10-12 14:37:38 UTC (rev 5191) +++ MOAB/trunk/src/DebugOutput.cpp 2011-10-13 14:43:58 UTC (rev 5192) @@ -9,6 +9,8 @@ #ifdef USE_MPI # include "moab_mpi.h" +#else +# include "time.h" #endif namespace moab {

1 0

Fwd: moab-announce Digest, Vol 5, Issue 2
by Hong-Jun Kim 12 Oct '11

12 Oct '11

If you still have the same problems with Tim's suggestion as below, could you please send me your "config.log" and error signs for me to replicate it? In addition, can you use "moab-dev(a)mcs.anl.gov" for this kind of question? "moab-announce" is for announcing new things and upgrades and looks it has some latencies to get mail.(I just got Tim's message which looks sent yesterday) Thanks. ----------------------------- Hong-Jun Kim Post-doc researcher MCS, Argonne National Laboratory 9700 S. Cass Ave. B240/R2147 Argonne, IL 60439 630-252-4791 hongjun(a)mcs.anl.gov ----------------------------- > Hong-Jun, > Can you check this out? Tiantian, we haven't seen this problem > anywhere. The output from your configure looks like > you're on a 64bit machine, but can you verify that? The only other > thing that looks strange in your configure is the > LFLAGS=-static; you should be able to get the same thing, in a more > standard way, using --disable-shared > --enable-static. Could you try that? Thanks. > > - tim > > On 10/11/2011 12:58 PM, Tiantian Xu wrote: > > > > 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 > > > > -- > ================================================================ > "You will keep in perfect peace him whose mind is > steadfast, because he trusts in you." Isaiah 26:3 > > Tim Tautges Argonne National Laboratory > (tautges(a)mcs.anl.gov) (telecommuting from UW-Madison) > phone: (608) 263-8485 1500 Engineering Dr. > fax: (608) 263-4499 Madison, WI 53706 > > > > ------------------------------ > > _______________________________________________ > moab-announce mailing list > moab-announce(a)mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/moab-announce > > > End of moab-announce Digest, Vol 5, Issue 2 > *******************************************

1 0

r5191 - MOAB/trunk/src/parallel/moab
by nbertram＠wisc.edu 12 Oct '11

12 Oct '11

Author: bertram Date: 2011-10-12 09:37:38 -0500 (Wed, 12 Oct 2011) New Revision: 5191 Modified: MOAB/trunk/src/parallel/moab/ParallelMergeMesh.hpp Log: Updated Documentation For ParallelMergeMesh Modified: MOAB/trunk/src/parallel/moab/ParallelMergeMesh.hpp =================================================================== --- MOAB/trunk/src/parallel/moab/ParallelMergeMesh.hpp 2011-10-11 21:25:01 UTC (rev 5190) +++ MOAB/trunk/src/parallel/moab/ParallelMergeMesh.hpp 2011-10-12 14:37:38 UTC (rev 5191) @@ -19,7 +19,14 @@ /* Class to merge meshes in parallel Requires a ParallelComm and tolerance epsilon - Currently uses a 1 dimensional partition of the global box + Currently uses a 3 dimensional partition of the global box + + Public Usage: + + //Initialize MPI, Load/Create Individual Meshes, Get ParallelComm... + ParallelMergeMesh pmm(PComm, .000001); + pmm.merge(); + */ namespace moab {

1 0

r5190 - MOAB/trunk/doc
by sjackson＠cae.wisc.edu 11 Oct '11

11 Oct '11

Author: sjackson Date: 2011-10-11 16:25:01 -0500 (Tue, 11 Oct 2011) New Revision: 5190 Modified: MOAB/trunk/doc/user.dox.in Log: Add DagMC.hpp to the MOAB Doxygen output Modified: MOAB/trunk/doc/user.dox.in =================================================================== --- MOAB/trunk/doc/user.dox.in 2011-10-10 23:42:13 UTC (rev 5189) +++ MOAB/trunk/doc/user.dox.in 2011-10-11 21:25:01 UTC (rev 5190) @@ -309,7 +309,8 @@ @top_srcdir@/src/MBTagConventions.hpp \ @top_srcdir@/src/MBCN.h \ @top_srcdir@/src/MBEntityType.h \ - @top_srcdir@/src/parallel/MBParallelConventions.h + @top_srcdir@/src/parallel/MBParallelConventions.h \ + @top_srcdir@/tools/dagmc/DagMC.hpp # If the value of the INPUT tag contains directories, you can use the # FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp

1 0

Re: [MOAB-dev] vertex to cell adjacencies in parallel
by Hong-Jun Kim 11 Oct '11

11 Oct '11

Hi, Lorenzo By detouring wrong way, I think I finally found a bug in your code. I thought the bug came from MOAB then, I have digged the wrong place. To get owned elements, the line 226 in your code should be changed as follows (not pstatus[0] != PSTATUS_SHARED). if (pstatus[0] == PSTATUS_SHARED && pstatus[0] != PSTATUS_NOT_OWNED && pstatus[0] != PSTATUS_GHOST) Moreover, I think you'd better use bitwise operator to get it as follows. if (pstatus[0] & PSTATUS_SHARED && !(pstatus[0] & PSTATUS_NOT_OWNED) && !(pstatus[0] & PSTATUS_GHOST)) Thanks. ----------------------------- Hong-Jun Kim Post-doc researcher MCS, Argonne National Laboratory 9700 S. Cass Ave. B240/R2147 Argonne, IL 60439 630-252-4791 hongjun(a)mcs.anl.gov ----------------------------- ----- Original Message ----- From: "Lorenzo Alessio Botti" <ihabiamx(a)yahoo.it> To: "Hong-Jun Kim" <hongjun(a)mcs.anl.gov> Sent: Friday, October 7, 2011 10:52:49 AM Subject: Re: [MOAB-dev] vertex to cell adjacencies in parallel Hi Hong-Jun, I attach the code you can run it as mpiexec -n 2 [exe_name] -P -R [path_to_one_of_the_mesh_files_here_attached] Let me explain it a bit. I start from a 5x5x5 hex cube with 2 partitions. The cells on the interface form more or less a 5x5x1 25 hexes row. (They do in the hex 27 mesh while in the hex 8 an hex is misplaced for some reason) 25 elements have a face on the interface, 25 elements share a face with owned cells, 20 elements have a face on boundary. You can take a look to the .vtk output. Let me comment the output iface faces size 25 ok ghost cells size 50 shared = 25 ok, every face on iface has two neighbors one owned one not owned Now the code searches the vertex adjacencies for the 25 owned cells, this is the output owned entities = 25 adjacent entities not found = 45 this in wrong, the number of adjacencies not found should be 25 smaller, that is equal to number of faces on the boundary. Thanks a lot. Lorenzo On Oct 7, 2011, at 4:53 PM, Hong-Jun Kim wrote: > Could you please send me the code to replicate? > Thanks. > > ----------------------------- > Hong-Jun Kim > Post-doc researcher > MCS, Argonne National Laboratory > 9700 S. Cass Ave. B240/R2147 > Argonne, IL 60439 > 630-252-4791 > hongjun(a)mcs.anl.gov > ----------------------------- > > ----- Original Message ----- >> From: "Lorenzo Alessio Botti" <ihabiamx(a)yahoo.it> >> To: "Tim Tautges" <tautges(a)mcs.anl.gov>, MOAB-dev(a)mcs.anl.gov >> Sent: Friday, October 7, 2011 9:47:52 AM >> Subject: Re: [MOAB-dev] vertex to cell adjacencies in parallel >> Thanks a lot for the reply. >> Let me know if you need the code to replicate this issue... >> >>>> For my application it would be very interesting to be able to >>>> partition based on entity sets. >>>> >>> >>> If those entity sets form a covering for the entities (each of the >>> entities included in exactly one of those sets), and those sets can >>> be identified by a tag and optionally tag value, then you should be >>> able to already read in parallel based on that partition (which has >>> to already be in the file). See section 5 of the user's guide (in >>> the doc subdir) and the description of how to read according to a >>> material_set partition. >> >> My request was a bit too cryptic... >> I'm now reading parallel meshes generated with mbzoltan with the >> partition tag set to PARALLEL_PARTITION. >> It would be useful (for geometric h-multigrid, adaptivity based on >> element agglomeration ecc...) >> to repartition based on tagged entity sets that form a covering for >> the entities >> (such sets might be generated requiring a lot of partitions to the >> partitioner) >> instead of mesh elements. >> A simpler trick would be to create a lot of tagged entity sets and run >> in parallel >> with n_processes = n_entity_set/n_entity_sets_per_process, using once >> again the >> entity sets as mesh elements. >> In this context the entity set can be viewed as very general elements >> (eg polygons). >> In both cases the ability to get the adjacencies of entity set would >> be also required. >> >> By the way I've seen that you already have a polygonal element >> implementation >> but I don't know if it has been introduced with the same goal. >> >> Now I'm still working on the standard element dG finite element >> library >> but later on it would be interesting to explore more general >> implementations. >> >> Lorenzo >> >> On Oct 7, 2011, at 3:54 PM, Tim Tautges wrote: >> >>> >>> >>> On 10/07/2011 04:05 AM, Lorenzo Alessio Botti wrote: >>>> Hi all, >>>> I have a question about getting adjacencies in parallel. >>>> >>>> After having partitioned a mesh, resolved shared entities and >>>> exchanged ghost cells I fail to >>>> update the mesh cell adjacencies so to include ghost cells. >>>> >>>> The face to elements adjacencies are correctly updated, that is the >>>> faces obtained with >>>> pcomm.get_iface_entities(1,2,faces); (I'm running on 2 processors) >>>> have two neighbors one owned and one non owned. >>>> >>>> However the vertex to cell adjacencies do not seem to be updated to >>>> include ghost cells >>>> and even after >>>> mb.get_entities_by_dimension(0,3,entities); >>>> mb.get_adjacencies(entities, 0, true, vertexEntities, >>>> Interface::UNION); >>>> entities.clear(); >>>> mb.get_adjacencies(vertexEntities, 3, true, entities, >>>> Interface::UNION); >>>> I'm not able to find vertex to not owned cells adjacencies. >>>> >>>> Is get_adjacencies(...,create if missing=true,...) supposed to work >>>> also for non owned cells? >>>> It seems that the vertex to non owned cell adjacencies are detected >>>> but not created. >>>> >>> >>> That sounds like a bug; Hong-Jun, could you look at that? >>> >>> MOAB's parallel model is that all locally-represented entities, >>> which includes ghost and shared interface entities, should appear >>> locally as a serial mesh, with all adjacencies and other API calls >>> available. >>> >>>> Overall MOAB works fine in parallel and >>>> pcomm.assign_global_ids(...) is useful. >>>> Are you also planning to introduce some repartitioning >>>> capabilities? >>> >>> Yes, this year's work plan includes migrating entities for >>> repartitioning. In theory, the partitioning class in tools/mbzoltan >>> should work to compute the new partition in parallel, though I think >>> it's currently hardwired to run on one processor (on my list to get >>> rid of that restriction). >>> >>>> For my application it would be very interesting to be able to >>>> partition based on entity sets. >>>> >>> >>> If those entity sets form a covering for the entities (each of the >>> entities included in exactly one of those sets), and those sets can >>> be identified by a tag and optionally tag value, then you should be >>> able to already read in parallel based on that partition (which has >>> to already be in the file). See section 5 of the user's guide (in >>> the doc subdir) and the description of how to read according to a >>> material_set partition. >>> >>> - tim >>> >>>> Thanks for help. >>>> Lorenzo >>> >>> -- >>> ================================================================ >>> "You will keep in perfect peace him whose mind is >>> steadfast, because he trusts in you." Isaiah 26:3 >>> >>> Tim Tautges Argonne National Laboratory >>> (tautges(a)mcs.anl.gov) (telecommuting from UW-Madison) >>> phone: (608) 263-8485 1500 Engineering Dr. >>> fax: (608) 263-4499 Madison, WI 53706 >>>

3 7

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

1 1

r5189 - MOAB/trunk/test
by iulian＠mcs.anl.gov 10 Oct '11

10 Oct '11

Author: iulian Date: 2011-10-10 18:42:13 -0500 (Mon, 10 Oct 2011) New Revision: 5189 Modified: MOAB/trunk/test/crop_vol_test.cpp Log: export only the volume, not the whole model Modified: MOAB/trunk/test/crop_vol_test.cpp =================================================================== --- MOAB/trunk/test/crop_vol_test.cpp 2011-10-08 16:17:44 UTC (rev 5188) +++ MOAB/trunk/test/crop_vol_test.cpp 2011-10-10 23:42:13 UTC (rev 5189) @@ -183,7 +183,7 @@ pFacet->delete_smooth_tags(); delete pFacet; pFacet = NULL;// try not to write the obb tree - rval = mb->write_file(vol_file.c_str()); + rval = mb->write_file(vol_file.c_str(), NULL, NULL, &volume, 1); return rval;

1 0

r5188 - in MOAB/trunk/src/parallel: . moab
by jain＠mcs.anl.gov 08 Oct '11

08 Oct '11

Author: jain Date: 2011-10-08 11:17:44 -0500 (Sat, 08 Oct 2011) New Revision: 5188 Modified: MOAB/trunk/src/parallel/Makefile.am MOAB/trunk/src/parallel/ParallelMergeMesh.cpp MOAB/trunk/src/parallel/moab/ParallelMergeMesh.hpp Log: Parallel MergeMesh with 3D partition - Nathan Bertram Modified: MOAB/trunk/src/parallel/Makefile.am =================================================================== --- MOAB/trunk/src/parallel/Makefile.am 2011-10-06 22:23:58 UTC (rev 5187) +++ MOAB/trunk/src/parallel/Makefile.am 2011-10-08 16:17:44 UTC (rev 5188) @@ -49,7 +49,7 @@ moab/ParallelData.hpp \ MBParallelConventions.h \ types.h minmax.h errmem.h \ - sort.h tuple_list.h + transfer.h crystal.h sort.h tuple_list.h if PARALLEL_HDF5 # libMOABpar_la_LIBADD = $(top_builddir)/mhdf/libmhdf.la Modified: MOAB/trunk/src/parallel/ParallelMergeMesh.cpp =================================================================== --- MOAB/trunk/src/parallel/ParallelMergeMesh.cpp 2011-10-06 22:23:58 UTC (rev 5187) +++ MOAB/trunk/src/parallel/ParallelMergeMesh.cpp 2011-10-08 16:17:44 UTC (rev 5188) @@ -1,57 +1,129 @@ #include "moab/ParallelMergeMesh.hpp" #include "moab/Core.hpp" #include "moab/CartVect.hpp" -#include "moab/Range.hpp" #include "moab/AdaptiveKDTree.hpp" #include "moab/Skinner.hpp" #include "moab/MergeMesh.hpp" -#include "moab/ParallelComm.hpp" #include "moab/CN.hpp" #include "float.h" #include <algorithm> -extern "C" -{ -#include "crystal.h" -#include "transfer.h" -} - #ifdef USE_MPI #include "moab_mpi.h" #endif - namespace moab{ //Constructor - /*1) Get Merge Data and tolerance*/ + /*Get Merge Data and tolerance*/ ParallelMergeMesh::ParallelMergeMesh(ParallelComm *pc, const double epsilon) : myPcomm(pc), myEps(epsilon) {

1 0

Fwd: vertex to cell adjacencies in parallel
by Lorenzo Alessio Botti 08 Oct '11

08 Oct '11

I forgot to reply to the list... Begin forwarded message: > From: Lorenzo Alessio Botti <ihabiamx(a)yahoo.it> > Subject: Re: [MOAB-dev] vertex to cell adjacencies in parallel > Date: October 7, 2011 5:52:49 PM GMT+02:00 > To: Hong-Jun Kim <hongjun(a)mcs.anl.gov> > > Hi Hong-Jun, > I attach the code you can run it as > mpiexec -n 2 [exe_name] -P -R [path_to_one_of_the_mesh_files_here_attached] > > Let me explain it a bit. > I start from a 5x5x5 hex cube with 2 partitions. > > The cells on the interface form more or less a 5x5x1 25 hexes row. > (They do in the hex 27 mesh while in the hex 8 an hex is misplaced for some reason) > > 25 elements have a face on the interface, 25 elements share a face with owned cells, > 20 elements have a face on boundary. You can take a look to the .vtk output. > > Let me comment the output > iface faces size 25 ok > ghost cells size 50 shared = 25 ok, every face on iface has two neighbors one owned one not owned > > Now the code searches the vertex adjacencies for the 25 owned cells, this is the output > owned entities = 25 adjacent entities not found = 45 this in wrong, the number of adjacencies not found should be 25 smaller, that is equal to number of faces on the boundary. > > Thanks a lot. > Lorenzo > > > > > On Oct 7, 2011, at 4:53 PM, Hong-Jun Kim wrote: > >> Could you please send me the code to replicate? >> Thanks. >> >> ----------------------------- >> Hong-Jun Kim >> Post-doc researcher >> MCS, Argonne National Laboratory >> 9700 S. Cass Ave. B240/R2147 >> Argonne, IL 60439 >> 630-252-4791 >> hongjun(a)mcs.anl.gov >> ----------------------------- >> >> ----- Original Message ----- >>> From: "Lorenzo Alessio Botti" <ihabiamx(a)yahoo.it> >>> To: "Tim Tautges" <tautges(a)mcs.anl.gov>, MOAB-dev(a)mcs.anl.gov >>> Sent: Friday, October 7, 2011 9:47:52 AM >>> Subject: Re: [MOAB-dev] vertex to cell adjacencies in parallel >>> Thanks a lot for the reply. >>> Let me know if you need the code to replicate this issue... >>> >>>>> For my application it would be very interesting to be able to >>>>> partition based on entity sets. >>>>> >>>> >>>> If those entity sets form a covering for the entities (each of the >>>> entities included in exactly one of those sets), and those sets can >>>> be identified by a tag and optionally tag value, then you should be >>>> able to already read in parallel based on that partition (which has >>>> to already be in the file). See section 5 of the user's guide (in >>>> the doc subdir) and the description of how to read according to a >>>> material_set partition. >>> >>> My request was a bit too cryptic... >>> I'm now reading parallel meshes generated with mbzoltan with the >>> partition tag set to PARALLEL_PARTITION. >>> It would be useful (for geometric h-multigrid, adaptivity based on >>> element agglomeration ecc...) >>> to repartition based on tagged entity sets that form a covering for >>> the entities >>> (such sets might be generated requiring a lot of partitions to the >>> partitioner) >>> instead of mesh elements. >>> A simpler trick would be to create a lot of tagged entity sets and run >>> in parallel >>> with n_processes = n_entity_set/n_entity_sets_per_process, using once >>> again the >>> entity sets as mesh elements. >>> In this context the entity set can be viewed as very general elements >>> (eg polygons). >>> In both cases the ability to get the adjacencies of entity set would >>> be also required. >>> >>> By the way I've seen that you already have a polygonal element >>> implementation >>> but I don't know if it has been introduced with the same goal. >>> >>> Now I'm still working on the standard element dG finite element >>> library >>> but later on it would be interesting to explore more general >>> implementations. >>> >>> Lorenzo >>> >>> On Oct 7, 2011, at 3:54 PM, Tim Tautges wrote: >>> >>>> >>>> >>>> On 10/07/2011 04:05 AM, Lorenzo Alessio Botti wrote: >>>>> Hi all, >>>>> I have a question about getting adjacencies in parallel. >>>>> >>>>> After having partitioned a mesh, resolved shared entities and >>>>> exchanged ghost cells I fail to >>>>> update the mesh cell adjacencies so to include ghost cells. >>>>> >>>>> The face to elements adjacencies are correctly updated, that is the >>>>> faces obtained with >>>>> pcomm.get_iface_entities(1,2,faces); (I'm running on 2 processors) >>>>> have two neighbors one owned and one non owned. >>>>> >>>>> However the vertex to cell adjacencies do not seem to be updated to >>>>> include ghost cells >>>>> and even after >>>>> mb.get_entities_by_dimension(0,3,entities); >>>>> mb.get_adjacencies(entities, 0, true, vertexEntities, >>>>> Interface::UNION); >>>>> entities.clear(); >>>>> mb.get_adjacencies(vertexEntities, 3, true, entities, >>>>> Interface::UNION); >>>>> I'm not able to find vertex to not owned cells adjacencies. >>>>> >>>>> Is get_adjacencies(...,create if missing=true,...) supposed to work >>>>> also for non owned cells? >>>>> It seems that the vertex to non owned cell adjacencies are detected >>>>> but not created. >>>>> >>>> >>>> That sounds like a bug; Hong-Jun, could you look at that? >>>> >>>> MOAB's parallel model is that all locally-represented entities, >>>> which includes ghost and shared interface entities, should appear >>>> locally as a serial mesh, with all adjacencies and other API calls >>>> available. >>>> >>>>> Overall MOAB works fine in parallel and >>>>> pcomm.assign_global_ids(...) is useful. >>>>> Are you also planning to introduce some repartitioning >>>>> capabilities? >>>> >>>> Yes, this year's work plan includes migrating entities for >>>> repartitioning. In theory, the partitioning class in tools/mbzoltan >>>> should work to compute the new partition in parallel, though I think >>>> it's currently hardwired to run on one processor (on my list to get >>>> rid of that restriction). >>>> >>>>> For my application it would be very interesting to be able to >>>>> partition based on entity sets. >>>>> >>>> >>>> If those entity sets form a covering for the entities (each of the >>>> entities included in exactly one of those sets), and those sets can >>>> be identified by a tag and optionally tag value, then you should be >>>> able to already read in parallel based on that partition (which has >>>> to already be in the file). See section 5 of the user's guide (in >>>> the doc subdir) and the description of how to read according to a >>>> material_set partition. >>>> >>>> - tim >>>> >>>>> Thanks for help. >>>>> Lorenzo >>>> >>>> -- >>>> ================================================================ >>>> "You will keep in perfect peace him whose mind is >>>> steadfast, because he trusts in you." Isaiah 26:3 >>>> >>>> Tim Tautges Argonne National Laboratory >>>> (tautges(a)mcs.anl.gov) (telecommuting from UW-Madison) >>>> phone: (608) 263-8485 1500 Engineering Dr. >>>> fax: (608) 263-4499 Madison, WI 53706 >>>> >

2 2