[petsc-users] Is it possible to keep track of original elements # after a call to DMPlexDistribute ?

[Eric Chamberland]

Hi Matthew,

we did it with PetscSFCreateInverseSF !

It is working well without overlap, so we can go forward with this and 
compute the overlap afterward with DMPlexDistributeOverlap.

Thanks,

Eric


On 2021-07-20 10:39 p.m., Eric Chamberland wrote:
>
>
> On 2021-07-14 6:42 p.m., Matthew Knepley wrote:
>>
>> Ah, there was a confusion of intent. GlobalToNatural() is for people 
>> that want data transformed back into the original
>> order. I thought that was what you wanted. If you just want mesh 
>> points in the original order, we give you the
>> transformation as part of the output of DMPlexDistribute(). The 
>> migrationSF that is output maps the original point to
>> the distributed point. You run it backwards to get the original ordering.
>>
>>   Thanks,
>>
>>      Matt
>
> Hi,
>
> that seems to work better!  However, if I understand well the 
> migrationSF is giving information on the originating process where the 
> elements have been migrated from.
>
> Is there a PETSc way to either:
>
> 1) send back the information to the originating process (somewhat 
> "inverting" the migrationSF) ?  So I can retrieve the "partitioning 
> array"  (just like the "part" parameter in ParMETIS_V3_PartMeshKway) 
> on the sender process.
>
> or
>
> 2) Have the pre-migrationSF: I mean I would like to extract the "where 
> are the elements going to be sent?" (again like "part" parameter)
>
> If not, I can always build the communication myself...
>
> Thanks,
>
> Eric
>
>
>
>
-- 
Eric Chamberland, ing., M. Ing
Professionnel de recherche
GIREF/Université Laval
(418) 656-2131 poste 41 22 42

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20210721/0700741a/attachment.html>