On Wed, Feb 17, 2010 at 8:32 AM, Lisandro Dalcin <span dir="ltr"><<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 17 February 2010 13:06, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> On Feb 17, 2010, at 9:05 AM, Lisandro Dalcin wrote:<br>
><br>
>> On 17 February 2010 11:45, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>>><br>
>>> 1) Make mpiuni truly a download package mimicing other ones exactly.<br>
>>> 2) Swallow mpiuni more completely into PETSc, no separate libmpiuni, put<br>
>>> the<br>
>>> includes/mods in a location they are found automatically without the<br>
>>> extra<br>
>>> -IXXXX<br>
>>> 3) Have a half-plant/half-animal model.<br>
>>><br>
>><br>
>> I definitely vote for (2) ... No separate libmpiuni (put stuff<br>
>> libpetscsys), put mpi.*.* in  ${PETSC_ARCH}/include/<br>
>><br>
>> However, just in case (think of ./configure --with-mpi=0 --prefix=/usr)<br>
>> ...<br>
>><br>
>> I think we could do the following:<br>
>><br>
>> 1) rename/move "include/mpiuni/mpi.h" to "include/mpiuni.h"<br>
>><br>
>> 2) autogenerate a header file "$PETSC_ARCH/include/petscmpi.h",<br>
>> #include'ing "mpi.h" or "mpiuni.h" depending on configuration.<br>
>><br>
>> 3) Change "petsc.h" to #incluide "petscmpi.h" instead of "mpi.h"<br>
><br>
>   Yuck. Users often like to shove a #include "mpi.h" into their source code<br>
> (even though, of course, when you include petsc.h you don't need to worry<br>
> about that), with your model it pushes people too much into a "PETSc way".<br>
><br>
>   Your model is clean, but too idealistic I think and would annoy people.<br>
><br>
<br>
</div>But if they shove a #include "mpi.h" into their source code, things<br>
will work, as long as they use a true MPI implementation... My point<br>
is that if users do want to maintain its code mpiuni-compatible, they<br>
should not #include "mpi.h", and let #include "petsc.h" handle the MPI<br>
details...<br></blockquote><div><br></div><div>I do not think this handles the situation for libraries. I write a library. It is</div><div>supposed to work with lots of stuff, including PETSc. I put in mpi.h, which</div>
<div>is completely reasonable. Then the user of the library wants to use mpiuni.</div><div>This works now, but would break in your model.</div><div><br></div><div>I still much prefer a separate package. It think it is cleaner, unambiguous</div>
<div>what is happening, and would allow someone not as lazy as us to do a full</div><div>serial MPI.</div><div><br></div><div>  Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Anyway, I'm fine with having $PETSC_ARCH/include/mpi*.* ... It's just<br>
that I have a bit of fear about a prefix PETSc install --with-mpi=0<br>
overwriting the mpi.h from a true MPI installation... I know, this<br>
situation is kinda nonsense, but you know...<br>
<div><div></div><div class="h5"><br>
<br>
--<br>
Lisandro Dalcin<br>
---------------<br>
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)<br>
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)<br>
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)<br>
PTLC - Güemes 3450, (3000) Santa Fe, Argentina<br>
Tel/Fax: +54-(0)342-451.1594<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>