Re: [OMPI users] Python code inconsistency on complex multiplication in MPI (MPI4py)

2018-05-23 Thread Lisandro Dalcin 
34314.10478436j
>> >
>> > b = -1.39818115e+09+1.39818115e+09j
>> >
>> > a*b = -7.97922802e+16+48j
>> >
>> > This has been checked in Matlab. Instead, the first program does not
work and the worker gives a*b = -7.97922801e+16+28534416.j while the second
program works correctly. Please note that the data is transmitted correctly
from the master to the worker and the data structures are the same in both
cases (see the print() functions).
>> >
>> > The first (wrong) program is program1.py and the second (correct) is
program2.py
>> >
>> > I am using MPI4py 3.0.0. along with Python 2.7.14 and the kernel of
Open MPI 2.1.2. I have been straggling with this problem for a whole day
and still cannot figure out what's going on. I have tried numerous
initializations like np.zeros(), np.zeros_like(), np.empty_like() as well
as both np.array and np.matrix and functions np.dot(), np.matmul() and the
operator *.
>> >
>> > Finally, I think that the problem is always with the imaginary part of
the product based on other examples I tried. Any suggestions?
>> >
___
>> > users mailing list
>> > users@lists.open-mpi.org
>> > https://lists.open-mpi.org/mailman/listinfo/users


>> --
>> Jeff Squyres
>> jsquy...@cisco.com


> ___
> users mailing list
> users@lists.open-mpi.org
> https://lists.open-mpi.org/mailman/listinfo/users


> ___
> users mailing list
> users@lists.open-mpi.org
> https://lists.open-mpi.org/mailman/listinfo/users



-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 0109
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459
___
users mailing list
users@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/users

Re: [OMPI users] mpi4py+OpenMPI: Qs about submitting bugs and examples

2016-11-01 Thread Lisandro Dalcin 
On 31 October 2016 at 20:39, Jason Maldonis  wrote:

> I may also submit bugs to mpi4py, but I don't yet know exactly where the
> bugs are originating from.  Do any of you know if github is the correct
> place to submit bugs for mpi4py?
>
>
https://bitbucket.org/mpi4py/mpi4py/issues

You can also write to the mailing list in Google Groups
https://groups.google.com/forum/#!forum/mpi4py

If you are not sure your issue is mpi4py's fault, I think is better to ask
in the mailing list.



> I have also learned some cool things that are not well documented on the
> web, and I'd like to provide nice examples or something similar. Can I
> contribute examples to either mpi4py or OpenMPI?
>

Indeed, mpi4py documentation is poor. Maybe we could start by adding your
examples in the wiki https://bitbucket.org/mpi4py/mpi4py/wiki/Home . Do you
have them online in some repo to take a look?


-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 0109
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459
___
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Re: [OMPI users] openmpi and mpi4py compatibility

2016-10-05 Thread Lisandro Dalcin 
On 5 October 2016 at 22:29, Mahdi, Sam  wrote:

> Hi everyone,
>
> I had a quick question regarding the compatibility of openmpi and mpi4py.
> I have openmpi 1.7.3 and mpi4py 1.3.1.  I know these are older versions of
> each, but I was having some problems running a program that uses mpi4py and
> openmpi, and I wanted to make sure it wasn't a compatibility issue between
> the 2 versions of these programs.
>
>
Hi, I'm the author of mpi4py. Could you elaborate on the issues you
experienced? I would start by disabling MPI_Init_threads() from mpi4py, for
you have to add the following code:

import mpi4py.rc
mpi4py.rc.threaded = False
from mpi4py import MPI

But you have to do it at the VERY BEGINNING of your code, more precisely,
the two first lines should be used before any attempt to "from mpi4py
import MPI".

PS: Any chance you can use a newer version of mpi4py, maybe even a git
checkout of the master branch?

-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 0109
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459
___
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users

Re: [OMPI users] python, mpi and shell subprocess: orte_error_log

2015-10-09 Thread Lisandro Dalcin 
On 9 October 2015 at 12:05, simona bellavista  wrote:
>
>
> 2015-10-09 9:40 GMT+02:00 Lisandro Dalcin :
>>
>> On 8 October 2015 at 14:54, simona bellavista  wrote:
>> >
>>
>> >>
>> >> I cannot figure out how spawn would work with a string-command. I tried
>> >> MPI.COMM_SELF.Spawn(cmd, args=None,maxproc=4) and it just hangs
>> >
>>
>> MPI.COMM_SELF.Spawn("/bin/echo", args=["Hello",
>> "World!"],maxprocs=1).Disconnect()
>>
>> Could you try the line above and confirm whether it hangs?
>
>
> I have tried the line above and it hangs
>

OK, as "echo" is not an MPI application, then it seems OpenMPI does
not support spawning.

>>
>> >
>> > I couldn't figure out how to run Spawn with a string-like command, in
>> > fact
>> > the command that I want to run varies for each processor.
>>
>> Use maxprocs=1 and make different spawn calls.
>>
>> However, I have to insist. If you are using mpi4py as a tool to spawn
>> a bunch of different processes that work in isolation and then collect
>> result at the end, then mpi4py is likely not the right tool for the
>> task, at least if you do not have previous experience with MPI
>> programming.
>>
> Well, I don't have a big experience in MPI programming, but I do use and
> modify existing MPI codes, and I thought MPI would be easiest choice.

Have you seen these existing MPI codes calling back to the shell to
execute commands?

> Clustershells looks a bit an overshoot for the goal I would like to achieve.
> What shall I use instead? Shall I try multiprocessing module?
>

