Thanks Matt. It is much clearer for me now. Regards, Alejandro
On Fri, Jul 10, 2015 at 6:14 PM, Matthew Knepley <knep...@gmail.com> wrote: > On Fri, Jul 10, 2015 at 6:48 AM, Alejandro D Otero <aot...@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 <knep...@gmail.com> >> wrote: >> >>> On Thu, Jul 9, 2015 at 7:42 AM, Alejandro D Otero <aot...@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 >