On Apr 24, 2012, at 3:33 PM, Tom Rosmond wrote:
> Yes, I would be interested in such a plugin. But be advised that I am
> strictly a fortran programmer, so if it requires any C/C++ talent, I
> would be in trouble. So maybe, before jumping into that, I would like
> to be able to look at what proc
Will do. My machine is currently quite busy, so it will be a while
before I get answers. Stay tuned.
T. Rosmond
On Tue, 2012-04-24 at 13:36 -0600, Ralph Castain wrote:
> Add --display-map to your mpirun cmd line
>
> On Apr 24, 2012, at 1:33 PM, Tom Rosmond wrote:
>
> > Jeff,
> >
> > Yes, I
Add --display-map to your mpirun cmd line
On Apr 24, 2012, at 1:33 PM, Tom Rosmond wrote:
> Jeff,
>
> Yes, I would be interested in such a plugin. But be advised that I am
> strictly a fortran programmer, so if it requires any C/C++ talent, I
> would be in trouble. So maybe, before jumping int
Jeff,
Yes, I would be interested in such a plugin. But be advised that I am
strictly a fortran programmer, so if it requires any C/C++ talent, I
would be in trouble. So maybe, before jumping into that, I would like
to be able to look at what processor/node mapping Open-mpi is actually
giving me.
On Apr 24, 2012, at 3:01 PM, Tom Rosmond wrote:
> My question is this: If the cartesian mapping is done so the two
> spacial dimensions are the 'most rapidly varying' in equivalent 1-D
> processor mapping, will Open-mpi automatically assign those 2 dimensions
> 'on-node', and assign the 'ensemble
We have a large ensemble-based atmospheric data assimilation system that
does a 3-D cartesian partitioning of the 'domain' using MPI_DIMS_CREATE,
MPI_CART_CREATE, etc. Two of the dimensions are spacial, i.e. latitude
and longitude; the third is an 'ensemble' dimension, across which
subsets of ense