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

[Van Snyder]

Tobias Burnus wrote:
> 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.

Sure.  But one could pass around team variables, if only you had one for 
the initial team to start the process with.

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

The problem with "team_variable ::" is that the child team needs to know 
the mapping from the parent team's image numbers to the child team.  If 
the child team knows that, what was the point of executing the CHANGE 
TEAM construct?

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

Yes, it would require listing them all.  I agree this could be tedious.  
It does, however, provide a functionality we cannot even get with 
argument association.  Maybe it doesn't solve the present problem 
ideally, but the present method doesn't admit a "team" solution to the 
following problem:

Suppose you have a 2-D grid of images, say 10x10 (after verifying there 
are 100 images).

Suppose you want to divide into four subteams, and have each one work on 
a 5x5 quadrant.  There's no mechanism, other than the "team_variable ::" 
mechanism, to give [1:5,1:5] to subteam 1, [1:5,6:10] to subteam 2, 
[6:10,1:5] to subteam 3, and [6:10,6:10] to subteam 4.  This isn't even 
valid syntax.  There's no concept of sequence association during 
procedure calls.  It can probably be done with corank-1 coarrays, but 
for higher coranks, I don't see how to do it.  Maybe I missed something, 
but it seems there's no clean "team" way to address this problem, which 
seems to fit rather well with the other poster children for teams.

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

The use-associated case doesn't work.  That is an argument for something 
like a "subteam pointer" concept.  For an ordinary array, one might put 
pointers to the array sections that each team is to work on in a 
module.  There's nothing comparable for coarrays.  E.g., assume A is an 
array and B is a pointer, C is a coarray and D is a "coarray pointer."  
We have

  b => a(i:i+4,j:j+4)

but nothing like

  d => c[i:i+4,j:j+4]

which one might do just before a CHANGE TEAM construct to allow a team 
to access a module coarray.  The CHANGE TEAM construct does this 
automatically for corank-1 coarrays, but offers no help for higher 
corank coarrays.

The argument-associated case does work if the subteam-associated coarray 
is passed, not the original one.  The processor needs to pass the 
mapping from "real" images to subteam images along with every coarray, 
so that it can do the image index mapping "under the covers," but I 
think that's needed in any case.

>
> Tobias