See src/vec/is/sf/examples/tutorials/ex1f.F90 in the master branch of the PETSc git repository
BTW: git grep -i petscsfgetgraph will show every use of the function in the source code. Very useful tool Barry > On Mar 4, 2018, at 1:05 PM, Danyang Su <danyang...@gmail.com> wrote: > > > > On 18-03-04 08:08 AM, Matthew Knepley wrote: >> On Fri, Mar 2, 2018 at 3:22 PM, Danyang Su <danyang...@gmail.com> wrote: >> Hi Matt, >> I use the latest Fortran style in PETSc 3.8. Enclosed are the PETSc >> configuration, code compiling log and the function that causes compiling >> error. The compiling error happens after I include petscsf.h in the >> following section. I didn't find petscsf.h in petsc/finclude/ folder so I >> use the head file in the 'include' folder and this seems not allowed. >> >> I apologize for taking so long. The PetscSF definitions are in >> >> #include <petsc/finclude/petscis.h> > Hi Matt, > > After including > #include <petsc/finclude/petscis.h> > use petscis > > I still get error saying undefined reference to `petscsfgetgraph_' > > Did I miss any other head file? > > Thanks, > > Danyang >> >> You are correct that they should be moved out. >> >> Thanks, >> >> Matt >> >> #ifdef PETSC_V3_8_X >> >> #include <petsc/finclude/petscsys.h> >> #include <petsc/finclude/petscdmplex.h> >> #include <petsc/finclude/petscdmlabel.h> >> #include <petscsf.h> >> use petscsys >> use petscdmplex >> use petscsf >> >> #endif >> >> Thanks, >> >> Danyang >> >> >> On 18-03-02 12:08 PM, Matthew Knepley wrote: >>> On Fri, Mar 2, 2018 at 3:00 PM, Danyang Su <danyang...@gmail.com> wrote: >>> On 18-03-02 10:58 AM, Matthew Knepley wrote: >>>> On Fri, Mar 2, 2018 at 1:41 PM, Danyang Su <danyang...@gmail.com> wrote: >>>> >>>> On 18-02-19 03:30 PM, Matthew Knepley wrote: >>>>> On Mon, Feb 19, 2018 at 3:11 PM, Danyang Su <danyang...@gmail.com> wrote: >>>>> Hi Matt, >>>>> >>>>> Would you please let me know how to check if a cell is local owned? When >>>>> overlap is 0 in DMPlexDistribute, all the cells are local owned. How >>>>> about overlap > 0? It sounds like impossible to check by node because a >>>>> cell can be local owned even if none of the nodes in this cell is local >>>>> owned. >>>>> >>>>> If a cell is in the PetscSF, then it is not locally owned. The local >>>>> nodes in the SF are sorted, so I use >>>>> PetscFindInt >>>>> (http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Sys/PetscFindInt.html). >>>> Hi Matt, >>>> >>>> Would you please give me a little more about how to mark the ghost cells >>>> when overlap > 0? What do you mean a cell is in the PetscSF? I use >>>> PetscSFView to export the graph (original mesh file pile.vtk) and it >>>> exports all the cells, including the ghost cells (PETScSFView.txt). >>>> >>>> Yes, I will send you some sample code when I get time. The first problem >>>> is that you are looking at a different PetscSF. This looks like the >>>> one returned by DMPlexDistribute(). This is mapping the serial mesh to the >>>> parallel mesh. You want >>>> >>>> >>>> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DMGetPointSF.html >>>> >>>> Then you can look at >>>> >>>> >>>> https://bitbucket.org/petsc/petsc/src/1788fc36644e622df8cb1a0de85676ccc5af0239/src/dm/impls/plex/plexsubmesh.c?at=master&fileviewer=file-view-default#plexsubmesh.c-683 >>>> >>>> I get the pointSF, get out the list of leaves, and find points in it using >>>> PetscFindInt() >>> Hi Matt, >>> By using the local dm, I can get the PetscSF I want, as shown below. Now I >>> need to get the number of ghost cells or local cells (here 4944) or number >>> of leaves (here 825) for each processor. I try to use PetscSFGetGraph to >>> get number of leaves in Fortran. After including "petscsf.h", I got >>> compilation error saying "You need a ISO C conforming compiler to use the >>> glibc headers". Is there any alternative way to do this? I do not need the >>> ghost-neighbor mapping, but just the number of local owned cells. >>> >>> Also, make sure you are using the latest Fortran style for PETSc: >>> >>> >>> http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Sys/UsingFortran.html >>> >>> [0] Number of roots=11449, leaves=825, remote ranks=1 >>> [0] 4944 <- (1,0) >>> [0] 4945 <- (1,28) >>> [0] 4946 <- (1,56) >>> ... >>> [1] Number of roots=11695, leaves=538, remote ranks=1 >>> [1] 5056 <- (0,21) >>> [1] 5057 <- (0,43) >>> [1] 5058 <- (0,65) >>> [1] 5059 <- (0,87) >>> >>> In file included from /usr/include/features.h:375:0, >>> from /usr/include/stdio.h:28, >>> from >>> /home/dsu/Soft/PETSc/petsc-3.8.3/include/petscsys.h:175, >>> from /home/dsu/Soft/PETSc/petsc-3.8.3/include/petscsf.h:7, >>> from ../../solver/solver_ddmethod.F90:4837: >>> /usr/include/x86_64-linux-gnu/sys/cdefs.h:30:3: error: #error "You need a >>> ISO C conforming compile\ >>> r to use the glibc headers" >>> # error "You need a ISO C conforming compiler to use the glibc headers" >>> >>> Can you send this to petsc-ma...@mcs.anl.gov? It looks like a build problem >>> that can be fixed. >>> >>> Thanks, >>> >>> Matt >>> >>> Thanks, >>> >>> Danyang >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> Thanks, >>>> >>>> Danyang >>>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>> Thanks, >>>>> >>>>> Danyang >>>>> -- >>>>> 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 >>>>> >>>>> https://www.cse.buffalo.edu/~knepley/ >>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>>> https://www.cse.buffalo.edu/~knepley/ >>> >>> >>> >>> >>> -- >>> 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 >>> >>> https://www.cse.buffalo.edu/~knepley/ >> >> >> >> >> -- >> 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 >> >> https://www.cse.buffalo.edu/~knepley/ >