February 2013 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Forward declarations of types?
by Barry Smith 15 Feb '13

15 Feb '13

Since google declared calorically that one cannot do this in C and I refuse to have #if !defined(PETSCDRAWLGTYPEDEFED) typedef struct xxx #define PETSCDRAWLGTYPEDEFED) #endif scattered around I put the typedef of PetscDrawLG into petscys.h then small changes were made to the following files M include/petsc-private/drawimpl.h M include/petscdraw.h M include/petscsys.h M src/dm/impls/composite/pack.c M src/dm/impls/da/da1.c M src/dm/impls/da/da2.c M src/dm/impls/da/da3.c M src/dm/impls/da/gr1.c M src/dm/impls/da/gr2.c M src/ksp/ksp/interface/eige.c M src/ksp/ksp/interface/itcreate.c M src/ksp/ksp/interface/itfunc.c M src/ksp/ksp/interface/xmon.c M src/ksp/pc/impls/bjacobi/bjacobi.c M src/ksp/pc/impls/fieldsplit/fieldsplit.c M src/ksp/pc/impls/mg/mg.c M src/ksp/pc/interface/precon.c M src/mat/impls/aij/mpi/mpiaij.c M src/mat/impls/aij/seq/aij.c M src/mat/impls/baij/mpi/mpibaij.c M src/mat/impls/baij/seq/baij.c M src/mat/impls/dense/mpi/mpidense.c M src/mat/impls/dense/seq/dense.c M src/mat/impls/sbaij/mpi/mpisbaij.c M src/mat/impls/sbaij/seq/sbaij.c M src/mat/matfd/fdmatrix.c M src/snes/impls/fas/fas.c M src/snes/interface/snes.c M src/sys/classes/draw/impls/x/ftn-custom/zdrawopenxf.c M src/sys/classes/draw/interface/ftn-custom/zdrawf.c M src/sys/classes/draw/interface/ftn-custom/zdrawregf.c M src/sys/classes/draw/interface/ftn-custom/zdtextf.c M src/sys/classes/draw/interface/ftn-custom/zdtextvf.c M src/sys/classes/draw/interface/ftn-custom/zdtrif.c M src/sys/classes/draw/utils/axis.c M src/sys/classes/draw/utils/axisc.c M src/sys/classes/draw/utils/axisimpl.h M src/sys/classes/draw/utils/dscatter.c M src/sys/classes/draw/utils/ftn-custom/zaxisf.c M src/sys/classes/draw/utils/ftn-custom/zzoomf.c M src/sys/classes/draw/utils/hists.c M src/sys/classes/draw/utils/lg.c M src/sys/classes/draw/utils/lgc.c M src/sys/classes/draw/utils/lgimpl.h M src/sys/classes/viewer/impls/draw/vdraw.h M src/ts/interface/ts.c M src/ts/interface/tseig.c M src/vec/vec/impls/mpi/pdvec.c M src/vec/vec/impls/seq/bvec2.c M src/vec/vec/utils/cmesh.c I'm fine with doing this. Is there a better solution? Barry On Feb 15, 2013, at 12:38 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > How does one prevent this problem? > > [ 15%] Building C object CMakeFiles/petsc.dir/src/ksp/pc/impls/is/nn/nn.c.o > In file included from /Users/barrysmith/Src/petsc-dev/src/ksp/pc/impls/bjacobi/bjacobi.c:184: > /Users/barrysmith/Src/petsc-dev/include/petscdraw.h:283: error: redefinition of typedef ‘PetscDrawLG’ > /Users/barrysmith/Src/petsc-dev/include/petscksp.h:598: error: previous declaration of ‘PetscDrawLG’ was here > > > On Feb 15, 2013, at 11:28 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > >> We currently use recursive includes everywhere, so petscdmda.h includes all of petscao.h just so it can declare DMDAGetAO and similar. Of course most users of (and implementation files in) DMDA do not reference AO so they don't need to know about all the AO functions. >> >> The normal approach to this is to forward-declare the type, so instead of >> >> #include <petscao.h> /* includes lots of other stuff */ >> PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*); >> >> one would write >> >> typedef struct _p_AO *AO; >> PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*); >> >> in which case all three files in PETSc that actually call AO routines would need to include petscao.h. That is arguably a good thing since it makes the actual dependencies more explicit, and is recommended by many (mostly C++) style guidelines. >> >> Is this something worth considering? I think stuff like petscvec.h and petscmat.h ends up pretty much always being needed, but petscdm.h is only used by a handful of files in petscksp and above, for example. >> >> It might be nice to get rarely-used stuff like petscdraw.h out of petscsys.h. >

