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

[Tobias Burnus]

Van Snyder wrote:
> An alternative to a new this_team() intrinsic, or executing a FORM 
> SUBTEAM statement, is a team variable in ISO_Fortran_env, whose value 
> is the initial team.

But that's not quite the same. Assume you have a larger code, where you 
partition the task into two subteams. From one of the subteams you call 
a library function. If now the library wants to partition the problem 
into another set of subteams, it needs to know the current team and not 
the initial team.

> I still think the idea of putting "team_variable ::" ahead of 
> cosubscripts is a bad idea.  I would rather see a syntax for 
> coassociation, along the lines of the ASSOCIATE statement, in the 
> CHANGE TEAM statement.

The advantage of "team_variable :: " to change team is that one can 
access an image of a different team without the need of a full 
synchronization.

Current coarray code is often slow (if a large number of CPUs is used) 
as most time is spend with communication, and communication mostly 
means: waiting. Event post/wait (and event query) are supposed to remove 
the need of synchronization. - If one uses teams, the issue of 
communicating with other teams often occurs; and in case only some data 
needs to be exchanged, some means to do so without full synchronization 
is useful. The "team_variable ::" syntax permits this. (For instance, 
pushing the new boundary values and posting an even that it is now 
available.)

I am not sure what do you mean by coassociation. I also do not really 
see the relation to ASSOCIATE as changing a team - and then accessing 
coarrays in the team. It seems that you propose something which requires 
to list all used coarrays in the change team construct, which sounds 
complicated and error prone. Additionally, I do not understand how this 
will work with called procedures, which, e.g. access a use-associated 
coarray - or one passed as actual argument to a coarray dummy argument.

Tobias