Re: [OMPI users] 'AINT' undeclared

2016-05-09 Thread Gilles Gouaillardet

Hi,


i was able to build openmpi 1.10.2 with the same configure command line 
(after i quoted the LDFLAGS parameters)



can you please run

grep SIZEOF_PTRDIFF_T config.status


it should be 4 or 8, but it seems different in your environment (!)


are you running 32 or 64 bit kernel ? on which processor ?


Cheers,


Gilles


On 5/10/2016 1:41 AM, Ilias Miroslav wrote:


Greetings,


I am trying to install OpenMPI 1.10.1/1.10.2 with gcc (GCC) 5.2.1 
20150902 (Red Hat 5.2.1-2) statically,



$ ./configure --prefix=/home/ilias/bin/openmpi-1.10.1_gnu_static 
CXX=g++ CC=gcc F77=gfortran FC=gfortran LDFLAGS=--static -ldl -lrt 
--disable-shared --enable-static --disable-vt


However, I am getting this error below. Any help, please ? Am I 
missing something in my GNU installation ?




make[2]: Entering directory 
`/home/ilias/bin/openmpi-1.10.1_gnu_static/openmpi-1.10.2/ompi/datatype'

  CC   ompi_datatype_args.lo
  CC   ompi_datatype_create.lo
  CC   ompi_datatype_create_contiguous.lo
  CC   ompi_datatype_create_indexed.lo
  CC   ompi_datatype_create_struct.lo
  CC   ompi_datatype_create_vector.lo
  CC   ompi_datatype_create_darray.lo
  CC   ompi_datatype_create_subarray.lo
  CC   ompi_datatype_external32.lo
  CC   ompi_datatype_match_size.lo
  CC   ompi_datatype_module.lo
  CC   ompi_datatype_sndrcv.lo
ompi_datatype_module.c:280:44: warning: implicit declaration of 
function 'OMPI_DATATYPE_INIT_UNAVAILABLE_BASIC_TYPE' 
[-Wimplicit-function-declaration]
 ompi_predefined_datatype_t ompi_mpi_aint = 
OMPI_DATATYPE_INIT_UNAVAILABLE_BASIC_TYPE(INT64_T, AINT, 
OMPI_DATATYPE_FLAG_DATA_C | OMPI_DATATYPE_FLAG_DATA_INT);

^
ompi_datatype_module.c:280:86: error: 'INT64_T' undeclared here (not 
in a function)
 ompi_predefined_datatype_t ompi_mpi_aint = 
OMPI_DATATYPE_INIT_UNAVAILABLE_BASIC_TYPE(INT64_T, AINT, 
OMPI_DATATYPE_FLAG_DATA_C | OMPI_DATATYPE_FLAG_DATA_INT);

^
ompi_datatype_module.c:280:95: error: 'AINT' undeclared here (not in a 
function)
 ompi_predefined_datatype_t ompi_mpi_aint = 
OMPI_DATATYPE_INIT_UNAVAILABLE_BASIC_TYPE(INT64_T, AINT, 
OMPI_DATATYPE_FLAG_DATA_C | OMPI_DATATYPE_FLAG_DATA_INT);

 ^
make[2]: *** [ompi_datatype_module.lo] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory 
`/home/ilias/bin/openmpi-1.10.1_gnu_static/openmpi-1.10.2/ompi/datatype'

make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/ilias/bin/openmpi-1.10.1_gnu_static/openmpi-1.10.2/ompi'

make: *** [all-recursive] Error 1
il...@grid.ui.savba.sk:~/bin/openmpi-1.10.1_gnu_static/openmpi-1.10.2/.


M.




___
users mailing list
us...@open-mpi.org
Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post: 
http://www.open-mpi.org/community/lists/users/2016/05/29142.php




Re: [OMPI users] Incorrect function call in simple C program

2016-05-09 Thread Gilles Gouaillardet
Devon,

send() is a libc function that is used internally by Open MPI, and it uses
your user function instead of the libc ne.
simply rename your function mysend() or something else that is not used by
libc, and your issue will likely be fixed

Cheers,

Gilles

On Tuesday, May 10, 2016, Devon Hollowood  wrote:

