Hi Jeff,
* Jeff Squyres wrote on Wed, Feb 10, 2010 at 10:02:27PM CET:
> WHAT: Add -DOPEN_MPI=1 to the mpif77 and mpif90 command lines
> But we can put -DOPEN_MPI=1 in the argv that the wrapper adds. This
> seems like a safe way to add it; it makes no difference whether the
> Fortran file is set
On Feb 11, 2010, at 1:00 AM, Ralf Wildenhues wrote:
> * Jeff Squyres wrote on Wed, Feb 10, 2010 at 10:02:27PM CET:
> > WHAT: Add -DOPEN_MPI=1 to the mpif77 and mpif90 command lines
>
> It won't work with IBM xlf which needs -WF,-D. I'm sure there are other
> Fortran compilers that don't grok -D
Where does bcast(1) synchronize?
(Oops on typo - if reduce(1) wasn't defined, that definitely would be bad :) )
-jms
Sent from my PDA. No type good.
- Original Message -
From: devel-boun...@open-mpi.org
To: Open MPI Developers
Sent: Wed Feb 10 12:50:03 2010
Subject: Re: [OMPI devel] f
I misparsed your reply. Yes, bcast(1) *can* sync if it wants to. I don't have a
spec handy to check if bcast(0) is defined or not (similar to reduce). If it
is, then sure, it could sync as well.
My previous point was that barrier is the only collective that is *required* to
synchronize.
-jms
On Feb 11, 2010, at 7:10 AM, Jeff Squyres (jsquyres) wrote:
> I misparsed your reply. Yes, bcast(1) *can* sync if it wants to. I don't have
> a spec handy to check if bcast(0) is defined or not (similar to reduce). If
> it is, then sure, it could sync as well.
FWIW, in looking through MPI-2.2,
On Feb 11, 2010, at 07:10 , Jeff Squyres (jsquyres) wrote:
> I misparsed your reply. Yes, bcast(1) *can* sync if it wants to. I don't have
> a spec handy to check if bcast(0) is defined or not (similar to reduce). If
> it is, then sure, it could sync as well.
I have to disagree here. There are
Jeff Squyres (jsquyres) wrote:
Re: [OMPI devel] failure with
zero-lengthReduce()andbothsbuf=rbuf=NULL
I misparsed your reply. Yes, bcast(1) *can* sync if it wants to. I
don't have a spec handy to check if bcast(0) is defined or not (similar
to reduce). If it is, then sure, it could syn
Why Request_free() and Cancel() do not fail when REQUEST_NULL is
passed? Am I missing something?
#include
int main(int argc, char *argv[])
{
MPI_Request req;
MPI_Init(&argc, &argv);
req = MPI_REQUEST_NULL;
MPI_Request_free(&req);
req = MPI_REQUEST_NULL;
MPI_Cancel(&req);
MPI_Finali
On Feb 11, 2010, at 10:04 AM, George Bosilca wrote:
>> I misparsed your reply. Yes, bcast(1) *can* sync if it wants to. I don't
>> have a spec handy to check if bcast(0) is defined or not (similar to
>> reduce). If it is, then sure, it could sync as well.
>
> I have to disagree here. There are
This has been corrected on the trunk
(https://svn.open-mpi.org/trac/ompi/changeset/20537). Unfortunately, the
corresponding patch didn't make it into the 1.4.1. I'll create a ticket to push
it into the 1.4.2.
george.
On Feb 11, 2010, at 10:15 , Lisandro Dalcin wrote:
> Why Request_free() an
...and 1.5. :-)
On Feb 11, 2010, at 10:53 AM, George Bosilca wrote:
> This has been corrected on the trunk
> (https://svn.open-mpi.org/trac/ompi/changeset/20537). Unfortunately, the
> corresponding patch didn't make it into the 1.4.1. I'll create a ticket to
> push it into the 1.4.2.
>
> g
On Feb 11, 2010, at 10:58 AM, Jeff Squyres (jsquyres) wrote:
> ...and 1.5. :-)
Err... never mind. It's already there. :-)
/me slinks off into the night...
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
On 11 February 2010 12:04, George Bosilca wrote:
>
> Therefore, we can argue as much as you want about what the correct arguments
> of a reduce call should be, a reduce(count=0) is one of the meaningless MPI
> calls and as such should not be tolerated.
>
Well, I have to disagree... I understand
I've reported this long ago (alongside other issues now fixed)...
I can see that this is fixed in trunk and branches/v1.5, but not
backported to branches/v1.4
Any chance to get this for 1.4.2? Or should it wait until 1.5?
--
Lisandro Dalcin
---
Centro Internacional de Métodos Compu
Jeff Squyres wrote:
There's no synchronization *guarantee* in MPI collectives except for
MPI_BARRIER. [...] BCAST *can* synchronize; I'm not saying it has to.
I fully agree with Jeff and would even go a step further.
As has already been noted, there are also some implicit data
dependencies
WHAT: Rename ompi/include/mpi_portable_platform.h to be
opal/include/opal_portable_platform.h
WHY: The file includes definitions and macros that identify the compiler used
to build the system, etc.
The contents actually have nothing specific to do with MPI.
WHEN:Weekend of F
This is absolutely not true. Open MPI supports zero length collective
operations (all of them actually), but if their arguments are correctly shaped.
What you're asking for is a free ticket to write MPI calls that do not follow
the MPI requirements when a special value for count is given.
While
WHAT: Add hardware thread support to processor affinity components and
new options to orterun.
WHY: OMPI currently does not correctly recognize processors that support
hardware threads. In cases where the user uses the mpirun options
-bind-to-* and -by-* processes are bound to the first threa
On 11 February 2010 15:06, George Bosilca wrote:
> This is absolutely not true. Open MPI supports zero length collective
> operations (all of them actually), but if their arguments are correctly
> shaped.
>
OK, you are right here ...
> What you're asking for is a free ticket to write MPI calls
Yes -- it should be in 1.4.2 -- the CMR George filed after your mail earlier
today includes both the REQUEST_NULL and WIN_*_ERRHANDLER stuff:
https://svn.open-mpi.org/trac/ompi/ticket/2257
I just added you to the CC.
BUT: I think we should be careful with r20537; if we bring that over (an
On Feb 11, 2010, at 2:14 PM, Lisandro Dalcin wrote:
> But you did not answer my previous question... What's the rationale
> for requiring sendbuf!=recvbuf when count=0? I would argue you want a
> free ticket :-) to put restrictions on user code (without an actual
> rationale) in order to simplify
My only $0.02 is that if we rename it to opal_portable_platform.h, we must
remember that this file is #included in mpi.h, and therefore it is installed in
user OMPI installations.
$includedir/mpi_portable_platform.h was deemed to be a "safe" filename. But
we've already had a name conflict with
I wouldn't change the installation location - just thought it would be good to
avoid the abstraction break in the source code.
Remember - this file doesn't get installed at all unless we built the MPI
layer...
On Feb 11, 2010, at 1:11 PM, Jeff Squyres wrote:
> My only $0.02 is that if we rena
In the MPI standard, the portion discussing the PMPI profiling
interface says:
3. document the implementation of different language
bindings of the MPI interface if
they are layered on top
of each other, so that the profiler developer knows
whether she must implement the p
On Feb 11, 2010, at 3:57 PM, Ralph Castain wrote:
> I wouldn't change the installation location - just thought it would be good
> to avoid the abstraction break in the source code.
>
> Remember - this file doesn't get installed at all unless we built the MPI
> layer...
Hmm. That becomes an in
On Feb 11, 2010, at 4:13 PM, Eugene Loh wrote:
> In the MPI standard, the portion discussing the PMPI profiling interface says:
>
> 3. document the implementation of different language
> bindings of the MPI interface if they are layered on top
> of each other, so that the profiler
Jeff Squyres wrote:
[about -D not working with xlf]
If we care, it is easy enough to add a configure test to
figure this kind of stuff out.
Might be worth logging a bug with the autotools/autoconf
people on this (if it's not already there), it's been
mentioned recently on their lists as som
Jeff Squyres wrote:
On Feb 11, 2010, at 4:13 PM, Eugene Loh wrote:
In the MPI standard, the portion discussing the PMPI profiling interface says:
3. document the implementation of different language
bindings of the MPI interface if they are layered on top
of each other, so that
Mm... good to know. Thanks!
On Feb 11, 2010, at 5:58 PM, Chris Samuel wrote:
> Jeff Squyres wrote:
>
> [about -D not working with xlf]
>
> > If we care, it is easy enough to add a configure test to
> > figure this kind of stuff out.
>
> Might be worth logging a bug with the autotools/autocon
On Feb 11, 2010, at 6:08 PM, Eugene Loh wrote:
> Back to the opening question: is this documented anywhere? (Such
> documentation *is* a requirement of the standard and OMPI is standard
> conforming, y'know.)
The code? ;-)
No, I don't believe we document this stuff anywhere.
--
Jeff Squyres
Hi Ralph,
hmm, I don't really care about the name itselve.
As Jeff mentioned, we'd have a "abstraction break" either way.
The question I have, why does orte_info need to include the information, which
compiler it was compiled with ;-)?
We basically only care to warn users about a typical MPI-use
Jeff Squyres wrote:
On Feb 11, 2010, at 6:08 PM, Eugene Loh wrote:
Back to the opening question: is this documented anywhere? (Such
documentation *is* a requirement of the standard and OMPI is standard
conforming, y'know.)
The code? ;-)
No, I don't believe we document this stuff an
On Feb 11, 2010, at 4:45 PM, Rainer Keller wrote:
> Hi Ralph,
> hmm, I don't really care about the name itselve.
> As Jeff mentioned, we'd have a "abstraction break" either way.
There is no abstraction break - I talked to Jeff about it and cleared up the
confusion. The OMPI code will have an in
33 matches
Mail list logo