1 0

Re: [petsc-dev] Forward declarations of types?
by Jed Brown 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 12:38 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > How does one prevent this problem? > > [ 15%] Building C object CMakeFiles/petsc.dir/src/ksp/pc/impls/is/nn/nn.c.o > In file included from > /Users/barrysmith/Src/petsc-dev/src/ksp/pc/impls/bjacobi/bjacobi.c:184: > /Users/barrysmith/Src/petsc-dev/include/petscdraw.h:283: error: > redefinition of typedef ‘PetscDrawLG’ > /Users/barrysmith/Src/petsc-dev/include/petscksp.h:598: error: previous > declaration of ‘PetscDrawLG’ was here > Heh, I thought I remembered that duplicate typedefs were invalid in C, but gcc happily compiled it without a warning. In fact, they _are_ allowed in C11, but not in our old, crusty version of C. I guess the reliable way to do this would be to have petsc-private/${pkg}types.h that were included internally by those headers that depend on the types, like petscksp.h. It wouldn't be user-visible, but I'm not sure it's worthwhile.

1 0

Re: [petsc-dev] Forward declarations of types?
by Barry Smith 15 Feb '13

15 Feb '13

How does one prevent this problem? [ 15%] Building C object CMakeFiles/petsc.dir/src/ksp/pc/impls/is/nn/nn.c.o In file included from /Users/barrysmith/Src/petsc-dev/src/ksp/pc/impls/bjacobi/bjacobi.c:184: /Users/barrysmith/Src/petsc-dev/include/petscdraw.h:283: error: redefinition of typedef ‘PetscDrawLG’ /Users/barrysmith/Src/petsc-dev/include/petscksp.h:598: error: previous declaration of ‘PetscDrawLG’ was here On Feb 15, 2013, at 11:28 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > We currently use recursive includes everywhere, so petscdmda.h includes all of petscao.h just so it can declare DMDAGetAO and similar. Of course most users of (and implementation files in) DMDA do not reference AO so they don't need to know about all the AO functions. > > The normal approach to this is to forward-declare the type, so instead of > > #include <petscao.h> /* includes lots of other stuff */ > PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*); > > one would write > > typedef struct _p_AO *AO; > PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*); > > in which case all three files in PETSc that actually call AO routines would need to include petscao.h. That is arguably a good thing since it makes the actual dependencies more explicit, and is recommended by many (mostly C++) style guidelines. > > Is this something worth considering? I think stuff like petscvec.h and petscmat.h ends up pretty much always being needed, but petscdm.h is only used by a handful of files in petscksp and above, for example. > > It might be nice to get rarely-used stuff like petscdraw.h out of petscsys.h.

1 0

Re: [petsc-dev] Forward declarations of types?
by Matthew Knepley 15 Feb '13

15 Feb '13

On Feb 15, 2013 1:01 PM, "Jed Brown" <jedbrown(a)mcs.anl.gov> wrote: > > We currently use recursive includes everywhere, so petscdmda.h includes all of petscao.h just so it can declare DMDAGetAO and similar. Of course most users of (and implementation files in) DMDA do not reference AO so they don't need to know about all the AO functions. > > The normal approach to this is to forward-declare the type, so instead of > > #include <petscao.h> /* includes lots of other stuff */ > PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*); > > one would write > > typedef struct _p_AO *AO; > PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*); > > in which case all three files in PETSc that actually call AO routines would need to include petscao.h. That is arguably a good thing since it makes the actual dependencies more explicit, and is recommended by many (mostly C++) style guidelines. > > Is this something worth considering? I think stuff like petscvec.h and petscmat.h ends up pretty much always being needed, but petscdm.h is only used by a handful of files in petscksp and above, for example. We do this in PyLith. I like it. We need to do it in the same place in every header, with a structured comment. Should we remove the forward declaration if we end up including the full header later? Matt > It might be nice to get rarely-used stuff like petscdraw.h out of petscsys.h.

1 0

Re: [petsc-dev] Forward declarations of types?
by Jed Brown 15 Feb '13

15 Feb '13

This package is pretty cool. http://code.google.com/p/include-what-you-use/ On Fri, Feb 15, 2013 at 11:28 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > We currently use recursive includes everywhere, so petscdmda.h includes > all of petscao.h just so it can declare DMDAGetAO and similar. Of course > most users of (and implementation files in) DMDA do not reference AO so > they don't need to know about all the AO functions. > > The normal approach to this is to forward-declare the type, so instead of > > #include <petscao.h> /* includes lots of other stuff */ > PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*); > > one would write > > typedef struct _p_AO *AO; > PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*); > > in which case all three files in PETSc that actually call AO routines > would need to include petscao.h. That is arguably a good thing since it > makes the actual dependencies more explicit, and is recommended by many > (mostly C++) style guidelines. > > Is this something worth considering? I think stuff like petscvec.h and > petscmat.h ends up pretty much always being needed, but petscdm.h is only > used by a handful of files in petscksp and above, for example. > > It might be nice to get rarely-used stuff like petscdraw.h out of > petscsys.h. >