> Hello,
>
> I am having trouble understanding why I am getting an error when running
> the program produced by the attached C file. In this file, there are three
> short functions: send(), bounce() and main(). send() and bounce() both use
> MPI_Send() and MPI_Recv(), but critically, neither one is called from
> main(), so as I understand it, neither function should ever be run. main()
> is just:
>
> int main(int argc, char *argv[]) {
>> int rank;
>>
>> MPI_Init(&argc, &argv);
>> MPI_Comm_rank(MPI_COMM_WORLD, &rank);
>>
>> MPI_Finalize();
>> }
>>
>
> Despite the fact that the program should never enter send() or bounce(),
> when I compile with
>
> mpicc mpi-issue.c -o mpi-issue
>>
>
> and run with
>
> mpirun -n 2 --verbose ./mpi-issue
>>
>
> I get the following:
>
> *** An error occurred in MPI_Send
>> *** on a NULL communicator
>> *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
>> ***and potentially your MPI job)
>> [dhcp-visitor-enr-117-111.slac.stanford.edu:99119] Local abort before
>> MPI_INIT completed successfully; not able to aggregate error messages, and
>> not able to guarantee that all other processes were killed!
>> ---
>> Primary job  terminated normally, but 1 process returned
>> a non-zero exit code.. Per user-direction, the job has been aborted.
>> ---
>> --
>> mpirun detected that one or more processes exited with non-zero status,
>> thus causing
>> the job to be terminated. The first process to do so was:
>>
>>   Process name: [[2829,1],0]
>>   Exit code:1
>> --
>>
>>
>
> How is it possible to be getting an error in MPI_Send(), if MPI_Send()
> never gets run?
>
> I am running open-mpi 1.10.2, installed via the Homebrew open-mpi package,
> and this is running on my Macbook, which is running OSX Yosemite. I have
> attached the results of ompi_info --all as ompi_info.txt.bz2
>
> Any help would be appreciated! Sorry if this is a newb question and I am
> missing something obvious--I tried my best to search for this issue but I
> couldn't find anything.
>
> -Devon
>


[OMPI users] Incorrect function call in simple C program

2016-05-09 Thread Devon Hollowood
Hello,

I am having trouble understanding why I am getting an error when running
the program produced by the attached C file. In this file, there are three
short functions: send(), bounce() and main(). send() and bounce() both use
MPI_Send() and MPI_Recv(), but critically, neither one is called from
main(), so as I understand it, neither function should ever be run. main()
is just:

int main(int argc, char *argv[]) {
> int rank;
>
> MPI_Init(&argc, &argv);
> MPI_Comm_rank(MPI_COMM_WORLD, &rank);
>
> MPI_Finalize();
> }
>

Despite the fact that the program should never enter send() or bounce(),
when I compile with

mpicc mpi-issue.c -o mpi-issue
>

and run with

mpirun -n 2 --verbose ./mpi-issue
>

I get the following:

*** An error occurred in MPI_Send
> *** on a NULL communicator
> *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
> ***and potentially your MPI job)
> [dhcp-visitor-enr-117-111.slac.stanford.edu:99119] Local abort before
> MPI_INIT completed successfully; not able to aggregate error messages, and
> not able to guarantee that all other processes were killed!
> ---
> Primary job  terminated normally, but 1 process returned
> a non-zero exit code.. Per user-direction, the job has been aborted.
> ---
> --
> mpirun detected that one or more processes exited with non-zero status,
> thus causing
> the job to be terminated. The first process to do so was:
>
>   Process name: [[2829,1],0]
>   Exit code:1
> --
>
>

How is it possible to be getting an error in MPI_Send(), if MPI_Send()
never gets run?

I am running open-mpi 1.10.2, installed via the Homebrew open-mpi package,
and this is running on my Macbook, which is running OSX Yosemite. I have
attached the results of ompi_info --all as ompi_info.txt.bz2

Any help would be appreciated! Sorry if this is a newb question and I am
missing something obvious--I tried my best to search for this issue but I
couldn't find anything.

-Devon
#include "mpi.h"
#include 
#include 


