(j3.2006) teams paper

[Van Snyder]

On Fri, 2013-02-01 at 18:01 -0600, Bill Long wrote:
> The paper submit process seems to be broken for the moment.  I've put 
> the file 13-teams.txt in the HPC folder on the server.   When the server 
> is more cooperative I'll submit is as a m200 paper.  In the mean time, 
> feel free to download a copy.

[T6] The term "ancestor team" appears not to be rigorously defined.

Replace "teams variable" by "team variable" and "teams-variable" by
"team-variable" throughout.  Or at least be consistent the other way.
Make TEAMS_TYPE consistent with whatever the decision is here.

[5.1p1] Replace "All images" by "All image"

[5.1p1] Delete "data on" because other aspects of images outside the
current team, such as the ability to synchronize, are also inaccessible.

[5.1p1] Replace "a call of" by "invoking"

[5.1p1 final sentence] Separate run-on sentence into two sentences.
Doesn't a team variable also indicate the team of which an image is a
member?

[5.1p2] Replace "back to the previous team" by "to the parent team".

[5.2 R501] Replace "end-team-stmt" by "end-change-team-stmt"

[5.2 C503] Can a team variable be a coindexed object here?  Indeed, can
a team variable be a coindexed object anywhere?  If not, this makes a
team variable a weird beast:  It is required to be a coarray, but cannot
be coindexed.  I think allowing it to be one is extremely risky.  Do we
really want to encourage things like

  call Atmosphere_Model ( team[42] )

In those places where a team variable is required to be an ancestor of
the current team, using an integer ancestor index (zero being the
current team, one being the parent team, etc., negative being an error)
would preclude the possibility of specifying a team variable that
denotes a team that is not an ancestor of the current team.  By
providing a TEAM_DEPTH() intrinsic function, and using an ancestor
index, the ROOT_TEAM constant (is it really a constant?) would not be
needed.

If "team variable" were replaced by "ancestor index," the only places
team variables occur would be in CHANGE TEAM statements and references
to FORM_TEAMS (which ought to be a statement, not an intrinsic
subroutine).  Since those are both synchronization points, it wouldn't
be necessary for team variables to be coarrays.  In any case, it doesn't
seem necessary (indeed risky rather than useful) that team variables are
coarrays.  Since TEAM_TYPE is opaque, it could have coarray components
if the implementation needs them.

[5.2 after C503] Replace "a call of" by "invoking"

[5.2 after C503] Replace "the call of" by "invoking"

[5.2 after C503] First sentence would be clearer as something like "The
<scalar-team-variable> shall have been defined by invoking the intrinsic
subroutine FORM_TEAMS.  The team that defined <scalar-team-variable>
shall be the current team."  The second sentence is confusing.  There is
no image specified in a reference to FORM_TEAMS.  Should "executing
image... FORM_TEAMS" be "image that invoked FORM_TEAMS"?

[5.2 second paragraph after C503]  Second sentence would be clearer and
simpler as "An allocatable coarray that is allocated during execution of
the CHANGE TEAM construct is deallocated when execution of the construct
completes."  This seems to be extremely difficult to do.  A processor
will need to keep track of every allocatable coarray accessible in the
current scope, and every allocatable coarray elsewhere that has the SAVE
attribute (not just the ones accessible in the construct), keep an
indicator whether they were allocated when the construct commenced
execution, then check the indicator when execution of the construct
completes.  Maybe it's better to say "shall be deallocated, or becomes
undefined if not deallocated", thereby putting the onus on the program
instead of the processor.

[5.2 final paragraph] Is it really necessary to define here what
"synchronization" means?

[5.3p1] Where is the constant ROOT_TEAM?  ISO_FORTRAN_ENV?  Is it really
a named constant, or is it a protected variable?  If a variable, does it
have the TARGET attribute?

[5.3p1] Replace "a call of" by "a reference to" since functions aren't
"called".

