On Dec 1, 2009, at 5:48 PM, Jeff Squyres wrote:
> On Dec 1, 2009, at 5:52 PM, Ralph Castain wrote:
>
>> > So perhaps it can become a param in the downcall to the MCA base as to
>> > whether the priority params should be automatically registered...?
>>
>> I can live with that, though I again qu
On Dec 1, 2009, at 5:52 PM, Ralph Castain wrote:
> So perhaps it can become a param in the downcall to the MCA base
as to whether the priority params should be automatically
registered...?
I can live with that, though I again question why anything needs to
be automatically registered. It
On Dec 1, 2009, at 7:00 PM, Chris Samuel wrote:
> You are absolutely correct. I've filed CMRs
> for v1.4 and v1.5.
To clarify one point for people who weren't at the
SC'09 Open-MPI BOF (hopefully I'll get this right!):
1.4 will be the bug-fix only continuation of the 1.3
feature series and wi
- "Jeff Squyres" wrote:
> You are absolutely correct. I've filed CMRs
> for v1.4 and v1.5.
To clarify one point for people who weren't at the
SC'09 Open-MPI BOF (hopefully I'll get this right!):
1.4 will be the bug-fix only continuation of the 1.3
feature series and will be binary compati
On Dec 1, 2009, at 3:40 PM, Jeff Squyres wrote:
> On Dec 1, 2009, at 5:23 PM, Ralph Castain wrote:
>
>> The only issue with that is it implies there is a param that can be adjusted
>> - and there isn't. So it can confuse a user - or even a developer, as it did
>> here.
>>
>> I should think we
On Dec 1, 2009, at 5:23 PM, Ralph Castain wrote:
The only issue with that is it implies there is a param that can be
adjusted - and there isn't. So it can confuse a user - or even a
developer, as it did here.
I should think we wouldn't want MCA to automatically add any
parameter. If the c
The only issue with that is it implies there is a param that can be adjusted -
and there isn't. So it can confuse a user - or even a developer, as it did here.
I should think we wouldn't want MCA to automatically add any parameter. If the
component doesn't register it, then it shouldn't exist. T
You are absolutely correct. I've filed CMRs for v1.4 and v1.5.
Thanks for the heads up!
On Dec 1, 2009, at 4:26 PM, David Singleton wrote:
It looks like MPI_Cart_create argument checking was fixed in 1.3.4
but not MPI_Graph_create.
vayu1:~/openmpi-1.3.4 > diff -w -u ompi/mpi/c/cart_create.
Thomas,
I connection with Josh's question about mpirun arguments, I suggest you
try setting
MPIRUN_CMD='mpirun -am ft-enable-cr -np %N %P %A'
in your environment before launching the GASNet application. This will
instruct GASNet's wrapper around mpirun to include the flag Josh mentioned.
It looks like MPI_Cart_create argument checking was fixed in 1.3.4
but not MPI_Graph_create.
vayu1:~/openmpi-1.3.4 > diff -w -u ompi/mpi/c/cart_create.c
ompi/mpi/c/graph_create.c
...
-int MPI_Cart_create(MPI_Comm old_comm, int ndims, int *dims,
-int *periods, int reorder,
Ok, I setup a doodle to figure out a time when to chat about the 2
MPI_Request changes:
1. What Brian just did for the ROMIO interface (because others might
benefit from the same technique).
2. Details of the pending RFC.
http://doodle.com/qgvvydks5t5s9dp4
Please reply to the Doodle by
Thomas,
I have not tried to use the checkpoint/restart feature with GASNet
over MPI, so I cannot comment directly on how they interact. However,
the combination should work as long as the proper arguments (-am ft-
enable-cr) are passed along to the mpirun command, and Open MPI is
configure
This is not a bug, it's a feature. :-)
The MCA base automatically adds a priority MCA parameter for every
component.
On Dec 1, 2009, at 7:40 AM, Ralph Castain wrote:
I'm afraid Sylvain is right, and we have a bug in ompi_info:
MCA routed: parameter
"routed_binomial_priori
I'm afraid Sylvain is right, and we have a bug in ompi_info:
MCA routed: parameter "routed_binomial_priority" (current value:
<0>, data source: default value)
MCA routed: parameter "routed_cm_priority" (current value: <0>,
data source: default value)
MCA
14 matches
Mail list logo
