[petsc-dev] (no subject)

Barry Smith bsmith at mcs.anl.gov
Sat Feb 16 18:00:53 CST 2013


On Feb 16, 2013, at 5:53 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> 
> On Sat, Feb 16, 2013 at 5:43 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> There might be a petsconf.h petsc-private/petscconfimpl.h petsc-private/petscconfsys.h petsc-private/petscconfdraw.h petsc-privatre/petscconfPACKAGE.h
> 
> Okay, but if we took this route, which of these would havePETSC_HAVE_HYPRE? Would it be petscconfksp.h because Hypre is a preconditioning library? Or petscconfdm.h because KSP depends on DM and there is some structured grid stuff in Hypre? Both of those answers would be wrong because of src/vec/vec/impls/hypre/vhyp.c, but I don't see any good way to locally reason about the link failures that would result from defining the macro at the wrong level.

   No, as I said in my previous email, it would be in petsc-private/petscconfhypre.h 

   When I wrote petsconfPACKAGE.h I meant this in the sense of PETSc/packages/*.py NOT in the sense of sys, ksp, vec, etc.  so there would be a petsconfhypre.py petscconfml.py petscconfsuperlu.py etc etc etc  

Yes there would also be a petscconfsys.h for things needed in the the sys directory (just so they are not included in snes, ts, etc.

  No, I am not strongly advocating making this change. Just suggesting it as a natural possibility related to the other recent changes

   Barry




More information about the petsc-dev mailing list