Meeting - 21th June 2017

Protocol of the GASPI Forum meeting on June, 21th, 2017, Frankfurt/Main

Date: 2017.06.21
Location: Frankfurt/Main, Wilhelm-Fay Straße 54
Start: 11:00h
End: 16:00h


  • Fraunhofer ITWM (Mirko Rahn)
  • ZIH, TU Dresden (Olaf Krzikalla, Ralph Müller-Pfefferkorn)
  • DLR (Thomas Gerhold, Barbara Brandfass)
  • IMEC (Tom van der Aa)
  • LRZ (Christoph Bernauer)

Not eligible to vote:

  • Heidelberg University (Mareike Schmidtobreik)
  • Tartu University, Estonia (Benson Muite)


13.00-13.30 Attendees, Quorum, next Forum meeting, Actions Items
13.30-14.00 Errata Proposals
14.00-15.00 General text proposal
15.00-15.15 Coffee break
15.15-15.30 Voting
15.30-17.00 GASPI Context, Migration from legacy codes

Errata Proposals

Various: Olaf Krzikalla raised a number of questions regarding definitions in the standard

  • GASPI standard has a definition for non-blocking, but its not used. Could be removed
  • Wikipedia has different definitions of blocking, non-blocking, time-based blocking proposal: remove all three and enhance the time out definition Such a change in the specification needs a merge request for all critical functions make an explanation on blocking, non-blocking.
  • gaspi_wait is defined in the standard both as „time-based blocking local“ and „asynchronous non-local time-based blocking“ - needs to be fixed
  • Definition of non-local in specification: remove „(and execution“) because it implies a processing question: Should the GASPI standard restrict functions to be local only? No, a) as there might be implementations using something remotely (e.g. data sctructures) and 2) as long there is no other restriction from the GASPI standard definition of synchronous
  • What means „progress towards completion“? Need to refine this term. Actually a function isn’t a/synchronous, but the process the function triggers.
  • Olaf Krzikalla was asked to open issues in github to continue the discussion

General Text Proposals

read_list_notify: Christian Simmendinger asked to add a new function gaspi_read_list_notify to the standard specification.

  • voting: unanimously accepted


Persistant queues: Christian Simmendinger: Should we establish a persistent communication using queues?

  • Example: one queue per local neighbor. The assumption is that it would improve performance as it would save routing overhead (costs for newly establishing communication channels)
  • What about resource usage of queues? Should not be a problem, number. No change in the specification needed, but concept could be introduced in the best practice guide and tutorial
  • Other possibility for persistent communication: use connect to get back a channel but this would be new concept, user should not need to care about
  • Why did MPI introduce persistent communication? What were the reasons (performance related nitty gritty details) ? Christian Simmendinger will continue to explore this issue.

Shared segments: Christian Simmendinger:

  • shared segments over processes. shared data, shared notifications between processes e.g. for halo exchange, collect data along a number of processes that form a segment. High speedups expected, exists as prototype, demo application planed. no change of standard needed
  • How to know which processes are part of a shared segments? There is no GASPI call – only GPI calls or MPI calls currently

Christian Simmendinger: GASPI header files (Fortran, c) are licence free now (no more GPL)

  • Commercial software (like Gromacs) can use them now
  • GPLs license inheritance (the need to publish again as GPL) is a problem for commercial usage.

Mirko Rahn

  • GASPI/GPI is part in several European projects, where code is ported to GASPI.
  • Exploitation of all GASPI features and thus getting significant improvements is often hard due to time constraints in the projects.

Web site

  • Provide a link from the GASPI web site to the GASPI Forum in github - Simmendinger
  • Provide a (link)list of projects/codes using GASPI - Simmendinger

Tom van der Aa: Could we arrange a GASPI hackathon?

  • with application developers to port programs to GASPI
  • How to get developers involved? Ideas needed


  • at LRZ Munich: Christopher Bernauer will arrange a date (not in conjunction with extreme scale workshop)
  • Benson Muite: Will ask at CSC (Finland) for a GASPI tutorial/hackathon

Next meeting:

  • January, 10 2017 in Frankfurt
Written on June 14, 2017