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

[Eric Chamberland]

Hi Matthew,

I have joined the ex44.c example so you can see that we see.

The problem is about the "f" field number which I can't see any clue in 
the documentation to what to put there... We are missing some 
information maybe written elsewhere?

I have tried 3 different calls (lines 180-182) with comments aside:

   //ierr = DMSetBasicAdjacency(ddm, PETSC_TRUE, PETSC_FALSE); 
CHKERRQ(ierr); //This works: it give only 2 cells for the overlap   
//ierr = DMSetAdjacency(ddm, 0, PETSC_TRUE, PETSC_FALSE); CHKERRQ(ierr); 
//This works too, but why do I have to use field #0 ???  Is it a 
convention?   ierr = DMSetAdjacency(ddm, PETSC_DEFAULT, PETSC_TRUE, 
PETSC_FALSE); CHKERRQ(ierr); //This does not works: it give 3 cells for 
the overlap instead of 2.

Also, do you think your gitlab/knepley/fix-plex-g2n branch will find 
it's way into next or main? ;)

Thanks,

Eric

On 2021-11-10 3:26 p.m., Matthew Knepley wrote:
> Okay, so the PETSC_DEFAULT one is what is used for topology. There  
> are two separate uses for adjacency info.
> First, for this kind of topological extension, and the second is for 
> calculating Jacobians. You should be able to see
> the difference between FEM and FVM in just the case of a 2x2 mesh 
> where each process gets 1 cell. With FEM,
> the overlap is the whole mesh, whereas with FVM it leaves out the 
> diagonal partner.
>
>   Thanks,
>
>      Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20211110/02e814f8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ex44.c
Type: text/x-csrc
Size: 9055 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20211110/02e814f8/attachment.bin>