To: J3 J3/13-333
From: Bill Long, Tobias Burnus
Subject: THIS_TEAM intrinsic
Date: 2013 September 30
References: N1983, N1989
Overview
--------
This paper contains a portion of the responses to the comments in
N1989, the results of the ballot on the TS 18508 draft N1983. The
following identifiers are used to indicate the source of comments:
Reinhold : Reinhold Bader Bill : Bill Long
Tobias : Tobias Burnus Nick : Nick Maclaren
Daniel : Daniel Chen Dan : Dan Nagel
Malcolm : Malcolm Cohen John : John Reid
Steve : Steve Lionel Van : Van Snyder
along with {Ed} for the document editor.
Discussion
----------
A ballot comment proposes a new intrinsic, THIS_TEAM ( ). The
following is extracted from N1989.
---
{Tobias 1}: N1983 permits at some places the use of a team variable,
which refers to the ancestor team. In particular in image selectors:
"[team-variable :: cosubscript-list]".
The PDTS requires that the team-variable was assigned a value by a
FORM SUBTEAM statement. However, that makes it rather complicated to
access the initial team (which encompasses all images). [Or the
current subteam, in case that the caller has already done some
partition before calling a procedure (in a library), which creates
further subteams.] Hence, I think it would be useful to have an
intrinsic procedure, which sets the value of the current team to a
team-variable. assuming For instance, "subroutine
this_team(team-variable)". One could add an optional "distance"
argument but as the caller has to be aware (for practical use) of the
image indexes, it is probably not needed.
One usage case would be a partition in a climate model into air, land
and sea (cf. Annex A.1) where one exchanges every few iterations
information for the boundaries between different subteams. This could
be done in the "air" subteam via "boundary[parent_team ::
sea_neighbor] = values; event post(data_is_there[parent_team ::
sea_neighbor])". Without the new subroutine, one had either leave the
subteam, exchange the boundaries, and re-enter. (Implies two global
synchronizations for end change team/change team for each exchange.)
Or one had to form an artificial subteam, which encompasses all of the
images of the (current, initial) team. The effect of the latter would
be similar to the proposed "this_team()" except that it is uglier and
requires three pointless synchronization (form subteam, change team,
end change team) - but at least not during the iteration.
---
{Ed}: An additional use case involves the need to access the parent
team variable in an image selector in a subprogram where the name
originally given to the parent team is not known. A local name for
the same team can be constructed and used.
THIS_TEAM would be a more efficient alternative to constructing a name
for the initial team.
If accepted, this feature would require a new subclause 7.4.14+,
modification to C501 to allow a new context for defining a variable of
TEAM_TYPE, and modifications to [10:13] to allow a variable defined by
THIS_TEAM to be used in a CHANGE TEAM construct.
Response: (TBD) This is a new feature that will require a committee
vote.
Edits to N1983:
--------------
(TBD)