void send(int msg_len, int partner) {
// initialize buffer
unsigned char *buffer =
(unsigned char *)malloc(msg_len * sizeof(unsigned char));
for(int i = 0; i < msg_len; ++i) {
buffer[i] = i % 256;
}

// time bounce
double start_t = MPI_Wtime();
MPI_Send(buffer, msg_len, MPI_UNSIGNED_CHAR, partner, msg_len,
MPI_COMM_WORLD);
MPI_Recv(buffer, msg_len, MPI_UNSIGNED_CHAR, partner, msg_len,
MPI_COMM_WORLD, MPI_STATUS_IGNORE);
double end_t = MPI_Wtime();

free(buffer);
double time_taken = end_t - start_t;
printf("%d: %e\n", msg_len, time_taken);
}

void bounce(int msg_len, int partner) {
unsigned char *buffer = (unsigned char *) malloc(msg_len);
MPI_Recv(buffer, msg_len, MPI_UNSIGNED_CHAR, partner, msg_len,
MPI_COMM_WORLD, MPI_STATUS_IGNORE);
MPI_Send(buffer, msg_len, MPI_UNSIGNED_CHAR, partner, msg_len,
MPI_COMM_WORLD);
free(buffer);
}


int main(int argc, char *argv[]) {
int rank;

MPI_Init(&argc, &argv);
MPI_Comm_rank(MPI_COMM_WORLD, &rank);

MPI_Finalize();
}


ompi_info.txt.bz2
Description: BZip2 compressed data


Re: [OMPI users] No core dump in some cases

2016-05-09 Thread dpchoudh .
Hi Gus

Thanks for your suggestion. But I am not using any resource manager (i.e. I
am launching mpirun from the bash shell.). In fact, both of the two
clusters I talked about run CentOS 7 and I launch the job the same way on
both of these, yet one of them creates standard core files and the other
creates the 'btr; files. Strange thing is, I could not find anything on the
.btr (= Backtrace?) files on Google, which is any I asked on this forum.

Best regards
Durga

The surgeon general advises you to eat right, exercise regularly and quit
ageing.

On Mon, May 9, 2016 at 12:04 PM, Gus Correa  wrote:

> Hi Durga
>
> Just in case ...
> If you're using a resource manager to start the jobs (Torque, etc),
> you need to have them set the limits (for coredump size, stacksize, locked
> memory size, etc).
> This way the jobs will inherit the limits from the
> resource manager daemon.
> On Torque (which I use) I do this on the pbs_mom daemon
> init script (I am still before the systemd era, that lovely POS).
> And set the hard/soft limits on /etc/security/limits.conf as well.
>
> I hope this helps,
> Gus Correa
>
> On 05/07/2016 12:27 PM, Jeff Squyres (jsquyres) wrote:
>
>> I'm afraid I don't know what a .btr file is -- that is not something that
>> is controlled by Open MPI.
>>
>> You might want to look into your OS settings to see if it has some kind
>> of alternate corefile mechanism...?
>>
>>
>> On May 6, 2016, at 8:58 PM, dpchoudh .  wrote:
>>>
>>> Hello all
>>>
>>> I run MPI jobs (for test purpose only) on two different 'clusters'. Both
>>> 'clusters' have two nodes only, connected back-to-back. The two are very
>>> similar, but not identical, both software and hardware wise.
>>>
>>> Both have ulimit -c set to unlimited. However, only one of the two
>>> creates core files when an MPI job crashes. The other creates a text file
>>> named something like
>>>
>>> .80s-,.btr
>>>
>>> I'd much prefer a core file because that allows me to debug with a lot
>>> more options than a static text file with addresses. How do I get a core
>>> file in all situations? I am using MPI source from the master branch.
>>>
>>> Thanks in advance
>>> Durga
>>>
>>> The surgeon general advises you to eat right, exercise regularly and
>>> quit ageing.
>>> ___
>>> users mailing list
>>> us...@open-mpi.org
>>> Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users
>>> Link to this post:
>>> http://www.open-mpi.org/community/lists/users/2016/05/29124.php
>>>
>>
>>
>>
> ___
> users mailing list
> us...@open-mpi.org
> Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post:
> http://www.open-mpi.org/community/lists/users/2016/05/29141.php
>


Re: [OMPI users] mpirun command won't run unless the firewalld daemon is disabled

2016-05-09 Thread dpchoudh .
Hello Llolsten

Is there a specific reason you run as root? This practice is discouraged,
isn't it?

Also, isn't it true that OMPI uses ephemeral (i.e. 'user level, randomly
chosen') ports for TCP transport? In that case, how did this ever worked
with a firewall enabled?

