(j3.2006) (SC22WG5.5029) WG5 vote on draft TS on further coarray features

Bill Long longb
Sun Jul 21 15:55:12 EDT 2013

If the application needs a name for the initial team, you can form a 
team in the main program with every image specifying the same team (1). 
   For the purposes of cosubscripts, this team is the same as the 
initial team.


On 7/21/13 9:29 AM, Tobias Burnus wrote:
> 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
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

More information about the J3 mailing list