date:20160210

Re: [OMPI users] shared memory zero size segment

2016-02-10 Thread Gilles Gouaillardet

I think Peter's point is that if
- the windows uses contiguous memory
*and*
- all tasks knows how much memory was allocated by all other tasks in the
window
then it could/should be possible to get rid of MPI_Win_shared_query

that is likely true if no task allocates zero byte.
now, if a task allocates zero byte, MPI_Win_allocate_shared could return a
null pointer and hence makes MPI_Win_shared_query usage mandatory.

in his example, task 0 allocates zero bytes, so he was expecting the
returned pointer on task zero points to the memory allocated by task 1.

if "may enable" should be read as "does enable", then returning a null
pointer can be seen as a bug.
if "may enable" can be read as "does not always enable", the returning a
null pointer is compliant with the standard.

I am clearly not good at reading/interpreting the standard, so using
MPI_Win_shared_query is my recommended way to get it work.
(feel free to call it "bulletproof",  "overkill", or even "right")

Cheers,

Gilles

On Thursday, February 11, 2016, Jeff Hammond  wrote:

>
>
> On Wed, Feb 10, 2016 at 8:44 AM, Peter Wind  > wrote:
>
>> I agree that in practice the best practice would be to use
>> Win_shared_query.
>>
>> Still I am confused by this part in the documentation:
>> "The allocated memory is contiguous across process ranks unless the info
>> key *alloc_shared_noncontig* is specified. Contiguous across process
>> ranks means that the first address in the memory segment of process i is
>> consecutive with the last address in the memory segment of process i - 1.
>> This may enable the user to calculate remote address offsets with local
>> information only."
>>
>> Isn't this an encouragement to use the pointer of Win_allocate_shared
>> directly?
>>
>>
> No, it is not.  Win_allocate_shared only gives you the pointer to the
> portion of the allocation that is owned by the calling process.  If you
> want to access the whole slab, call Win_shared_query(..,rank=0,..) and use
> the resulting baseptr.
>
> I attempted to modify your code to be more correct, but I don't know
> enough Fortran to get it right.  If you can parse C examples, I'll provide
> some of those.
>
> Jeff
>
>
>> Peter
>>
>> --
>>
>> I don't know about bulletproof, but Win_shared_query is the *only* valid
>> way to get the addresses of memory in other processes associated with a
>> window.
>>
>> The default for Win_allocate_shared is contiguous memory, but it can and
>> likely will be mapped differently into each process, in which case only
>> relative offsets are transferrable.
>>
>> Jeff
>>
>> On Wed, Feb 10, 2016 at 4:19 AM, Gilles Gouaillardet <
>> gilles.gouaillar...@gmail.com
>> > wrote:
>>
>>> Peter,
>>>
>>> The bulletproof way is to use MPI_Win_shared_query after
>>> MPI_Win_allocate_shared.
>>> I do not know if current behavior is a bug or a feature...
>>>
>>> Cheers,
>>>
>>> Gilles
>>>
>>>
>>> On Wednesday, February 10, 2016, Peter Wind >> > wrote:
>>>
 Hi,

 Under fortran, MPI_Win_allocate_shared is called with a window size of
 zero for some processes.
 The output pointer is then not valid for these processes (null pointer).
 Did I understood this wrongly? shouldn't the pointers be contiguous, so
 that for a zero sized window, the pointer should point to the start of the
 segment of the next rank?
 The documentation explicitly specifies "size = 0 is valid".

 Attached a small code, where rank=0 allocate a window of size zero. All
 the other ranks get valid pointers, except rank 0.

 Best regards,
 Peter
 ___
 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/2016/02/28485.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/2016/02/28493.php
>>>
>>
>>
>>
>> --
>> Jeff Hammond
>> jeff.scie...@gmail.com
>> 
>> http://jeffhammond.github.io/
>>
>> ___
>> 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/2016/02/28496.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/2016/02/28497.php
>>
>
>
>
> --
> Jeff Hammond
> jeff.scie...@gmail.com
> 
> http://jeffhammond.github.io/
>

Re: [OMPI users] shared memory zero size segment

2016-02-10 Thread Jeff Hammond

On Wed, Feb 10, 2016 at 8:44 AM, Peter Wind  wrote:

> I agree that in practice the best practice would be to use
> Win_shared_query.
>
> Still I am confused by this part in the documentation:
> "The allocated memory is contiguous across process ranks unless the info
> key *alloc_shared_noncontig* is specified. Contiguous across process
> ranks means that the first address in the memory segment of process i is
> consecutive with the last address in the memory segment of process i - 1.
> This may enable the user to calculate remote address offsets with local
> information only."
>
> Isn't this an encouragement to use the pointer of Win_allocate_shared
> directly?
>
>
No, it is not.  Win_allocate_shared only gives you the pointer to the
portion of the allocation that is owned by the calling process.  If you
want to access the whole slab, call Win_shared_query(..,rank=0,..) and use
the resulting baseptr.

I attempted to modify your code to be more correct, but I don't know enough
Fortran to get it right.  If you can parse C examples, I'll provide some of
those.

Jeff


