[petsc-users] Nodes coordinates in distributed dmplex

[Alejandro D Otero]

Thanks Matt.
It is much clearer for me now.
Regards,

Alejandro

On Fri, Jul 10, 2015 at 6:14 PM, Matthew Knepley <knepley at gmail.com> wrote:

> On Fri, Jul 10, 2015 at 6:48 AM, Alejandro D Otero <aotero at fi.uba.ar>
> wrote:
>
>> Hi Matt, thanks for your answer.
>>
>> I got a vector from getCoordinates(). How are their components indexed?
>> is (p * dim + d) with p: node, dim: of the problem, x_d coordinate of the
>> node, ok?
>> Which numbering for p? The local number of node, the number of point in
>> the DAG of the dm, the original number of node?
>>
>
> All data layouts for Plex are described by a PetscSection (which is how it
> should be in the rest of PETSc as well). The PetscSection is a map
> from mesh points to (# dof, offset) pairs. Thus, the way I get coordinates
> is the following:
>
> DMGetCoordinatesLocal(dm, &coordinates);
> DMGetCoordinateDM(dm, &cdm);
> DMGetDefaultSection(cdm, &cs);
> PetscSectionGetChart(cs, &pStart, &pEnd);
> VecGetArrayRead(coordinates, &coords);
> for (p = pStart; p < pEnd; ++p) {
>   PetscInt dof, off;
>
>   PetscSectionGetDof(cs, p, &dof);
>   PetscSectionGetOffset(cs, p, &off);
>   for (d = 0; d < dof; ++d) <compute with coords[off+d]>
> }
> VecRestoreArrayRead(coordinates, &coords);
>
>
>> I am trying a simple square mesh with 16 4-node square elements parted
>> into 2 process. Total of 25 nodes.
>> The distributed dm seems alright to me. Each process gets a dm with 8
>> elements an 15 nodes, which means that the 5 shared nodes are local to each
>> process. But one of the process gives negative values for the shared nodes.
>> How need them to be mapped to get the right number.
>>
>
> Where do you get negative point numbers? I encode off-process point
> numbers as -(remote point + 1).
>
>
>> It seems I'm using a wrong approach to this. May be I need to get the
>> coordinates in a somehow different way. I'm working on a from-scratch
>> implementation of a FEM code based on petsc4py. I want to code the problem
>> matrices assembly from elemental matrices. I've already done this
>> sequentially, but I got stuck when trying to compute elemental matrices in
>> parallel because I don't understand the way of obtaining the coordinates of
>> the nodes in for each element.
>>
>
> The way I get coordinates for the element c is
>
>   PetscScalar *coords = NULL;
>   PetscInt        csize;
>
>   ierr = DMPlexVecGetClosure(dm, cs, coordinates, c, &csize,
> &coords);CHKERRQ(ierr);
>   ierr = DMPlexVecRestoreClosure(dm, cs, coordinates, c, &csize,
> &coords);CHKERRQ(ierr);
>
>   Thanks,
>
>      Matt
>
>
>> Again, thanks for your help,
>>
>> A.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jul 9, 2015 at 5:18 PM, Matthew Knepley <knepley at gmail.com>
>> wrote:
>>
>>> On Thu, Jul 9, 2015 at 7:42 AM, Alejandro D Otero <aotero at fi.uba.ar>
>>> wrote:
>>>
>>>> Hi, sorry if this is an obvious question, but I cannot figure out how
>>>> to recover finite element nodes coordinates once I have distributed a mesh
>>>> stored as a dmplex. I am using petsc4py as interface to petsc rutines.
>>>>
>>>> I first created a dmplex using:
>>>> dm.createFromCellList()
>>>>
>>>> In a sequential run I got the coordinates with:
>>>> Coords = dm.getCoordinates()
>>>>
>>>> which gave a sequential vector with the coordinates of the mesh nodes.
>>>>
>>>> When I distribute the mesh with:
>>>> dm.distribute()
>>>>
>>>> each mpi process has it own dm but the indexing of the vector resulting
>>>> from getCoordinates() or getCoordinatesLocal() seems not consistent with
>>>> the local numbering of the cells and nodes.
>>>>
>>>
>>> When the mesh is distributed, the vertices are renumbered. Thus the
>>> coordinates you get out are
>>> for reordered local vertices, but they are consistent with the local
>>> topology (cells still contain the
>>> right vertices) and the overlap mapping (SF still connects the shared
>>> vertices).
>>>
>>> What do you need it to do?
>>>
>>>   Thanks,
>>>
>>>     Matt
>>>
>>>
>>>> Which is the correct way of doing this in PETSc philosophy?
>>>>
>>>> Thanks in advance,
>>>> Alejandro
>>>>
>>>
>>>
>>>
>>> --
>>> What most experimenters take for granted before they begin their
>>> experiments is infinitely more interesting than any results to which their
>>> experiments lead.
>>> -- Norbert Wiener
>>>
>>
>>
>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20150713/41b1119a/attachment-0001.html>