Re: [OMPI users] Java MPI and OWL API: segmentation fault

2015-02-12 Thread Riccardo Zese
I have just solved my problem by specifying
export LD_PRELOAD=libjvm.so-directory/libjsig.so;
before the call to mpirun.
In my case it missed signal chaining (
http://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/signals.html
).

2015-02-11 20:30 GMT+01:00 Jeff Squyres (jsquyres) :

> This may well be related to:
>
> https://github.com/open-mpi/ompi/issues/369
>
>
> > On Feb 10, 2015, at 9:24 AM, Riccardo Zese 
> wrote:
> >
> > Hi,
> > I'm trying to modify an old algorithm of mine in order to exploit
> parallelization and I would like to use MPI. My algorithm is written in
> Java and make use of OWL API library. I've noticed that if I try to load an
> ontology after the initialization of MPI the process ends returning signal
> 11 (segmentation fault).
> >
> > The code I've tried to test is below
> >
> > public static void main(String[] args) {
> >
> > try {
> > MPI.Init(args);
> >
> > OWLOntologyManager manager;
> > OWLOntology ontology = null;
> >
> > manager = new OWLManager().buildOWLOntologyManager();
> > String ontologyPath = "file:/path/to/file"; //This variable
> contains the correct path
> > System.out.println("Before load");
> > ontology =
> manager.loadOntologyFromOntologyDocument(IRI.create(ontologyPath));
> > System.out.println("After load");
> >
> > MPI.Finalize();
> >
> >
> >
> > } catch (MPIException | OWLOntologyCreationException ex) {
> > System.out.println(ex);
> > }
> >
> > }
> >
> >
> > Does anyone have an idea of why or where is the error?
> >
> > --
> > Riccardo Zese
> > PhD Student
> > ENDIF - Dipartimento di Ingegneria
> > Università di Ferrara
> > Via Saragat 1, I-44122,  Ferrara,  Italy
> > Tel. +39 0532974827
> > ___
> > users mailing list
> > us...@open-mpi.org
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> > Link to this post:
> http://www.open-mpi.org/community/lists/users/2015/02/26312.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: http://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post:
> http://www.open-mpi.org/community/lists/users/2015/02/26314.php




-- 
Riccardo Zese
PhD Student
ENDIF - Dipartimento di Ingegneria
Università di Ferrara
Via Saragat 1, I-44122,  Ferrara,  Italy
Tel. +39 0532974827


Re: [OMPI users] How to disable the MCA MTL setting at run time

2015-02-12 Thread Jeff Squyres (jsquyres)
Sorry for not replying earlier.

Yes, you hit on a solution.

Note, too, that the MTLs are only used by the "cm" PML, and the BTLs are only 
used by the "ob1" PML.

So if you're using the openib BTL for IB support (vs. the MXM MTL), you can 
effectively choose one or the other by setting 

OMPI_MCA_pml=ob1
or
OMPI_MCA_pml=cm

Which will force the use of ob1 or cm, and therefore force the use of the BTLs 
or MTLs, respectively.  More importantly, forcing the use of ob1/BTLs means 
that the MTLs will *not* be opened (i.e., so you won't see the MX MTL complain 
about the lack of myriexpress).

Make sense?

You probably figured out that you can set these values either in the 
environments of these machines or in machine-specific config files in the Open 
MPI installation tree. Environment is usually easier, especially if you have 
Open MPI installed in a single, common location on a networked filesystem that 
is available on all servers.

Hope that helps!



> On Feb 11, 2015, at 8:07 PM, Avalon Johnson  wrote:
> 
> 
> 
> Hi all
> 
> I have figured this out. For anyone who needs to at run time disable a single 
> item default MCA value, the solution is to set.
> 
>OMPI_MCA_mtl=^mx
>OMPI_MCA_btl=self,sm,openib,tcp
> 
> 
> as mentioned
> 
>OMPI_MCA_mtl=""
> 
> will not do the job.
> 
> Avalon Johnson
> ITS HPCC
> USC
> 
>  "It takes a village ..."
> 
> On Wed, 11 Feb 2015, Avalon Johnson wrote:
> 
>> 
>> 
>> We have a cluster which is a combination of Myrinet and Infiniband nodes.
>> 
>> We are using a common openmpi 1.8.4 software tree accessible to both set of 
>> nodes.
>> 
>> Our Infiniband nodes do NOT have the libmyriexpress.so library installed 
>> (since it is not needed).
>> Likewise the Myrinet nodes do not have the OFED libraries installed.
>> 
>> 
>> When running an MPI program on the Infiniband node, openmpi in trying to 
>> determine what transport methods are available, tries to load the 
>> libmyriexpress.so, and then complains that it is not found.
>> 
>> 
>> I would like to disable this behavior. I had hoped to use the OMPI_MCA_mtl 
>> environment variable to do this.
>> But I unable to come up with a setting that accomplishes this. That is have 
>> OMPI_MCA_btl set to 'self,sm,openib,tcp' and no MCA mtl checked or used.
>> 
>> 
>> For the equivalent problem on our Myrinet cluster I set OMPI_MCA_btl, to 
>> 'self,sm,tcp' and OMPI_MCA_mtl to 'mx'
>> 
>> Does anyone know how to disable the MCA mtl at run time, since it's not 
>> needed on the Infiniband nodes?
>> 
>> 
>> Thanks in advance.
>> 
>> My apologies if this has been addressed before,  I did not find it when 
>> searching the list.
>> 
>> 
>> Avalon Johnson ITS HPCC
>> USC
>> 
>> "It takes a village ..."
>> ___
>> users mailing list
>> us...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/users/2015/02/26315.php
>> 
> ___
> users mailing list
> us...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post: 
> http://www.open-mpi.org/community/lists/users/2015/02/26317.php


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