> Peter
>
> --
>
> I don't know about bulletproof, but Win_shared_query is the *only* valid
> way to get the addresses of memory in other processes associated with a
> window.
>
> The default for Win_allocate_shared is contiguous memory, but it can and
> likely will be mapped differently into each process, in which case only
> relative offsets are transferrable.
>
> Jeff
>
> On Wed, Feb 10, 2016 at 4:19 AM, Gilles Gouaillardet <
> gilles.gouaillar...@gmail.com> wrote:
>
>> Peter,
>>
>> The bulletproof way is to use MPI_Win_shared_query after
>> MPI_Win_allocate_shared.
>> I do not know if current behavior is a bug or a feature...
>>
>> Cheers,
>>
>> Gilles
>>
>>
>> On Wednesday, February 10, 2016, Peter Wind  wrote:
>>
>>> Hi,
>>>
>>> Under fortran, MPI_Win_allocate_shared is called with a window size of
>>> zero for some processes.
>>> The output pointer is then not valid for these processes (null pointer).
>>> Did I understood this wrongly? shouldn't the pointers be contiguous, so
>>> that for a zero sized window, the pointer should point to the start of the
>>> segment of the next rank?
>>> The documentation explicitly specifies "size = 0 is valid".
>>>
>>> Attached a small code, where rank=0 allocate a window of size zero. All
>>> the other ranks get valid pointers, except rank 0.
>>>
>>> Best regards,
>>> Peter
>>> ___
>>> 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/2016/02/28485.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/2016/02/28493.php
>>
>
>
>
> --
> Jeff Hammond
> jeff.scie...@gmail.com
> http://jeffhammond.github.io/
>
> ___
> 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/2016/02/28496.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/2016/02/28497.php
>



-- 
Jeff Hammond
jeff.scie...@gmail.com
http://jeffhammond.github.io/


sharetest.f90
Description: Binary data

Re: [OMPI users] a single build of Open MPI that can be used with multiple GCC versions

2016-02-10 Thread David Shrader


A bit of an update:

I was mistaken when I said users were reporting 1.10.1 was throwing an 
error. The error occurs for 1.6.5 (which I still have to keep on my 
production systems). Users report that they do not see the error with 
1.10.1.


