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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
: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
/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
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
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
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
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
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
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
{
-/* 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
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
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).
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
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
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,
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
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/
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
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
).
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().
36 matches
Mail list logo
