From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Dec 10 01:54:06 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 0CAE43582EF; Tue, 10 Dec 2013 01:54:06 +0100 (CET) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1189 seconds by postgrey-1.34 at www5.open-std.org; Tue, 10 Dec 2013 01:54:05 CET Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by www.open-std.org (Postfix) with ESMTP id 28CBC3581CB for ; Tue, 10 Dec 2013 01:54:04 +0100 (CET) Received: from ndmsppt103.ndc.nasa.gov (ndmsppt103.ndc.nasa.gov [198.117.0.68]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 8FC91A8009; Mon, 9 Dec 2013 18:34:13 -0600 (CST) Received: from NDMSCHT115.ndc.nasa.gov (ndmscht115-pub.ndc.nasa.gov [198.117.0.215]) by ndmsppt103.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id rBA0YDRq014546; Mon, 9 Dec 2013 18:34:13 -0600 Received: from [10.44.125.166] (199.115.243.182) by smtp02.ndc.nasa.gov (198.117.0.215) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 18:34:12 -0600 Content-Type: multipart/alternative; boundary="Apple-Mail=_8B091489-5252-4C28-8416-5D3C33D21FE7" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: (j3.2006) (SC22WG5.5138) image selectors From: Tom Clune In-Reply-To: <20131209235209.B17BB3582CB@www.open-std.org> Date: Mon, 9 Dec 2013 19:34:09 -0500 CC: sc22wg5 Message-ID: <58C3552A-D330-43F6-BBB3-A9E1562A58DE@nasa.gov> References: <20131204000730.3A09F3582D0@www.open-std.org> <1386116202.16299.164.camel@math.jpl.nasa.gov> <52A39BE9.2060403@cray.com> <20131209230519.94A273582C9@www.open-std.org> <52A64FCB.3080901@cray.com> <20131209235209.B17BB3582CB@www.open-std.org> To: , fortran standards email list for J3 X-Mailer: Apple Mail (2.1510) X-Originating-IP: [199.115.243.182] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.72,1.0.14,0.0.0000 definitions=2013-12-09_03:2013-12-09,2013-12-09,1970-01-01 signatures=0 Sender: owner-sc22wg5@open-std.org Precedence: bulk --Apple-Mail=_8B091489-5252-4C28-8416-5D3C33D21FE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Dec 9, 2013, at 6:52 PM, Van Snyder wrote: > On Mon, 2013-12-09 at 17:18 -0600, Bill Long wrote: >>=20 >> On 12/9/13 5:05 PM, Van Snyder wrote: >>>> OK. Reinhold's revised ballot reworded this idea in terms of the = image >>>>> index in the initial team rather than physical processors. That = is >>>>> arguably better terminology to use. The image's image index in = the >>>>> initial team never changes throughout the program execution. >>=20 >>> I assume this refers to Reinhold's message of 2 December. That >>> message's attachment did not include any comments concerning 5.1. = The >>> problem is that "image indices are relative to a specified team" at >>> [9:5-6] does not give any information concerning the correspondence >>> between coindices in parent teams and subteams, nor does = "cosubscripts >>=20 >> See [11:21-22]. The program can explicitly specify the new image = index.=20 >> Otherwise it is processor dependent. >=20 > I think that means that in most applications one must specify = NEW_INDEX. > Why make it optional? >=20 > Instead of "assigned by the processor" the term "processor dependent" > should be used. >=20 > Better yet would be to specify the mapping from parent team to = subteam. > If NEW_INDEX is not specified, is there really a difficulty with > specifying, for example, that the image indices for the subteam are in > the same order as the image indices in the parent team, so that image > index 1 for the subteam applies to the image with the smallest image > index in the parent team that becomes part of the subteam, etc.? I'll second that. ince many applications will be ported from MPI, the = principle of "least surprise" should be invoked here. Unless there is a = reason to the contrary, the MPI convention for subcommunicator ranks = should apply to subteam image indices. MPI allows redefining ranks as = well, but I've only used that once (maybe) in 20+ years of coding in = MPI. - Tom >=20 >>> are interpreted as if the current team were the team specified by >>> " at [11:4]. Without standardizing this, indexing = with >>> respect to ancestor teams is not useful. I tried in vain to find = this >>> mapping in 5.3 -- 5.5. The addition of DISTANCE to THIS_IMAGE = doesn't >>> seem to do the job. >=20 >=20 > _______________________________________________ > J3 mailing list > J3@mailman.j3-fortran.org > http://mailman.j3-fortran.org/mailman/listinfo/j3 Thomas Clune, Ph. D. = Chief, Software Systems Support Office Code 610.3 NASA GSFC = 301-286-4635 MS 610.8 B33-C128 = Greenbelt, MD 20771 --Apple-Mail=_8B091489-5252-4C28-8416-5D3C33D21FE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" Van.Snyder@jpl.nasa.gov> = wrote:
On Mon, 2013-12-09 at 17:18 -0600, Bill Long = wrote:

On 12/9/13 5:05 PM, Van Snyder = wrote:
OK. =  Reinhold's revised ballot reworded this idea in terms of the = image
index in the initial team rather than = physical processors.  That is
arguably better terminology to = use.  The image's image index in the
initial team never changes = throughout the program = execution.

I assume this refers to Reinhold's message of 2 December. =  That
message's attachment did not include any comments = concerning 5.1.  The
problem is that "image indices are relative = to a specified team" at
[9:5-6] does not give any information = concerning the correspondence
between coindices in parent teams and = subteams, nor does "cosubscripts

See [11:21-22]. =  The program can explicitly specify the new image index. =
Otherwise it is processor dependent.

I think = that means that in most applications one must specify NEW_INDEX.
Why = make it optional?

Instead of "assigned by the processor" the term = "processor dependent"
should be used.

Better yet would be to = specify the mapping from parent team to subteam.
If NEW_INDEX is not = specified, is there really a difficulty with
specifying, for example, = that the image indices for the subteam are in
the same order as the = image indices in the parent team, so that image
index 1 for the = subteam applies to the image with the smallest image
index in the = parent team that becomes part of the subteam, = etc.?

I'll second that. =   ince many applications will be ported from MPI, the = principle of "least surprise" should be invoked here.  Unless there = is a reason to the contrary, the MPI convention for subcommunicator = ranks should apply to subteam image indices.   MPI allows = redefining ranks as well, but I've only used that once (maybe) in 20+ = years of coding in MPI.

- = Tom




are = interpreted as if the current team were the team specified = by
<team-variable>" at [11:4].  Without standardizing = this, indexing with
respect to ancestor teams is not useful.  I = tried in vain to find this
mapping in 5.3 -- 5.5.  The addition = of DISTANCE to THIS_IMAGE doesn't
seem to do the = job.


________________________________= _______________
J3 mailing list
J3@mailman.j3-fortran.orghttp://mailman.= j3-fortran.org/mailman/listinfo/j3

Thomas Clune, Ph. = D.  = <Thomas.L.Clune@nasa.gov>
Chief, Software Systems Support Office = Code 610.3
NASA GSFC = 301-286-4635
MS 610.8 B33-C128 = = <http://ssso.gsfc.nasa.gov>
=
Greenbelt, MD = 20771





= --Apple-Mail=_8B091489-5252-4C28-8416-5D3C33D21FE7--