That being said, I do see references to my GCC 5.2.0 installation in the 
/lib/*.la 1.10.1 files and would like to ask if I need to 
worry at all? It seems the way files were named and organized in 
/lib changed in 1.7 which may be why 1.10.1 is working.


Thank you very much for your time,
David

On 02/10/2016 10:58 AM, David Shrader wrote:

Hello,

Is it possible to use a single build of Open MPI against multiple 
versions of GCC if the versions of GCC are from the same release 
series? I was under the assumption that as long as a binary-compatible 
compiler was used, it was possible to "swap out" the compiler from 
underneath Open MPI.


That is the general question I have, but here is the specific scenario 
that prompted it:


  * built Open MPI 1.10.1 against GCC 5.2.0 with a directory name of
openmpi-1.10.1-gcc-5
  * installed GCC 5.3.0
  * removed GCC 5.2.0

I now have users who are getting errors like the following when using 
mpicxx:


/bin/grep: 
/usr/projects/hpcsoft/toss2/common/gcc/5.2.0/lib/../lib64/libstdc++.la: No 
such file or directory


I can see several references to my previous GCC 5.2.0 installation in 
the /lib/*.la files, including a reference to 
/usr/projects/hpcsoft/toss2/common/gcc/5.2.0/lib/../lib64/libstdc++.la.


This is all disconcerting as users of GCC 5.3.0 were using 5.3.0's 
binaries but were getting some 5.2.0 library configs before I removed 
5.2.0, but no one knew it.


If it should be possible to use a single build of Open MPI with 
multiple binary-compatible compilers, is there a way to fix my above 
situation or prevent it from happening at build time?


Thanks,
David

--
David Shrader
HPC-3 High Performance Computer Systems
Los Alamos National Lab
Email: dshrader  lanl.gov


--
David Shrader
HPC-3 High Performance Computer Systems
Los Alamos National Lab
Email: dshrader  lanl.gov

Re: [OMPI users] a single build of Open MPI that can be used with multiple GCC versions

2016-02-10 Thread Douglas L Reeder

David,

I you use modules to mange your PATH and LD_LIBRARY_PATH and  load only the gcc 
tht you want when you build openmpi and your applications that sould fix it 
going forward.

Doug
> On Feb 10, 2016, at 10:58 AM, David Shrader  wrote:
> 
> Hello,
> 
> Is it possible to use a single build of Open MPI against multiple versions of 
> GCC if the versions of GCC are from the same release series? I was under the 
> assumption that as long as a binary-compatible compiler was used, it was 
> possible to "swap out" the compiler from underneath Open MPI.
> 
> That is the general question I have, but here is the specific scenario that 
> prompted it:
> built Open MPI 1.10.1 against GCC 5.2.0 with a directory name of 
> openmpi-1.10.1-gcc-5
> installed GCC 5.3.0
> removed GCC 5.2.0
> I now have users who are getting errors like the following when using mpicxx:
> /bin/grep: 
> /usr/projects/hpcsoft/toss2/common/gcc/5.2.0/lib/../lib64/libstdc++.la: No 
> such file or directory
> I can see several references to my previous GCC 5.2.0 installation in the 
> /lib/*.la files, including a reference to 
> /usr/projects/hpcsoft/toss2/common/gcc/5.2.0/lib/../lib64/libstdc++.la.
> This is all disconcerting as users of GCC 5.3.0 were using 5.3.0's binaries 
> but were getting some 5.2.0 library configs before I removed 5.2.0, but no 
> one knew it.
> If it should be possible to use a single build of Open MPI with multiple 
> binary-compatible compilers, is there a way to fix my above situation or 
> prevent it from happening at build time?
> Thanks,
> David
> -- 
> David Shrader
> HPC-3 High Performance Computer Systems
> Los Alamos National Lab
> Email: dshrader  lanl.gov
> ___
> 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/2016/02/28498.php

Re: [OMPI users] error openmpi check hdf5

2016-02-10 Thread Edgar Gabriel

yes and no :-) That particular functions was fixed, but there are a few 
other especially in the shardefp framework that would cause similar 
problems if compiled without RTLD_GLOBAL.


But more importantly, I can confirm that ompio in the 1.8 and 1.10 
series does *not* pass the HDF5 tests and should not be used for that 
(it passes on master and the 2.x series).  ROMIO is the default in 1.7, 
1.8 and 1.10 and should be used therefore.


Thganks
Edgar

On 2/10/2016 6:32 AM, Gilles Gouaillardet wrote:

Edgar,

It seems this the consequence of an abstraction violation
(fcoll/two_phases directly calls the io/ompio component) and that was 
fixed in master.

Can you confirm that ?

Delphine,

The problem should disappear if you use romio instead of ompio

Cheers,

Gilles

On Wednesday, February 10, 2016, Edgar Gabriel 
> wrote:


which version of Open MPI is this?
Thanks
Edgar

On 2/10/2016 4:13 AM, Delphine Ramalingom wrote:

Hello,

I try to compile a parallel version of hdf5.
I have error messages when I check with openmpi.

Support on HDF5 told me that the errors seem related to the new
ompio implementation inside
open MPI for MPI-I/O. He suggests that I talk to the OMPI mailing
list to resolve  these errors.

For information, my version of openmpi is : gcc (GCC) 4.8.2
mpicc --showme
gcc -I/programs/Compilateurs2/usr/include -pthread -Wl,-rpath
-Wl,/programs/Compilateurs2/usr/lib -Wl,--enable-new-dtags
-L/programs/Compilateurs2/usr/lib -lmpi

Errors are :

.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:f
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so:
undefined symbol: ompi_io_ompio_decode_datatype
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so:
undefined symbol: ompi_io_ompio_decode_datatype
---
Primary job  terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
---
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so:
undefined symbol: ompi_io_ompio_set_aggregator_props
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so:
undefined symbol: ompi_io_ompio_set_aggregator_props
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so:
undefined symbol: ompi_io_ompio_set_aggregator_props


Thanks in advance for your help.

Regards
Delphine

-- 
 *Delphine Ramalingom Barbary |

Ingénieure en Calcul Scientifique *
Direction des Usages du Numérique (DUN)
Centre de Développement du Calcul Scientifique
TEL : 02 62 93 84 87- FAX : 02 62 93 81 06


-- 
Edgar Gabriel

Associate Professor
Parallel Software Technologies Labhttp://pstl.cs.uh.edu
Department of Computer Science  University of Houston
Philip G. Hoffman Hall, Room 524Houston, TX-77204, USA
Tel: +1 (713) 743-3857  Fax: +1 (713) 743-3335
--



--
Edgar Gabriel
Associate Professor
Parallel Software Technologies Lab  http://pstl.cs.uh.edu
Department of Computer Science  University of Houston
Philip G. Hoffman Hall, Room 524Houston, TX-77204, USA
Tel: +1 (713) 743-3857  Fax: +1 (713) 743-3335
--

[OMPI users] a single build of Open MPI that can be used with multiple GCC versions

2016-02-10 Thread David Shrader


Hello,

Is it possible to use a single build of Open MPI against multiple 
versions of GCC if the versions of GCC are from the same release series? 
I was under the assumption that as long as a binary-compatible compiler 
was used, it was possible to "swap out" the compiler from underneath 
Open MPI.


That is the general question I have, but here is the specific scenario 
that prompted it:


 * built Open MPI 1.10.1 against GCC 5.2.0 with a directory name of
   openmpi-1.10.1-gcc-5
 * installed GCC 5.3.0
 * removed GCC 5.2.0

I now have users who are getting errors like the following when using 
mpicxx:


/bin/grep: 
/usr/projects/hpcsoft/toss2/common/gcc/5.2.0/lib/../lib64/libstdc++.la: 
No such file or directory


I can see several references to my previous GCC 5.2.0 installation in 
the /lib/*.la files, including a reference to 
/usr/projects/hpcsoft/toss2/common/gcc/5.2.0/lib/../lib64/libstdc++.la.


This is all disconcerting as users of GCC 5.3.0 were using 5.3.0's 
binaries but were getting some 5.2.0 library configs before I removed 
5.2.0, but no one knew it.


If it should be possible to use a single build of Open MPI with multiple 
binary-compatible compilers, is there a way to fix my above situation or 
prevent it from happening at build time?


Thanks,
David

--
David Shrader
HPC-3 High Performance Computer Systems
Los Alamos National Lab
Email: dshrader  lanl.gov

Re: [OMPI users] shared memory zero size segment

2016-02-10 Thread Peter Wind

I agree that in practice the best practice would be to use Win_shared_query. 

Still I am confused by this part in the documentation: 
"The allocated memory is contiguous across process ranks unless the info key 
alloc_shared_noncontig is specified. Contiguous across process ranks means that 
the first address in the memory segment of process i is consecutive with the 
last address in the memory segment of process i - 1. This may enable the user 
to calculate remote address offsets with local information only." 

Isn't this an encouragement to use the pointer of Win_allocate_shared directly? 

Peter 

- Original Message -

> I don't know about bulletproof, but Win_shared_query is the *only* valid way
> to get the addresses of memory in other processes associated with a window.

> The default for Win_allocate_shared is contiguous memory, but it can and
> likely will be mapped differently into each process, in which case only
> relative offsets are transferrable.

> Jeff

> On Wed, Feb 10, 2016 at 4:19 AM, Gilles Gouaillardet <
> gilles.gouaillar...@gmail.com > wrote:

> > Peter,
> 

> > The bulletproof way is to use MPI_Win_shared_query after
> > MPI_Win_allocate_shared.
> 
> > I do not know if current behavior is a bug or a feature...
> 

> > Cheers,
> 

> > Gilles
> 

> > On Wednesday, February 10, 2016, Peter Wind < peter.w...@met.no > wrote:
> 

> > > Hi,
> > 
> 

> > > Under fortran, MPI_Win_allocate_shared is called with a window size of
> > > zero
> > > for some processes.
> > 
> 
> > > The output pointer is then not valid for these processes (null pointer).
> > 
> 
> > > Did I understood this wrongly? shouldn't the pointers be contiguous, so
> > > that
> > > for a zero sized window, the pointer should point to the start of the
> > > segment of the next rank?
> > 
> 
> > > The documentation explicitly specifies "size = 0 is valid".
> > 
> 

> > > Attached a small code, where rank=0 allocate a window of size zero. All
> > > the
> > > other ranks get valid pointers, except rank 0.
> > 
> 

> > > Best regards,
> > 
> 
> > > Peter
> > 
> 
> > > ___
> > 
> 
> > > 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/2016/02/28485.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/2016/02/28493.php
> 

> --
> Jeff Hammond
> jeff.scie...@gmail.com
> http://jeffhammond.github.io/

> ___
> 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/2016/02/28496.php

Re: [OMPI users] shared memory zero size segment

2016-02-10 Thread Jeff Hammond

I don't know about bulletproof, but Win_shared_query is the *only* valid
way to get the addresses of memory in other processes associated with a
window.

The default for Win_allocate_shared is contiguous memory, but it can and
likely will be mapped differently into each process, in which case only
relative offsets are transferrable.

Jeff

On Wed, Feb 10, 2016 at 4:19 AM, Gilles Gouaillardet <
gilles.gouaillar...@gmail.com> wrote:

> Peter,
>
> The bulletproof way is to use MPI_Win_shared_query after
> MPI_Win_allocate_shared.
> I do not know if current behavior is a bug or a feature...
>
> Cheers,
>
> Gilles
>
>
> On Wednesday, February 10, 2016, Peter Wind  wrote:
>
>> Hi,
>>
>> Under fortran, MPI_Win_allocate_shared is called with a window size of
>> zero for some processes.
>> The output pointer is then not valid for these processes (null pointer).
>> Did I understood this wrongly? shouldn't the pointers be contiguous, so
>> that for a zero sized window, the pointer should point to the start of the
>> segment of the next rank?
>> The documentation explicitly specifies "size = 0 is valid".
>>
>> Attached a small code, where rank=0 allocate a window of size zero. All
>> the other ranks get valid pointers, except rank 0.
>>
>> Best regards,
>> Peter
>> ___
>> 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/2016/02/28485.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/2016/02/28493.php
>



-- 
Jeff Hammond
jeff.scie...@gmail.com
http://jeffhammond.github.io/

[OMPI users] error openmpi check hdf5

2016-02-10 Thread Gilles Gouaillardet

Edgar,

It seems this the consequence of an abstraction violation
(fcoll/two_phases directly calls the io/ompio component) and that was fixed
in master.
Can you confirm that ?

Delphine,

The problem should disappear if you use romio instead of ompio

Cheers,

Gilles

On Wednesday, February 10, 2016, Edgar Gabriel > wrote:

> which version of Open MPI is this?
> Thanks
> Edgar
>
> On 2/10/2016 4:13 AM, Delphine Ramalingom wrote:
>
> Hello,
>
> I try to compile a parallel version of hdf5.
> I have error messages when I check with openmpi.
>
> Support on HDF5 told me that the errors seem related to the new ompio
> implementation inside
> open MPI for MPI-I/O. He suggests that I talk to the OMPI mailing list to
> resolve  these errors.
>
> For information, my version of openmpi is : gcc (GCC) 4.8.2
> mpicc --showme
> gcc -I/programs/Compilateurs2/usr/include -pthread -Wl,-rpath
> -Wl,/programs/Compilateurs2/usr/lib -Wl,--enable-new-dtags
> -L/programs/Compilateurs2/usr/lib -lmpi
>
> Errors are :
>
> .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:f
> /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> symbol: ompi_io_ompio_decode_datatype
> .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> symbol: ompi_io_ompio_decode_datatype
> ---
> Primary job  terminated normally, but 1 process returned
> a non-zero exit code.. Per user-direction, the job has been aborted.
> ---
> .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> symbol: ompi_io_ompio_set_aggregator_props
> .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> symbol: ompi_io_ompio_set_aggregator_props
> .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> symbol: ompi_io_ompio_set_aggregator_props
>
>
> Thanks in advance for your help.
>
> Regards
> Delphine
>
> --
>  *Delphine Ramalingom Barbary | Ingénieure en
> Calcul Scientifique *
> Direction des Usages du Numérique (DUN)
> Centre de Développement du Calcul Scientifique
> TEL : 02 62 93 84 87- FAX : 02 62 93 81 06
>
>
> --
> Edgar Gabriel
> Associate Professor
> Parallel Software Technologies Lab  http://pstl.cs.uh.edu
> Department of Computer Science  University of Houston
> Philip G. Hoffman Hall, Room 524Houston, TX-77204, USA
> Tel: +1 (713) 743-3857  Fax: +1 (713) 743-3335
> --
>
>

Re: [OMPI users] error openmpi check hdf5

2016-02-10 Thread Gilles Gouaillardet

Delphine,

I am surprised you are using ompio with openmpi 1.8 series.
The default is to use romio
Did you explicitly ask for ompio ?
If not, can you check your environment and ensure you are not mixing
openmpi 1.8 and v2.x ?

Cheers,

Gilles

On Wednesday, February 10, 2016, Delphine Ramalingom <
delphine.ramalin...@univ-reunion.fr> wrote:

> It's version 1.8.1.
> Regards
> Delphine
>
>
>  *Delphine Ramalingom Barbary | Ingénieure en
> Calcul Scientifique *
> Direction des Usages du Numérique (DUN)
> Centre de Développement du Calcul Scientifique
> TEL : 02 62 93 84 87- FAX : 02 62 93 81 06
> Le 10/02/2016 15:50, Edgar Gabriel a écrit :
>
> which version of Open MPI is this?
> Thanks
> Edgar
>
> On 2/10/2016 4:13 AM, Delphine Ramalingom wrote:
>
> Hello,
>
> I try to compile a parallel version of hdf5.
> I have error messages when I check with openmpi.
>
> Support on HDF5 told me that the errors seem related to the new ompio
> implementation inside
> open MPI for MPI-I/O. He suggests that I talk to the OMPI mailing list to
> resolve  these errors.
>
> For information, my version of openmpi is : gcc (GCC) 4.8.2
> mpicc --showme
> gcc -I/programs/Compilateurs2/usr/include -pthread -Wl,-rpath
> -Wl,/programs/Compilateurs2/usr/lib -Wl,--enable-new-dtags
> -L/programs/Compilateurs2/usr/lib -lmpi
>
> Errors are :
>
> .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> symbol: ompi_io_ompio_decode_datatype
> .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> symbol: ompi_io_ompio_decode_datatype
> ---
> Primary job  terminated normally, but 1 process returned
> a non-zero exit code.. Per user-direction, the job has been aborted.
> ---
> .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> symbol: ompi_io_ompio_set_aggregator_props
> .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> symbol: ompi_io_ompio_set_aggregator_props
> .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> symbol: ompi_io_ompio_set_aggregator_props
>
>
> Thanks in advance for your help.
>
> Regards
> Delphine
>
> --
>  *Delphine Ramalingom Barbary | Ingénieure en
> Calcul Scientifique *
> Direction des Usages du Numérique (DUN)
> Centre de Développement du Calcul Scientifique
> TEL : 02 62 93 84 87- FAX : 02 62 93 81 06
>
>
> --
> Edgar Gabriel
> Associate Professor
> Parallel Software Technologies Lab  http://pstl.cs.uh.edu
> Department of Computer Science  University of Houston
> Philip G. Hoffman Hall, Room 524Houston, TX-77204, USA
> Tel: +1 (713) 743-3857  Fax: +1 (713) 743-3335
> --
>
>
>
> ___
> users mailing listus...@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/2016/02/28489.php
>
>
>

Re: [OMPI users] shared memory zero size segment

2016-02-10 Thread Gilles Gouaillardet

Peter,

The bulletproof way is to use MPI_Win_shared_query after
MPI_Win_allocate_shared.
I do not know if current behavior is a bug or a feature...

Cheers,

Gilles

On Wednesday, February 10, 2016, Peter Wind  wrote:

> Hi,
>
> Under fortran, MPI_Win_allocate_shared is called with a window size of
> zero for some processes.
> The output pointer is then not valid for these processes (null pointer).
> Did I understood this wrongly? shouldn't the pointers be contiguous, so
> that for a zero sized window, the pointer should point to the start of the
> segment of the next rank?
> The documentation explicitly specifies "size = 0 is valid".
>
> Attached a small code, where rank=0 allocate a window of size zero. All
> the other ranks get valid pointers, except rank 0.
>
> Best regards,
> Peter
> ___
> 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/2016/02/28485.php
>

Re: [OMPI users] error openmpi check hdf5

2016-02-10 Thread Delphine Ramalingom


It's version 1.8.1.
Regards
Delphine


 *Delphine Ramalingom Barbary | Ingénieure 
en Calcul Scientifique *

Direction des Usages du Numérique (DUN)
Centre de Développement du Calcul Scientifique
TEL : 02 62 93 84 87- FAX : 02 62 93 81 06
Le 10/02/2016 15:50, Edgar Gabriel a écrit :

which version of Open MPI is this?
Thanks
Edgar

On 2/10/2016 4:13 AM, Delphine Ramalingom wrote:

Hello,

I try to compile a parallel version of hdf5.
I have error messages when I check with openmpi.

Support on HDF5 told me that the errors seem related to the new ompio 
implementation inside
open MPI for MPI-I/O. He suggests that I talk to the OMPI mailing 
list to resolve  these errors.


For information, my version of openmpi is : gcc (GCC) 4.8.2
mpicc --showme
gcc -I/programs/Compilateurs2/usr/include -pthread -Wl,-rpath 
-Wl,/programs/Compilateurs2/usr/lib -Wl,--enable-new-dtags 
-L/programs/Compilateurs2/usr/lib -lmpi


Errors are :

.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_decode_datatype
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_decode_datatype

---
Primary job  terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
---
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_set_aggregator_props
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_set_aggregator_props
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_set_aggregator_props



Thanks in advance for your help.

Regards
Delphine

--
 *Delphine Ramalingom Barbary | 
Ingénieure en Calcul Scientifique *

Direction des Usages du Numérique (DUN)
Centre de Développement du Calcul Scientifique
TEL : 02 62 93 84 87- FAX : 02 62 93 81 06


--
Edgar Gabriel
Associate Professor
Parallel Software Technologies Labhttp://pstl.cs.uh.edu
Department of Computer Science  University of Houston
Philip G. Hoffman Hall, Room 524Houston, TX-77204, USA
Tel: +1 (713) 743-3857  Fax: +1 (713) 743-3335
--


___
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/2016/02/28489.php

Re: [OMPI users] error openmpi check hdf5

2016-02-10 Thread Peter Wind

Sorry, This was the wrong thread! please disregard the ast answer (1.8.5 and 
1.10.2...) 

Peter 

- Original Message -

> I have tested 1.8.5 and 1.10.2, both fail. (And Intel and Gnu compilers).

> Peter

> - Original Message -

> > which version of Open MPI is this?
> 
> > Thanks
> 
> > Edgar
> 

> > On 2/10/2016 4:13 AM, Delphine Ramalingom wrote:
> 

> > > Hello,
> > 
> 

> > > I try to compile a parallel version of hdf5.
> > 
> 
> > > I have error messages when I check with openmpi.
> > 
> 

> > > Support on HDF5 told me that the errors seem related to the new ompio
> > > implementation inside
> > 
> 
> > > open MPI for MPI-I/O. He suggests that I talk to the OMPI mailing list to
> > > resolve these errors.
> > 
> 

> > > For information, my version of openmpi is : gcc (GCC) 4.8.2
> > 
> 
> > > mpicc --showme
> > 
> 
> > > gcc -I/programs/Compilateurs2/usr/include -pthread -Wl,-rpath
> > > -Wl,/programs/Compilateurs2/usr/lib -Wl,--enable-new-dtags
> > > -L/programs/Compilateurs2/usr/lib -lmpi
> > 
> 

> > > Errors are :
> > 
> 

> > > .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> > > /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> > > symbol: ompi_io_ompio_decode_datatype
> > 
> 
> > > .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> > > /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> > > symbol: ompi_io_ompio_decode_datatype
> > 
> 
> > > ---
> > 
> 
> > > Primary job terminated normally, but 1 process returned
> > 
> 
> > > a non-zero exit code.. Per user-direction, the job has been aborted.
> > 
> 
> > > ---
> > 
> 
> > > .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> > > /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> > > symbol: ompi_io_ompio_set_aggregator_props
> > 
> 
> > > .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> > > /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> > > symbol: ompi_io_ompio_set_aggregator_props
> > 
> 
> > > .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> > > /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> > > symbol: ompi_io_ompio_set_aggregator_props
> > 
> 

> > > Thanks in advance for your help.
> > 
> 

> > > Regards
> > 
> 
> > > Delphine
> > 
> 

> > > --
> > 
> 
> > > Delphine Ramalingom Barbary | Ingénieure en Calcul Scientifique
> > 
> 
> > > Direction des Usages du Numérique (DUN)
> > 
> 
> > > Centre de Développement du Calcul Scientifique
> > 
> 
> > > TEL : 02 62 93 84 87- FAX : 02 62 93 81 06
> > 
> 

> > --
> 
> > Edgar Gabriel
> 
> > Associate Professor
> 
> > Parallel Software Technologies Lab http://pstl.cs.uh.edu Department of
> > Computer Science  University of Houston
> 
> > Philip G. Hoffman Hall, Room 524Houston, TX-77204, USA
> 
> > Tel: +1 (713) 743-3857  Fax: +1 (713) 743-3335
> 
> > --
> 

> > ___
> 
> > 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/2016/02/28489.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/2016/02/28490.php

Re: [OMPI users] error openmpi check hdf5

2016-02-10 Thread Peter Wind

I have tested 1.8.5 and 1.10.2, both fail. (And Intel and Gnu compilers). 

Peter 

- Original Message -

> which version of Open MPI is this?
> Thanks
> Edgar

> On 2/10/2016 4:13 AM, Delphine Ramalingom wrote:

> > Hello,
> 

> > I try to compile a parallel version of hdf5.
> 
> > I have error messages when I check with openmpi.
> 

> > Support on HDF5 told me that the errors seem related to the new ompio
> > implementation inside
> 
> > open MPI for MPI-I/O. He suggests that I talk to the OMPI mailing list to
> > resolve these errors.
> 

> > For information, my version of openmpi is : gcc (GCC) 4.8.2
> 
> > mpicc --showme
> 
> > gcc -I/programs/Compilateurs2/usr/include -pthread -Wl,-rpath
> > -Wl,/programs/Compilateurs2/usr/lib -Wl,--enable-new-dtags
> > -L/programs/Compilateurs2/usr/lib -lmpi
> 

> > Errors are :
> 

> > .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> > /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> > symbol: ompi_io_ompio_decode_datatype
> 
> > .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> > /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> > symbol: ompi_io_ompio_decode_datatype
> 
> > ---
> 
> > Primary job terminated normally, but 1 process returned
> 
> > a non-zero exit code.. Per user-direction, the job has been aborted.
> 
> > ---
> 
> > .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> > /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> > symbol: ompi_io_ompio_set_aggregator_props
> 
> > .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> > /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> > symbol: ompi_io_ompio_set_aggregator_props
> 
> > .../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error:
> > /programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: undefined
> > symbol: ompi_io_ompio_set_aggregator_props
> 

> > Thanks in advance for your help.
> 

> > Regards
> 
> > Delphine
> 

> > --
> 
> > Delphine Ramalingom Barbary | Ingénieure en Calcul Scientifique
> 
> > Direction des Usages du Numérique (DUN)
> 
> > Centre de Développement du Calcul Scientifique
> 
> > TEL : 02 62 93 84 87- FAX : 02 62 93 81 06
> 

> --
> Edgar Gabriel
> Associate Professor
> Parallel Software Technologies Lab http://pstl.cs.uh.edu Department of
> Computer Science  University of Houston
> Philip G. Hoffman Hall, Room 524Houston, TX-77204, USA
> Tel: +1 (713) 743-3857  Fax: +1 (713) 743-3335
> --

> ___
> 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/2016/02/28489.php

Re: [OMPI users] error openmpi check hdf5

2016-02-10 Thread Edgar Gabriel


which version of Open MPI is this?
Thanks
Edgar

On 2/10/2016 4:13 AM, Delphine Ramalingom wrote:

Hello,

I try to compile a parallel version of hdf5.
I have error messages when I check with openmpi.

Support on HDF5 told me that the errors seem related to the new ompio 
implementation inside
open MPI for MPI-I/O. He suggests that I talk to the OMPI mailing list 
to resolve  these errors.


For information, my version of openmpi is : gcc (GCC) 4.8.2
mpicc --showme
gcc -I/programs/Compilateurs2/usr/include -pthread -Wl,-rpath 
-Wl,/programs/Compilateurs2/usr/lib -Wl,--enable-new-dtags 
-L/programs/Compilateurs2/usr/lib -lmpi


Errors are :

.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_decode_datatype
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_decode_datatype

---
Primary job  terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
---
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_set_aggregator_props
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_set_aggregator_props
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_set_aggregator_props



Thanks in advance for your help.

Regards
Delphine

--
 *Delphine Ramalingom Barbary | Ingénieure 
en Calcul Scientifique *

Direction des Usages du Numérique (DUN)
Centre de Développement du Calcul Scientifique
TEL : 02 62 93 84 87- FAX : 02 62 93 81 06


--
Edgar Gabriel
Associate Professor
Parallel Software Technologies Lab  http://pstl.cs.uh.edu
Department of Computer Science  University of Houston
Philip G. Hoffman Hall, Room 524Houston, TX-77204, USA
Tel: +1 (713) 743-3857  Fax: +1 (713) 743-3335
--

Re: [OMPI users] shared memory zero size segment

2016-02-10 Thread Peter Wind

Sorry for that, here is the attachement!

Peter

- Original Message -
> Peter --
> 
> Somewhere along the way, your attachment got lost.  Could you re-send?
> 
> Thanks.
> 
> 
> > On Feb 10, 2016, at 5:56 AM, Peter Wind  wrote:
> > 
> > Hi,
> > 
> > Under fortran, MPI_Win_allocate_shared is called with a window size of zero
> > for some processes.
> > The output pointer is then not valid for these processes (null pointer).
> > Did I understood this wrongly? shouldn't the pointers be contiguous, so
> > that for a zero sized window, the pointer should point to the start of the
> > segment of the next rank?
> > The documentation explicitly specifies "size = 0 is valid".
> > 
> > Attached a small code, where rank=0 allocate a window of size zero. All the
> > other ranks get valid pointers, except rank 0.
> > 
> > Best regards,
> > Peter
> > ___
> > 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/2016/02/28485.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/2016/02/28486.php
> 
program sharetest

! test zero size segment.
! run on at least 3 cpus
! mpirun -np 4 a.out

   use mpi

   use, intrinsic :: iso_c_binding,

   implicit none


   integer, parameter :: nsize = 20
   integer, pointer   :: array(:)
   integer:: num_procs
   integer:: ierr
   integer:: irank, irank_group
   integer:: win
   integer:: disp_unit
   type(c_ptr):: cp1
   type(c_ptr):: cp2

   integer(MPI_ADDRESS_KIND) :: win_size
   integer(MPI_ADDRESS_KIND) :: segment_size

   call MPI_Init(ierr)
   call MPI_Comm_size(MPI_COMM_WORLD, num_procs, ierr)
   call MPI_Comm_rank(MPI_COMM_WORLD, irank, ierr)

   disp_unit = sizeof(1)

   win_size = irank*disp_unit

   call MPI_Win_allocate_shared(win_size, disp_unit, MPI_INFO_NULL, MPI_COMM_WORLD, cp1, win, ierr)

!   write(*,*)'rank ', irank,', pointer ',cp1

  call c_f_pointer(cp1, array, [nsize])

77 format(4(A,I3))

   if(irank/=0)then
  array(1)=irank
  CALL MPI_BARRIER(MPI_COMM_WORLD, ierr)
  if(irank/=num_procs-1)then
 print 77, ' rank', irank, ':  array(1)', array(1),' shared with next rank: ',array(irank+1)
  else
 print 77, ' rank', irank, ':  array(1)', array(1),' shared with previous rank: ',array(0)
  endif
  CALL MPI_BARRIER(MPI_COMM_WORLD, ierr)
   else
 CALL MPI_BARRIER(MPI_COMM_WORLD, ierr)
  CALL MPI_BARRIER(MPI_COMM_WORLD, ierr)
 if(.not.associated(array))then
print 77, 'zero pointer found, rank', irank
 else
print 77, ' rank', irank, ' array associated '
print 77, ' rank', irank, ':  array(1) ', array(1),' shared with next rank: ',array(irank+1)
 endif
   endif


   call MPI_Finalize(ierr)

 end program sharetest

Re: [OMPI users] shared memory zero size segment

2016-02-10 Thread Peter Wind



- Original Message -
> Peter --
> 
> Somewhere along the way, your attachment got lost.  Could you re-send?
> 
> Thanks.
> 
> 
> > On Feb 10, 2016, at 5:56 AM, Peter Wind  wrote:
> > 
> > Hi,
> > 
> > Under fortran, MPI_Win_allocate_shared is called with a window size of zero
> > for some processes.
> > The output pointer is then not valid for these processes (null pointer).
> > Did I understood this wrongly? shouldn't the pointers be contiguous, so
> > that for a zero sized window, the pointer should point to the start of the
> > segment of the next rank?
> > The documentation explicitly specifies "size = 0 is valid".
> > 
> > Attached a small code, where rank=0 allocate a window of size zero. All the
> > other ranks get valid pointers, except rank 0.
> > 
> > Best regards,
> > Peter
> > ___
> > 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/2016/02/28485.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/2016/02/28486.php
> 
program sharetest

! test zero size segment.
! run on at least 3 cpus
! mpirun -np 4 a.out

   use mpi

   use, intrinsic :: iso_c_binding,

   implicit none


   integer, parameter :: nsize = 20
   integer, pointer   :: array(:)
   integer:: num_procs
   integer:: ierr
   integer:: irank, irank_group
   integer:: win
   integer:: disp_unit
   type(c_ptr):: cp1
   type(c_ptr):: cp2

   integer(MPI_ADDRESS_KIND) :: win_size
   integer(MPI_ADDRESS_KIND) :: segment_size

   call MPI_Init(ierr)
   call MPI_Comm_size(MPI_COMM_WORLD, num_procs, ierr)
   call MPI_Comm_rank(MPI_COMM_WORLD, irank, ierr)

   disp_unit = sizeof(1)

   win_size = irank*disp_unit

   call MPI_Win_allocate_shared(win_size, disp_unit, MPI_INFO_NULL, MPI_COMM_WORLD, cp1, win, ierr)

!   write(*,*)'rank ', irank,', pointer ',cp1

  call c_f_pointer(cp1, array, [nsize])

77 format(4(A,I3))

   if(irank/=0)then
  array(1)=irank
  CALL MPI_BARRIER(MPI_COMM_WORLD, ierr)
  if(irank/=num_procs-1)then
 print 77, ' rank', irank, ':  array(1)', array(1),' shared with next rank: ',array(irank+1)
  else
 print 77, ' rank', irank, ':  array(1)', array(1),' shared with previous rank: ',array(0)
  endif
  CALL MPI_BARRIER(MPI_COMM_WORLD, ierr)
   else
 CALL MPI_BARRIER(MPI_COMM_WORLD, ierr)
  CALL MPI_BARRIER(MPI_COMM_WORLD, ierr)
 if(.not.associated(array))then
print 77, 'zero pointer found, rank', irank
 else
print 77, ' rank', irank, ' array associated '
print 77, ' rank', irank, ':  array(1) ', array(1),' shared with next rank: ',array(irank+1)
 endif
   endif


   call MPI_Finalize(ierr)

 end program sharetest

Re: [OMPI users] shared memory zero size segment

2016-02-10 Thread Jeff Squyres (jsquyres)

Peter --

Somewhere along the way, your attachment got lost.  Could you re-send?

Thanks.


> On Feb 10, 2016, at 5:56 AM, Peter Wind  wrote:
> 
> Hi,
> 
> Under fortran, MPI_Win_allocate_shared is called with a window size of zero 
> for some processes.
> The output pointer is then not valid for these processes (null pointer).
> Did I understood this wrongly? shouldn't the pointers be contiguous, so that 
> for a zero sized window, the pointer should point to the start of the segment 
> of the next rank?
> The documentation explicitly specifies "size = 0 is valid".
> 
> Attached a small code, where rank=0 allocate a window of size zero. All the 
> other ranks get valid pointers, except rank 0.
> 
> Best regards,
> Peter
> ___
> 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/2016/02/28485.php


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

[OMPI users] shared memory zero size segment

2016-02-10 Thread Peter Wind

Hi,

Under fortran, MPI_Win_allocate_shared is called with a window size of zero for 
some processes.
The output pointer is then not valid for these processes (null pointer).
Did I understood this wrongly? shouldn't the pointers be contiguous, so that 
for a zero sized window, the pointer should point to the start of the segment 
of the next rank?
The documentation explicitly specifies "size = 0 is valid".

Attached a small code, where rank=0 allocate a window of size zero. All the 
other ranks get valid pointers, except rank 0.

Best regards,
Peter

[OMPI users] error openmpi check hdf5

2016-02-10 Thread Delphine Ramalingom


Hello,

I try to compile a parallel version of hdf5.
I have error messages when I check with openmpi.

Support on HDF5 told me that the errors seem related to the new ompio 
implementation inside
open MPI for MPI-I/O. He suggests that I talk to the OMPI mailing list 
to resolve  these errors.


For information, my version of openmpi is : gcc (GCC) 4.8.2
mpicc --showme
gcc -I/programs/Compilateurs2/usr/include -pthread -Wl,-rpath 
-Wl,/programs/Compilateurs2/usr/lib -Wl,--enable-new-dtags 
-L/programs/Compilateurs2/usr/lib -lmpi


Errors are :

.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_decode_datatype
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_decode_datatype

---
Primary job  terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
---
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_set_aggregator_props
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_set_aggregator_props
.../hdf5-1.8.16_gnu/testpar/.libs/t_mpi: symbol lookup error: 
/programs/Compilateurs2/usr/lib/openmpi/mca_fcoll_two_phase.so: 
undefined symbol: ompi_io_ompio_set_aggregator_props



Thanks in advance for your help.

Regards
Delphine

--
 *Delphine Ramalingom Barbary | Ingénieure 
en Calcul Scientifique *

Direction des Usages du Numérique (DUN)
Centre de Développement du Calcul Scientifique
TEL : 02 62 93 84 87- FAX : 02 62 93 81 06

Re: [OMPI users] OMPI users] Fortran vs C reductions

2016-02-10 Thread Jed Brown

Gilles Gouaillardet  writes:
>> implementation.  Must I compile in support for being called with
>> MPI_DOUBLE_COMPLEX?
>>
> does that really matter ?

Possibly.  For example, if the library needed to define some static
data, its setup might involve communicating values before being called
with that particular type.  That setup phase would fail if the Fortran
type is invalid.

> i assume your library and the user code are built with the same OpenMPI.
> if there is no Fortran support, then you are compiling code that cannot 
> be invoked (e.g. dead code),
> and though that is not the most elegant thing to do, that does not sound 
> like a showstopper to me.
>
> so yes, compile in support for being called with Fortran predefined 
> datatypes,
> worst case scenario is you generate broken dead code.

No, worst case is that the library crashes at run-time, e.g., during
setup of some sort.

I don't have a specific library with this behavior, but I can fill in
the details to scientifically justify such a thing.

Anyway, my suggestion is to either make a compile-time error so that a
configure script can test its validity or make it possible to query at
run-time whether the type/object is valid.  The latter would have the
advantage that you could rebuild MPI to add Fortran support and
dependent projects would not need to be rebuilt because they saw the
same environment.  I think that would involve new function(s).

signature.asc
Description: PGP signature

Re: [OMPI users] shared memory zero size segment

Re: [OMPI users] shared memory zero size segment

Re: [OMPI users] a single build of Open MPI that can be used with multiple GCC versions

Re: [OMPI users] a single build of Open MPI that can be used with multiple GCC versions

Re: [OMPI users] error openmpi check hdf5

[OMPI users] a single build of Open MPI that can be used with multiple GCC versions

Re: [OMPI users] shared memory zero size segment

Re: [OMPI users] shared memory zero size segment

[OMPI users] error openmpi check hdf5

Re: [OMPI users] error openmpi check hdf5

Re: [OMPI users] shared memory zero size segment

Re: [OMPI users] error openmpi check hdf5

Re: [OMPI users] error openmpi check hdf5

Re: [OMPI users] error openmpi check hdf5

Re: [OMPI users] error openmpi check hdf5

Re: [OMPI users] shared memory zero size segment

Re: [OMPI users] shared memory zero size segment

Re: [OMPI users] shared memory zero size segment

[OMPI users] shared memory zero size segment

[OMPI users] error openmpi check hdf5

Re: [OMPI users] OMPI users] Fortran vs C reductions

21 matches

Site Navigation

Mail list logo

Footer information