I have, in the past, have faced similar situations, thus I am curious to
know the answer as well.

Thanks
Durga

The surgeon general advises you to eat right, exercise regularly and quit
ageing.

On Mon, May 9, 2016 at 2:31 PM, Llolsten Kaonga  wrote:

> Hello all,
>
>
>
> We’ve been running openmpi for a long time and up to version 1.8.2 and
> CentOS 6.7 with commands such as the one below:
>
>
>
> usr/local/bin/mpirun --allow-run-as-root --mca btl openib,self,sm --mca
> pml ob1 -np 2 -np 8 -hostfile /root/mpi-hosts /usr/local/bin/IMB-MPI1
>
>
>
> To be able to run the above command, we normally just disabled the IPv4
> firewall and SELinux.
>
>
>
> We recently made the following updates:
>
>
>
> OS: CentOS 7.2
>
> IMB:  4.1
>
> OpenMPI: 1.10.2
>
>
>
> When we tried to execute the above mpirun command, we got a TCP Broken
> Pipe error. There was no IP assignment conflict and eventually, we narrowed
> down the problem to the firewall. Disabling the firewalld daemon allows the
> command to run to completion. We would prefer not to disable the daemon as
> our servers may sometimes be connected to the rest of our subnet.
>
>
>
> Are there other options such as perhaps specifying a port (I am guessing,
> so specific instructions will be greatly appreciated).
>
>
>
> I thank you.
>
> ___
> users mailing list
> us...@open-mpi.org
> Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post:
> http://www.open-mpi.org/community/lists/users/2016/05/29143.php
>


[OMPI users] mpirun command won't run unless the firewalld daemon is disabled

2016-05-09 Thread Llolsten Kaonga
Hello all,



We've been running openmpi for a long time and up to version 1.8.2 and
CentOS 6.7 with commands such as the one below:



usr/local/bin/mpirun --allow-run-as-root --mca btl openib,self,sm --mca pml
ob1 -np 2 -np 8 -hostfile /root/mpi-hosts /usr/local/bin/IMB-MPI1



To be able to run the above command, we normally just disabled the IPv4
firewall and SELinux.



We recently made the following updates:



OS: CentOS 7.2

IMB:  4.1

OpenMPI: 1.10.2



When we tried to execute the above mpirun command, we got a TCP Broken Pipe
error. There was no IP assignment conflict and eventually, we narrowed down
the problem to the firewall. Disabling the firewalld daemon allows the
command to run to completion. We would prefer not to disable the daemon as
our servers may sometimes be connected to the rest of our subnet.



Are there other options such as perhaps specifying a port (I am guessing, so
specific instructions will be greatly appreciated).



I thank you.



[OMPI users] 'AINT' undeclared

2016-05-09 Thread Ilias Miroslav
Greetings,


I am trying to install OpenMPI 1.10.1/1.10.2 with gcc (GCC) 5.2.1 20150902 (Red 
Hat 5.2.1-2) statically,


$ ./configure --prefix=/home/ilias/bin/openmpi-1.10.1_gnu_static CXX=g++ CC=gcc 
F77=gfortran FC=gfortran LDFLAGS=--static -ldl -lrt --disable-shared 
--enable-static --disable-vt

However, I am getting this error below. Any help, please ? Am I missing 
something in my GNU installation ?



