hi,
Iam new to OpenMPI. I have installed the java bindings of OpenMPI and
running some samples in the cluster.
iam interested in some samples using THREAD_SERIALIZED and THREAD_FUNNLED
fields in OpenMPI. please provide me some samples.
--
Lokah samasta sukhinobhavanthu
Thanks,
Madhurima
To add on to what Ralph said:
1. There are two different message passing paths in OMPI:
- "OOB" (out of band): used for control messages
- "BTL" (byte transfer layer): used for MPI traffic
(there are actually others, but these seem to be the relevant 2 for your
setup)
2. If you don't sp
Ralph -- it seems to be picking up "-pthread" from libslurm.la (i.e., outside
of the OMPI tree), which pgcc doesn't seem to like.
Another solution might be to (temporarily?) remove the "-pthread" from
libslurm.la (which is a text file that you can edit). Then OMPI shouldn't pick
up that flag,
On Mar 16, 2014, at 10:24 PM, christophe petit
wrote:
> I am studying the optimization strategy when the number of communication
> functions in a codeis high.
>
> My courses on MPI say two things for optimization which are contradictory :
>
> 1*) You have to use temporary message copy to allo
On 03/17/2014 10:52 AM, Jeff Squyres (jsquyres) wrote:
To add on to what Ralph said:
1. There are two different message passing paths in OMPI:
- "OOB" (out of band): used for control messages
- "BTL" (byte transfer layer): used for MPI traffic
(there are actually others, but these se
On Mar 17, 2014, at 9:37 AM, Gus Correa wrote:
> On 03/17/2014 10:52 AM, Jeff Squyres (jsquyres) wrote:
>> To add on to what Ralph said:
>>
>> 1. There are two different message passing paths in OMPI:
>>- "OOB" (out of band): used for control messages
>>- "BTL" (byte transfer layer): us
On Mar 17, 2014, at 12:37 PM, Gus Correa wrote:
> In other words, does OOB pick the interface associated to the IP address
> that resolves the specific node name, or does OOB have its own will and
> picks whatever interface it wants?
I'll let Ralph contribute the detail here, but it's basically
Thanks Jeff, I understand better the different cases and how to choose as a
function of the situation
2014-03-17 16:31 GMT+01:00 Jeff Squyres (jsquyres) :
> On Mar 16, 2014, at 10:24 PM, christophe petit <
> christophe.peti...@gmail.com> wrote:
>
> > I am studying the optimization strategy when
Hi Madhurima,
Currently we only have tests which start MPI and check the provided
level of thread support:
int provided = MPI.InitThread(args, MPI.THREAD_FUNNELED);
if(provided < MPI.THREAD_FUNNELED)
{
throw new MPIException("MPI_Init_thread returned less "+
Hi,
Can comm_spawn be used with win_create?
For ex:
Master process:
---
MPI_Comm_spawn(worker_program,MPI_ARGV_NULL, world_size-1,
info, 0, MPI_COMM_SELF, &everyone,
MPI_ERRCODES_IGNORE);
MPI_Win_create(&testval, sizeof(double), 1,
Also, this presentation might be useful
http://extremecomputingtraining.anl.gov/files/2013/07/tuesday-slides2.pdf
Thank you,
Saliya
On Mar 17, 2014 2:18 PM, "christophe petit"
wrote:
> Thanks Jeff, I understand better the different cases and how to choose as
> a function of the situation
>
>
> 2
Hi Ralph, I found another corner case hangup in openmpi-1.7.5rc3.
Condition:
1. allocate some nodes using RM such as TORQUE.
2. request the head node only in executing the job with
-host or -hostfile option.
Example:
1. allocate node05,node06 using TORQUE.
2. request node05 only with -host op
Hmm...no, I don't think that's the correct patch. We want that function to
remain "clean" as it's job is simply to construct the list of nodes for the VM.
It's the responsibility of the launcher to decide what to do with it.
Please see https://svn.open-mpi.org/trac/ompi/ticket/4408 for a fix
Ra
I do not understand your fix yet, but it would be better, I guess.
I'll check it later, but now please let me expalin what I thought:
If some nodes are allocated, it doen't go through this part because
opal_list_get_size(&nodes) > 0 at this location.
1590if (0 == opal_list_get_size(&nodes)
Hello,
Gustavo Correa wrote:
I guess you need to provide buffers of char type to
MPI_Send and MPI_Recv, not NULL.
That was not the problem, I was anyway using message size 0, so then
it should be OK to give NULL as the buffer pointer.
I did find the problem now; it turns out that this was
Understood, and your logic is correct. It's just that I'd rather each launcher
decide to declare the daemons as reported rather than doing it in the common
code, just in case someone writes a launcher where they choose to respond
differently to the case where no new daemons need to be launched.
16 matches
Mail list logo
