[J3] (SC22WG5.6294) Fwd: BOUNCE sc22wg5 at open-std.org: Non-member submission from [John Reid <John.Reid9 at talktalk.net>]
d.muxworthy at icloud.com
Thu Oct 8 13:18:59 EDT 2020
> From owner-sc22wg5 at www.open-std.org Thu Oct 8 17:49:29 2020
> Return-Path: <owner-sc22wg5 at www.open-std.org>
> Delivered-To: sc22wg5 at open-std.org
> X-Greylist: delayed 487 seconds by postgrey-1.34 at www5.open-std.org; Thu, 08 Oct 2020 17:49:29 CEST
> Received: from smtp-out-6.tiscali.co.uk (smtp-out-6.tiscali.co.uk [18.104.22.168])
> (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
> (No client certificate requested)
> by www.open-std.org (Postfix) with ESMTP id 5E8D23568C0
> for <sc22wg5 at open-std.org>; Thu, 8 Oct 2020 17:49:29 +0200 (CEST)
> Received: from [192.168.1.10] ([22.214.171.124])
> by smtp.talktalk.net with SMTP
> id QY2ckQWIhXXMUQY2cke00l; Thu, 08 Oct 2020 16:41:14 +0100
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=talktalk.net;
> s=cmr1711; t=1602171674;
> X-Originating-IP: [126.96.36.199]
> To: WG5 <sc22wg5 at open-std.org>
> Cc: Nathan Weeks <weeks at iastate.edu>
> From: John Reid <John.Reid9 at talktalk.net>
> Subject: Vote on interps
> Message-ID: <933b5c67-03a9-7f7d-299b-f0ba65f19009 at talktalk.net>
> Date: Thu, 8 Oct 2020 16:41:19 +0100
> User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101
> Firefox/60.0 SeaMonkey/2.53.2
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 8bit
> X-CMAE-Envelope: MS4wfEQTbg4AVDca63JXvAqeNan3/3x4sm0bncljWNQxZT/8jmho+B/W/TtvuWJVX7ro2SkYVk50SrkLfpZK3/IZEwkF1XGhCxkKpEtAt9GXT5J6bQBCdel0
> The following Fortran 2018 interpretations are being balloted:
> Yes No Number Title
> -Y- --- F18/001 ACOSH principal value specification is wrong
> -Y- --- F18/002 Internal procedures in generic interface blocks
> -Y- --- F18/003 Pointer association of component of non-definable selector
> -Y- --- F18/004 Program execution sequence with failed images
> -Y- --- F18/005 Does INPUT_UNIT really identify the same unit as *?
> -Y- --- F18/006 Connection of INPUT_UNIT on different images
> -Y- --- F18/008 Contradictory assumed-rank requirements
> -Y- --- F18/009 Bad examples in IEEE_ARITHMETIC functions
> -Y- --- F18/010 Categories of pure procedures
> -Y- --- F18/011 Categories of elemental procedures
> -Y- --- F18/012 Internal procedure in a generic interface
> -C- --- F18/013 TEAM_NUMBER arguments and intrinsic function are ambiguous
> -Y- --- F18/014 Type of OPERATION arguments to the REDUCE intrinsic
> --- -N- F18/015 Example in C.6.8 is wrong
> -Y- --- F18/016 Host association changes in Fortran 2018
> -Y- --- F18/017 Final subroutine invocation order
> -Y- --- F18/018 Public namelist and private variable
> Comment on F18/013.
> Edit for [20:30] 3.145.4 team number, definition.
> The edit and its expanded version are not consistent. I suggest
> removing "(5.3.4)" from the expanded version. I think that this
> reference is unnecessary with the term "sibling teams" defined
> (see edit for [20:27+] Terms and definitions).
> Reason for no vote on F18/015.
> Nathan Weeks has pointed out to me that there are three problems with
> the new code for C.6.8 in N2176, viz
> 1. The code for choosing the number of spares does not correspond to
> the comment for it.
> The simplest solution is to change "10" to "9" in
> the line
> images_spare = MAX(NUM_IMAGES()/100,0,MIN(NUM_IMAGES()-10,1))
> but I prefer the suggestion of Anton Shterenlikht to replace this
> line by
> images_spare = 0
> if ( NUM_IMAGES() .GE. 10 ) images_spare = 1
> if ( NUM_IMAGES() .GE. 200 ) images_spare = NUM_IMAGES()/100
> It is absolutely clear what this does, which I see as an example of
> good practice. It does not need a comment to explain what is going on.
> Therefore I suggest changing the comment to
> ! Choose how many images to keep as spares.
> 2. The variable images_used is incremented only on image 1 but is
> referenced by other images near the beginning and end of DO outer.
> The statement
> IF (THIS_IMAGE () > images_used) done = done
> near the end of DO outer may be replaced by
> IF (team_number == 2) done = done
> which avoids the problem here and I think it is an improvement anyway.
> A simple solution for the use of images_used near the beginning
> of DO outer in the statement
> team_number = MERGE (1, 2, local_index<=images_used)
> is to make images_used a coarray and replace "images_used" by
> "images_used" in this statement. This will need the addition of a
> SYNC ALL statement just before the statement
> outer : DO
> to ensure that the correct value is used on all images on the
> first iteration of the loop.
> 3. The intention is that on each cycle of the DO iter loop, a
> calculation is performed on the worker images and if any of them fail
> during this, the calculation is resumed from a checkpoint with the
> failed images replaced by spares. On resumption, the variable
> read_checkpoint should have the value true on all the worker images
> so that they access the checkpoint data. On a replacement image,
> this variable will still have its initial value of false.
> A simple way to fix this is to change the initial value of
> read_checkpoint to true. The subroutine simulation_procedure will need
> to keep track of which checkpoint data to use or that none is
> available because this is an initial call. The statement
> read_checkpoint = .FALSE. ! Initial startup, not from checkpoint.
> should be replaced by the statement
> read_checkpoint = .TRUE.
> This ensures that read_checkpoint has the value true on a spare
> image when it first comes into use. For clarity I also suggest
> changing the declaration of read_checkpoint to
> LOGICAL :: read_checkpoint ! If read_checkpoint true on entering
> ! simulation_procedure, go back to previous check point if one
> ! exists.
More information about the J3