make[2]: Entering directory 
`/home/ilias/bin/openmpi-1.10.1_gnu_static/openmpi-1.10.2/ompi/datatype'
  CC   ompi_datatype_args.lo
  CC   ompi_datatype_create.lo
  CC   ompi_datatype_create_contiguous.lo
  CC   ompi_datatype_create_indexed.lo
  CC   ompi_datatype_create_struct.lo
  CC   ompi_datatype_create_vector.lo
  CC   ompi_datatype_create_darray.lo
  CC   ompi_datatype_create_subarray.lo
  CC   ompi_datatype_external32.lo
  CC   ompi_datatype_match_size.lo
  CC   ompi_datatype_module.lo
  CC   ompi_datatype_sndrcv.lo
ompi_datatype_module.c:280:44: warning: implicit declaration of function 
'OMPI_DATATYPE_INIT_UNAVAILABLE_BASIC_TYPE' [-Wimplicit-function-declaration]
 ompi_predefined_datatype_t ompi_mpi_aint = 
OMPI_DATATYPE_INIT_UNAVAILABLE_BASIC_TYPE(INT64_T, AINT, 
OMPI_DATATYPE_FLAG_DATA_C | OMPI_DATATYPE_FLAG_DATA_INT);
^
ompi_datatype_module.c:280:86: error: 'INT64_T' undeclared here (not in a 
function)
 ompi_predefined_datatype_t ompi_mpi_aint = 
OMPI_DATATYPE_INIT_UNAVAILABLE_BASIC_TYPE(INT64_T, AINT, 
OMPI_DATATYPE_FLAG_DATA_C | OMPI_DATATYPE_FLAG_DATA_INT);

  ^
ompi_datatype_module.c:280:95: error: 'AINT' undeclared here (not in a function)
 ompi_predefined_datatype_t ompi_mpi_aint = 
OMPI_DATATYPE_INIT_UNAVAILABLE_BASIC_TYPE(INT64_T, AINT, 
OMPI_DATATYPE_FLAG_DATA_C | OMPI_DATATYPE_FLAG_DATA_INT);

   ^
make[2]: *** [ompi_datatype_module.lo] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory 
`/home/ilias/bin/openmpi-1.10.1_gnu_static/openmpi-1.10.2/ompi/datatype'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/ilias/bin/openmpi-1.10.1_gnu_static/openmpi-1.10.2/ompi'
make: *** [all-recursive] Error 1
il...@grid.ui.savba.sk:~/bin/openmpi-1.10.1_gnu_static/openmpi-1.10.2/.


M.




Re: [OMPI users] No core dump in some cases

2016-05-09 Thread Gus Correa

Hi Durga

Just in case ...
If you're using a resource manager to start the jobs (Torque, etc),
you need to have them set the limits (for coredump size, stacksize, 
locked memory size, etc).

This way the jobs will inherit the limits from the
resource manager daemon.
On Torque (which I use) I do this on the pbs_mom daemon
init script (I am still before the systemd era, that lovely POS).
And set the hard/soft limits on /etc/security/limits.conf as well.

I hope this helps,
Gus Correa

On 05/07/2016 12:27 PM, Jeff Squyres (jsquyres) wrote:

I'm afraid I don't know what a .btr file is -- that is not something that is 
controlled by Open MPI.

You might want to look into your OS settings to see if it has some kind of 
alternate corefile mechanism...?



On May 6, 2016, at 8:58 PM, dpchoudh .  wrote:

Hello all

I run MPI jobs (for test purpose only) on two different 'clusters'. Both 
'clusters' have two nodes only, connected back-to-back. The two are very 
similar, but not identical, both software and hardware wise.

Both have ulimit -c set to unlimited. However, only one of the two creates core 
files when an MPI job crashes. The other creates a text file named something 
like
.80s-,.btr

I'd much prefer a core file because that allows me to debug with a lot more 
options than a static text file with addresses. How do I get a core file in all 
situations? I am using MPI source from the master branch.

Thanks in advance
Durga

The surgeon general advises you to eat right, exercise regularly and quit 
ageing.
___
users mailing list
us...@open-mpi.org
Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post: 
http://www.open-mpi.org/community/lists/users/2016/05/29124.php







Re: [OMPI users] Isend, Recv and Test

2016-05-09 Thread Zhen Wang
Jeff,

Thanks for the explanation. It's very clear.

Best regards,
Zhen

On Mon, May 9, 2016 at 10:19 AM, Jeff Squyres (jsquyres)  wrote:

> On May 9, 2016, at 8:23 AM, Zhen Wang  wrote:
> >
> > I have another question. I thought MPI_Test is a local call, meaning it
> doesn't send/receive message. Am I misunderstanding something? Thanks again.
>
> From the user's perspective, MPI_TEST is a local call, in that it checks
> to see if an MPI_Request has completed.  It is also defined to return
> "immediately", which most MPI implementations -- Open MPI included --
> interpret to mean "return in a short, finite time."
>
> In Open MPI's case, MPI_TEST (and friends) run through the internal
> progression engine. I.e., it checks the status of ongoing MPI_Requests and
> sees if it can advance them in a non-blocking manner.  For example, a
> socket may have [partially] drained since the last time through the
> progression engine, and therefore we can write new bytes down that socket
> without blocking.
>
> In your case, if you MPI_ISEND a very large message, and it uses the TCP
> BTL as the transport, it'll likely try to send the first fragment of that
> message to the peer.  When the peer ACKs that first fragment, that gives
> the sender permission to send the remaining fragments (i.e., the receiver
> is ready for the entire message).  Hence, each time through the progression
> engine, the sender will write as many bytes as possible down the socket to
> that peer until the entire message has been written.
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> ___
> users mailing list
> us...@open-mpi.org
> Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post:
> http://www.open-mpi.org/community/lists/users/2016/05/29139.php
>


