Re: [OMPI devel] 5.0.x bug release blockers hard stop

ase levy any objections to this here.   Thanks, William -- Josh Hursey IBM Spectrum MPI Developer

Re: [OMPI devel] First Open MPI v5.0.x docs have been merged

TODO" items in the HTML docs.   We merged "early" so that we could get wider testing of the configury, and we need people to stop updating the old docs.  It was time to switch everyone over to the new system, and move forward from there. Please, please, please make edits to the docs.  Using RST makes the docs pretty darn easy. --  Jeff Squyres jsquy...@cisco.com <mailto:jsquy...@cisco.com> -- Josh Hursey IBM Spectrum MPI Developer

Re: [OMPI devel] Configure --help results

l PMIx/PRRTE are being built, but that is probably worth the tradeoff.   Anyone else have thoughts or better ideas?   Brian -- Josh Hursey IBM Spectrum MPI Developer

Re: [OMPI devel] --mca coll choices

It makes sense, thanks. Is there a debug flag that prints out which component is chosen? Regards, Luis On 07/04/2020 19:42, Josh Hursey via devel wrote: Good question. The reason for this behavior is that the Open MPI coll(ective) framework does not require that every compone

Re: [OMPI devel] --mca coll choices

ned "Not found" (-13) instead of "Success" (0) Can you please help? Regards, Luis The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Josh Hursey IBM Spectrum MPI Developer

[OMPI devel] CI Testing Coordination

.   https://github.com/open-mpi/ompi-ci-tests/issues/1 I flagged some folks on the Issue but wanted to post here in case I missed anyone that might be interested. If you can fill it out this week then we can try to meet early next week to start our discussion. Thanks, Josh -- Josh Hursey IBM

[OMPI devel] Call for Participation: Inaugural PMIx Standard Quarterly Administrative Steering Committee (ASC) Meeting

://github.com/pmix/pmix-standard [3] PMIx website: https://pmix.org -- Josh Hursey IBM Spectrum MPI Developer ___ devel mailing list devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/devel

[OMPI devel] Fwd: System Runtime Interfaces: What’s the Best Way Forward?

/hpc-runtime-wg/LGaHyZ0jRvE/n2t9MeSkDgAJ Thanks, Josh -- Forwarded message - From: Josh Hursey Date: Fri, Jan 18, 2019 at 6:55 PM Subject: System Runtime Interfaces: What’s the Best Way Forward? To: I'd like to share this meeting announcement with the PMIx community. I am co

Re: [OMPI devel] IBM CI re-enabled.

rg > https://lists.open-mpi.org/mailman/listinfo/devel > > ___ > devel mailing list > devel@lists.open-mpi.org > https://lists.open-mpi.org/mailman/listinfo/devel -- Josh Hursey IBM Spectrum MPI Developer ___ devel mailing list devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] Upcoming nightly tarball URL changes

master-201803170305-bf3dd8a > master-201803082122-0f345c0 > master-201803160306-e08e580 > > > -- > > Best regards, Boris Karasev. > ___ > devel mailing list > devel@lists.open-mpi.org > https://lists.open-mpi.org/mailman/listinfo/devel > > >

Re: [OMPI devel] Upcoming nightly tarball URL changes

-mpi.org/ > nightly/open-mpi/master > > > Thanks, > > Brian > _______ > devel mailing list > devel@lists.open-mpi.org > https://lists.open-mpi.org/mailman/listinfo/devel -- Josh Hursey IBM Spectrum MPI Developer ___ devel mailing list devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] ROMIO support in OpenMPI

hing i can resume when needed (we just have to agree on > romio version 3.2 vs 3.3a2). > > if you are going to SC, i'll spend quite some time at the RIST booth #219 > and i will be happy to discuss > this face to face. > > > Cheers, > > Gilles > > On 11/8/

Re: [OMPI devel] ROMIO support in OpenMPI

> > devel@lists.open-mpi.org > > https://lists.open-mpi.org/mailman/listinfo/devel > _______ > devel mailing list > devel@lists.open-mpi.org > https://lists.open-mpi.org/mailman/listinfo/devel > -- Josh Hursey IBM Spectrum MPI Developer ___ devel mailing list devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] MTT database

. -- Josh On Thu, Oct 12, 2017 at 12:30 PM, Josh Hursey <jjhur...@open-mpi.org> wrote: > It looks like the AWS database is unreachable. From the dashboard it looks > like we exhausted disk space, which might be the root cause. From the logs > I can see on the Dashboard, it looks like

