This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
Have a look at the MUMPS linear solver code. They define a dummy MPI interface for their serial version. That works well and it's enabled by changing an include path and compiling without mpicc.
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Gus Correa <gus_at_[hidden]> wrote:
Hi Gabrielle, Jeff
Not sure if my interjection here may help,
but user-defined macros like this,
appear in many codes we use here, combined with #ifdef
This is certainly not new.
BTW, the name convention varies, I've seen MPI, USE_MPI, SPMD, MPP, etc.
Sometimes this programming style can clutter the code quite a bit,
particularly when competing and nesting with other #ifdefs associated to
other macros (including _OPENMP, but certainly not only that one).
Normally the user-MPI macro is defined one step before compilation, in a
Makefile or header file, or by configure-type scripts
that generate Makefiles, fool around with other directives
and header files, etc.
To avoid the excess pre-processor #ifdefs on the main code,
some even dare to define a "trivial MPI library", via wrappers
to the regular MPI routines, which presumably produce
serial code when the MPI macro is not defined.
This is perhaps reminiscent of the _OPENMP macro functionality
mentioned by Gabrielle.
Something like this (I'm not claiming this one works!):
I wonder if grand unified serial+parallel code is really
worth the effort, or if branching out a serial version is
less of a maintenance nightmare, but that may be out of the topic
of this discussion.
Would another macro, say now part of mpi.h, be really helpful?
Would it only replicate the functionality (and perhaps conflict with)
the user-defined macros I mentioned above, or would it be "smarter"
in some sense that I don't realize?
Some codes and Makefiles break badly if one replaces the bare compiler
by the MPI compiler wrapper.
Instead, they set the includes and libraries separately.
This practice is not uncommon,
and may be there because in some MPI implementations
the compiler wrappers simply don't exist, as Jeff mentioned.
Would the new MPI macro help or harm in such cases?
My two cents.
Jeff Squyres wrote:
> I unfortunately won't be at the next Forum meeting,
> but you might want to ask someone to bring it up for you.
> It might not give you exactly what you want,
> however, because not all platforms have "mpicc" (or similar)
> wrapper compilers.
> I.e., to compile an MPI application on some platforms,
> you just "cc ... -lmpi". Hence, there's no way for the compiler to know whether to #define MPI or not.
> Such a macro *could* be added to mpi.h (but not Fortran),
> but then you wouldn't get at least one of the use cases that
> you (assumedly :-) ) want:
> #if MPI
> #include <mpi.h>
> On Aug 23, 2011, at 7:46 AM, Gabriele Fatigati wrote:
>> Can I suggest to insert this macro in next MPI 3 standard?
>> I think It's very useful.
>> 2011/8/23 Jeff Squyres <jsquyres_at_[hidden]>
>> I'm afraid not. Sorry! :-(
>> We have the OPEN_MPI macro -- it'll be defined to 1 if you compile with Open MPI, but that doesn't really help your portability issue. :-\
>> On Aug 23, 2011, at 5:19 AM, Gabriele Fatigati wrote:
>>> Dear OpenMPi users,
>>> is there some portable MPI macro to check if a code is compiled with MPI compiler? Something like _OPENMP for OpenMP codes:
>>> #ifdef _OPENMP
>>> it exist?
>>> #ifdef MPI
>>> Ing. Gabriele Fatigati
>>> HPC specialist
>>> SuperComputing Applications and Innovation Department
>>> Via Magnanelli 6/3, Casalecchio di Reno (BO) Italy
>>> www.cineca.it Tel: +39 051 6171722
>>> g.fatigati [AT] cineca.it
>>> users mailing list
>> Jeff Squyres
>> For corporate legal information go to:
>> users mailing list
>> Ing. Gabriele Fatigati
>> HPC specialist
>> SuperComputing Applications and Innovation Department
>> Via Magnanelli 6/3, Casalecchio di Reno (BO) Italy
>> www.cineca.it Tel: +39 051 6171722
>> g.fatigati [AT] cineca.it
>> users mailing list
users mailing list