[5.4] Not really a comment on this paper:  This illustrates that we
really should have provided enumerations that are new types.  If
STAT_*_IMAGE were enumerators of a variety of enumeration type that does
not permit duplicates (e.g., ordered enumerations as described in
04-139), the words about "different from ..." would be unnecessary.

[5.5] 5.2 -- 5.4 would be clearer if 5.5 were after 5.1.

[5.5] Is an extension of TEAMS_TYPE allowed to have length parameters,
or allocatable or pointer components?

[7.3.6a] COLOR seems like a poor choice for a name for a new intrinsic
function.  Almost guaranteed to invalidate numerous programs that have
implicit interfaces.  It also has no value answering the "what the hell
is this" question.  How about "SUBTEAM_INDEX"?  A facility to retrieve
the COLOR seems to be superfluous.  At least in the example, what would
be difficult about replacing COLOR() with 1+MOD(ME,2)?  Given that
THIS_IMAGE can get the index of the current image in any ancestor team,
one could compute a number that would serve the purpose of COLOR, at
least as used in the example.  One could store the color of a subteam of
which the current image is a member in a (probably non-coarray)
variable.  Am I missing something important here, or is it merely a
convenience that the "color" of a subteam is (apparently) stored in the
team variable?

[7.3.6a] Example is opaque.  Insert "ME = IMAGE(INDEX)" before the
reference to FORM_TEAMS.  Change the comments to "Code for images that
had odd [even] image numbers in the parent team".

[7.3.13] Why is FORM_TEAMS a subroutine instead of a "FORM TEAMS"
statement?

[7.3.13 COLOR argument] How does one know the "number of subteams"?  Is
it the number of distinct values of the COLOR argument on all the images
invoking the FORM_TEAMS subroutine?  It seems difficult for a processor
to tell at run time that N images are trying to divide into three teams
with COLOR indices of, say, 1, 2 and 42.  If a program were to attempt
to do this, what happens?  An undetectable error condition?  It would be
easier to detect and respond to this error if FORM_TEAMS were a FORM
TEAMS statement, with STAT= and ERMSG= specifiers.  Instead of
(apparently) requiring the processor to detect that COLOR indices are in
the range 1 ... number of subteams, why not simply specify that the
number of subteams is the number of distinct COLOR indices (which the
processor has to deduce anyway), and allow the COLOR indices to be
arbitrary?

[7.3.13 TEAMS argument] TEAMS seems like a misleading choice for a dummy
argument name.  How about TEAM, since the actual argument is required to
be a scalar?

[7.3.13 INDEX argument] Allowing to permute the image indices seems to
be a superfluous feature.  Why can't the images keep track of this
themselves?

[7.3.13 paragraph after INDEX argument] Replace "store ... belongs" by
"represent the subteam of which the executing image is a member."
Replace "new team created" by "subteam represented by the TEAMS
variable".

[7.3.13 second example] What does this illustrate?  It seems like the
result is the same as if INDEX were not present.

[7.4.2+] If team variables are not replaced by ancestor indices in those
places where the team variable is required to denote an ancestor of the
current team, an intrinsic function to return a pointer to the current
team variable would be useful, so that one could later use it in a
reference to THIS_IMAGE.  For the same reason, it would be useful to
have an intrinsic function (perhaps the same one) to return a pointer to
an ancestor of the current (or a specified) team variable.

I agree that some examples are needed to replace the last line of the
paper.  An example showing, for example, formation of subteams indexed
merge(1,2,THIS(IMAGE)<=NUM_IMAGES()/2), and subteams 1+MOD(ME,2), and
then alternating blocks using those teams, would illustrate why team
variables, as opposed to using simply ancestor indices and subteam
indices (colors -- ugh), are useful at all.

It would also be useful to show an example where subteams are formed,
the current team is changed to a subteam, and further subteams are
formed.  Then the CHANGE TEAM constructs are exited.  Later, the team is
changed to the first level of subteams, and then to the second level,
maybe in a loop, without forming new subteams.