Re: [OMPI devel] MTT database

Database abort: Could not connect to the ompidb database; submit this > run later. > > Howard > > ___ > devel mailing list > devel@lists.open-mpi.org > https://lists.open-mpi.org/mailman/listinfo/devel &g

Re: [MTT devel] trying again to ppost results to "IU" using pyclient

gt;> Absolute URI not allowed if server is not a proxy. >> >> Also, what should be the format of the POST request to get a serial #? >> I'm suspicious that >> >> this area of the pyclient is buggy. >> >> Howard >> >> >> >> 2017-08-14 15:

Re: [OMPI devel] MTT / Open MPI Visibility of New Failures

We are putting a pin in this for now. Amazon had an idea they wanted to run with and report back. Once they have more info then we'll try to setup another meeting. On Tue, Jul 11, 2017 at 3:20 PM, Josh Hursey <jjhur...@open-mpi.org> wrote: > In the Open MPI face-to-face meeting we h

Re: [OMPI devel] MTT / Open MPI Visibility of New Failures

isplayed by > jenkins > > Cheers, > > Gilles > > On Wed, Jul 12, 2017 at 5:20 AM, Josh Hursey <jjhur...@open-mpi.org> > wrote: > > In the Open MPI face-to-face meeting we had a long discussion about how > to > > better harness MTT such that new failures are

[OMPI devel] MTT / Open MPI Visibility of New Failures

eir "known to fail" list. If the "failed, but we expected to pass" number is >0 then this is a 'new failure' and an email to the community is generated. -- Josh Hursey IBM Spectrum MPI Developer ___ devel mailing list devel@lists.op

Re: [OMPI devel] [3.0.0rc1] ppc64/gcc-4.8.3 check failure (regression).

cc/ > > > openmpi-3.0.0rc1/test/class/opal_fifo.c:109:26: warning: assignment > > > discards 'volatile' qualifier from pointer target type [enabled by > default] > > > for (count = 0, item = fifo->opal_fifo_head.data.item ; item != > > > >opal_fifo_ghost ; > ___ > devel mailing list > devel@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel > -- Josh Hursey IBM Spectrum MPI Developer ___ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] Mellanox Jenkins

.org >>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >>> >> >> >> >> -- >> С Уважением, Поляков Артем Юрьевич >> Best regards, Artem Y. Polyakov >> >> ___ >> devel mailing list >> devel@lists.open-mpi.org >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >> > > ___ > devel mailing list > devel@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel > > > > ___ > devel mailing list > devel@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel > -- Josh Hursey IBM Spectrum MPI Developer ___ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] Open MPI 3.x branch naming

ey had > local changes to a branch based on v3.x. In theory, it shouldn’t be much > work to clean all that up. But theory and practice don’t always match when > using git :). > > Brian > ___ > devel mailing list > devel@lists.open-mpi.

Re: [OMPI devel] count = -1 for reduce

- >>> -- >>> >> >>> >> #include >>> >> #include >>> >> #include >>> >> int main(int argc, char** argv) >>> >> { >>> >> >>> >> int r[1], s[1]; >>> >> MPI_Init(,); >>> >> >>> >> s[0] = 1; >>> >> r[0] = -1; >>> >> MPI_Reduce(s,r,-1,MPI_INT,MPI_SUM,0,MPI_COMM_WORLD); >>> >> printf("%d\n",r[0]); >>> >> MPI_Finalize(); >>> >> } >>> >> >>> >> ___ >>> >> devel mailing list >>> >> devel@lists.open-mpi.org >>> >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >>> > >>> > ___ >>> > devel mailing list >>> > devel@lists.open-mpi.org >>> > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >>> > >>> > >>> > ___ >>> > devel mailing list >>> > devel@lists.open-mpi.org >>> > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >>> > >>> > >>> > ___ >>> > devel mailing list >>> > devel@lists.open-mpi.org >>> > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >>> > >>> > ___ >>> > devel mailing list >>> > devel@lists.open-mpi.org >>> > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >>> >>> >>> -- >>> Jeff Squyres >>> jsquy...@cisco.com >>> >>> ___ >>> devel mailing list >>> devel@lists.open-mpi.org >>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >>> >> >> >> ___ >> devel mailing list >> devel@lists.open-mpi.org >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >> > > > ___ > devel mailing list > devel@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel > -- Josh Hursey IBM Spectrum MPI Developer ___ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] OMPI devel] Travis: one thing that might help

