[J3] (SC22WG5.6294) Fwd: BOUNCE sc22wg5 at open-std.org: Non-member submission from [John Reid <John.Reid9 at talktalk.net>]

[David Muxworthy]

> 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 [62.24.135.134])
> 	(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] ([92.20.143.4])
> 	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;
> 	bh=R7aiDEfjS+VACXYMKYlxj1JULZIprtfKtEEdnuzsO3M=;
> 	h=To:Cc:From:Subject:Date;
> 	b=IhH8YiKRvSKPaMTHXUsJFK5JGL95PAImNT3iC7qX+Oqm+hYqCfzXXeDhYZX+hXxOm
> 	 AS5x68gSJBnDYBIQQ3tho5d490J1Tagxz5TH0tOJGBIYf0cvjJ8W+Y5MhG1oGMtSF/
> 	 YadZst0cbo1f8Av+CaCkAn8BRIE0pkd/r6cqwUTA=
> X-Originating-IP: [92.20.143.4]
> 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
> 69XrktKfAe5V1P6dHf12UNhsF5MIVZlvaVvySIXpFb37KRPLsuc3IvMQx6AO6EzOshFN2Fm+m5c/AFYjaVrePXRcllb0QpdXoKvnffC72kpZEMvRaq2zpH5/
> 
> 
> 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[1]
> near the end of DO outer may be replaced by
>     IF (team_number == 2) done = done[1]
> 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[1]" 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.
> 
>