Re: [OMPI devel] ROMIO support in OpenMPI

I saw you opened this PR to get the initial steps started: https://github.com/open-mpi/ompi/pull/4487 Thanks for that. I'll be at SC next week. I don't know how much I'll be around the IBM booth at the moment. Let's make sure to touch base on this though. If I don't see you at the RIST booth we

Re: [OMPI devel] ROMIO support in OpenMPI

Josh, i started updating ROMIO some times ago (the latest version was 3.2b1 at that time). iirc, ROMIO 3.2 introduced some asynchronous operations that involve MPI_Grequest. i cannot remember what i did for that (e.g. #ifdef out ? compile but no test ?). today, the stable version is 3.

Re: [OMPI devel] ROMIO support in OpenMPI

We (IBM) are interested in maintaining support for ROMIO in Open MPI. We are investigating upgrading the ROMIO version inside Open MPI, but I have no ETA on when that work will be complete/available. On Wed, Nov 8, 2017 at 4:37 AM, Gilles Gouaillardet < gilles.gouaillar...@gmail.com> wrote: > Far

Re: [OMPI devel] ROMIO support in OpenMPI

Farouk, as far as i am concerned, there is no plan to stop supporting ROMIO. that being said, i am not aware there are any plans to upgrade to the latest ROMIO in a near future. Also, please note ROMIO is the default module when the Lustre filesystem is used. Cheers, Gilles On Wed, Nov 8, 2017

[OMPI devel] ROMIO support in OpenMPI

Hello, A simple question about the expected support for ROMIO. Since OMPIO became the default IO implementation, we would like to have a cleared view of how much time the ROMIO will be supported ? Regards, Farouk Mansouri DDN IME software engineer ___

Re: [OMPI devel] ROMIO+Lustre problems 2.0

Hello all, JFYI and for log purposes: *In short: 'caddr_t' issue is known and is addressed in new(er) ROMIO releases.* Below the (off-list) answer (snippet) from Rob Latham. On 12/08/15 13:16, Paul Kapinos wrote: In short: ROMIO in actual OpenMPI versions cannot configure using old versions of

[OMPI devel] ROMIO+Lustre problems 2.0

Dear Open MPI and ROMIO developer, In short: ROMIO in actual OpenMPI versions cannot configure using old versions of Intel compiler. A while ago we reported about trouble in compiling Open MPI =>1.8.3 with ROMIO support, cf. (1), which was reported to be fixed (2). However we've found out

[OMPI devel] romio refresh on master

Hi Folks, I merged in the refresh of romio 3.1.4, special thanks to Gilles for doing this! I did some testing, but can't say it was extensive. If others would have time to run some of the MTT setups requesting romio rather than ompio for a bit that would be great. Thanks, Howard

Re: [OMPI devel] ROMIO+Lustre problems in OpenMPI 1.8.3

(2nd try as the first log package was too big) Hello Howard, The version 1.8.1 installed on Jun 27 this year run fine, ROMIO is OK. Trying ro re-run using the same install script: found out that also 1.8.1 version of Open MPI now *cannot* build ROMIO support. Wow. That means that the regress

Re: [OMPI devel] ROMIO+Lustre problems in OpenMPI 1.8.3

Hi Paul, Thanks for the forward. I've opened an issue #255 to track the ROMIO config regression. Just to make sure, older releases of the 1.8 branch still configure and build properly with your current lustre setup? Thanks, Howard 2014-10-28 5:00

[OMPI devel] ROMIO+Lustre problems in OpenMPI 1.8.3

Dear Open MPI and ROMIO developer, We use Open MPI v.1.6.x and 1.8.x in our cluster. We have Lustre file system; we wish to use MPI_IO. So the OpenMPI's are compiled with this flag: > --with-io-romio-flags='--with-file-system=testfs+ufs+nfs+lustre' In our newest installation openmpi/1.8.3 we fou

Re: [OMPI devel] ROMIO update breaks trunk

Ah, thanks! Yes indeed On Nov 14, 2013, at 1:05 PM, Thomas Naughton wrote: > Hi Ralph, > > Does the version in AM_INIT_AUTOMAKE in configure.ac also need to be > increased? It currently shows 1.11. > > Thanks, > --tjn > > __

Re: [OMPI devel] ROMIO update breaks trunk

Hi Ralph, Does the version in AM_INIT_AUTOMAKE in configure.ac also need to be increased? It currently shows 1.11. Thanks, --tjn _ Thomas Naughton naught...@ornl.gov Research Assoc

Re: [OMPI devel] ROMIO update breaks trunk

Ha! Jeff points out that our web site says we are at AM 1.12.2 - yet our HACKING file says 1.11.1 Sadness I'll leave the romio update alone and update the HACKING file to avoid future confusion On Nov 14, 2013, at 12:41 PM, Ralph Castain wrote: > Just in case others are encountering this: t

[OMPI devel] ROMIO update breaks trunk

Just in case others are encountering this: the recent ROMIO update contains a line in its configure.ac that breaks the trunk for automake versions less than 1.12: "I've looked a bit around online for this, and the consensus generally seems to be that AM_PROG_AR should be added in libtool, not i

Re: [OMPI devel] ROMIO code in OMPI

The code is in ompi/mca/fcoll/two_phase/ . This is exactly similar to the ROMIO's implementation of two-phase which has been ported to OMPIO. In this code the buf_indices for the send_buffer is defined as an integer but this should be something like a size_t. This will fix the problem in fco

Re: [OMPI devel] ROMIO code in OMPI

Vishwanath, Can you point me to the two_phase module code? (I just wanted to make sure that we are looking at the same problem.) Rayson == Open Grid Scheduler - The Official Open Source Grid Engine http://gridscheduler.sourceforge.net/ On Thu, No

Re: [OMPI devel] ROMIO code in OMPI

I just checked the code for testing 2GB limitation in OMPIO. The code works with OMPIO's " fcoll dynamic" module. Although it does have the same 2GB limitation with the two_phase module which is based on ROMIO's implementation and the static module. I have a fix for both these modules I will co

Re: [OMPI devel] ROMIO code in OMPI

Hi Rayson We take snapshots from time to time. We debated whether or not to update again for the 1.7 release, but ultimately decided not to do so - IIRC, none of our developers had the time. If you are interested and willing to do the update, and perhaps look at removing the limit, that is fine w

[OMPI devel] ROMIO code in OMPI

How is the ROMIO code in Open MPI developed & maintained? Do Open MPI releases take snapshots of the ROMIO code from time to time from the ROMIO project, or was the ROMIO code forked a while ago and maintained separately in Open MPI?? I would like to fix the 2GB limit in the ROMIO code... and that

Re: [OMPI devel] ROMIO build broken in 1.5.5rc1 [SOLVED]

On 1/31/2012 3:43 PM, Jeff Squyres wrote: On Jan 31, 2012, at 6:17 PM, Paul H. Hargrove wrote: I took a quick look and discovered that all the generated Makefile's under ompi/mca/io/romio/romio contain explicit MAKE=make (twice per Makefile, actually). I haven't gone back to look at 1.5.x

Re: [OMPI devel] ROMIO build broken in 1.5.5rc1 [SOLVED]

On Jan 31, 2012, at 6:17 PM, Paul H. Hargrove wrote: > I took a quick look and discovered that all the generated Makefile's under > ompi/mca/io/romio/romio contain explicit MAKE=make (twice per Makefile, > actually). I haven't gone back to look at 1.5.x yet -- but just to be clear, you're *no

[OMPI devel] ROMIO build broken in 1.5.5rc1 [SOLVED]

On 1/31/2012 1:53 PM, Paul H. Hargrove wrote: I can supply details if anybody want to work on this ahead of 1.5.5rc2, but the short report is: gmake[3]: Entering directory `/home/phargrov/OMPI/openmpi-1.5.5rc1-openbsd5-amd64/BLD/ompi/mca/io/romio/romio' Making all in include make: don't know

[OMPI devel] ROMIO updates

I just committed two patches to OMPI's ROMIO that I discussed this morning on the teleconf. They remove two things from OMPI's bundled ROMIO: - function renaming (foo -> io_romio_foo) - file sym linking (foo.c -> io_romio_foo.c) Although these features were added for a good reason (to abide

Re: [OMPI devel] ROMIO

I know that Argonne was engaged at some level to help with the OMPI ROMIO integration -- was it on a formal or informal basis? On Feb 7, 2008, at 12:02 PM, Ralph H Castain wrote: I just -know- this is everyone's favorite subject, but... Brian used to take care of the ROMIO code in Open MPI,

[OMPI devel] ROMIO

I just -know- this is everyone's favorite subject, but... Brian used to take care of the ROMIO code in Open MPI, but he has now moved on to greener, happier pastures. As he left, he did raise the question of who was going to maintain ROMIO, which we all happily dodged. I raise this question again