> >>>> unfortunatly, master could not build any more because there was a > >> indeed > >>>> a conflict that git had no way to detect. > >>> I agree -- building pushes is not a bad thing for exactly the reason > >> you cite. > >>>

[MTT devel] Teleconf restart for 2017

When should we restart our weekly teleconfs for 2017? Maybe this week or the week of Jan 30? Next week is the OMPI face-to-face meeting so it might not be the best timing. -- Josh Hursey IBM Spectrum MPI Developer ___ mtt-devel mailing list mtt-devel

Re: [OMPI devel] MTT Server Downtime - Fri., Oct. 21, 2016 (Updated)

. This move requires -no- changes to any of your MTT client setups. Let me know if you have any issues. -- Josh On Fri, Oct 21, 2016 at 9:53 PM, Josh Hursey <jjhur...@open-mpi.org> wrote: > I have taken down the MTT Reporter at mtt.open-mpi.org while we finish up > the migration. I'll send

Re: [OMPI devel] MTT Server Downtime - Fri., Oct. 21, 2016 (Updated)

I have taken down the MTT Reporter at mtt.open-mpi.org while we finish up the migration. I'll send out another email when everything is up and running again. On Fri, Oct 21, 2016 at 10:17 AM, Josh Hursey <jjhur...@open-mpi.org> wrote: > Reminder that the MTT will go offline starting at

Re: [OMPI devel] MTT Server Downtime - Fri., Oct. 21, 2016 (Updated)

any questions or concerns. On Tue, Oct 18, 2016 at 10:59 AM, Josh Hursey <jjhur...@open-mpi.org> wrote: > We are moving this downtime to *Friday, Oct. 21 from 2-5 pm US Eastern*. > > We hit a snag with the AWS configuration that we are working through. > > On Sun, Oct 16,

Re: [OMPI devel] MTT Server Downtime - Tues., Oct. 18, 2016

We are moving this downtime to *Friday, Oct. 21 from 2-5 pm US Eastern*. We hit a snag with the AWS configuration that we are working through. On Sun, Oct 16, 2016 at 9:53 AM, Josh Hursey <jjhur...@open-mpi.org> wrote: > I will announce this on the Open MPI developer's teleconf o

[OMPI devel] MTT Server Downtime - Tues., Oct. 18, 2016

to access MTT using themtt.open-mpi.org URL. No changes are needed in your MTT client setup, and all permalinks are expected to still work after the move. Let me know if you have any questions or concerns about the move. -- Josh Hursey IBM Spectrum MPI Developer

Re: [OMPI devel] ompi-release repo is now closed; long live the ompi repo!

ompi repo! > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: http://www.cisco.com/web/ > about/doing_business/legal/cri/ > > _______ > devel mailing list > devel@lists.open-mpi.org > https://rfd.n

[MTT devel] Performance Measurement

(next couple months). We can use the GitHub to track comments, but maybe carve out part of the weekly teleconf to talk about progress. -- Josh Hursey IBM Spectrum MPI Developer ___ mtt-devel mailing list mtt-devel@lists.open-mpi.org https

Re: [OMPI devel] openmpi-2.0.0 - problems with ppc64, PGI and atomics

t;>>> 000324d0 t opal_lifo_pop_atomic > >>>>>>> 000cc260 t opal_lifo_pop_atomic > >>>>>>> 0002a490 t opal_lifo_push_atomic > >>>>>>> > >>>>>>> Any idea of how to fix the problem?

Re: [MTT devel] reporter error using pyclient

) > InternalError: current transaction is aborted, commands ignored until end > of transaction block > > > > > Powered by http://www.cherrypy.org;>CherryPy 5.1.0 > > > > > > <<<<<<<

Re: [MTT devel] reporter error using pyclient

