[petsc-dev] forget about libmpiuni completely

[Matthew Knepley]

On Wed, Feb 17, 2010 at 8:32 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:

> On 17 February 2010 13:06, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> > On Feb 17, 2010, at 9:05 AM, Lisandro Dalcin wrote:
> >
> >> On 17 February 2010 11:45, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >>>
> >>> 1) Make mpiuni truly a download package mimicing other ones exactly.
> >>> 2) Swallow mpiuni more completely into PETSc, no separate libmpiuni,
> put
> >>> the
> >>> includes/mods in a location they are found automatically without the
> >>> extra
> >>> -IXXXX
> >>> 3) Have a half-plant/half-animal model.
> >>>
> >>
> >> I definitely vote for (2) ... No separate libmpiuni (put stuff
> >> libpetscsys), put mpi.*.* in  ${PETSC_ARCH}/include/
> >>
> >> However, just in case (think of ./configure --with-mpi=0 --prefix=/usr)
> >> ...
> >>
> >> I think we could do the following:
> >>
> >> 1) rename/move "include/mpiuni/mpi.h" to "include/mpiuni.h"
> >>
> >> 2) autogenerate a header file "$PETSC_ARCH/include/petscmpi.h",
> >> #include'ing "mpi.h" or "mpiuni.h" depending on configuration.
> >>
> >> 3) Change "petsc.h" to #incluide "petscmpi.h" instead of "mpi.h"
> >
> >   Yuck. Users often like to shove a #include "mpi.h" into their source
> code
> > (even though, of course, when you include petsc.h you don't need to worry
> > about that), with your model it pushes people too much into a "PETSc
> way".
> >
> >   Your model is clean, but too idealistic I think and would annoy people.
> >
>
> But if they shove a #include "mpi.h" into their source code, things
> will work, as long as they use a true MPI implementation... My point
> is that if users do want to maintain its code mpiuni-compatible, they
> should not #include "mpi.h", and let #include "petsc.h" handle the MPI
> details...
>

I do not think this handles the situation for libraries. I write a library.
It is
supposed to work with lots of stuff, including PETSc. I put in mpi.h, which
is completely reasonable. Then the user of the library wants to use mpiuni.
This works now, but would break in your model.

I still much prefer a separate package. It think it is cleaner, unambiguous
what is happening, and would allow someone not as lazy as us to do a full
serial MPI.

  Matt


> Anyway, I'm fine with having $PETSC_ARCH/include/mpi*.* ... It's just
> that I have a bit of fear about a prefix PETSc install --with-mpi=0
> overwriting the mpi.h from a true MPI installation... I know, this
> situation is kinda nonsense, but you know...
>
>
> --
> Lisandro Dalcin
> ---------------
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
>



-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100217/3ae7cb97/attachment.html>