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)