ting dropped > connection: mtt.open-mpi.org > DEBUG:requests.packages.urllib3.connectionpool:"POST > /submit/cpy/api/submit HTTP/1.1" 200 90 > <<<<<<< Response -->>>>>> > Result: 200: application/json > {'content-lengt

Re: [MTT devel] reporter error using pyclient

t=iso-8859-1', 'Connection': 'close', > 'Server': 'Apache/2.2.15 (Red Hat)'} > > Not Found > > <<<<<<<---- Raw Output (Start) >>>>>> > > > > > > 404 Not Found > > > > Not Found > &g

Re: [MTT devel] reporter error using pyclient

t Found > > > > Not Found > > The requested URL /submit//serial was not found on this server. > > > > Apache/2.2.15 (Red Hat) Server at mtt.open-mpi.org Port > 443 > > > > > Any ideas on how to proceed? > &g

Re: [OMPI devel] Jenkins setup

There are two pages that I know of: * https://github.com/open-mpi/ompi/wiki/PRJenkins * https://github.com/open-mpi/ompi/wiki/PRJenkinsSetupFirewall I wrote the second one, and it includes some details on how to setup the Pull Request Builder. You probably don't need all of it, since it also

Re: [OMPI devel] LANL jenkins update

Awesome. Can you add that to this wiki page for future reference: https://github.com/open-mpi/ompi/wiki/PRJenkins#how-to-re-trigger-jenkins-testing On Thu, Jul 21, 2016 at 10:39 AM, Pritchard Jr., Howard wrote: > Hi Folks, > > The LANL/(soon to not be iu) jenkins should now

Re: [OMPI devel] Migration of mailman mailing lists

Now that netloc has rolled into hwloc, I think it is safe to kill the netloc lists. mtt-devel-core and mtt-annouce should be kept. They probably need to be cleaned. But the hope is that we release MTT at some point in the near-ish future. On Mon, Jul 18, 2016 at 10:20 AM, Jeff Squyres (jsquyres)

Re: [OMPI devel] [2.0.0rc4] dlopen_test crash with xlc

xlc -qversion > IBM XL C/C++ for Linux, V13.1.2 (5725-C73, 5765-J08) > Version: 13.01.0002. > > $ [...]/configure -prefix=[] --enable-debug \ > CC=xlc CXX=xlC FC=xlf --disable-mpi-fortran > > > There is no xlf installation on this system. > > -Paul &g

Re: [OMPI devel] [2.0.0rc4] dlopen_test crash with xlc

Paul, What was the configure string you used for this? We have a Jenkins CI mechanism for XL, but it is using XLC 13.1.3 on that system and we haven't been runing 'make check'. I have another system that has XLC 13.1.2 that I can test on as well. I'm not sure if I'll be able to fix without

[OMPI devel] Additional bot:retest target for IBM Jenkins: bot:ibm:retest

I added a feature to IBM's Jenkins setup yesterday that other orgs doing Jenkins CI testing might find helpful to add as well. We have the retest target for all of the Jenkins systems to re-test a particular PR: *bot:retest* I wanted an additional target that would trigger only the IBM Jenkins

[MTT devel] Ticket to finish the python support for the IU Database submissions

Per the teleconf today, I filed a ticket for the remaining todo items in the IUDatabase python module: https://github.com/open-mpi/mtt/issues/443 -- Josh

Re: [OMPI devel] RFC: Public Test Repo

ere, if you like. > > > On May 19, 2016, at 8:24 AM, Josh Hursey <jjhur...@open-mpi.org> wrote: > > I think talking to the MPICH folks about creating a common test pool might > be useful. More useful would be to get the MPI Forum to 'bless' it and take > inp

Re: [OMPI devel] RFC: Public Test Repo

ir test suite is general > enough for all MPI implementations, and B) if they would accept a bunch of > random tests from us? > > And if not, I think I'd like to understand better the value add that we > can provide by making another MPI test suite. > > Sent from my phone. No

Re: [OMPI devel] Github pricing plan changes announced today

Related to this conversation, I am proposing that we as a community try to cultivate some public tests. See the following link for the start of the dicussion. https://www.open-mpi.org/community/lists/devel/2016/05/18997.php We won't be able to open up the ompi-tests repo to the public. But we

[OMPI devel] RFC: Public Test Repo

WHAT: Create a public test repo (ompi-tests-public) to collect WHY: ompi-tests is private, and difficult/impossible to open up. There is a demand for a public collection of unit tests. This repo would allow us to cultivate such a collection of unit tests. WHERE: open-mpi GitHub project TIMEOUT:

Re: [MTT devel] GitHub Issue Cleanup

uple weeks ago we identified some development items for the short term. Can folks take point on filing those tickets so we can track their progress? I'll add the left-to-do items for the Server side. Label all those tickets that you need/want soon as v4.0. On Fri, May 13, 2016 at 1:08 PM, Josh Hur

Re: [OMPI devel] New Github labels

:+1: This is helpful. Thanks! On Wed, May 11, 2016 at 10:19 AM, Ralph Castain wrote: > Hi folks > > For PRs on the master, I have added two labels: > > Target: 2.x > Target: 1.10 > > These are intended to mark that this PR should be ported to the target > branch once it has

Re: [OMPI devel] [PATCH] Fix for xlc-13.1.0 ICE (hwloc)

