> MatSolverPackage became MatSolverType
> On Mar 5, 2018, at 1:35 PM, Danyang Su <[email protected]> wrote: > > Hi Barry and Matt, > > The compiling problem should be caused by the PETSc version installed on my > computer. When updated to PETSc-Dev version, the ex1f example works fine. > However, I cannot compile this example under PETSc-3.8.3 version. > > After updating to PETSc-Dev verison, I encounter another compiling problem in > my code. > > MatSolverPackage :: solver_pkg_flow > 1 > Error: Unclassifiable statement at (1) > > Including petscmat.h or petscpc.h does not help to solve this problem. I can > rewrite this part to get rid of this. But I would rather to keep this if > there is alternative way to go. What is the head file should I include in > order to use MatSolverPackage? > > Thanks, > > Danyang > > > On 18-03-04 11:15 AM, Smith, Barry F. wrote: >> 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 <[email protected]> wrote: >>> >>> >>> >>> On 18-03-04 08:08 AM, Matthew Knepley wrote: >>>> On Fri, Mar 2, 2018 at 3:22 PM, Danyang Su <[email protected]> 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 <[email protected]> wrote: >>>>> On 18-03-02 10:58 AM, Matthew Knepley wrote: >>>>>> On Fri, Mar 2, 2018 at 1:41 PM, Danyang Su <[email protected]> wrote: >>>>>> >>>>>> On 18-02-19 03:30 PM, Matthew Knepley wrote: >>>>>>> On Mon, Feb 19, 2018 at 3:11 PM, Danyang Su <[email protected]> >>>>>>> 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 [email protected]? 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/ >