Re: [OMPI users] How to disable the MCA MTL setting at run time

2015-02-12 Thread Avalon Johnson


Thanks, I didn't think of going "one level up". Great to have an alternative 
solution.




Avalon Johnson
ITS HPCC
USC

  "It takes a village ..."

On Thu, 12 Feb 2015, Jeff Squyres (jsquyres) wrote:


Sorry for not replying earlier.

Yes, you hit on a solution.

Note, too, that the MTLs are only used by the "cm" PML, and the BTLs are only used by the 
"ob1" PML.

So if you're using the openib BTL for IB support (vs. the MXM MTL), you can 
effectively choose one or the other by setting

OMPI_MCA_pml=ob1
or
OMPI_MCA_pml=cm

Which will force the use of ob1 or cm, and therefore force the use of the BTLs 
or MTLs, respectively.  More importantly, forcing the use of ob1/BTLs means 
that the MTLs will *not* be opened (i.e., so you won't see the MX MTL complain 
about the lack of myriexpress).

Make sense?

You probably figured out that you can set these values either in the 
environments of these machines or in machine-specific config files in the Open 
MPI installation tree. Environment is usually easier, especially if you have 
Open MPI installed in a single, common location on a networked filesystem that 
is available on all servers.

Hope that helps!




On Feb 11, 2015, at 8:07 PM, Avalon Johnson  wrote:



Hi all

I have figured this out. For anyone who needs to at run time disable a single 
item default MCA value, the solution is to set.

   OMPI_MCA_mtl=^mx
   OMPI_MCA_btl=self,sm,openib,tcp


as mentioned

   OMPI_MCA_mtl=""

will not do the job.

Avalon Johnson
ITS HPCC
USC

 "It takes a village ..."

On Wed, 11 Feb 2015, Avalon Johnson wrote:




We have a cluster which is a combination of Myrinet and Infiniband nodes.

We are using a common openmpi 1.8.4 software tree accessible to both set of 
nodes.

Our Infiniband nodes do NOT have the libmyriexpress.so library installed (since 
it is not needed).
Likewise the Myrinet nodes do not have the OFED libraries installed.


When running an MPI program on the Infiniband node, openmpi in trying to 
determine what transport methods are available, tries to load the 
libmyriexpress.so, and then complains that it is not found.


I would like to disable this behavior. I had hoped to use the OMPI_MCA_mtl 
environment variable to do this.
But I unable to come up with a setting that accomplishes this. That is have 
OMPI_MCA_btl set to 'self,sm,openib,tcp' and no MCA mtl checked or used.


For the equivalent problem on our Myrinet cluster I set OMPI_MCA_btl, to 
'self,sm,tcp' and OMPI_MCA_mtl to 'mx'

Does anyone know how to disable the MCA mtl at run time, since it's not needed 
on the Infiniband nodes?


Thanks in advance.

My apologies if this has been addressed before,  I did not find it when 
searching the list.


Avalon Johnson ITS HPCC
USC

"It takes a village ..."
___
users mailing list
us...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post: 
http://www.open-mpi.org/community/lists/users/2015/02/26315.php


___
users mailing list
us...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post: 
http://www.open-mpi.org/community/lists/users/2015/02/26317.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: http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post: 
http://www.open-mpi.org/community/lists/users/2015/02/26319.php



[OMPI users] Fail to lock/unlock a shared memory window iteratively

2015-02-12 Thread Thibaud Kloczko
Hi all, 

Here is my problem (see attached file for more details). 

I create a window using MPI_Win_allocate_share d. 
The rank 0 is then in charge to fill iteratively the shared buffers using the 
MPI_Put function. 

At each iteration, I use also MPI_Lock and MPI_Unlock function as follows: 