eople's > software - I can fix things too] > > On Thu, May 5, 2016 at 2:28 PM, Jeff Squyres (jsquyres) < > <jsquy...@cisco.com>jsquy...@cisco.com> wrote: > >> On May 5, 2016, at 5:27 PM, Josh Hursey < <jjhur...@open-mpi.org> >> jjhur...@open-mpi.org> wro

Re: [OMPI devel] [2.0.0rc2] xlc-13.1.0 ICE (hwloc)

Brice: Can you take a look at Paul's patch here: https://www.open-mpi.org/community/lists/devel/2016/05/18918.php Thanks, Josh On Thu, May 5, 2016 at 4:28 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote: > On May 5, 2016, at 5:27 PM, Josh Hursey <jjhur...@open-mp

Re: [OMPI devel] [2.0.0rc2] xlc-13.1.0 ICE (hwloc)

Thanks. I can confirm that too. I have a power7 with xlc -qversion: IBM XL C/C++ for Linux, V12.1 (5765-J03, 5725-C73) Version: 12.01.. And it built v2.0.0rc2 fine. Unfortunately, I don't have access to a power7 system with v13.1. We might have to just make this in the release notes.

Re: [OMPI devel] opal/mca/dl/ opal_dl_open with NULL fname - assert?

> In dl.h, I even said that you could pass NULL as fname: > > https://github.com/open-mpi/ompi/blob/master/opal/mca/dl/dl.h#L67 > > These asserts can safely be removed. Thanks! > > > > On May 5, 2016, at 3:40 PM, Josh Hursey <jjhur...@open-mpi.org> wrote: >

[OMPI devel] opal/mca/dl/ opal_dl_open with NULL fname - assert?

We noticed that there is an assert(fname) in both of the dl components: * https://github.com/open-mpi/ompi/blob/master/opal/mca/dl/dlopen/dl_dlopen_module.c#L53 * https://github.com/open-mpi/ompi/blob/master/opal/mca/dl/libltdl/dl_libltdl_module.c#L21 But according to the dl.h, NULL should be

Re: [OMPI devel] [2.0.0rc2] xlc build failure (inline asm)

nd why the last : can be omitted when there are no >> clobbers. >> >> -Nathan >> >> On Wed, May 04, 2016 at 01:34:48PM -0500, Josh Hursey wrote: >> >Did someone pick this up to merge into master & v2.x? >> >I can confirm that Paul's patch f

Re: [OMPI devel] [2.0.0rc2] xlc build failure (inline asm)

Did someone pick this up to merge into master & v2.x? I can confirm that Paul's patch fixes the issue for XL compilers. I didn't see a PR for it, but can file one if no one has yet. On Mon, May 2, 2016 at 6:55 PM, Paul Hargrove wrote: > It appears that xlc's support for

Re: [OMPI devel] [2.0.0rc2] xlc-13.1.0 ICE (hwloc)

5725-C73, 5765-J08) > Version: 13.01.0002. > > However, it is worth noting that my understanding from IBM docs is that > the xlc for ppc64el is a VERY different compiler. > Specifically it uses the Clang front-end rather than IBM's own. > > -Paul > > > On Tue, May 3, 2016

Re: [OMPI devel] [2.0.0rc2] xlc-13.1.0 ICE (hwloc)

Paul, What generation of the power arch are you using? We have successfully built (a few weeks ago) with the xlc compiler 13.1.3 on a Power 8 (pcc64le). It might be related the big vs. little endian, but I wonder if it is something that was fixed in a point release of the xlc compiler. Are you

Re: [OMPI devel] 1.10.3rc MTT failures

IBM had a stale version of ompi-tests. I have sync'ed that repo, and will try again later today. The loop spawn error will take some digging. I'll see what we can find. On Mon, Apr 25, 2016 at 9:14 AM, Gilles Gouaillardet < gilles.gouaillar...@gmail.com> wrote: > This is a known bug that is

[OMPI devel] mpirun --verbose && opal_output_verbose() on 0

