<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Thanks for the quick fix, it really helps! </div><div>I’m going to use it since the (small) extra cost worth the increased robustness.</div><div><br></div><div>Bests.</div><div>Lorenzo</div><br><div><div>On 18 Nov 2013, at 16:52, Iulian Grindeanu <<a href="mailto:iulian@mcs.anl.gov">iulian@mcs.anl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt;">Thank you, Lorenzo, for reporting it;<br>I have tried with the latest repo, and indeed, it hangs out with mesh.h5m.<br><br>I have tried with bridge dimension 0 and 1, and it seems to get out of ghosting;<br>So for bridge dimension 2 that you are using, there is a problem.<br><font face="courier new,courier,monaco,monospace,sans-serif">"<br> if (pcomm->rank() == 0)<br> std::cout<<pcomm->rank()<<" Exchange ghost cells"<<std::endl;<br> result = pcomm->exchange_ghost_cells(dim,<font color="#ff0000">1</font>,1,0,true,true);<br> assert(MB_SUCCESS==result);<br>"</font><br>In the meantime, can you use bridge 0 or 1?<span class="Apple-converted-space"> </span><br><br>Thanks,<br>Iulian<br><br><hr id="zwchr"><blockquote style="border-left-width: 2px; border-left-style: solid; border-left-color: rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica, Arial, sans-serif; font-size: 12pt;">Dear all,<br>I’m writing to inform you all of a problem with MOAB in parallel that bothers me a lot.<br>Sometimes after reading a parallel .h5m mesh file and resolving shared entities the execution hangs while exchanging ghost cells.<br>The issue arises randomly but I noticed a clear tendency to occur when the number of elements in each partition decreases, that is, given the same mesh, when the number of partition increases.<br>Here attached is a simple code that should allow you to reproduce the issue (I tried to run both with 4.6.0 and trunk and obtain the same behavior).<br>mesh.h5m and mesh_ok.h5m are two different 16 part partitions of the same mesh (a 3D tetrahedral elements mesh).<span class="Apple-converted-space"> </span><br>While with mesh_ok.h5m the code works perfectly, using mesh.h5m it hangs, meaning that the process with rank 1 does not return from exchange_ghost_cells if the code is executed in parallel with 16 processors (mpiexec -n 16 <reader_exec_name>).<span class="Apple-converted-space"> </span><br>The weird thing is that the code works if executed on less that 16 processors <br><br>Any help is appreciated. Thanks in advance.<br>Lorenzo</blockquote></div></div></blockquote></div><br></body></html>