(j3.2006) (SC22WG5.5029) WG5 vote on draft TS on further coarray features
Tobias Burnus
burnus
Sun Jul 21 10:29:29 EDT 2013
John Reid wrote:
> This is a WG5 letter ballot on N1983, the second draft DTS for
> TS 18508, Additional Parallel Features in Fortran.
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.
Tobias
More information about the J3
mailing list