I was rummaging through the code today and made two observations related to verbose. Neither is terribly critical, but probably worth making the developer community aware. (2) might need to be fixed. (1) mpirun --verbose It does not seem to do anything in the current master (and probably for

[MTT devel] statement_timeout on MTT Reporter Queries

I just added a 60 second timeout on any query submitted to the MTT Reporter. Two commits for this (sorry I didn't go through the pull request mechanism - will do next time) [1][2] This was in response to, what we think, was a bot clicking around on the web form and submitting some very long

Re: [OMPI devel] ORTE headers in OPAL source

H, > mca_btl_sm_component.sm_seg->shmem_ds.seg_name); > > > Do you have an idea how to fix those two? The first variable > orte_cr_continue_like_restart could probably be moved but I am not sure > how to handle the sstore call. > > Adrian > >

Re: [OMPI devel] ORTE headers in OPAL source

Those calls should be protected with the CR FT #define - If I remember correctly. We were using the sstore to track the shared memory file names so we could clean them up on restart. I'm not sure if the sstore framework is necessary in this location, since we should be able to tell opal_crs and

Re: [OMPI devel] 1-question developer poll

For Open MPI: - Primary: Mercurial (hosted on BitBucket - better deal for academia) - Secondary: Git (hosted on either BitBucket or GitHub) - SVN only to commit back For other projects: - SVN - Becoming less commonly used, but still used for some projects like Open MPI - Mercurial and Git -

Re: [OMPI devel] orte-restart and PATH

It looks like I did not add the prefix path to the binary name before fork/exec in orte-restart. There is a string variable that you can use to get the appropriate prefix: opal_install_dirs.prefix from opal/mca/installdirs/installdirs.h It's the same one that Ralph mentioned that orterun

Re: [OMPI devel] Fix compiler warnings in FT code

kip FileM (Debug Only) = False >> >> >> >> On Mon, Mar 03, 2014 at 05:42:13PM +0100, Adrian Reber wrote: >> > I will prepare a patch that moves the parameter initialization >> somewhere else >> > and will not remove it. Do you think the othe

Re: [OMPI devel] Fix compiler warnings in FT code

; applied (without sstore_stage_select() removal)? > > > On Mon, Mar 03, 2014 at 10:07:36AM -0600, Josh Hursey wrote: > > It should probably be moved to the component initialization of the sstore > > stage component since those parameters are how the user controls where to > > store thos

Re: [OMPI devel] Fix compiler warnings in FT code

#ifdef it out. > > On Mon, Mar 03, 2014 at 07:17:19AM -0600, Josh Hursey wrote: > > It looks like you removed a number of sstore stage MCA parameters. Did > they > > move somewhere else? or do you have a different way to set those > parameters? > > > > Other than t

Re: [OMPI devel] Fix compiler warnings in FT code

It looks like you removed a number of sstore stage MCA parameters. Did they move somewhere else? or do you have a different way to set those parameters? Other than that it looks good to me. On Mon, Mar 3, 2014 at 5:29 AM, Adrian Reber wrote: > I have a simple patch which

Re: [OMPI devel] startup sstore orte/mca/ess/base/ess_base_std_tool.c

+1 On Fri, Feb 21, 2014 at 10:04 AM, Ralph Castain wrote: > looks fine to me > > > On Feb 21, 2014, at 6:23 AM, Adrian Reber wrote: > > > To restart a process using orte-restart I need sstore initialized when > > running as a tool. This is currently

Re: [OMPI devel] CRS/CRIU: add code to actually checkpoint a process

Yep. For the checkpoint/continue that patch looks good. On Tue, Feb 18, 2014 at 11:30 AM, Adrian Reber <adr...@lisas.de> wrote: > On Tue, Feb 18, 2014 at 10:21:23AM -0600, Josh Hursey wrote: > > So when a process is restarted with CRIU, does it resume execution after &g

Re: [OMPI devel] OPAL_CRS_* meaning

used to checkpoint the process as well as > > restart the process? I would have expected opal_crs.restart() is used > > for restart. I am confused. Looking at CRS/BLCR checkpoint() seems to > > only checkpoint and restart() seems to only restart. The comment in > > opa

Re: [OMPI devel] CRS/CRIU: add code to actually checkpoint a process

oint() I am using criu_dump() to > checkpoint the process and the plan is to use criu_restore() in > opal_crs_criu_restart() (which I have not yet implemented). > > On Mon, Feb 17, 2014 at 03:45:49PM -0600, Josh Hursey wrote: > > It look fine except that the restart state is n

Re: [OMPI devel] CRS/CRIU: add code to actually checkpoint a process

It look fine except that the restart state is not flagged. When a process is restarted does it resume execution inside the criu_dump() function? If so, is there a way to tell from its return code (or some other mechanism) that it is being restarted versus continuing after checkpointing? On Mon,

Re: [OMPI devel] OPAL_CRS_* meaning

These values indicate the current state of the checkpointing lifecycle. In particular CONTINUE/RESTART are set by the checkpointer in the CRS (all others are used by the INC mechanism). In the opal_crs.checkpoint() call the checkpointer will capture the program state and it is possible to emerge

Re: [OMPI devel] new CRS component added (criu)

That is fantastic! Thanks for the hard work so far getting the C/R infrastructure back in place. On Fri, Feb 7, 2014 at 3:46 PM, Adrian Reber wrote: > I have created a new CRS component using criu (criu.org) to support > checkpoint/restart in Open MPI. My current patch only

Re: [OMPI devel] C/R and orte_oob

In the original implementation, the OOB ft_event did not do much of anything on checkpoint preparation and continue. We did not even close the sockets. However, during restart the OOB will need to renegotiate the socket connections - usually by calling the finalization function (close stale

Re: [OMPI devel] SNAPC: dynamic send buffers

Looks good to me too. On Wed, Jan 29, 2014 at 11:00 AM, Ralph Castain wrote: > Looks good to me! > > On Jan 29, 2014, at 8:52 AM, Adrian Reber wrote: > > > Thanks for pointing out orte_rml_recv_callback(). It does just what I > > need. I removed my own

Re: [OMPI devel] [PATCH] use ORTE_PROC_IS_APP

That should be ok. On Thu, Jan 23, 2014 at 10:17 AM, Ralph Castain wrote: > Sure - no issues with me > > > On Jan 23, 2014, at 7:10 AM, Adrian Reber wrote: > > > Selecting SNAPC requires the information if it is an app or not: > > > > int

Re: [OMPI devel] return value of opal_compress_base_register() in opal/mca/compress/base/compress_base_open.c

if( !opal_cr_is_enabled ) { > > -opal_output_verbose(10, > opal_compress_base_framework.framework_output, > > -"compress:open: FT is not enabled, > skipping!"); > > -return OPAL_SUCCESS; > > -} > > - > > /*

Re: [OMPI devel] return value of opal_compress_base_register() in opal/mca/compress/base/compress_base_open.c

I think the only reason I protected that framework is to reduce the overhead of an application using a build of Open MPI with CR support, but no enabling it at runtime. Nothing in the compress framework depends on the CR infrastructure (although the CR infrastructure can use the compress framework

Re: [OMPI devel] [PATCH v3 1/2] Trying to get the C/R code to compile again. (recv_*_nb)

+1 On Thu, Dec 19, 2013 at 4:04 PM, Ralph Castain wrote: > Looks okay to me. On the places where you need to block while waiting for > an answer, you can use OMPI_WAIT_FOR_COMPLETION - this will spin on > opal_progress until the condition is met. We use it elsewhere for

Re: [OMPI devel] [PATCH v3 2/2] Trying to get the C/R code to compile again. (send_*_nb)

(Sorry for the delay, just catching up on email after the holidays) I think that looks good too. On Thu, Dec 19, 2013 at 4:01 PM, Ralph Castain wrote: > +1 from me > > > On Dec 19, 2013, at 12:54 PM, Adrian Reber wrote: > > > From: Adrian Reber

Re: [OMPI devel] [PATCH v2 1/2] Trying to get the C/R code to compile again. (recv_*_nb)

(Sorry for the delay, just catching up on email after the holidays) I agree with Ralph. You can remove the old function signatures, but keep the places where you replace a blocking send/recv with a non-blocking version. Then I think it is good. Thanks, Josh On Wed, Dec 18, 2013 at 9:52 AM,

Re: [OMPI devel] OMPI developer's meeting today

I think we had C/R slated for Friday morning - is that still correct? I have a meeting at 10 that just popped up, so I can only attend for an hour if we start at 9. I just wanted to confirm that that was the current plan or if had been modified. -- Josh On Thu, Dec 12, 2013 at 6:53 AM, Jeff

Re: [OMPI devel] [PATCH v2] Trying to get the C/R code to compile again. (last)

With the modification that Ralph mentioned below, I think the patch it good to go. Thanks! On Mon, Dec 9, 2013 at 2:19 PM, Ralph Castain wrote: > On Dec 9, 2013, at 10:07 AM, Ralph Castain wrote: > > > I see some things in here that concern me. First,

Re: [OMPI devel] [PATCH 2/4] Trying to get the C/R code to compile again. (send_*_nb)

etc. > > https://svn.open-mpi.org/trac/ompi/wiki/Dec13Meeting > > > > On Dec 6, 2013, at 9:30 AM, Josh Hursey <jjhur...@open-mpi.org> wrote: > > > Since the blocking semantics are important for correctness of the prior > code, I would not just replace send_bu

Re: [OMPI devel] [PATCH 4/4] Trying to get the C/R code to compile again. (last)

Did the mca_base_component_distill_checkpoint_ready paramter go away? Its intention was to allow a user to have a build with C/R compiled in and then choose at runtime if they want to restrict their component section to just C/R enabled components or not. I have reservations about that part of the

Re: [OMPI devel] [PATCH 3/4] Trying to get the C/R code to compile again. (recv_*_nb)

Per my other email, I would suggest #ifdef comments instead of nonblocking replacements for the blocking calls. After that modification, I think this patch is fine. As was mentioned previously, we will need to go back (after things compile) and figure out a new model for this behavior. For the

Re: [OMPI devel] [PATCH 2/4] Trying to get the C/R code to compile again. (send_*_nb)

Since the blocking semantics are important for correctness of the prior code, I would not just replace send_buffer with send_buffer_nb. This makes the semantics incorrect, and will make things confusing later when you try to sort out prior calls to send_buffer_nb with those that you replaced. As

Re: [OMPI devel] [PATCH 1/4] Trying to get the C/R code to compile again. (void value not ignored)

This patch looks good to me. Let me look at some of the others. On Fri, Dec 6, 2013 at 7:14 AM, Jeff Squyres (jsquyres) wrote: > Let's see what Josh says (he said he'd review the patches today). I'm > guessing he'll be ok with this one, but let's see. > > > On Dec 6, 2013,

Re: [OMPI devel] Annual OMPI membership review: SVN accounts

Keep my account active. On Tue, Jul 9, 2013 at 11:54 AM, Tim Mattox wrote: > What, my SVN account is still there? > I'm just a lurker now, so please remove timattox from SVN > > On Mon, Jul 8, 2013 at 6:32 PM, Jeff Squyres (jsquyres) < > jsquy...@cisco.com> wrote: > >>

Re: [OMPI devel] [EXTERNAL] Re: RFC: Python-generated Fortran wrappers

Is this Python 2.x or 3.x? I ask because they are not 100% compatible due to changes in the language syntax. Meaning not all 2.x compilant Python programs work with a 3.x interpreter. IIRC there is a way to write a 2.x compliant Python program so that it is also 3.x compliant, but my Python

Re: [OMPI devel] CRIU checkpoint support in Open-MPI?

+1 I would be interested in seeing support for this in Open MPI. On Thu, Dec 6, 2012 at 8:14 AM, George Bosilca wrote: > Samuel, > > Yes, all contributions are welcomed. It should be almost trivial to write > a new backend in Open MPI to support what the kernel developers

Re: [OMPI devel] Open MPI MTT is moving

experience any problems with the new server. -- Josh On Fri, Nov 2, 2012 at 9:26 AM, Josh Hursey <jjhur...@open-mpi.org> wrote: > Reminder that we will be shutting down the MTT submission and reporter > services this weekend to migrate it to another machine. The MTT > services

Re: [OMPI devel] Open MPI MTT is moving

Reminder that we will be shutting down the MTT submission and reporter services this weekend to migrate it to another machine. The MTT services will go offline at COB today, and be brought back by Monday morning. On Wed, Oct 31, 2012 at 7:54 AM, Jeff Squyres wrote: > *** IF

Re: [OMPI devel] ORCA - Another runtime supported

Yeah. I am having trouble finding cycles to spend on this at the moment. We know what we need to do to finish it so that isn't the barrier at the moment. Just hands on deck. I hope to get back to it soon, but I cannot put time bounds on soon at the moment :/ -- Josh On Wed, Aug 22, 2012 at 10:17

Re: [OMPI devel] Quiet Time on Trunk - ORCA Integration

Hursey <jjhur...@open-mpi.org> wrote: > ORCA was backed out of the trunk in r26676. > > Once we fix the linking issue, we will bring this back. > > Sorry for the noise folks. The trunk is open again. > > -- Josh > > On Tue, Jun 26, 2012 at 9:04 PM, Josh Hursey <jjh

Re: [OMPI devel] Quiet Time on Trunk - ORCA Integration

ORCA was backed out of the trunk in r26676. Once we fix the linking issue, we will bring this back. Sorry for the noise folks. The trunk is open again. -- Josh On Tue, Jun 26, 2012 at 9:04 PM, Josh Hursey <jjhur...@open-mpi.org> wrote: > So I'm spinning my wheels on this one. I

  1   2   3   4   >