Re: [OMPI users] Isend, Recv and Test

2016-05-09 Thread Jeff Squyres (jsquyres)
On May 9, 2016, at 8:23 AM, Zhen Wang  wrote:
> 
> I have another question. I thought MPI_Test is a local call, meaning it 
> doesn't send/receive message. Am I misunderstanding something? Thanks again.

>From the user's perspective, MPI_TEST is a local call, in that it checks to 
>see if an MPI_Request has completed.  It is also defined to return 
>"immediately", which most MPI implementations -- Open MPI included -- 
>interpret to mean "return in a short, finite time."

In Open MPI's case, MPI_TEST (and friends) run through the internal progression 
engine. I.e., it checks the status of ongoing MPI_Requests and sees if it can 
advance them in a non-blocking manner.  For example, a socket may have 
[partially] drained since the last time through the progression engine, and 
therefore we can write new bytes down that socket without blocking.

In your case, if you MPI_ISEND a very large message, and it uses the TCP BTL as 
the transport, it'll likely try to send the first fragment of that message to 
the peer.  When the peer ACKs that first fragment, that gives the sender 
permission to send the remaining fragments (i.e., the receiver is ready for the 
entire message).  Hence, each time through the progression engine, the sender 
will write as many bytes as possible down the socket to that peer until the 
entire message has been written.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [OMPI users] Isend, Recv and Test

2016-05-09 Thread Zhen Wang
Jeff,

I have another question. I thought MPI_Test is a local call, meaning it
doesn't send/receive message. Am I misunderstanding something? Thanks again.

Best regards,
Zhen

On Thu, May 5, 2016 at 9:45 PM, Jeff Squyres (jsquyres) 
wrote:

