* What is the precise distinction between the "true" and "false" values
of the info keys?
* What is the precise definition of when an implementation is required
to provide the same info keys/values between processes?
From: mp
quot; values
of the info keys?
* What is the precise definition of when an implementation is required
to provide the same info keys/values between processes?
From: mpi-forum on behalf of Jeff
Squyres (jsquyres) via mpi-forum
Sent: Thursday, November
w_resource_type" info key that can guide
the splitting of communicators on hardware-basis
(i.e. with a call to MPI_comm_split_type with MPI_COMM_TYPE_HW_GUIDED
as the input split_type value). MPI_Get_hw_resource_info fills
this gap and makes applications that rely on this mechanism more
po
resource_type" info key that can guide
the splitting of communicators on hardware-basis
(i.e. with a call to MPI_comm_split_type with MPI_COMM_TYPE_HW_GUIDED
as the input split_type value). MPI_Get_hw_resource_info fills
this gap and makes applications that rely on this mechanism more
portable than previ
I see that MPI_Get_hw_resource_info() was introduced in MPI-4.1 p445:13.
I'm a little confused by the description of this routine. p445:30-32 says (the
PDF won't copy-n-paste this section for some reason, so I'm copy-n-pasting from
the corresponding LaTeX source):
This information is stored as
This is a pretty trivial issue (famous last words), and I have no idea about
the current timeline, but it would be nice if this issue could make it into
MPI-4.1.
Either Howard Pritchard or Joseph Schuchart will read the following at the next
meeting where this can be scheduled (this is clearly
nich, Boltzmannstraße 3, D-85748
Garching
Member of the Board of Directors at the Leibniz
Supercomputing Centre (LRZ)
Email:schu...@in.tum.de<mailto:schu...@in.tum.de> <mailto:schu...@in.tum.de>
*From:*mpi-forum
mailto:mpi-forum-boun...@lists.mpi-forum.org>
<mailto:mp
I am in agreement with all that has been said so far -- generally, this is
great. Minor tweaks (already cited by George and Joseph) would be nice
improvements.
On Sep 3, 2021, at 5:46 PM, Gropp, William D via mpi-forum
mailto:mpi-forum@lists.mpi-forum.org>> wrote:
One option is to use a diff
I can't imagine a vendor would:
- support mpi_f08
- then stop supporting mpi_f08 just so that they can get an "MPI-4.0" release
out
- then support mpi_f08 again
I think their users would be very unhappy.
On Jan 10, 2021, at 10:55 AM, William Gropp via mpi-forum
mailto:mpi-forum@lists.mpi-foru
...or MPI-4.1 or whatever it is that we're nominating for right now.
[https://i.imgflip.com/4pv31j.jpg]
On Dec 10, 2020, at 2:11 PM, Jeff Squyres (jsquyres) via mpi-forum
mailto:mpi-forum@lists.mpi-forum.org>> wrote:
I nominate Wesley Bland for MPI-5 secretary.
--
Jeff Sq
I nominate Wesley Bland for MPI-5 secretary.
--
Jeff Squyres
jsquy...@cisco.com
___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
On Sep 10, 2020, at 10:22 AM, William Gropp wrote:
>
> I think this is an editorial fix, though with chapter committee review.
Sounds good. I already review/approved -- I'll pass it on to the bindings
committee, too.
--
Jeff Squyres
jsquy...@cisco.com
___
A handful of routines in the bindings chapter accidentally escaped
Pythonization.
Martin R. just Pythonized them:
https://github.com/mpi-forum/mpi-standard/pull/276
Does this qualify as an errata? (i.e., does it need a reading+vote)
Or is it an editorial fix?
Or is is a chapter committee chang
Two in a single day: announcing another all-new, exciting errata item!
https://github.com/mpi-forum/mpi-issues/issues/307
The C bindings for MPI_STATUS_F082C and MPI_STATUS_C2F08 are missing "const".
3.x and 4.0 PRs and PDFs are attached to the issue.
Enjoy!
--
Jeff Squyres
jsquy...@cisco
Announcing an all-new, exciting errata item!
https://github.com/mpi-forum/mpi-issues/issues/306
In MPI-3.1, the Fortran INTEGER-array-style status object constant
MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, and MPI_ERROR are explicitly only defined
in Fortran. This does not make sense, because F
The Fortran/language bindings working group would like to announce the
following issue and associated pull requests for reading at the next Voting
Meeting:
* "Fortran errata: Clarify where TYPE(MPI_Status) type must be defined":
https://github.com/mpi-forum/mpi-issues/issues/298
* MPI-3.x err
ding.
>
> Cheers,
> Marc-Andre
>
> On 03.02.20 23:25, Jeff Squyres (jsquyres) via mpi-forum wrote:
>> The Embiggenment WG is ready for a formal reading at the Feb 2020 Portland
>> MPI Forum physical meeting.
>>
>> Issue: https://github.com/mpi-forum/mpi-issue
The Embiggenment WG is ready for a formal reading at the Feb 2020 Portland MPI
Forum physical meeting.
Issue: https://github.com/mpi-forum/mpi-issues/issues/137
PR:https://github.com/mpi-forum/mpi-standard/pull/132
PDF: attached to Feb 3, 2020 comments on the issue/PR
(this PDF inclu
Thank you to all Chapter Chairs/Committees who completed reviews. The
Pythonization effort is nearly complete.
Note that this is essentially a "ticket 0" PR. Based on the feedback from the
ABQ Forum meeting and discussions afterwards, we strove to make Pythonization
as much of a no-op as po
Here's the slides we presented in the Virtual meeting today (Pythonization /
Embiggening status):
https://docs.google.com/presentation/d/1vnuKbWXfmegj4EDiq6Aj7BmkXV6cHkMOSu8SREF0i5w/edit#slide=id.p
--
Jeff Squyres
jsquy...@cisco.com
___
mpi-foru
The Pythonization group has Pythonized the bindings in the entire document.
We've completed a first correctness pass over the work, but we need more eyes
to compare the end result of our work to the (non-Pythonized) head of the
mpi-4.x branch.
Some of you have already done your review. Thank
Thanks Guillaume!
Some of those things -- particularly the widow/orphan stuff -- likely won't be
handled until the near-completion of the MPI-4 doc. But it sounds like barring
your minor fixes cited below, we Pythonized chapter 6 correctly. Thanks!
> On Jan 6, 2020, at 3:10 AM, Guillaume Me
ck what has been done / what still needs to be done.
Please review ASAP.
Thank you.
On Dec 18, 2019, at 2:47 PM, Jeff Squyres (jsquyres) via mpi-forum
mailto:mpi-forum@lists.mpi-forum.org>> wrote:
Bill Gropp (the MPI Standard document Editor) has two PRs with "ticket 0"
On Dec 24, 2019, at 9:08 PM, Guillaume Mercier via mpi-forum
wrote:
>
> I did just that:
> make PYTHON=/usr/bin/python3.8 cleandoc
>
> But the result is the same:
Yes, that does not work right now -- we'd have to add that. I was asking if
that would be useful to you. I guess the answer is y
and I don't want to change that.
Is there a way to modify your scripts/makefiles so that I can force
it to consider python 3.8 instead (and not change my system)?
Thanks.
Guillaume
On 12/18/19 8:47 PM, Jeff Squyres (jsquyres) via mpi-forum wrote:
Chapter Committees / Chairs --
We need Ch
hange that.
Is there a way to modify your scripts/makefiles so that I can force
it to consider python 3.8 instead (and not change my system)?
Thanks.
Guillaume
On 12/18/19 8:47 PM, Jeff Squyres (jsquyres) via mpi-forum wrote:
Chapter Committees / Chairs --
We need Chapter Committees to review thei
Chapter Committees / Chairs --
We need Chapter Committees to review their chapters in three sets of upcoming
document-wide changes that are slated to be merged "soon".
After you complete a review, please put an "X" in the corresponding row/column
for your chapter and the specified PR in this Go
This is not going to be a formal reading for the December meeting (because
we're not expected to be done by then), but we will present the bindings
Pythonization effort in December.
The end effect will be a "largely ticket 0" result on the MPI-4 document, but
since this touches nearly every cha
Martin --
We probably need some plenary time for the Pythonization effort.
Technically, it's a "ticket 0" change (and we won't have all of it done/ready
by the T-2 week deadline tomorrow). But it does touch a giant portion of the
spec. How do you want to handle it?
On Nov 23, 2019, at 4:56
Pythonization (THIS WILL AFFECT ANYONE WHO WORKS IN THE LATEX!):
https://docs.google.com/presentation/d/1dcyTuX4My-M9lwL9g2zEqAKuFQuL3dulCfN44YngLgM/edit
Embiggenment:
https://docs.google.com/presentation/d/13X_4moTKxIHB0YJI-bBlJ5V3bF2WywB1DfOOvSzH8Cc/edit
--
Jeff Squyres
jsquy...@cisco.com
_
This was discovered after the 2-week window for the Zurich meeting. If this
can't make it into the Zurich meeting agenda, please put it on the meeting
agenda for December.
It's a trivial one-word fix in the language-neutral binding for
MPI_UNPACK_EXTERNAL -- needs to be applied to both the mpi
Some points:
1. C11 _Generic support in an MPI implementation has to be optional, at least
for now, because not all compilers support C11 _Generic (just like the F08
bindings are still optional, and just like aspects of the C++ bindings were
optional back in the '90s when C++ compilers still ha
SHORT VERSION
=
Due to the possibility of silently introducing errors into user applications,
the BigCount WG no longer thinks that C11 _Generic is a good idea. We are
therefore dropping that from our proposal. The new proposal will therefore
essentially just be the addition of a
On Jul 31, 2019, at 12:59 PM, Jeff Hammond wrote:
>
> “C++ compilers shall produce the same result as C11 generic.” Why does this
> need to say anything different for profiling and tools? Is this impossible?
Is there a way to have C++ overloading call the same symbols that we'll
dispatch to fr
On Jul 31, 2019, at 12:14 PM, Jeff Hammond wrote:
>
>> You're ignoring the long tail of consequences here -- what about PMPI/tools?
>> What about other C++ features that we should be using, too? ...?
>
> No scope creep. No slippery slope. Do the one thing we need to go and stop.
> Leave the
On Jul 31, 2019, at 11:59 AM, Jeff Hammond wrote:
>
> It’s a long email to read on my phone while on vacation.
Then stop reading on your phone while on vacation and defer this until next
week! ;-)
> If you don’t say C++, there’s no reason OMPI and MPICH can’t do the obvious,
> trivial and i
On Jul 31, 2019, at 10:52 AM, Jeff Hammond wrote:
>
> You’re going to have to mention C++. You can’t just pretend that C++ supports
> C11 generic, because it explicitly doesn’t.
We are mentioning C++. Please re-read my prior email.
> And you really should do this because it’s ridiculous not
On Jul 31, 2019, at 4:31 AM, Joseph Schuchart via mpi-forum
wrote:
> Should we mark in the interface the fact that the MPI_Count overloads are
> only available in C11? I'm thinking about something similar to cppreference's
> distinction between C/C++ standard versions, e.g.,
>
>
> ```
> int
pears second in the chapter?
>
> Get Outlook for Android
>
> From: mpi-forum on behalf of Jeff
> Squyres (jsquyres) via mpi-forum
> Sent: Tuesday, July 30, 2019 11:13:09 AM
> To: MPI Forum list
> Cc: Jeff Squyres (jsquyres)
> Subject: [Mpi-forum] "BigCount" r
Forum members:
Slides 12 and 15 from the "Big Count" presentation today have links to sample
PDFs showing the different options for rendering the MPI function bindings both
throughout the text and in Annex A.
We're sending you these links so that you can view these PDFs on your own
screens a
Track 2 is tools.
> On May 28, 2019, at 2:17 PM, Jithin Jose via mpi-forum
> wrote:
>
> Hi Marc Andre,
>
> We are just setting it up, please wait for a few more minutes.
>
> Thanks.
> Jithin
>
> -Original Message-
> From: mpi-forum On Behalf Of
> Marc-Andre Hermanns via mpi-forum
9am or 10am US Eastern on 10/31 works for me.
> On Oct 24, 2018, at 12:24 PM, Anthony Skjellum via mpi-forum
> wrote:
>
> Dear Forum Members:
>
> We would like to schedule a meeting about "new language bindings" as an
> action item from our virtual last meeting (just ended).
>
> This cover
42 matches
Mail list logo
