).
George.
On Fri, Dec 12, 2014 at 2:58 AM, Pascal Deveze
mailto:pascal.dev...@bull.net>> wrote:
George,
My initial problem is that when MPI is compiled with
“--enable-mpi-thread-multiple”, the variable enable_mpi_threads is set to 1
even if MPI_Init() is called in place of MPI_Init_thread().
elect a specific thread-level in any
module, a behavior that is allowed now with the new setting.
A drastic change in behavior...
George.
On Tue, Dec 9, 2014 at 3:33 AM, Ralph Castain
mailto:r...@open-mpi.org>> wrote:
Kewl - I’ll fix. Thanks!
On Dec 9, 2014, at 12:32 AM, Pascal Deveze
Pascal
Is this in the trunk or in the 1.8 series (or both)?
On Dec 9, 2014, at 12:28 AM, Pascal Deveze
mailto:pascal.dev...@bull.net>> wrote:
In case where MPI is compiled with --enable-mpi-thread-multiple, a call to
opal_using_threads() always returns 0 in the routine btl_xxx_componen
In case where MPI is compiled with --enable-mpi-thread-multiple, a call to
opal_using_threads() always returns 0 in the routine btl_xxx_component_init()
of the BTLs, event if the application calls MPI_Init_thread() with
MPI_THREAD_MULTIPLE.
This is because opal_set_using_threads(true) in ompi/
devel-boun...@open-mpi.org a écrit sur 28/02/2012 10:54:15 :
> De : Ralph Castain
> A : Open MPI Developers
> Date : 28/02/2012 10:54
> Objet : Re: [OMPI devel] Problem with the openmpi-default-hostfile
> (on the trunk)
> Envoyé par : devel-boun...@open-mpi.org
>
> I'll see what I can do when
devel-boun...@open-mpi.org a écrit sur 27/02/2012 15:53:06 :
> De : Ralph Castain
> A : Open MPI Developers
> Date : 27/02/2012 16:17
> Objet : Re: [OMPI devel] Problem with the openmpi-default-hostfile
> (on the trunk)
> Envoyé par : devel-boun...@open-mpi.org
>
> That's strange - I run on sl
Hi all,
I have problems with the openmpi-default-hostfile since the following
patch on the trunk
changeset: 19874:088fc6c84a9f
user:rhc
date:Wed Feb 01 17:40:44 2012 +
summary: In accordance with prior releases, we are supposed to default
to looking at the openmpi-defa
Calling MPI_Type_create_hindexed(int count, int array_of_blocklengths[],
MPI_Aint array_of_displacements[], MPI_Datatype oldtype,
MPI_Datatype *newtype)
with a count parameter of 1 causes a loss of memory detected by valgrind :
==2053== 576 (448 direct, 128 indirect) bytes i
/nightly/ompi_cronjob.sh
contrib/nightly/unimplemented_report.sh
contrib/ompi_cplusplus.sed
contrib/ompi_cplusplus.sh
contrib/ompi_cplusplus.txt
contrib/platform/cisco/ebuild/hlfr
contrib/platform/cisco/ebuild/hlfr.conf
Pascal Deveze a écrit :
The bitbucket tree
(https://bitbucket.org/devezep/new
:Pascal Deveze
date:Mon Jan 17 13:40:10 2011 +0100
summary: Remove all files
changeset: 26:e3989f46f83a
user:Pascal Deveze
date:Mon Jan 17 14:46:48 2011 +0100
summary: Import from http://svn.open-mpi.org/svn/ompi/trunki (r24256)
changeset: 27:97f54ec8a575
tag
Pascal Deveze a écrit :
Jeff Squyres a écrit :
I'm actually confused by the changelog on the repo:
- r1 (https://bitbucket.org/devezep/new-romio-for-openmpi) says "Initial import from
branch v1.5"
- r15 (https://bitbucket.org/devezep/new-romio-for-openmpi/changeset/a535d7cdb
st (re?)noticed that your mercurial tree is based on the 1.4 branch:
https://bitbucket.org/devezep/new-romio-for-openmpi
Are we targeting the v1.4 series for this?
I thought we were targeting trunk/v1.5 for the new ROMIO, but perhaps I'm
forgetting something...?
On Jan 1
Jeff Squyres a écrit :
Great!
I see in your other mail that you pulled something from MPICH2 to make this
work.
Does that mean that there's a even-newer version of ROMIO that we should pull in its entirety? It's a little risky to pull most stuff from one released version of ROMIO and then mor
This problem of assertion is now solved by a patch in ROMIO just
commited in http://bitbucket.org/devezep/new-romio-for-openmpi
I don't know any other problem in this porting of ROMIO.
Pascal
Pascal Deveze a écrit :
Jeff Squyres a écrit :
On Dec 16, 2010, at 3:31 AM, Pascal Deveze
A new patch in ROMIO solves this problem
Thanks to Dave.
Pascal
Dave Goodell a écrit :
Hmm... Apparently I was too optimistic about my untested patch. I'll work with
Rob this afternoon to straighten this out.
-Dave
On Jan 10, 2011, at 5:53 AM CST, Pascal Deveze wrote:
Dave,
So, to eventually answer your question yes I do have some remarks, but
I have no answers. It's been a couple of years since I added those
frees...
==rob
On Fri, Jan 07, 2011 at 09:47:17AM +0100, Pascal Deveze wrote:
Hi Rob,
As you perhaps remember, I was porting ROMIO on OpenMPI.
The
I have a problem to finish the porting of ROMIO into Open MPI. It is
related to the routines MPI_Comm_dup together with MPI_Keyval_create,
MPI_Keyval_free, MPI_Attr_get and MPI_Attr_put.
Here is a simple program that reproduces my problem:
===
#include
Jeff Squyres a écrit :
On Dec 16, 2010, at 3:31 AM, Pascal Deveze wrote:
I got the assert every time with the following "trivial" code:
#include "mpi.h"
Good; let's add this trivial test to ompi-tests. Do you guys have a set of
ROMIO / IO test cases that y
6(__libc_start_main+0xfd) [0x3e8521ec5d]
[cuzco10:10336] [12] ./a.out() [0x401fc9]
[cuzco10:10336] *** End of error message ***
I am currently analysing the problem (MPI_File_close() now calls
MPI_File_set_errhandler()).
Pascal
Jeff Squyres a écrit :
On Dec 1, 2010, at 7:35 AM, Pascal De
Hi Jeff,
Comments are in the text
Jeff Squyres a écrit :
On Nov 30, 2010, at 6:44 AM, Pascal Deveze wrote:
I have commited all my last changes in bitbucket, including those that follows.
I got a checkout, and still have some problems/questions. More below.
If you do the IM thing
I didn't try to run it yet because you
said there were some things that weren't pushed back up to bitbucket yet.
On Nov 24, 2010, at 10:48 AM, Pascal Deveze wrote:
Hi Jeff,
Here is the unified diff.
As only the romio subtree is modified, I made the following command:
diff
Squyres a écrit :
Great!
Are those final changes committed back to the bitbucket? If so, I'll give it a
whirl.
On Nov 24, 2010, at 10:48 AM, Pascal Deveze wrote:
Hi Jeff,
Here is the unified diff.
As only the romio subtree is modified, I made the following command:
diff -u -r -x
vs. the
SVN trunk HEAD?
E.g., if you have an hg+ssh combo tree, could you "hg up" in there to get all your work, and
then "svn diff > diff.out" and then compress and send the diff.out?
Thanks!
On Nov 10, 2010, at 8:43 AM, Pascal Deveze wrote:
WHAT: Port the
WHAT: Port the lastest ROMIO version from MPICH2-1.3 into the trunk.
WHY: There is a considerable interest in updating the ROMIO branch that
was ported from mpich2-1.0.7
WHERE: ompi/mca/io/romio/
WHEN: Before 1.5.2, so asap
TIMEOUT: Next Tuesday teleconf, 23 Nov 2010
-
I am in charge o
I just commited the very last modifications of ROMIO (mpich2-1.3rc1)
into bitbucket.
Pascal
Jeff Squyres a écrit :
On Sep 17, 2010, at 6:36 AM, Pascal Deveze wrote:
In charge of ticket 1888 (see at
https://svn.open-mpi.org/trac/ompi/ticket/1888) ,
I have put the resulting code in
Jeff Squyres a écrit :
On Sep 17, 2010, at 6:36 AM, Pascal Deveze wrote:
In charge of ticket 1888 (see at
https://svn.open-mpi.org/trac/ompi/ticket/1888) ,
I have put the resulting code in bitbucket at:
http://bitbucket.org/devezep/new-romio-for-openmpi/
Sweet!
The work in this
Hi all,
In charge of ticket 1888 (see at
https://svn.open-mpi.org/trac/ompi/ticket/1888) ,
I have put the resulting code in bitbucket at:
http://bitbucket.org/devezep/new-romio-for-openmpi/
The work in this repo consisted in refreshing ROMIO to a newer
version: the one from the very last MPICH
george.
On Apr 22, 2010, at 08:50 , Pascal Deveze wrote:
Hi all,
The sendrecv_replace in Open MPI seems to allocate/free memory with
MPI_Alloc_mem()/MPI_Free_mem()
I measured the time to allocate/free a buffer of 1MB.
MPI_Alloc_mem/MPI_Free_mem take 350us while malloc/free only t
george.
On Apr 22, 2010, at 08:50 , Pascal Deveze wrote:
Hi all,
The sendrecv_replace in Open MPI seems to allocate/free memory with
MPI_Alloc_mem()/MPI_Free_mem()
I measured the time to allocate/free a buffer of 1MB.
MPI_Alloc_mem/MPI_Free_mem take 350us while malloc/free only t
Hi all,
The sendrecv_replace in Open MPI seems to allocate/free memory with
MPI_Alloc_mem()/MPI_Free_mem()
I measured the time to allocate/free a buffer of 1MB.
MPI_Alloc_mem/MPI_Free_mem take 350us while malloc/free only take 8us.
malloc/free in ompi/mpi/c/sendrecv_replace.c was replaced by
what the ROMIO developers had in mind
for the ADIOI_Datatype_iscontig function, but it doesn't look like
they just want to know if the content is contiguous. I guess this
function return true if the content is contiguous AND the content
start at the pointer position (displacement zero).
george.
On
what the ROMIO developers had in mind
for the ADIOI_Datatype_iscontig function, but it doesn't look like
they just want to know if the content is contiguous. I guess this
function return true if the content is contiguous AND the content
start at the pointer position (displacement zero).
ou plan to fix
it, the correct solution is to retrieve the true lower bound of the
datatype in the contiguous case and add it to st_offset.
george.
On Mar 18, 2010, at 12:27 , Pascal Deveze wrote:
Hi all,
Sorry, I missed my porting from MPICH2 to OpenMPI concerning the file
romio/adio/comm/fl
{
-/* basic or contiguous type */
- count++;
- (*curr_index)++;
- }
- break;
-
default:
/* TODO: FIXME */
FPRINTF(stderr, "Error: Unsupported datatype passed to
ADIOI_Count_contiguous_blocks, combiner = %d\n", combiner);
Regards,
Pasca
Hi all,
I use a very simple datatype defined as follow:
lng[0]= 1;
dsp[0]= 1;
err=MPI_Type_indexed(1, lng, dsp, MPI_CHAR, &offtype);
err=MPI_Type_create_resized(offtype, 0, 2, &filetype);
MPI_Type_commit(&filetype);
This datatype consists of a hole (of length 1 char) followed by
I have seen that ROMIO goes wrong with fix 2014: A lot of ROMIO tests in
ompi/mca/io/romio/romio/test/ are failing
For example, with noncontig_coll2:
[inti15:28259] *** Process received signal ***
[inti15:28259] Signal: Segmentation fault (11)
[inti15:28259] Signal code: Address not mapped (1)
[in
36 matches
Mail list logo