> It's taking so long because you are sleeping for .1 second between calling
> MPI_Test().
>
> The TCP transport is only sending a few fragments of your message during
> each iteration through MPI_Test (because, by definition, it has to return
> "immediately").  Other transports do better handing off large messages like
> this to hardware for asynchronous progress.
>
> Additionally, in the upcoming v2.0.0 release is a non-default option to
> enable an asynchronous progress thread for the TCP transport.  We're up to
> v2.0.0rc2; you can give that async TCP support a whirl, if you want.  Pass
> "--mca btl_tcp_progress_thread 1" on the mpirun command line to enable the
> TCP progress thread to try it.
>
>
> > On May 4, 2016, at 7:40 PM, Zhen Wang  wrote:
> >
> > Hi,
> >
> > I'm having a problem with Isend, Recv and Test in Linux Mint 16 Petra.
> The source is attached.
> >
> > Open MPI 1.10.2 is configured with
> > ./configure --enable-debug --prefix=/home//Tool/openmpi-1.10.2-debug
> >
> > The source is built with
> > ~/Tool/openmpi-1.10.2-debug/bin/mpiCC a5.cpp
> >
> > and run in one node with
> > ~/Tool/openmpi-1.10.2-debug/bin/mpirun -n 2 ./a.out
> >
> > The output is in the end. What puzzles me is why MPI_Test is called so
> many times, and it takes so long to send a message. Am I doing something
> wrong? I'm simulating a more complicated program: MPI 0 Isends data to MPI
> 1, computes (usleep here), and calls Test to check if data are sent. MPI 1
> Recvs data, and computes.
> >
> > Thanks in advance.
> >
> >
> > Best regards,
> > Zhen
> >
> > MPI 0: Isend of 0 started at 20:32:35.
> > MPI 1: Recv of 0 started at 20:32:35.
> > MPI 0: MPI_Test of 0 at 20:32:35.
> > MPI 0: MPI_Test of 0 at 20:32:35.
> > MPI 0: MPI_Test of 0 at 20:32:35.
> > MPI 0: MPI_Test of 0 at 20:32:35.
> > MPI 0: MPI_Test of 0 at 20:32:35.
> > MPI 0: MPI_Test of 0 at 20:32:35.
> > MPI 0: MPI_Test of 0 at 20:32:36.
> > MPI 0: MPI_Test of 0 at 20:32:36.
> > MPI 0: MPI_Test of 0 at 20:32:36.
> > MPI 0: MPI_Test of 0 at 20:32:36.
> > MPI 0: MPI_Test of 0 at 20:32:36.
> > MPI 0: MPI_Test of 0 at 20:32:36.
> > MPI 0: MPI_Test of 0 at 20:32:36.
> > MPI 0: MPI_Test of 0 at 20:32:36.
> > MPI 0: MPI_Test of 0 at 20:32:36.
> > MPI 0: MPI_Test of 0 at 20:32:37.
> > MPI 0: MPI_Test of 0 at 20:32:37.
> > MPI 0: MPI_Test of 0 at 20:32:37.
> > MPI 0: MPI_Test of 0 at 20:32:37.
> > MPI 0: MPI_Test of 0 at 20:32:37.
> > MPI 0: MPI_Test of 0 at 20:32:37.
> > MPI 0: MPI_Test of 0 at 20:32:37.
> > MPI 0: MPI_Test of 0 at 20:32:37.
> > MPI 0: MPI_Test of 0 at 20:32:37.
> > MPI 0: MPI_Test of 0 at 20:32:37.
> > MPI 0: MPI_Test of 0 at 20:32:38.
> > MPI 0: MPI_Test of 0 at 20:32:38.
> > MPI 0: MPI_Test of 0 at 20:32:38.
> > MPI 0: MPI_Test of 0 at 20:32:38.
> > MPI 0: MPI_Test of 0 at 20:32:38.
> > MPI 0: MPI_Test of 0 at 20:32:38.
> > MPI 0: MPI_Test of 0 at 20:32:38.
> > MPI 0: MPI_Test of 0 at 20:32:38.
> > MPI 0: MPI_Test of 0 at 20:32:38.
> > MPI 0: MPI_Test of 0 at 20:32:38.
> > MPI 0: MPI_Test of 0 at 20:32:39.
> > MPI 0: MPI_Test of 0 at 20:32:39.
> > MPI 0: MPI_Test of 0 at 20:32:39.
> > MPI 0: MPI_Test of 0 at 20:32:39.
> > MPI 0: MPI_Test of 0 at 20:32:39.
> > MPI 0: MPI_Test of 0 at 20:32:39.
> > MPI 1: Recv of 0 finished at 20:32:39.
> > MPI 0: MPI_Test of 0 at 20:32:39.
> > MPI 0: Isend of 0 finished at 20:32:39.
> >
> > ___
> > users mailing list
> > us...@open-mpi.org
> > Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users
> > Link to this post:
> http://www.open-mpi.org/community/lists/users/2016/05/29085.php
>
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> ___
> users mailing list
> us...@open-mpi.org
> Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post:
> http://www.open-mpi.org/community/lists/users/2016/05/29105.php
>


Re: [OMPI users] Segmentation Fault (Core Dumped) on mpif90 -v

2016-05-09 Thread Giacomo Rossi
I've send you all the outputs from configure, make and make install
commands...

Today I've compiled openmpi with the latest gcc version (6.1.1) shipped
with my archlinux distro and everything seems ok, so I think that the
problem is with intel compiler.

Giacomo Rossi Ph.D., Space Engineer

Research Fellow at Dept. of Mechanical and Aerospace Engineering, "Sapienza"
University of Rome
*p: *(+39) 0692927207 | *m**: *(+39) 3408816643 | *e: *giacom...@gmail.com

Member of Fortran-FOSS-programmers



2016-05-06 9:45 GMT+02:00 Giacomo Rossi :