1 0

Forward declarations of types?
by Jed Brown 15 Feb '13

15 Feb '13

We currently use recursive includes everywhere, so petscdmda.h includes all of petscao.h just so it can declare DMDAGetAO and similar. Of course most users of (and implementation files in) DMDA do not reference AO so they don't need to know about all the AO functions. The normal approach to this is to forward-declare the type, so instead of #include <petscao.h> /* includes lots of other stuff */ PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*); one would write typedef struct _p_AO *AO; PETSC_EXTERN PetscErrorCode DMDAGetAO(DM,AO*); in which case all three files in PETSc that actually call AO routines would need to include petscao.h. That is arguably a good thing since it makes the actual dependencies more explicit, and is recommended by many (mostly C++) style guidelines. Is this something worth considering? I think stuff like petscvec.h and petscmat.h ends up pretty much always being needed, but petscdm.h is only used by a handful of files in petscksp and above, for example. It might be nice to get rarely-used stuff like petscdraw.h out of petscsys.h.

1 0

Re: [petsc-dev] Graph of dependencies in include/
by Barry Smith 14 Feb '13

14 Feb '13

On Feb 14, 2013, at 4:40 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Thu, Feb 14, 2013 at 4:20 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > src/ts/examples/tutorials/ex28.c (though the comment is wrong, the example did run for me). > > TSView() to binary stores the ENTIRE TS state needed to run (yes including the function pointers provided by the user) and TSLoad() loads it back up ready to run again :-) > > Barry > > Note 1) it is still only proof of concept, I don't do anything with user contexts etc etc. > > Yeah, this would need the user to provide create routines that started from scratch. Having that is actually relevant to UQ, so it may be worth adding. > > > Note 2) it, course, doesn't save state inside SNES, KSP, PC, or Mat nor should it ever. Those will all get rebuilt when the next TSSolve() is called. > > Okay, it loads when I link with '-pie', but the binary file output from ex1 does not have the DM: It worked for me :-) Presumably something changed somewhere since then and since I did not make a nightly test for it, or even remember I wrote it, it has gone bad. Or it doesn't work on Linux :-) Barry > > [0]PETSC ERROR: --------------------- Error Message ------------------------------------ > [0]PETSC ERROR: Invalid argument! > [0]PETSC ERROR: Not DM next in file! > [0]PETSC ERROR: ------------------------------------------------------------------------ > [0]PETSC ERROR: Petsc Development HG revision: unknown HG Date: unknown > [0]PETSC ERROR: See docs/changes/index.html for recent updates. > [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. > [0]PETSC ERROR: See docs/index.html for manual pages. > [0]PETSC ERROR: ------------------------------------------------------------------------ > [0]PETSC ERROR: ./ex28 on a mpich named batura by jed Thu Feb 14 16:37:57 2013 > [0]PETSC ERROR: Libraries linked from /home/jed/petsc/mpich/lib > [0]PETSC ERROR: Configure run at Wed Feb 13 09:54:27 2013 > [0]PETSC ERROR: Configure options --download-ams --download-blacs --download-chaco --download-generator --download-hypre --download-ml --download-spai --download-spooles --download-sundials --download-superlu --download-superlu_dist --download-triangle --with-blas-lapack=/usr --with-c2html --with-cholmod-dir=/usr --with-clique-dir=/home/jed/usr/clique-mpich --with-elemental-dir=/home/jed/usr/clique-mpich --with-exodusii-dir=/usr --with-hdf5-dir=/opt/mpich --with-lgrind --with-metis-dir=/home/jed/usr/clique-mpich --with-mpi-dir=/opt/mpich --with-netcdf-dir=/usr --with-openmp --with-parmetis-dir=/home/jed/usr/clique-mpich --with-pcbddc --with-pthreadclasses --with-shared-libraries --with-single-library=0 --with-sowing --with-threadcomm --with-umfpack-dir=/usr --with-x -PETSC_ARCH=mpich > [0]PETSC ERROR: ------------------------------------------------------------------------ > [0]PETSC ERROR: DMLoad() line 2622 in /home/jed/petsc/src/dm/interface/dm.c > [0]PETSC ERROR: TSLoad() line 1206 in /home/jed/petsc/src/ts/interface/ts.c > [0]PETSC ERROR: main() line 28 in src/ts/examples/tutorials/ex28.c > application called MPI_Abort(MPI_COMM_WORLD, 62) - process 0 >

