[MOAB-dev] Fwd: exchanging sets of entities between processors in parallel

[Iulian Grindeanu]

Thank you, 
I am forwarding the message to the group 

----- Forwarded Message -----
From: "Kirill Terehov" <kirill.terehov at gmail.com> 
To: "Iulian Grindeanu" <iulian at mcs.anl.gov> 
Sent: Wednesday, April 18, 2012 6:29:24 AM 
Subject: Re: [MOAB-dev] exchanging sets of entities between processors in parallel 




On Apr 17, 2012, at 7:35 PM, Iulian Grindeanu wrote: 






----- Forwarded Message -----

<blockquote>
Yes, I've made it public 



One of the goals is to make adaptively refined mesh based on octree with repartitioning 
The code I've sent to you can do initial partitioning on the same run, but can't do repartitioning 






OK, I see. 
This is a nice problem, but I am not sure anybody did it yet using MOAB. I think we would be happy if you want to contribute your ideas. Most of the parallel communication is done in the ParallelComm class. 

mesh refinement/coarsening in parallel is a difficult problem; do you rebalance or you start with a new partitioning? I don't even know if you can rebalance in parmetis. (I mean, can you start from an existing graph, modify it, and partition again, with minimal "changes"?) 

</blockquote>





Parmetis can do what you say, there is a function for that (ParMETIS_V3_AdaptiveRepart) 
But when I try to do that with moab, something goes wrong 




I have also faced several issues and want to share it with you 


1) While installing moab on SUSE Linux Enterprise Server 10 I've got following error: 



SparseTag.cpp(377): error: no default constructor exists for class "Internal::hashtable_const_iterator<std::pair<const moab::EntityHandle={size_t={unsigned long}}, void *>, false, false>" 
SparseTag::MapType::const_iterator iter; 
^ 
detected during instantiation of "void moab::get_tagged(const moab::SparseTag::MapType &, Container &, moab::EntityType, const moab::Range *) [with Container=moab::Range]" at line 433 


it was intel compiler 11.1 20101201, i've got same error with g++ 4.1.0 
the problem seems to come from unordered_map class on this platform 
i've successfully installed moab by removing check for this class inside configure script 
probably there should be an option to omit this check or more tests for usability of this class inside configure 


2) I attach a simple example when moab hangs inside exchange_ghost_cells 
attachments are: 
a. an initial mesh nmesh-0.vtk 
b. mesh out.mhdf prepared by mbpart with command ./mbpart -p partgeomkway 6 nmesh-0.vtk out.mhdf 
c. simple code bug.cpp that can be compiled by 
mpicxx bug.cpp -lMOAB -lnetcdf 
and run by 
mpiexec -np 6 ./a.out out.mhdf 


it fails to pass exchange_ghost_cells 


I'll try to replace code for message passing inside this function 
If I'll have a success I'll share it with you 



<blockquote>



I will look at your code more, but I don't think I can be of much help, sorry about that. 

Iulian 


<blockquote>


</blockquote>

</blockquote>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20120418/4610d96a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.cpp
Type: application/octet-stream
Size: 2018 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20120418/4610d96a/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nmesh-0.vtk
Type: application/octet-stream
Size: 994944 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20120418/4610d96a/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out.mhdf
Type: application/octet-stream
Size: 551200 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20120418/4610d96a/attachment-0005.obj>