<p dir="ltr">mbpart - R 2 file.h5m file2.h5m</p>
<p dir="ltr">Now use file2.h5m in your program. </p>
<p dir="ltr">Vijay</p>
<div class="gmail_quote">On Aug 19, 2014 11:00 AM, "Gerd Heber" <<a href="mailto:gheber@hdfgroup.org">gheber@hdfgroup.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
'mbpart -R' doesn't appear to make a difference. Same behavior. G.<br>
<br>
-----Original Message-----<br>
From: Vijay S. Mahadevan [mailto:<a href="mailto:vijay.m@gmail.com">vijay.m@gmail.com</a>]<br>
Sent: Tuesday, August 19, 2014 10:48 AM<br>
To: Gerd Heber<br>
Cc: MOAB dev<br>
Subject: Re: [MOAB-dev] DMMOAB (PETSc 3.5.1)<br>
<br>
Yes, the entities in your sets with PARALLEL_PARTITION tag look badly segmented. You could try running the original mesh through the mbpart tool with the reorder option (-R) to get a new mesh with contiguous entity numbering. Let me know if the behavior reverts when using this new mesh.<br>

<br>
Vijay<br>
<br>
On Tue, Aug 19, 2014 at 10:41 AM, Gerd Heber <<a href="mailto:gheber@hdfgroup.org">gheber@hdfgroup.org</a>> wrote:<br>
> Maybe that's what's going on. Attached is the output from "mbsize -ll"<br>
> and the range returned by DMMoabGetAllVertices on process 1.<br>
> There are quite a few gaps. Does that make sense?<br>
><br>
> G.<br>
><br>
> -----Original Message-----<br>
> From: Vijay S. Mahadevan [mailto:<a href="mailto:vijay.m@gmail.com">vijay.m@gmail.com</a>]<br>
> Sent: Tuesday, August 19, 2014 10:27 AM<br>
> To: Gerd Heber<br>
> Cc: MOAB dev<br>
> Subject: Re: [MOAB-dev] DMMOAB (PETSc 3.5.1)<br>
><br>
> You could use the mbsize tool installed at $MOAB_INSTALL/bin/mbsize<br>
> with options "-ll" to see all entities<br>
><br>
> mbsize -ll <filename><br>
><br>
> You can track down the PARALLEL_PARTITION tag on entity sets and find out whether the corresponding vertices in the element are number contiguously (in terms of GLOBAL_ID). If this is segmented, internally, things get reverted back to a native PETSc Vec in DMMoab.<br>

> Sorry about this confusion and I should've documented this better.<br>
> This inconsistent behavior needs to change and I'm working on a patch that will possibly perform renumbering on the fly so that contiguous memory access is available for MOAB based Vecs.<br>
><br>
> Vijay<br>
><br>
> On Tue, Aug 19, 2014 at 10:13 AM, Gerd Heber <<a href="mailto:gheber@hdfgroup.org">gheber@hdfgroup.org</a>> wrote:<br>
>> What's the best way to verify that? G.<br>
>><br>
>> -----Original Message-----<br>
>> From: Vijay S. Mahadevan [mailto:<a href="mailto:vijay.m@gmail.com">vijay.m@gmail.com</a>]<br>
>> Sent: Tuesday, August 19, 2014 9:58 AM<br>
>> To: Gerd Heber<br>
>> Cc: MOAB dev<br>
>> Subject: Re: [MOAB-dev] DMMOAB (PETSc 3.5.1)<br>
>><br>
>>> DMMoabCreateVector(dm, existing_tag, PETSC_NULL, PETSC_TRUE,<br>
>>> PETSC_FALSE, &X)<br>
>><br>
>> Yes, this should preserve the values in X vector. There is currently an implementation quirk that underneath the MOAB specific Vec, we check whether the local entities (vertices) are numbered contiguously so that tag_iterate can be used. If that's not the case, it actually creates a native PETSc Vec underneath and manages the memory through that. I am working on a patch to remove this limitation but I'm not sure whether you have hit this issue now.<br>

>><br>
>> Can you just verify whether your local vertices in the mesh per<br>
>> processor are contiguously arranged ? i.e.,<br>
>><br>
>> P1: (1-10) P2: (11-20) instead of P1: (1-5,11-15), P2: (6-10, 16-20)<br>
>><br>
>> I will let you know once this patch is ready (along with a PR to track in PETSc) so that you can try it out.<br>
>><br>
>> Vijay<br>
>><br>
>> On Tue, Aug 19, 2014 at 9:49 AM, Gerd Heber <<a href="mailto:gheber@hdfgroup.org">gheber@hdfgroup.org</a>> wrote:<br>
>>> Vijay, here's something that I find confusing, or maybe I'm just doing something wrong.<br>
>>><br>
>>> I call<br>
>>><br>
>>> DMMoabCreateVector(dm, existing_tag, PETSC_NULL, PETSC_TRUE,<br>
>>> PETSC_FALSE, &X)<br>
>>><br>
>>> and would expect X to have the values of existing_tag (non-zero). But X's values are all zero.<br>
>>> Is that the expected behavior?<br>
>>><br>
>>> Thanks, G.<br>
>>><br>
>>><br>
>>><br>
>>><br>
</blockquote></div>