(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 :: 

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.
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.


More information about the J3 mailing list