> Yes, I've tried three simple "Hello world" programs in fortan, C and C++
> and the compile and run with intel 16.0.3. The problem is with the openmpi
> compiled from source.
>
> Giacomo Rossi Ph.D., Space Engineer
>
> Research Fellow at Dept. of Mechanical and Aerospace Engineering, "Sapienza"
> University of Rome
> *p: *(+39) 0692927207 | *m**: *(+39) 3408816643 | *e: *giacom...@gmail.com
> 
> Member of Fortran-FOSS-programmers
> 
>
>
> 2016-05-05 11:15 GMT+02:00 Giacomo Rossi :
>
>>  gdb /opt/openmpi/1.10.2/intel/16.0.3/bin/mpif90
>> GNU gdb (GDB) 7.11
>> Copyright (C) 2016 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <
>> http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-pc-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /opt/openmpi/1.10.2/intel/16.0.3/bin/mpif90...(no
>> debugging symbols found)...done.
>> (gdb) r -v
>> Starting program: /opt/openmpi/1.10.2/intel/16.0.3/bin/mpif90 -v
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x76858f38 in ?? ()
>> (gdb) bt
>> #0  0x76858f38 in ?? ()
>> #1  0x77de5828 in _dl_relocate_object () from
>> /lib64/ld-linux-x86-64.so.2
>> #2  0x77ddcfa3 in dl_main () from /lib64/ld-linux-x86-64.so.2
>> #3  0x77df029c in _dl_sysdep_start () from
>> /lib64/ld-linux-x86-64.so.2
>> #4  0x774a in _dl_start () from /lib64/ld-linux-x86-64.so.2
>> #5  0x77dd9d98 in _start () from /lib64/ld-linux-x86-64.so.2
>> #6  0x0002 in ?? ()
>> #7  0x7fffaa8a in ?? ()
>> #8  0x7fffaab6 in ?? ()
>> #9  0x in ?? ()
>>
>> Giacomo Rossi Ph.D., Space Engineer
>>
>> Research Fellow at Dept. of Mechanical and Aerospace Engineering, "Sapienza"
>> University of Rome
>> *p: *(+39) 0692927207 | *m**: *(+39) 3408816643 | *e: *
>> giacom...@gmail.com
>> 
>> Member of Fortran-FOSS-programmers
>> 
>>
>>
>> 2016-05-05 10:44 GMT+02:00 Giacomo Rossi :
>>
>>> Here the result of ldd command:
>>> 'ldd /opt/openmpi/1.10.2/intel/16.0.3/bin/mpif90
>>> linux-vdso.so.1 (0x7ffcacbbe000)
>>> libopen-pal.so.13 =>
>>> /opt/openmpi/1.10.2/intel/16.0.3/lib/libopen-pal.so.13 (0x7fa9597a9000)
>>> libm.so.6 => /usr/lib/libm.so.6 (0x7fa9594a4000)
>>> libpciaccess.so.0 => /usr/lib/libpciaccess.so.0 (0x7fa95929a000)
>>> libdl.so.2 => /usr/lib/libdl.so.2 (0x7fa959096000)
>>> librt.so.1 => /usr/lib/librt.so.1 (0x7fa958e8e000)
>>> libutil.so.1 => /usr/lib/libutil.so.1 (0x7fa958c8b000)
>>> libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7fa958a75000)
>>> libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7fa958858000)
>>> libc.so.6 => /usr/lib/libc.so.6 (0x7fa9584b7000)
>>> libimf.so =>
>>> /home/giacomo/intel/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libimf.so
>>> (0x7fa957fb9000)
>>> libsvml.so =>
>>> /home/giacomo/intel/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libsvml.so
>>> (0x7fa9570ad000)
>>> libirng.so =>
>>> /home/giacomo/intel/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libirng.so
>>> (0x7fa956d3b000)
>>> libintlc.so.5 =>
>>> /home/giacomo/intel/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64/libintlc.so.5
>>> (0x7fa956acf000)
>>> /lib64/ld-linux-x86-64.so.2 (0x7fa959ab9000)'
>>>
>>> I can't provide a core file, because I can't compile or launch any
>>> program with mpifort... I've always the error 'core dumped' also when I try
>>> to compile a program with mpifort, and of course there isn't any core file.
>>>
>>>
>>> Giacomo Rossi Ph.D., Space Engineer
>>>
>>> Research Fellow at Dept. of Mechanical and Aerospace Engineering, "Sapienza"
>>> University of Rome
>>> *p: *(+39) 0692927207 | *m**: *(+39) 3408816643 | *e: *
>>> giacom...@gmail.c