As long as running on a single compute node is many cores is enough
for your application, there is no reason to use MPI. Python's
multiprocessing of perhaps the Python 3 "concurrent.futures" package
(there is a backport for Python 2 on PyPI) would be trivial to get
working.


-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Numerical Porous Media Center (NumPor)
King Abdullah University of Science and Technology (KAUST)
http://numpor.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 4332
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

Re: [OMPI users] python, mpi and shell subprocess: orte_error_log

2015-10-09 Thread Lisandro Dalcin 
On 8 October 2015 at 14:54, simona bellavista  wrote:
>

>>
>> I cannot figure out how spawn would work with a string-command. I tried
>> MPI.COMM_SELF.Spawn(cmd, args=None,maxproc=4) and it just hangs
>

MPI.COMM_SELF.Spawn("/bin/echo", args=["Hello",
"World!"],maxprocs=1).Disconnect()

Could you try the line above and confirm whether it hangs?

>
> I couldn't figure out how to run Spawn with a string-like command, in fact
> the command that I want to run varies for each processor.

Use maxprocs=1 and make different spawn calls.

However, I have to insist. If you are using mpi4py as a tool to spawn
a bunch of different processes that work in isolation and then collect
result at the end, then mpi4py is likely not the right tool for the
task, at least if you do not have previous experience with MPI
programming.


-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Numerical Porous Media Center (NumPor)
King Abdullah University of Science and Technology (KAUST)
http://numpor.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 4332
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

Re: [OMPI users] python, mpi and shell subprocess: orte_error_log

2015-10-07 Thread Lisandro Dalcin 
On 7 October 2015 at 14:54, simona bellavista  wrote:
> I have written a small code in python 2.7 for launching 4 independent
> processes on the shell viasubprocess, using the library mpi4py. I am getting
> ORTE_ERROR_LOG and I would like to understand where it is happening and why.
>
> This is my code:
>
> #!/usr/bin/python
> import subprocess
> import re
> import sys
> from mpi4py import MPI
>
> def main():
> root='base'
> comm = MPI.COMM_WORLD
> if comm.rank == 0:
> job = [root+str(i) for i in range(4)]
> else:
> job = None
>
> job = comm.scatter(job, root=0)
> cmd="../../montepython/montepython/MontePython.py -conf
> ../config/default.conf -p ../config/.param -o ../chains/  -N 1 >
> .log"
>
> cmd_job = re.sub(r"", job, cmd)
> subprocess.check_call(cmd_job, shell=True)
> return
>
> if __name__ == '__main__':
>   main()
>
> I am running with the command:
>
> mpirun -np 4 ./run.py
>
> This is the error message that I get:
>
> [localhost:51087] [[51455,0],0] ORTE_ERROR_LOG: Not found in file
> base/odls_base_default_fns.c at line 1762
> [localhost:51087] [[51455,0],0] ORTE_ERROR_LOG: Not found in file
> orted/orted_comm.c at line 916
> [localhost:51087] [[51455,0],0] ORTE_ERROR_LOG: Not found in file
> base/odls_base_default_fns.c at line 1762
> [localhost:51087] [[51455,0],0] ORTE_ERROR_LOG: Not found in file
> orted/orted_comm.c at line 916
> --
> A system call failed during shared memory initialization that should
> not have.  It is likely that your MPI job will now either abort or
> experience performance degradation.
>
>   Local host:  localhost
>   System call: open(2)
>   Error:   No such file or directory (errno 2)
> --
>
>
> I cannot understand where the error is happening. MontePython by itself
> should not use mpibecause it should be serial.
>

This is likely related to a bad interaction between the way Python's
subprocess is implemented and the MPI implementation.

Anyway, you should not use mpi4py for such a simple trivial
parallelism, I recommend you to take a look at Python's
multiprocessing module.

If for any reason you want to go the MPI way, you should use MPI
dynamic process management, e.g. MPI.COMM_SELF.Spawn(...).


-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Numerical Porous Media Center (NumPor)
King Abdullah University of Science and Technology (KAUST)
http://numpor.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 4332
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

Re: [OMPI users] Problem with using MPI in a Python extension

2015-09-17 Thread Lisandro Dalcin 
On 17 September 2015 at 18:56, Jeff Squyres (jsquyres)
 wrote:
> On Sep 17, 2015, at 11:44 AM, Joel Hermanns  wrote:
>>
>> Thanks for the quick answer!
>
> Be sure to see Nick's answer, too -- mpi4py is a nice package.
>
>> I have a few questions now:
>>
>> 1. Are there any downsides of using —disable-dlopen?
>
> You won't be able to add or remove plugins in the filesystem after you do the 
> Open MPI installation.  But that's a pretty unusual thing to do, so I 
> wouldn't worry about it.
>
>> 2. Are there any other options? We might not be able to change MPI 
>> installation, when this is running on a supercomputer.
>
> I'm not super familiar with Python and its extension capabilities -- Nick's 
> email implies that there's a different way to solve the problem, and I 
> confess to not remembering what mpi4py does, offhand.
>

mpi4py just calls

dlopen("libmpi.so", RTLD_NOW | RTLD_GLOBAL | RTLD_NOLOAD);

before calling MPI_Init(), see the code below:

https://bitbucket.org/mpi4py/mpi4py/src/master/src/lib-mpi/compat/openmpi.h?fileviewer=file-view-default#openmpi.h-52



-- 
Lisandro Dalcin

Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Numerical Porous Media Center (NumPor)
King Abdullah University of Science and Technology (KAUST)
http://numpor.kaust.edu.sa/

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 4332
Thuwal 23955-6900, Kingdom of Saudi Arabia
http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

Re: [OMPI users] possible bug exercised by mpi4py

