<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>OK, thanks again for that explanation, I never would have been
able to figure out that this_set was the root set. I apologize for
all the dumb questions, hopefully they are all getting me closer
to self sufficiency..<br>
</p>
<p>I'm getting an error that doesn't make sense to me. I specifying
the resolve_dim and shared_dim in the call:</p>
<p> // Get the ParallelComm instance<br>
ParallelComm* pcomm = new ParallelComm(mb, mpi_comm);<br>
int nprocs = pcomm->proc_config().proc_size();<br>
int rank = pcomm->proc_config().proc_rank();<br>
<br>
// get the root set handle<br>
EntityHandle root_set = mb->get_root_set();<br>
<br>
merr = pcomm->resolve_shared_ents(root_set, 2, -1);</p>
<p><br>
</p>
<p>but I'm getting this message:</p>
<p>[0]MOAB ERROR: Unable to guess shared_dim or resolve_dim!</p>
<p><br>
</p>
<p>what am i missing?</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 10/25/18 12:51, Vijay S. Mahadevan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOcbyd0RnfRKUX0zUGEHe6UT2DEXmrTXAPEv-56_LL2BirPYVQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">It is your root set or fileset if you added
entities to it. You can get the root set handle from Core
object.
<div dir="auto"><br>
</div>
<div dir="auto">Vijay </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Thu, Oct 25, 2018, 14:38 Ryan O'Kuinghttons
<<a href="mailto:ryan.okuinghttons@noaa.gov"
moz-do-not-send="true">ryan.okuinghttons@noaa.gov</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks
again, Vijay. However, I still don't understand what this_set
<br>
should be, is it an output maybe?<br>
<br>
Ryan<br>
<br>
On 10/25/18 12:27, Vijay S. Mahadevan wrote:<br>
> You can try either the first or the second variant
instead [1] with<br>
> following arguments.<br>
><br>
> ErrorCode
moab::ParallelComm::resolve_shared_ents(EntityHandle this_set,<br>
> int resolve_dim = 2,<br>
> int shared_dim = -1,<br>
> const Tag * id_tag = 0<br>
> )<br>
><br>
> That should resolve 2-dim entities with shared edges
across<br>
> partitions. You can leave id_tag pointer as zero since
the default is<br>
> GLOBAL_ID.<br>
><br>
>> This brings up a more general question I've had about
the moab<br>
> documentation for a while. In the doc for this routine,
it only lists 2<br>
> parameters, proc_ents and shared_dim, even though in the
function<br>
> signature above it clearly shows more. I've had trouble
understanding<br>
> which parameters are relevant in the past, or what they
do because I'm<br>
> not quite sure how to read the documentation.<br>
><br>
> This is an oversight. We will go through and rectify some
of the<br>
> inconsistencies in the documentation. We are preparing
for an upcoming<br>
> release and I'll make sure that routines in
Core/ParallelComm have<br>
> updated documentation that match the interfaces.
Meanwhile, if you<br>
> have questions, feel free to shoot an email to the list.<br>
><br>
> Hope that helps.<br>
><br>
> Vijay<br>
><br>
> [1] <a
href="http://ftp.mcs.anl.gov/pub/fathom/moab-docs-develop/classmoab_1_1ParallelComm.html#a29a3b834b3fc3b4ddb3a5d8a78a37c8a"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://ftp.mcs.anl.gov/pub/fathom/moab-docs-develop/classmoab_1_1ParallelComm.html#a29a3b834b3fc3b4ddb3a5d8a78a37c8a</a><br>
> On Thu, Oct 25, 2018 at 1:58 PM Ryan O'Kuinghttons<br>
> <<a href="mailto:ryan.okuinghttons@noaa.gov"
target="_blank" rel="noreferrer" moz-do-not-send="true">ryan.okuinghttons@noaa.gov</a>>
wrote:<br>
>> Hi Vijay,<br>
>><br>
>> Thanks again for that explanation.<br>
>><br>
>> ESMF does use unique global ids for the vertices and
set them to the<br>
>> GLOBAL_ID in the moab mesh. So I think we are good
there.<br>
>><br>
>> I can't quite figure out how to use
resolve_shared_entities though.<br>
>> There are three versions of the call in the
documentation, and I assume<br>
>> that I should use the first and pass in a Range
containing all entities<br>
>> for proc_ents:<br>
>><br>
>> <a
href="http://ftp.mcs.anl.gov/pub/fathom/moab-docs-develop/classmoab_1_1ParallelComm.html#a59e35d9906f2e33fe010138a144a5cb6"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://ftp.mcs.anl.gov/pub/fathom/moab-docs-develop/classmoab_1_1ParallelComm.html#a59e35d9906f2e33fe010138a144a5cb6</a><br>
>><br>
>> However, I'm not sure what the this_set EntityHandle
should be.<br>
>><br>
>> This brings up a more general question I've had about
the moab<br>
>> documentation for a while. In the doc for this
routine, it only lists 2<br>
>> parameters, proc_ents and shared_dim, even though in
the function<br>
>> signature above it clearly shows more. I've had
trouble understanding<br>
>> which parameters are relevant in the past, or what
they do because I'm<br>
>> not quite sure how to read the documentation.<br>
>><br>
>> Any example or explanation you give me for
resolve_shared_entities is<br>
>> much appreciated!<br>
>><br>
>> Ryan<br>
>><br>
>> On 10/25/18 09:40, Vijay S. Mahadevan wrote:<br>
>>> Hi Ryan,<br>
>>><br>
>>> Glad the example helped.<br>
>>><br>
>>>> The example shows the ghost exchange
happening between shared owned<br>
>>> entities. In my experiments I've been unable to
make the ghost exchange<br>
>>> work, and I think that might be because my
entities are not shared.<br>
>>><br>
>>> You need to call resolve_shared_entities on the
entities prior to<br>
>>> doing ghost exchange. When we load the mesh from
file, this happens<br>
>>> automatically based on the read options but if
you are forming a mesh<br>
>>> in memory, you need to make sure that the shared
vertices have the<br>
>>> same GLOBAL_ID numbering consistently across
processes. That is shared<br>
>>> vertices are unique. Once that is set, shared
entities resolution will<br>
>>> work correctly out of the box and you will have
shared edges/entities<br>
>>> query working correctly. A call to get ghosted
layers once this is<br>
>>> done would be the way to go.<br>
>>><br>
>>> I assume ESMF has a unique global numbering for
the vertices ? Use<br>
>>> that to set the GLOBAL_ID tag. Let us know if you
are still having<br>
>>> issues.<br>
>>><br>
>>> Vijay<br>
>>> On Thu, Oct 25, 2018 at 11:17 AM Ryan
O'Kuinghttons<br>
>>> <<a href="mailto:ryan.okuinghttons@noaa.gov"
target="_blank" rel="noreferrer" moz-do-not-send="true">ryan.okuinghttons@noaa.gov</a>>
wrote:<br>
>>>> Hi Vijay,<br>
>>>><br>
>>>> I've had some time to play with this now, and
I have another question.<br>
>>>> Thank you for sending along the example code,
it has been extremely<br>
>>>> helpful.<br>
>>>><br>
>>>> The example shows the ghost exchange
happening between shared owned<br>
>>>> entities. In my experiments I've been unable
to make the ghost exchange<br>
>>>> work, and I think that might be because my
entities are not shared. The<br>
>>>> situation I have is entities that are owned
wholly on a single<br>
>>>> processor, which need to be communicated to
other processors which<br>
>>>> require them as part of a halo region for
mesh based computation. In<br>
>>>> this situation would I need to "share" my
entities across the whole<br>
>>>> processor space, before requesting a ghost
exchange? I'm not even really<br>
>>>> sure what shared entities mean, is there a
good place to look in the<br>
>>>> documentation to learn more about the
terminology? Thanks,<br>
>>>><br>
>>>> Ryan<br>
>>>><br>
>>>> On 10/8/18 12:17, Vijay S. Mahadevan wrote:<br>
>>>>> Ryan,<br>
>>>>><br>
>>>>> You need to use the ParallelComm object
in MOAB to call<br>
>>>>> exchange_ghost_cells [1] with appropriate
levels of ghost layers for<br>
>>>>> your mesh. This needs to be done after
the mesh is loaded, or you can<br>
>>>>> pass this information also as part of the
options when loading a file<br>
>>>>> and MOAB will internally load the file
with ghosted layers. Here's an<br>
>>>>> example [2].<br>
>>>>><br>
>>>>> Vijay<br>
>>>>><br>
>>>>> [1] <a
href="http://ftp.mcs.anl.gov/pub/fathom/moab-docs-develop/classmoab_1_1ParallelComm.html#a55dfa308f56fd368319bfb4244428878"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://ftp.mcs.anl.gov/pub/fathom/moab-docs-develop/classmoab_1_1ParallelComm.html#a55dfa308f56fd368319bfb4244428878</a><br>
>>>>> [2] <a
href="http://ftp.mcs.anl.gov/pub/fathom/moab-docs-develop/HelloParMOAB_8cpp-example.html"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://ftp.mcs.anl.gov/pub/fathom/moab-docs-develop/HelloParMOAB_8cpp-example.html</a><br>
>>>>> On Mon, Oct 8, 2018 at 1:23 PM Ryan
O'Kuinghttons<br>
>>>>> <<a
href="mailto:ryan.okuinghttons@noaa.gov" target="_blank"
rel="noreferrer" moz-do-not-send="true">ryan.okuinghttons@noaa.gov</a>>
wrote:<br>
>>>>>> Hi, I am wondering if there is a way
to create ghost elements in MOAB.<br>
>>>>>> By this I mean a list of copies of
elements surrounding a specific MOAB<br>
>>>>>> element, ghost elements may exist on
a different processor than the<br>
>>>>>> source element. I see a ghost_elems
class in the appData namespace, but<br>
>>>>>> there is not much documentation on
how to use it.. Thank you,<br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Ryan O'Kuinghttons<br>
>>>>>> Cherokee Nation Management and
Consulting<br>
>>>>>> NESII/NOAA/Earth System Research
Laboratory<br>
>>>>>> <a
href="mailto:ryan.okuinghttons@noaa.gov" target="_blank"
rel="noreferrer" moz-do-not-send="true">ryan.okuinghttons@noaa.gov</a><br>
>>>>>> <a
href="https://www.esrl.noaa.gov/gsd/nesii/" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true">https://www.esrl.noaa.gov/gsd/nesii/</a><br>
>>>>>><br>
</blockquote>
</div>
</blockquote>
</body>
</html>