[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