2012-05-24 Thread Lisandro Dalcin 
On 24 May 2012 12:40, George Bosilca  wrote:
> On May 24, 2012, at 11:22 , Jeff Squyres wrote:
>
>> On May 24, 2012, at 11:10 AM, Lisandro Dalcin wrote:
>>
>>>> So I checked them all, and I found SCATTERV, GATHERV, and REDUCE_SCATTER 
>>>> all had the issue.  Now fixed on the trunk, and will be in 1.6.1.
>>>
>>> Please be careful with REDUCE_SCATTER[_BLOCK] . My understanding of
>>> the MPI standard is that the the length of the recvcounts array is the
>>> local group size
>>> (http://www.mpi-forum.org/docs/mpi22-report/node113.htm#Node113)
>>
>>
>> I read that this morning and it made my head hurt.
>>
>> I read it to be: reduce the data in the local group, scatter the results to 
>> the remote group.
>>
>> As such, the reduce COUNT is sum(recvcounts), and is used for the reduction 
>> in the local group.  Then use recvcounts to scatter it to the remote group.
>>
>> …right?
>
> Right, you reduce locally but you scatter remotely. As such the size of the 
> recvcounts buffer is the remote size. As in the local group you do a reduce 
> (where every process participate with the same amount of data) you only need 
> a total count which in this case is the sum of all recvcounts. This 
> requirement is enforced by the fact that the input buffer is of size sum of 
> all recvcounts, which make sense only if you know the remote group receives 
> counts.

The standard says this:

"Within each group, all processes provide the same recvcounts
argument, and provide input vectors of  sum_i^n recvcounts[i] elements
stored in the send buffers, where n is the size of the group"

So, I read " Within each group, ... where n is the size of the group"
as being the LOCAL group size.

>
> I don't see much difference with the other collective. The generic behavior 
> is that you apply the operation on the local group but the result is moved 
> into the remote group.
>

Well, for me this one DO IS different (for example, SCATTER is
unidirectional for intercomunicators, but REDUCE_SCATTER is
bidirectional). The "recvbuff" is a local buffer, but you understand
"recvcounts" as remote.

Mmm, the standard is really confusing in this point...

-- 
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169

Re: [OMPI users] possible bug exercised by mpi4py

2012-05-24 Thread Lisandro Dalcin 
On 24 May 2012 10:28, Jeff Squyres  wrote:
> On May 24, 2012, at 6:53 AM, Jonathan Dursi wrote:
>
>> It seems like this might also be an issue for gatherv and reduce_scatter as 
>> well.
>
>
> Gah.  I spot-checked a few of these before my first commit, but didn't see 
> these.
>
> So I checked them all, and I found SCATTERV, GATHERV, and REDUCE_SCATTER all 
> had the issue.  Now fixed on the trunk, and will be in 1.6.1.
>

Please be careful with REDUCE_SCATTER[_BLOCK] . My understanding of
the MPI standard is that the the length of the recvcounts array is the
local group size
(http://www.mpi-forum.org/docs/mpi22-report/node113.htm#Node113)

-- 
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169

Re: [OMPI users] possible bug exercised by mpi4py

2012-05-23 Thread Lisandro Dalcin 
On 23 May 2012 19:04, Jeff Squyres  wrote:
> Thanks for all the info!
>
> But still, can we get a copy of the test in C?  That would make it 
> significantly easier for us to tell if there is a problem with Open MPI -- 
> mainly because we don't know anything about the internals of mpi4py.
>

FYI, this test ran fine with previous (but recent, let say 1.5.4)
OpenMPI versions, but fails with 1.6. The test also runs fine with
MPICH2.

Sorry for the delay, but writing the test in C takes some time
compared to Python. Also, it is a bit tiring for me to recode my tests
to C everytime a new issue shows up with code I'm confident about, but
I understand you really need something reproducible, so here you have.

Find attached a C version of the test. See the output below, the test
runs fine and shows the expected output for np=2,3,4,6,7 but something
funny happens for np=5.

[dalcinl@trantor tmp]$ mpicc allgather.c
[dalcinl@trantor tmp]$ mpiexec -n 2 ./a.out
[0] - [0] a
[1] - [0] a
[dalcinl@trantor tmp]$ mpiexec -n 3 ./a.out
[0] - [0] ab
[1] - [0] a
[2] - [1] a
[dalcinl@trantor tmp]$ mpiexec -n 4 ./a.out
[3] - [1] ab
[0] - [0] ab
[1] - [1] ab
[2] - [0] ab
[dalcinl@trantor tmp]$ mpiexec -n 6 ./a.out
[4] - [1] abc
[5] - [2] abc
[0] - [0] abc
[1] - [1] abc
[2] - [2] abc
[3] - [0] abc
[dalcinl@trantor tmp]$ mpiexec -n 7 ./a.out
[5] - [2] abc
[6] - [3] abc
[0] - [0] abcd
[1] - [1] abcd
[2] - [2] abcd
[3] - [0] abc
[4] - [1] abc
[dalcinl@trantor tmp]$ mpiexec -n 5 ./a.out
[trantor:13791] *** An error occurred in MPI_Allgatherv
[trantor:13791] *** on communicator
[trantor:13791] *** MPI_ERR_COUNT: invalid count argument
[trantor:13791] *** MPI_ERRORS_ARE_FATAL: your MPI job will now abort
--
mpiexec has exited due to process rank 2 with PID 13789 on
node trantor exiting improperly. There are two reasons this could occur:

1. this process did not call "init" before exiting, but others in
the job did. This can cause a job to hang indefinitely while it waits
for all processes to call "init". By rule, if one process calls "init",
then ALL processes must call "init" prior to termination.

2. this process called "init", but exited without calling "finalize".
By rule, all processes that call "init" MUST call "finalize" prior to
exiting or it will be considered an "abnormal termination"

This may have caused other processes in the application to be
terminated by signals sent by mpiexec (as reported here).
--
[trantor:13786] 2 more processes have sent help message
help-mpi-errors.txt / mpi_errors_are_fatal
[trantor:13786] Set MCA parameter "orte_base_help_aggregate" to 0 to
see all help / error messages



-- 
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
#include 
#include 
#include 

int main(int argc, char* argv[])
{
  int thlevel;
  void *sbuf = NULL;
  int scount = 0;
  MPI_Datatype stype = MPI_BYTE;
  void *rbuf = NULL;
  int *rcounts = NULL, sumrcounts;
  int *rdispls = NULL;
  MPI_Datatype rtype = MPI_BYTE;
  MPI_Comm comm;
  int worldrank,worldsize;
  int rank,size;
  int loop,i;
  
  //MPI_Init_thread(0,0,MPI_THREAD_MULTIPLE,&thlevel);
  MPI_Init(0,0);
  
  MPI_Comm_size(MPI_COMM_WORLD, &worldsize);
  MPI_Comm_rank(MPI_COMM_WORLD, &worldrank);
  {
MPI_Comm intracomm;
int color,local_leader,remote_leader; 
if (worldsize < 2) goto end;
if (worldrank < worldsize/2) {
  color = 0;
  local_leader = 0;
  remote_leader = worldsize/2;
} else {
  color = 1;
  local_leader = 0;
  remote_leader = 0;
}
MPI_Comm_split(MPI_COMM_WORLD,color,0,&intracomm);
MPI_Intercomm_create(intracomm, local_leader,
 MPI_COMM_WORLD, remote_leader,
 0, &comm); 
MPI_Comm_free(&intracomm);
  }

  MPI_Comm_rank(comm, &rank);
  MPI_Comm_remote_size(comm, &size);

  for (loop=0; loop<1; loop++) {

scount = 1;
sbuf = malloc(scount*sizeof(char));
((char*)sbuf)[0] = 'a'+rank;

rcounts = malloc(size*sizeof(int));
MPI_Allgather(&scount, 1, MPI_INT,
  rcounts, 1, MPI_INT,
  comm);

rdispls = malloc(size*sizeof(int));
sumrcounts = 0;
for (i=0; i

Re: [OMPI users] What will happen if a non-MPI executible loaded a MPI enabled shared library?

2010-09-11 Thread Lisandro Dalcin 
On 7 September 2010 17:08, Allen Zhao  wrote:
>  Hi, All,
>
> A newbie question:
>
> Suppose that I have a main executable (a non-MPI code, which just
> dynamically loaded a named share library), and I do compile the shared
> library with mpi-gcc. This way, when the main executable loads the shared
> library, what is going to happen?
>

Should work just fine. This is the way I use many MPI-based libs and
MPI itself from Python. However, make sure you dlopen() libmpi.so with
mode RTLD_GLOBAL, or things can co bad (this is the case with
OpenMPI).

> Can I parallel this application without calling MPI_Init() inside the main
> code, instead, I call MPI_Init() when the shared library is loaded by the
> main executable?

Of course.

> Will it then be able to run in parallel?

Unlikely. But you could use MPI_Comm_spawn() to spawn a new
application, then your main sequential code "chats" to the child
parallel app using MPI calls.

> If this scenario
> is possible, when should I call MPI_Finalize()?
>

When you know you will not use MPI any more. Perhaps you could
register a finalizer using atexit()...


-- 
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169

Re: [OMPI users] Problem including C MPI code from C++ using C linkage

2010-09-01 Thread Lisandro Dalcin 
On 31 August 2010 18:39, Patrik Jonsson  wrote:
> Hi all,
>
> I'm have a C MPI code that I need to link into my C++ code. As usual,
> from my C++ code, I do
>
> extern "C" {
> #include "c-code.h"
> }
>

#include 
extern "C" {
#include "c-code.h"
}

Would that be enough?

> where c-code.h includes, among other things, mpi.h.
>
> This doesn't work, because it appears mpi.h tries to detect whether
> it's being compiled as C or C++ and includes mpicxx.h if the language
> is C++. The problem is that that doesn't work in C linkage, so the
> compilation dies with errors like:
>
> mpic++  -I. -I$HOME/include/libPJutil -I$HOME/code/arepo -m32
> arepotest.cc -I$HOME/include -I/sw/include -L/sw/lib
> -L$HOME/code/arepo -larepo -lhdf5  -lgsl -lgmp -lmpi
> In file included from /usr/include/c++/4.2.1/map:65,
>                 from /sw/include/openmpi/ompi/mpi/cxx/mpicxx.h:36,
>                 from /sw/include/mpi.h:1886,
>                 from /Users/patrik/code/arepo/allvars.h:23,
>                 from /Users/patrik/code/arepo/proto.h:2,
>                 from arepo_grid.h:36,
>                 from arepotest.cc:3:
> /usr/include/c++/4.2.1/bits/stl_tree.h:134: error: template with C linkage
> /usr/include/c++/4.2.1/bits/stl_tree.h:145: error: declaration of C
> function 'const std::_Rb_tree_node_base* std::_Rb_tree_increment(const
> std::_Rb_tree_node_base*)' conflicts with
> /usr/include/c++/4.2.1/bits/stl_tree.h:142: error: previous
> declaration 'std::_Rb_tree_node_base*
> std::_Rb_tree_increment(std::_Rb_tree_node_base*)' here
> /usr/include/c++/4.2.1/bits/stl_tree.h:151: error: declaration of C
> function 'const std::_Rb_tree_node_base* std::_Rb_tree_decrement(const
> std::_Rb_tree_node_base*)' conflicts with
> /usr/include/c++/4.2.1/bits/stl_tree.h:148: error: previous
> declaration 'std::_Rb_tree_node_base*
> std::_Rb_tree_decrement(std::_Rb_tree_node_base*)' here
> /usr/include/c++/4.2.1/bits/stl_tree.h:153: error: template with C linkage
> /usr/include/c++/4.2.1/bits/stl_tree.h:223: error: template with C linkage
> /usr/include/c++/4.2.1/bits/stl_tree.h:298: error: template with C linkage
> /usr/include/c++/4.2.1/bits/stl_tree.h:304: error: template with C linkage
> /usr/include/c++/4.2.1/bits/stl_tree.h:329: error: template with C linkage
> etc. etc.
>
> It seems a bit presumptuous of mpi.h to just include mpicxx.h just
> because __cplusplus is defined, since that makes it impossible to link
> C MPI code from C++.
>
> I've had to resort to something like
>
> #ifdef __cplusplus
> #undef __cplusplus
> #include 
> #define __cplusplus
> #else
> #include 
> #endif
>
> in c-code.h, which seems to work but isn't exactly smooth. Is there
> another way around this, or has linking C MPI code with C++ never come
> up before?
>
> Thanks,
>
> /Patrik Jonsson
>
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>



-- 
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169

Re: [OMPI users] mpic++ compilation : C++ program with MPI-C calls

2010-08-17 Thread Lisandro Dalcin 
On 17 August 2010 04:16, Manoj Vaghela  wrote:
> Hi,
>
> I am compiling a C++ program with MPI-C function calls with mpic++.
>
> Is there effect of this on efficiency/speed of parallel program?
>

No.

-- 
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169

Re: [OMPI users] Unable to include mpich library

2010-07-02 Thread Lisandro Dalcin 
On 28 June 2010 04:26, Reuti  wrote:
>
> I saw makefiles, where the compilers (i.e. MPI wrappers) were only used for
> compiling the source to object files. Later on these were still linked with
> `gcc` or `ld`. Hence the MPI library must be accessed also for the linker
> step by `mpicc` instead of `gcc` when setting $LD is supported, or set in
> e.g. $LDFLAGS for the latter.
>
> Why is there no `mpild` to do this automatically then?
>

Why not use LD=mpicc ?

-- 
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169

Re: [OMPI users] Allgather in inter-communicator bug,

2010-05-20 Thread Lisandro Dalcin 
On 20 May 2010 11:09, Jeff Squyres  wrote:
> Can you send us an all-C or all-Fortran example that shows the problem?
>
> We don't have easy access to test through the python bindings.  ...ok, I 
> admit it, it's laziness on my part.  :-)
>

Jeff, you should really learn Python and give a try to mpi4py. Even if
you do not consider Python a language for serious, production work
:-), it would be a VERY productive one for writing tests targeting
MPI. However, mpi4py have a BIG issue: not enough man-power for
writing decent documentation.

>
> But having a pure Open MPI test app would also remove some possible variables 
> and possible sources of error.
>

So you are suggesting my code could be buggy? No way ! ;-) . Slightly
more serious: almost all my bug reports were discovered while
unittesting mpi4py and getting failures when running with Open MPI, so
I'm really confident about my Python bindings.


-- 
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169

Re: [OMPI users] Embedding MPI program into a webservice ?

2009-07-17 Thread Lisandro Dalcin 
I do not know anything about implementing webservices, but you should
take a look at MPI-2 dynamic process management. This way, your
webservice can MPI_Comm_spawn() a brand-new set of parallel processes
doing the heavy work. This way, your webservice will act as a kind of
proxy application between the request coming from the outside world
and your parallel computing resources...


On Fri, Jul 17, 2009 at 12:44 AM, Ashika Umanga
Umagiliya wrote:
> Greetings all,
>
> I am in the design level of parallizing an SVM algorithm.We need to expose
> this as a webservice.I have decided to go with Axis2/C implementation.
>
> Please refer to : http://i30.tinypic.com/i707qq.png
>
> As can be seen in the Figure1 , can I embedd my MPI logic in side my
> Webservice ? I guess that its not possible because the webservice is
> packaged as a static library (myService.so) and can not execute the
> "mpirun".
>
> In Figure2, I have illustrated another alternative.In my Webservice, I
> invoke my parallel program (myParallelProg) using "mpirun" and other
> parameters.
>
> Is there any good design to accomplish what I am trying to do?I think the
> second is not a good design ?
>
> Thanks in advance,
> umanga
>
>
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>



-- 
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

Re: [OMPI users] Using openmpi within python and crashes

2009-07-10 Thread Lisandro Dalcin 
What Python version are you using?

I would use 'ctypes' modules (available in recent Python's stdlib) in
order do open the MPI shared library, next call MPI_Init() from Python
code... Of couse, I'm assuming you Fortran code can manage the case of
MPI being initialized (by using MPI_Initialized()).

Regarding argc,argv, you just should pass NULL. OpenMPI is MPI-2
compiant, so it does not require the actuall cmd line args.

BTW, you should use ctypes.RTLD_GLOBAL flag when opening libmpi.so.

If you have trouble, feel free to mail me directly for futher help.


BTW: Do you know about mpi4py http://mpi4py.scipy.org/ ? It has
support for interoperate with Fortran codes. You can even use dynamic
process management, and build a python script that "chats" with a
Fortran program lauched by using MPI_Comm_spawn()... See for example
the master/worker Mandelbrot example at
http://mpi4py.googlecode.com/svn/trunk/demo/mandelbrot/


On Thu, Jul 9, 2009 at 2:53 PM, John R. Cary wrote:
> Our scenario is that we are running python, then importing a module written
> in Fortran.
> We run via:
>
> mpiexec -n 8 -x PYTHONPATH -x SIDL_DLL_PATH python tokHsmNP8.py
>
> where the script calls into Fortran to call MPI_Init.
>
> On 8 procs (but not one) we get hangs in the code (on some machines but not
> others!). Hard to tell precisely where, because it is in a PETSc method.
>
> Running with valgrind
>
> mpiexec -n 8 -x PYTHONPATH -x SIDL_DLL_PATH valgrind python tokHsmNP8.py
>
> gives a crash, with some salient output:
>
> ==936==
> ==936== Syscall param sched_setaffinity(mask) points to unaddressable
> byte(s)
> ==936==    at 0x39336DAA79: syscall (in /lib64/libc-2.10.1.so)
> ==936==    by 0x10BCBD58: opal_paffinity_linux_plpa_api_probe_init (in
> /usr/local/openmpi-1.3.2-notorque/lib/libopen-pal.so.0.0.0)
> ==936==    by 0x10BCE054: opal_paffinity_linux_plpa_init (in
> /usr/local/openmpi-1.3.2-notorque/lib/libopen-pal.so.0.0.0)
> ==936==    by 0x10BCC9F9:
> opal_paffinity_linux_plpa_have_topology_information (in
> /usr/local/openmpi-1.3.2-notorque/lib/libopen-pal.so.0.0.0)
> ==936==    by 0x10BCBBFF: linux_module_init (in
> /usr/local/openmpi-1.3.2-notorque/lib/libopen-pal.so.0.0.0)
> ==936==    by 0x10BC99C3: opal_paffinity_base_select (in
> /usr/local/openmpi-1.3.2-notorque/lib/libopen-pal.so.0.0.0)
> ==936==    by 0x10B9DB83: opal_init (in
> /usr/local/openmpi-1.3.2-notorque/lib/libopen-pal.so.0.0.0)
> ==936==    by 0x10920C6C: orte_init (in
> /usr/local/openmpi-1.3.2-notorque/lib/libopen-rte.so.0.0.0)
> ==936==    by 0x10579D06: ompi_mpi_init (in
> /usr/local/openmpi-1.3.2-notorque/lib/libmpi.so.0.0.0)
> ==936==    by 0x10599175: PMPI_Init (in
> /usr/local/openmpi-1.3.2-notorque/lib/libmpi.so.0.0.0)
> ==936==    by 0x10E2BDF4: mpi_init (in
> /usr/local/openmpi-1.3.2-notorque/lib/libmpi_f77.so.0.0.0)
> ==936==    by 0xDF30A1F: uedge_mpiinit_ (in
> /home/research/cary/projects/facetsall-iter/physics/uedge/par/build/uedgeC.so)
> ==936==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
>
> This makes me think that our call to mpi_init is wrong.  At
>
>  http://www.mcs.anl.gov/research/projects/mpi/www/www3/MPI_Init.html
>
> it says
>
>  Because the Fortran and C versions of MPI_Init
>  are
> different, there is a restriction on who can call MPI_Init
> . The
> version (Fortran or C) must match the main
>  program. That is, if the main program is in C, then the C version of
> MPI_Init 
> must be called. If the main program is in Fortran, the Fortran version must
> be called.
>
> Should I infer from this that since python is a C code, one must call the C
> version of MPI_Init (with argc, argv)?
>
> Or since the module is written mostly in Fortran with mpi calls of only the
> Fortran variety, I can initialize
> with the Fortran MPI_Init?
>
> Thanks.John Cary
>
>
>
>
>
>
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>



-- 
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

Re: [OMPI users] Open MPI 1.2.4 verbosity w.r.t. osc pt2pt

2007-12-13 Thread Lisandro Dalcin 
On 12/13/07, Jeff Squyres  wrote:
> On Dec 12, 2007, at 7:47 PM, Lisandro Dalcin wrote:
> Specifically: it would probably require some significant hackery in
> the OMPI build process to put in a #define that indicates whether OMPI
> is being built statically or not.  But the AM/LT process shields this
> information from the build process by design (part of the issue is
> that AM/LT allows both static and shared libraries to be built
> simultaneously).

I see.

> We'd then have to introduce some global symbol that
> could be queried that is outside of the MPI interface.  Neither of
> these things are attractive.  :-(

You are right, a globlal symbols is not attractive at all just for this.

> > AFAIK, Python does not. It uses specific, private code for this,
> > handling the loading of extension modules according to the OS's and
> > their idiosyncracies. However, Python enable users to change the flags
> > used for dlopen'ing your extension modules; the tricky part is to get
> > the correct values RTLD_GLOBAL in a portable way.
>
> That's somewhat surprising -- there's no public interfaces for modules
> to portably load sub-modules?  Bummer.

Perhaps I was not clear enough. There are many public ways of
importing modules in Python. Modules can came mainly from two sources:
pure Python code, or C compiled code. In the later case (called
extension modules), they are normally a shared object
(.so,.dylib,.dll) exporting only a simbol: 'void
init(void)', this functions bootstraps the initialization
of the extension module. What is somewhat hidden is the actual way
Python loads this shared object and calls the init function. I believe
the reason for this is related to de gory details of dlopen()ing in
different OS's/archs combination.

Anyway, Python enables you to temporarily change the flags to be used
in dlopen() calls, what is not (currently) so easy is to get the value
of RTLD_GLOBAL in a portable way.

Jeff, in short: I believe I solved (with the help of Brian) the issue
in the context of Python and the platforms we have access to. So, from
our side, things are working.

However, I believe this issue is going to cause trouble to any other
guy trying  to load shared objects using MPI. This makes me think that
Open MPI should be in charge or solving this, but I understand the
situation is complex and all us are usually out of time. I'll try to
re-read all the stuff to better understand the beast.

Regards,


-- 
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

Re: [OMPI users] Open MPI 1.2.4 verbosity w.r.t. osc pt2pt

2007-12-12 Thread Lisandro Dalcin 
On 12/12/07, Jeff Squyres  wrote:
> On Dec 12, 2007, at 6:32 PM, Lisandro Dalcin wrote:
> > Do I have the libtool API calls available when linking against
> > libmpi.so ?
>
> You should, yes.

OK, but now I realize that I cannot simply call libtool dlopen()
inconditionally, as libmpi.so could not exist in a static lib build.

> Also, see my later post: doesn't perl/python have some kind of
> portable dlopen anyway?  They're opening your module...?

AFAIK, Python does not. It uses specific, private code for this,
handling the loading of extension modules according to the OS's and
their idiosyncracies. However, Python enable users to change the flags
used for dlopen'ing your extension modules; the tricky part is to get
the correct values RTLD_GLOBAL in a portable way.

> > Is there any another way of setting a MCA parameter?
> See http://www.open-mpi.org/faq/?category=tuning#setting-mca-params.

OK, it seems there isn't a programatic way. Anyway, putenv() should
not be a souce of portability problems.

Jeff, once you have this parameter enabled, please write me in order I
can do some testing. Many tanks for your clarifications and help.

-- 
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

Re: [OMPI users] Open MPI 1.2.4 verbosity w.r.t. osc pt2pt

2007-12-12 Thread Lisandro Dalcin 
On 12/12/07, Jeff Squyres  wrote:
> Yes, this is problematic; dlopen is fun on all the various OS's...
>
> FWIW: we use the Libtool DL library for this kind of portability; OMPI
> itself doesn't have all the logic for the different OS loaders.

Do I have the libtool API calls available when linking against libmpi.so ?

> > Anyway, perhaps OpenMPI could provide an extension: a function call,
> (after much thinking...) Perhaps a better solution would be an MCA
> parameter: if the logical "mca_do_dlopen_hackery"

Fine with this.

> This should hypothetically allow you to do a simple putenv() before
> calling MPI_INIT and then the Right magic should occur.

Is there any another way of setting a MCA parameter? Or playing with
the environment is the only available way?


-- 
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

Re: [OMPI users] Open MPI 1.2.4 verbosity w.r.t. osc pt2pt

2007-12-11 Thread Lisandro Dalcin 
On 12/10/07, Jeff Squyres  wrote:
> Brian / Lisandro --
> I don't think that I heard back from you on this issue.  Would you
> have major heartburn if I remove all linking of our components against
> libmpi (etc.)?
>
> (for a nicely-formatted refresher of the issues, check out 
> https://svn.open-mpi.org/trac/ompi/wiki/Linkers)

Sorry for the late response...

I've finally 'solved' this issue by using RTLD_GLOBAL for loading the
Python extension module that actually calls MPI_Init(). However, I'm
not completelly sure if my hackery is completelly portable.

Looking briefly at the end of the link to the wiki page, you say that
if the explicit linking to libmpi on componets is removed, then
dlopen() has to be explicitelly called.

Well, this would be a mayor headhace for me, because portability
issues. Please note that I've developed mpi4py on a rather old 32 bits
linux box, but it works in many different plataforms and OS's. I do
really do not have the time of testing and figure out how to
appropriatelly call dlopen() in platforms/OS's that I even do not have
access!!

Anyway, perhaps OpenMPI could provide an extension: a function call,
let say 'ompi_load_dso()' or something like that, that can be called
before MPI_Init() for setting-up the monster. What to you think about
this? Would it be hard for you?


-- 
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

Re: [OMPI users] Possible Memcpy bug in MPI_Comm_split

2007-08-17 Thread Lisandro Dalcin 
On 8/16/07, George Bosilca  wrote:
> Well, finally someone discovered it :) I know about this problem for
> quite a while now, it pop up during our own valgrind test of the
> collective module in Open MPI. However, it never create any problems
> in the applications, at least not as far as I know. That's why I'm
> reticent to replace the memcpy by a memmove (where the arguments are
> allowed to overlap) as there is a performance penalty.

George, I believe I also reported this some time ago, and your
comments were the same :-).

No time to dive into the internals, but for my the question is: What's
going on in Comm::Split() that it falls to copy everlapping memory? It
is expected, or it is perhaps a bug?

Regards,

>
>george.
>
> On Aug 16, 2007, at 9:31 AM, Allen Barnett wrote:
>
> > Hi:
> > I was running my OpenMPI 1.2.3 application under Valgrind and I
> > observed
> > this error message:
> >
> > ==14322== Source and destination overlap in memcpy(0x41F5BD0,
> > 0x41F5BD8,
> > 16)
> > ==14322==at 0x49070AD: memcpy (mc_replace_strmem.c:116)
> > ==14322==by 0x4A45CF4: ompi_ddt_copy_content_same_ddt
> > (in /home/scratch/DMP/RHEL4-GCC4/lib/libmpi.so.0.0.0)
> > ==14322==by 0x7A6C386: ompi_coll_tuned_allgather_intra_bruck
> > (in /home/scratch/DMP/RHEL4-GCC4/lib/openmpi/mca_coll_tuned.so)
> > ==14322==by 0x4A29FFE: ompi_comm_split
> > (in /home/scratch/DMP/RHEL4-GCC4/lib/libmpi.so.0.0.0)
> > ==14322==by 0x4A4E322: MPI_Comm_split
> > (in /home/scratch/DMP/RHEL4-GCC4/lib/libmpi.so.0.0.0)
> > ==14322==by 0x400A26: main
> > (in /home/scratch/DMP/severian_tests/ompi/a.out)
> >
> > Attached is a reduced code example. I run it like:
> >
> > mpirun -np 3 valgrind ./a.out
> >
> > I only see this error if there are an odd number of processes! I don't
> > know if this is really a problem or not, though. My OMPI application
> > seems to work OK. However, the linux man page for memcpy says
> > overlapping range copying is undefined.
> >
> > Other details: x86_64 (one box, two dual-core opterons), RHEL 4.5,
> > OpenMPI-1.2.3 compiled with the RHEL-supplied GCC 4 (gcc4 (GCC) 4.1.1
> > 20070105 (Red Hat 4.1.1-53)), valgrind 3.2.3.
> >
> > Thanks,
> > Allen
> >
> >
> > --
> > Allen Barnett
> > Transpire, Inc.
> > e-mail: al...@transpireinc.com
> > Ph: 518-887-2930
> >
> > ___
> > users mailing list
> > us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/users
>
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>


-- 
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

Re: [OMPI users] dual Gigabit ethernet support

2006-10-23 Thread Lisandro Dalcin 

On 10/23/06, Tony Ladd  wrote:

A couple of comments regarding issues raised by this thread.

1) In my opinion Netpipe is not such a great network benchmarking tool for
HPC applications. It measures timings based on the completion of the send
call on the transmitter not the completion of the receive. Thus, if there is
a delay in copying the send buffer across the net, it will report a
misleading timing compared with the wall-clock time. This is particularly
problematic with multiple pairs of edge exchanges, which can oversubscribe
most GigE switches. Here the netpipe timings can be off by orders of
magnitude compared with the wall clock. The good thing about writing your
own code is that you know what it has done (of course no one else knows,
which can be a problem). But it seems many people are unaware of the timing
issue in Netpipe.


Yes! I've noticed that. I am now using Intel MPI Benchmarck. PingPong
/PingPing and SendRecv test cases seems to be more realistic. Does any
one have any comments about this test suite?



2) Its worth distinguishing between ethernet and TCP/IP. With MPIGAMMA, the
Intel Pro 1000 NIC has a latency of 12 microsecs including the switch and a
duplex bandwidth of 220 MBytes/sec. With the Extreme Networks X450a-48t
switch we can sustain 220MBytes/sec over 48 ports at once. This is not IB
performance but it seems sufficient to scale a number of applications to the
100 cpu level, and perhaps beyond.