MPI_Win_lock(MPI_LOCK_EXCLUSIVE, rank, MPI_MODE_NOCHECK, win); 
MPI_Put(&i, buffer_size, MPI_BYTE, rank, position, buffer_size, MPI_BYTE, win); 
MPI_Win_unlock(wid, win); 

Surprisingly, at the second iteration, I get the following error: 

Open MPI v1.8.4, package: Open MPI Distribution, ident: 1.8.4, repo rev: 
v1.8.3-330-g0344f04, Dec 19, 2014 

*** An error occurred in MPI_Win_lock 
*** reported by process [140394923687937,140393890971648] 
*** on win 
*** MPI_ERR_RMA_SYNC: error executing rma sync 
*** MPI_ERRORS_ARE_FATAL (processes in this win will now abort, 
*** and potentially your MPI job) 

I observed the same behaviour when allocating the window using MPI_Win_allocate 
function. 

On the other hand, everything works well with MPI_Win_Create . 

Am I wrong somewhere, any idea would be great :-) ! 

Cheers, 

Thibaud Kloczko. 

- 
Ingénieur d'Expérimentation et de Développement 
Inria CRISAM 
2004, route des lucioles 
06902 Sophia Antipolis 
+33 4 92 38 50 03 

// Version: $Id$
// 
// 

// Commentary: 
// 
// 

// Change Log:
// 
// 

// Code:

#include "mpi.h"
#include 

int main(int argc, char **argv)
{
MPI_Init(&argc, &argv);

int cap = 101;
int objectSize = sizeof(int);
int buffer_size = cap * objectSize;
int *array = NULL;

MPI_Win win;

MPI_Win_allocate_shared(buffer_size, objectSize, MPI_INFO_NULL, MPI_COMM_WORLD, &array, &win);

int size;
MPI_Comm_size(MPI_COMM_WORLD, &size);
int rank;
MPI_Comm_rank(MPI_COMM_WORLD, &rank);

MPI_Barrier(MPI_COMM_WORLD);
if (rank == 0) {

char version[MPI_MAX_LIBRARY_VERSION_STRING];
int len;
MPI_Get_library_version(version, &len);
std::cout << version << std::endl;

for (int i = 0; i < cap * size; ++i) {
int wid = i / cap;
std::cout << std::endl;
std::cout << "iteration " << i << " locking window"  << std::endl;
MPI_Win_lock(MPI_LOCK_EXCLUSIVE, wid, MPI_MODE_NOCHECK, win);
MPI_Put(&i, buffer_size, MPI_BYTE, wid, i%size, buffer_size, MPI_BYTE, win);
std::cout << "unlocking " << std::endl;
MPI_Win_unlock(wid, win);
}
}
MPI_Finalize();

return 0;
}

// 
// main.cpp ends here


Re: [OMPI users] Java MPI and OWL API: segmentation fault

2015-02-12 Thread Oscar Vega-Gisbert

Hi Ricardo,

Thanks for your information.
Unfortunately, your solution does not work here:
https://github.com/open-mpi/ompi/issues/369

Regards,
Oscar

El 12/02/15 a las 09:53, Riccardo Zese escribió:

