Dear all, I would like to request a first reading for the following changes: *RMA: MPI_REQUEST_FREE is not allowed to clean up RMA requests* Issue: https: //urldefense. us/v3/__https: //github. com/mpi-forum/mpi-issues/issues/760__;!!G_uCfscf7eWS!ZzaXoP1-rHDUS8JWsYsU7SMRd22mnloUljnqA5ppfkka0EnH
Hi all, I'd like to get some feedback on the work to integrate hyperlinks for symbols. The work is almost done but there are some decisions to be made. PR: https: //urldefense. us/v3/__https: //github. com/mpi-forum/mpi-standard/pull/954__;!!G_uCfscf7eWS!dIPhZiHNIVkUlz25pTMfwlI1fGc76y1kucfANGL
Dear all,
I'd like to read the current state of the MPI Continuations proposal to
gather further feedback and chart a route for possible publication as a
side document. The current version of the proposal can be found at [1].
Thanks
Joseph
[1]
https://github.com/mpiwg-hybrid/hybrid-issues/
Martin, all,
I went through the issues grouped under the RMA chapter (Chapter 12) and
found that some of them are issues in the I/O chapter: rows 228-259
(except for row 239) seem relevant for the I/O chapter and not the RMA
chapter. I guess there has been some confusion about document and PDF
The RMA WG would like to read the following errata:
RMA chapter committee changes
Issue: https://github.com/mpi-forum/mpi-issues/issues/745
PR: https://github.com/mpi-forum/mpi-standard/pull/857
These changes were somehow missed for the 4.1rc and will likely address
many of the issues reviewers
Dear Forum,
On behalf of the RMA WG I would to request a second vote on the
following MPI-4.1 ticket:
*RMA accumulate operations don't distinguish between throughput and
latency sensitive applications*
Issue: https://github.com/mpi-forum/mpi-issues/issues/640
PR: https://github.com/mpi-forum
Dear all,
The RMA WG would like to request the following votes:
No-no-vote and subsequent 1st vote:
*RMA accumulate operations don't distinguish between throughput and
latency sensitive applications*
Issue: https://github.com/mpi-forum/mpi-issues/issues/640
PR: https://github.com/mpi-forum/mp
Dear Wes, all,
On behalf of the RMA working group, I would like to request the
following readings and votes. All PRs should have an auto-generated PDF
attached.
Reading:
*RMA accumulate operations don't distinguish between throughput and
latency sensitive applications*
Issue: https://githu
Dear all,
On behalf of the RMA WG I'd like to make the following voting and
reading requests for the February meeting:
Second votes:
*RMA: Add missing win-sync calls to Example 12.21*
Issue: https://github.com/mpi-forum/mpi-issues/issues/553
PR: https://github.com/mpi-forum/mpi-standard/pull
Dear all,
I'd like to request a no-no-vote and first vote for the following ticket:
*Deprecate mpif.h*
Issue: https://github.com/mpi-forum/mpi-issues/issues/561
PR: https://github.com/mpi-forum/mpi-standard/pull/722
Changes since the last reading:
https://github.com/mpi-forum/mpi-standard/pull/
On behalf of JeffH I'd like to request a no-no reading and first vote
for the following issues/PRs addressing language interoperability issues:
*add MPI_Status_{set,get} for 3 status fields*
Issue: https://github.com/mpi-forum/mpi-issues/issues/645
PR: https://github.com/mpi-forum/mpi-standard/p
Hi Wes,
I believe we're missing a no-no-vote for issue #429 (RMA: Replace
'operation' with 'operator' where appropriate), which had changes since
the first reading. The rest looks good from our side.
Thanks
Joseph
On 11/18/22 18:14, Joseph Schuchart wrote:
Dear all,
On behalf of the RMA WG
On behalf of JeffH I'd like to request the first reading of the
following issues/PRs addressing language interoperability issues at the
December 2022 meeting:
*add MPI_Status_{set,get} for 3 status fields*
Issue: https://github.com/mpi-forum/mpi-issues/issues/645
PR: https://github.com/mpi-foru
I'd like to push three more items to the heap of first reading requests
for the RMA chapter:
*RMA communication procedures should have local semantics*
Issue: https://github.com/mpi-forum/mpi-issues/issues/653
PR: https://github.com/mpi-forum/mpi-standard/pull/769
This change depends on the larg
Yes, if the Forum agrees that it's an errata then we can vote on it
right away.
Thanks
Joseph
On 11/21/22 09:21, Wes Bland wrote:
#634 is marked as errata. Should I schedule this for a vote as well?
Thanks,
Wes
On Nov 18, 2022, at 5:14 PM, Joseph Schuchart via mpi-forum
wrote:
Dea
Dear all,
I'd like to request the reading of the following ticket:
*Deprecate mpif.h*
Issue: https://github.com/mpi-forum/mpi-issues/issues/561
PR: https://github.com/mpi-forum/mpi-standard/pull/722
I'd like to request the second vote for the following ticket:
*MPI_*_GET_NAME functions accept
Dear all,
On behalf of the RMA WG I'd like to request a first reading of the
following tickets:
*Add info key for RMA accumulate behavior preference*
Issue: https://github.com/mpi-forum/mpi-issues/issues/640
PR: https://github.com/mpi-forum/mpi-standard/pull/749
PDF:
https://github.com/mpi-fo
Since I (and likely others) are interested in both I'd prefer them to be
separate :)
Thanks
Joseph
On 9/14/22 14:35, Wes Bland wrote:
Can these be in parallel? Or do they need to be separate?
On Sep 14, 2022, at 1:31 PM, Joseph Schuchart via mpi-forum
wrote:
Martin, all,
Both th
Martin, all,
Both the RMA and HACC WGs have expressed interest in a slot for WG
discussions at the September meeting in Chattanooga. Will there be time
for a few hours each to discuss topics with the broader forum? I
understand that we only have 2.5 days but maybe this can be a backfiller...
I'd like to request a first vote for the following ticket:
*Allow MPI_*_GET_NAME functions to accept MPI_*_NULL handles*
PR: https://github.com/mpi-forum/mpi-standard/pull/652
Issue: https://github.com/mpi-forum/mpi-issues/issues/544
This had a reading and a no-no vote at the last meeting.
Than
All,
The RMA WG would like to read the following tickets at the September
2022 meeting in Chattanooga:
*Allow MPI_WIN_SHARED_QUERY on created and allocated windows*
- Ticket: https://github.com/mpi-forum/mpi-issues/issues/23
- PR: https://github.com/mpi-forum/mpi-standard/pull/708
*MPI_Win_fr
A gentle reminder, please feel free to distribute where you see fit :)
Apologies if you receive multiple copies.
*Future of MPI RMA Workshop (FoRMA'22)*
https://mpiwg-rma.github.io/forma22/
The MPI RMA Working Group is organizing a virtual workshop aimed at
gathering input from users and impl
[Apologies if you got multiple copies of this email.]
*1st Future of MPI RMA Workshop (FoRMA'22)*
https://mpiwg-rma.github.io/forma22/
The MPI RMA Working Group is organizing a workshop aimed at gathering
inputs from users and implementors of MPI RMA with past experiences and
ideas for improv
I'd like to read the following proposal at the May 2022 meeting on
behalf of JeffS:
- MPI_*_GET_NAME functions accept MPI_*_NULL handles:
https://github.com/mpi-forum/mpi-standard/pull/652
We will address Rolf's comment on the PR about the strings in the
appendix later today and may have to
The RMA WG would like to read the following proposals:
- Fix semantic terms in RMA chapter:
https://github.com/mpi-forum/mpi-standard/pull/611
- RMA: Add missing win-sync calls to Example 12.21:
https://github.com/mpi-forum/mpi-standard/pull/663/files
- MPI_Win_free is synchronizing, except whe
Hi Wesley,
If there is still time, I would like to give a high-level overview of
MPI Continuations (preferably towards the end of the meeting). I will
prepare a couple of slides to introduce the topic, hoping for some early
feedback from the broader forum.
Thanks
Joseph
On 11/26/21 2:48 PM
All,
I'd like to announce a reading of the following two tickets:
#637 RMA: Replace 'operation' with 'operator' where appropriate:
https://github.com/mpi-forum/mpi-standard/pull/637
Addresses: https://github.com/mpi-forum/mpi-issues/issues/429
#611 Fix semantic terms in RMA chapter:
https://
I am working on the fix for Open MPI. The modular infrastructure and
lazy initialization there makes this challenging in some places. For
example, during communicator creation we don't yet know which collective
module will serve which collective operation. Assume we have a
hypothetical custom i
p
Director, NCSA
Thomas M. Siebel Chair in Computer Science
University of Illinois Urbana-Champaign
IEEE-CS President-Elect
On Sep 3, 2021, at 1:40 PM, Joseph Schuchart via mpi-forum
<mailto:mpi-forum@lists.mpi-forum.org>> wrote:
I am OK with leaving out line numbers in tables. Maybe that
I am OK with leaving out line numbers in tables. Maybe that will be
solved in the future.
One comment I had was on the code formatting. While I definitely prefer
the lstlistings formatting over the verbatim we have so far, I find the
bold highlighting somewhat distracting. I find it hard to fo
Wesley,
I do not have a strong opinion on this question. However, you keep
mentioning that the testing infrastructure is broken. I wasn't at the
last meeting so I must have missed the discussion there. How would
moving to a repo restore the testing infrastucture?
Cheers
Joseph
On 2/3/20 8:5
Hi Martin,
I would like to request the second vote for ticket 121 (memory alignment):
Ticket: https://github.com/mpi-forum/mpi-issues/issues/121
PR: https://github.com/mpi-forum/mpi-standard/pull/96
PDF:
https://github.com/mpi-forum/mpi-issues/files/3886563/mpi-report-issue-121_2019-11-25-13.28
Sorry y'all, this wasn't meant for everyone :( I really need to fix my
thunderbird's address book...
On 11/25/19 3:43 PM, Joseph Schuchart via mpi-forum wrote:
Hallo Marc-André,
Jannis und ich hatten uns auf der SC kurz über MPI und Task-basierte
Programmiermodelle ausgetausch
Hallo Marc-André,
Jannis und ich hatten uns auf der SC kurz über MPI und Task-basierte
Programmiermodelle ausgetauscht. Wir sind uns mehr oder wenig einig,
dass MPI ein Interface braucht, das es dem Nutzer erlaubt asynchron über
den Abschluss von Operationen hinter einem Requests benachrichtig
I would like to request the first vote for ticket 121 (memory alignment):
Ticket: https://github.com/mpi-forum/mpi-issues/issues/121
PR: https://github.com/mpi-forum/mpi-standard/pull/96
PDF:
https://github.com/mpi-forum/mpi-issues/files/3886563/mpi-report-issue-121_2019-11-25-13.28.pdf
(change
Dear all,
I would like to request the reading of the following two proposals at
the Zurich meeting:
*Memory Alignment*
Ticket #121: https://github.com/mpi-forum/mpi-issues/issues/121
PR: https://github.com/mpi-forum/mpi-standard/pull/96
PDF:
https://github.com/mpi-forum/mpi-issues/files/3528
Jed,
On 8/13/19 5:54 AM, Jed Brown via mpi-forum wrote:
"Jeff Squyres \(jsquyres\) via mpi-forum"
writes:
Let me ask a simple question: how will users to write portable MPI programs in
C with large count values?
Answer: they will explicitly call MPI_Send_x(), and not rely on C11 _Generic.
so makes it impossible to do
anything at all because there’s always somebody too ignorant to use some
feature correctly, and the union of the ignorance covers all nontrivial
changes.
Jeff
On Thu, Aug 1, 2019 at 7:28 AM Joseph Schuchart via mpi-forum
mailto:mpi-forum@lists.mpi-forum.org>&
I think the point he wanted to make was that you won't see a
compile-time error if you /think/ you're using the MPI_Count overloads
but are in fact not, i.e., you are modernizing a legacy code base that
is stuck in the nineties and you introduce MPI_Count for size arguments
because the standard
I agree with Jeff H that excluding C++ from the BigCount polymorphism
seems unfortunate (and unintuitive for C++ developers). The _Generic
selectors in C11 map a call to MPI_YYY() to either MPI_YYY(int) or
MPI_YYY_x(MPI_Count). A C++ interface could do the same, with some macro
work in the back
Jeff,
The first look at the definitions might indeed be a bit confusing, as it
is strange to see overloaded C functions (even though C11 _Generic has
been around for a while). It is also not clear when the second variant
(using MPI_Count) is available, that is only if C11 _Generic is
supporte
Hi Martin,
I would like to read the Memory Alignment ticket (#121) again and
hopefully get it to a vote. The RMA ordering ticket needs some more work
from my side and I am not yet sure I will have enough time to work on it
before the Zurich meeting. I will know more in 2 weeks :)
Best
Joseph
All,
Please find below the links relevant for today's virtual meeting:
*Memory Alignment*
Issue: https://github.com/mpi-forum/mpi-issues/issues/121
PR: https://github.com/mpi-forum/mpi-standard/pull/96
PDF:
https://github.com/mpi-forum/mpi-issues/files/3324565/mpi-report-issue-121_2019-06-25_11
Dear all,
I would like to request the reading of the following two proposals at
the Chicago meeting:
Memory Alignment:
Issue #121: https://github.com/mpi-forum/mpi-issues/issues/121
PR #96: https://github.com/mpi-forum/mpi-standard/pull/96
Annotated PDF:
https://github.com/mpi-forum/mpi-issue
Schuchart via mpi-forum wrote:
Dear MPI forum members,
[Apologies for double-posting, I did not receive a notification for my
previous mail and it does not show up in the archives]
I would like to request a reading of the changes proposed in issue #121
"Clarify alignment of memory provid
Dear MPI forum members,
[Apologies for double-posting, I did not receive a notification for my
previous mail and it does not show up in the archives]
I would like to request a reading of the changes proposed in issue #121
"Clarify alignment of memory provided to applications":
https://github
46 matches
Mail list logo