GAMMA seems to be a great work, looking at some of its reports in web
site. Hoever, I have not tried it yet, and I am not sure if I will,
mainly because only supports MPICH-1. Has anyone any rough idea how
much work it could be to make it availabe for OpenMPI. Seems to be a
very interesting student project...

--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

Re: [OMPI users] dual Gigabit ethernet support

2006-10-23 Thread Lisandro Dalcin 

On 10/23/06, Jayanta Roy  wrote:

Sometime before I have posted doubts about using dual gigabit support
fully. See I get ~140MB/s full duplex transfer rate in each of following
runs.



Can you please tell me how are you measuring transfer rates? I mean,
Can you  show us a snipet of the code you use to obtain  the measure
~140MB/s?


--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

Re: [OMPI users] Trouble with shared libraries

2006-10-11 Thread Lisandro Dalcin 

On 10/11/06, Jeff Squyres  wrote:

Open MPI v1.1.1 requires that you set your LD_LIBRARY_PATH to include the
directory where its libraries were installed (typically, $prefix/lib).  Or,
you can use mpirun's --prefix functionality to avoid this


BTW, Why mpicc/mpicxx does not symply pass a -rpath/-R flag to the
linker? Do you want to select libraries at runtime? There are
portability problem in some target plataform? This behavior can be
really useful to experienced unix users/developers but I am not sure
if this holds true for all users.