1 0

Re: [petsc-dev] Graph of dependencies in include/
by Jed Brown 14 Feb '13

14 Feb '13

On Thu, Feb 14, 2013 at 4:20 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > src/ts/examples/tutorials/ex28.c (though the comment is wrong, the > example did run for me). > > TSView() to binary stores the ENTIRE TS state needed to run (yes > including the function pointers provided by the user) and TSLoad() loads it > back up ready to run again :-) > > Barry > > Note 1) it is still only proof of concept, I don't do anything with user > contexts etc etc. > Yeah, this would need the user to provide create routines that started from scratch. Having that is actually relevant to UQ, so it may be worth adding. > > Note 2) it, course, doesn't save state inside SNES, KSP, PC, or Mat nor > should it ever. Those will all get rebuilt when the next TSSolve() is > called. > Okay, it loads when I link with '-pie', but the binary file output from ex1 does not have the DM: [0]PETSC ERROR: --------------------- Error Message ------------------------------------ [0]PETSC ERROR: Invalid argument! [0]PETSC ERROR: Not DM next in file! [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: Petsc Development HG revision: unknown HG Date: unknown [0]PETSC ERROR: See docs/changes/index.html for recent updates. [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. [0]PETSC ERROR: See docs/index.html for manual pages. [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: ./ex28 on a mpich named batura by jed Thu Feb 14 16:37:57 2013 [0]PETSC ERROR: Libraries linked from /home/jed/petsc/mpich/lib [0]PETSC ERROR: Configure run at Wed Feb 13 09:54:27 2013 [0]PETSC ERROR: Configure options --download-ams --download-blacs --download-chaco --download-generator --download-hypre --download-ml --download-spai --download-spooles --download-sundials --download-superlu --download-superlu_dist --download-triangle --with-blas-lapack=/usr --with-c2html --with-cholmod-dir=/usr --with-clique-dir=/home/jed/usr/clique-mpich --with-elemental-dir=/home/jed/usr/clique-mpich --with-exodusii-dir=/usr --with-hdf5-dir=/opt/mpich --with-lgrind --with-metis-dir=/home/jed/usr/clique-mpich --with-mpi-dir=/opt/mpich --with-netcdf-dir=/usr --with-openmp --with-parmetis-dir=/home/jed/usr/clique-mpich --with-pcbddc --with-pthreadclasses --with-shared-libraries --with-single-library=0 --with-sowing --with-threadcomm --with-umfpack-dir=/usr --with-x -PETSC_ARCH=mpich [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: DMLoad() line 2622 in /home/jed/petsc/src/dm/interface/dm.c [0]PETSC ERROR: TSLoad() line 1206 in /home/jed/petsc/src/ts/interface/ts.c [0]PETSC ERROR: main() line 28 in src/ts/examples/tutorials/ex28.c application called MPI_Abort(MPI_COMM_WORLD, 62) - process 0

1 0

Re: [petsc-dev] Graph of dependencies in include/
by Barry Smith 14 Feb '13

14 Feb '13

On Feb 14, 2013, at 4:10 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Thu, Feb 14, 2013 at 3:56 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > I got upset one day that trivially restarting an ODE integration in PETSc required the user to write any code at all so decided to do something about. Hence the mushrooms > > What was your idea here? The restarted code would go along up until TSSolve, but TSSolve would be fed an option that it would use to initialize its state? What are the stored function pointers being used for? src/ts/examples/tutorials/ex28.c (though the comment is wrong, the example did run for me). TSView() to binary stores the ENTIRE TS state needed to run (yes including the function pointers provided by the user) and TSLoad() loads it back up ready to run again :-) Barry Note 1) it is still only proof of concept, I don't do anything with user contexts etc etc. Note 2) it, course, doesn't save state inside SNES, KSP, PC, or Mat nor should it ever. Those will all get rebuilt when the next TSSolve() is called.

1 0

Re: [petsc-dev] Graph of dependencies in include/
by Jed Brown 14 Feb '13

14 Feb '13

On Thu, Feb 14, 2013 at 3:56 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > I got upset one day that trivially restarting an ODE integration in > PETSc required the user to write any code at all so decided to do something > about. Hence the mushrooms What was your idea here? The restarted code would go along up until TSSolve, but TSSolve would be fed an option that it would use to initialize its state? What are the stored function pointers being used for?

1 0