I have just solved my problem by specifying
export LD_PRELOAD=libjvm.so-directory/libjsig.so;
before the call to mpirun.
In my case it missed signal chaining 
(http://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/signals.html).


2015-02-11 20:30 GMT+01:00 Jeff Squyres (jsquyres) >:


This may well be related to:

https://github.com/open-mpi/ompi/issues/369


> On Feb 10, 2015, at 9:24 AM, Riccardo Zese
mailto:riccardo.z...@unife.it>> wrote:
>
> Hi,
> I'm trying to modify an old algorithm of mine in order to
exploit parallelization and I would like to use MPI. My algorithm
is written in Java and make use of OWL API library. I've noticed
that if I try to load an ontology after the initialization of MPI
the process ends returning signal 11 (segmentation fault).
>
> The code I've tried to test is below
>
> public static void main(String[] args) {
>
> try {
> MPI.Init(args);
>
> OWLOntologyManager manager;
> OWLOntology ontology = null;
>
> manager = new OWLManager().buildOWLOntologyManager();
> String ontologyPath = "file:/path/to/file"; //This
variable contains the correct path
> System.out.println("Before load");
> ontology =
manager.loadOntologyFromOntologyDocument(IRI.create(ontologyPath));
> System.out.println("After load");
>
> MPI.Finalize();
>
>
>
> } catch (MPIException | OWLOntologyCreationException ex) {
> System.out.println(ex);
> }
>
> }
>
>
> Does anyone have an idea of why or where is the error?
>
> --
> Riccardo Zese
> PhD Student
> ENDIF - Dipartimento di Ingegneria
> Università di Ferrara
> Via Saragat 1, I-44122,  Ferrara,  Italy
> Tel. +39 0532974827 
> ___
> users mailing list
> us...@open-mpi.org 
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post:
http://www.open-mpi.org/community/lists/users/2015/02/26312.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: http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post:
http://www.open-mpi.org/community/lists/users/2015/02/26314.php




--
Riccardo Zese
PhD Student
ENDIF - Dipartimento di Ingegneria
Università di Ferrara
Via Saragat 1, I-44122,  Ferrara,  Italy
Tel. +39 0532974827


___
users mailing list
us...@open-mpi.org
Subscription:http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this 
post:http://www.open-mpi.org/community/lists/users/2015/02/26318.php




Re: [OMPI users] Fail to lock/unlock a shared memory window iteratively

2015-02-12 Thread Nathan Hjelm

There was a bug in the MPI_MODE_NOCHECK path in osc/sm. It has been
fixed on master and a fix has been CMRed to 1.8. Thank you for reporting
this.

In the meantime you can remove MPI_MODE_NOCHECK and it should work
fine.

-Nathan

On Thu, Feb 12, 2015 at 11:10:59PM +0100, Thibaud Kloczko wrote:
>Hi all,
>Here is my problem (see attached file for more details).
>I create a window using MPI_Win_allocate_shared.
>The rank 0 is then in charge to fill iteratively the shared buffers using
>the MPI_Put function.
>At each iteration, I use also MPI_Lock and MPI_Unlock function as follows:
>MPI_Win_lock(MPI_LOCK_EXCLUSIVE, rank, MPI_MODE_NOCHECK, win);
>MPI_Put(&i, buffer_size, MPI_BYTE, rank, position, buffer_size, MPI_BYTE,
>win);
>MPI_Win_unlock(wid, win);
>Surprisingly, at the second iteration, I get the following error:
>Open MPI v1.8.4, package: Open MPI Distribution, ident: 1.8.4, repo rev:
>v1.8.3-330-g0344f04, Dec 19, 2014
>*** An error occurred in MPI_Win_lock
>*** reported by process [140394923687937,140393890971648]
>*** on win
>*** MPI_ERR_RMA_SYNC: error executing rma sync
>*** MPI_ERRORS_ARE_FATAL (processes in this win will now abort,
>***and potentially your MPI job)
>I observed the same behaviour when allocating the window using
>MPI_Win_allocate function.
>On the other hand, everything works well with MPI_Win_Create.
>Am I wrong somewhere, any idea would be great :-) !
>Cheers,
>Thibaud Kloczko.
>-
>Ingenieur d'Experimentation et de Developpement
>Inria CRISAM
>2004, route des lucioles
>06902 Sophia Antipolis
>+33 4 92 38 50 03

> // Version: $Id$
> // 
> // 
> 
> // Commentary: 
> // 
> // 
> 
> // Change Log:
> // 
> // 
> 
> // Code:
> 
> #include "mpi.h"
> #include 
> 
> int main(int argc, char **argv)
> {
> MPI_Init(&argc, &argv);
> 
> int cap = 101;
> int objectSize = sizeof(int);
> int buffer_size = cap * objectSize;
> int *array = NULL;
> 
> MPI_Win win;
> 
> MPI_Win_allocate_shared(buffer_size, objectSize, MPI_INFO_NULL, 
> MPI_COMM_WORLD, &array, &win);
> 
> int size;
> MPI_Comm_size(MPI_COMM_WORLD, &size);
> int rank;
> MPI_Comm_rank(MPI_COMM_WORLD, &rank);
> 
> MPI_Barrier(MPI_COMM_WORLD);
> if (rank == 0) {
> 
> char version[MPI_MAX_LIBRARY_VERSION_STRING];
> int len;
> MPI_Get_library_version(version, &len);
> std::cout << version << std::endl;
> 
> for (int i = 0; i < cap * size; ++i) {
> int wid = i / cap;
> std::cout << std::endl;
> std::cout << "iteration " << i << " locking window"  << std::endl;
> MPI_Win_lock(MPI_LOCK_EXCLUSIVE, wid, MPI_MODE_NOCHECK, win);
> MPI_Put(&i, buffer_size, MPI_BYTE, wid, i%size, buffer_size, 
> MPI_BYTE, win);
> std::cout << "unlocking " << std::endl;
> MPI_Win_unlock(wid, win);
> }
> }
> MPI_Finalize();
> 
> return 0;
> }
> 
> // 
> // main.cpp ends here

> ___
> users mailing list
> us...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
> Link to this post: 
> http://www.open-mpi.org/community/lists/users/2015/02/26321.php



pgpcuhcYbv1UU.pgp
Description: PGP signature