--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

[OMPI users] problem with MPI_[Pack|Unpack]_external

2006-09-29 Thread Lisandro Dalcin 

I've just catched a problem with packing/unpacking using 'external32'
in Linux. The problem seems to be word ordering, I believe you forgot
to make the little-endian <-> big-endian conversion somewhere. Below,
an interactive session with ipython (sorry, no time to write in C)
showing the problem. Please, ignore me if this has been already
reported.

In [1]: import numpy

In [2]: from mpi4py import MPI

In [3]: print numpy.dtype('i').itemsize, MPI.INT.extent
4 4

In [4]: print numpy.dtype('b').itemsize, MPI.BYTE.extent
1 1

In [5]:

In [5]: arr1 = numpy.array([256], dtype='i') # one int, for input

In [6]: print arr1
[256]

In [7]: buf = numpy.array([0,0,0,0], dtype='b') # four bytes, auxiliar

In [8]: print buf
[0 0 0 0]

In [9]: p = MPI.INT.Pack_external('external32', arr1, buf, 0)

In [10]: print buf, repr(buf.tostring())
[0 1 0 0] '\x00\x01\x00\x00'

In [11]: arr2 = numpy.array([0], dtype='i') # one int, for output

In [12]: print arr2
[0]

In [13]: p = MPI.INT.Unpack_external('external32', buf, 0, arr2)

In [14]: print arr2
[65536]

In [15]: print arr2.byteswap()
[256]


--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594