[MITgcm-devel] [altMITgcm/MITgcm66h] Bugfix/scratch files (#11)

[Martin Losch]

Hi Jean-Michel,

maybe better to move this to the devel list, because it is really something that we can now only test in the “real repository”:

- Previously the STOP statement was exclusive to SINGLE_DISK_IO, I did not change that, see the CVS-repository. Do we have a single regular test anywhere, where we check this SINGLE_DISK_IO code?
- yes, it's exactly like the TARGET_BGL or TARGET_CRAYXT code, except that now, the associated close statements have a CLOSE(iUnit,STATUS='DELETE'), so that the files are deleted. This STATUS='DELETE' is default for files that are opened with STATUS='SCRATCH’. Now i just do it implicitly.

Maybe I can check-in all the close statements for now (they should not change anything, because for the “SCRATCH” status files, it’s the default anyway), have everything tested overnight and then do the other two changes in eeset_parms and open_copy_data_file
OR
(which may be easier), just do this for eeset_parms.F because that’s simple and requires only changing one file.

Martin

> On 24. Jul 2017, at 16:37, jm-c <notifications at github.com> wrote:
> 
> Hi,
> 
> It requires more tests. For instance, I read in "eeset_parms.F", line 137:
> > C Stop if called from eeboot_minimal.F before myProcId is set
> this will also apply to scratchFile1 & 2 settings.
> 
> Also, it seems that the new way is similar to what was done with
> TARGET_BGL or TARGET_CRAYXT defined (or may be I missed something).
> May be keeping the old way (i.e., OPEN(UNIT=scrUnit1,STATUS='SCRATCH'))
> but changing the default would allow -- in case some problems occur on/with
> some disk systems -- to continue to use what currently works.
> 
> Cheers,
> Jean-Michel
> 
> On Mon, Jul 24, 2017 at 10:41:53AM +0000, christophernhill wrote:
> > @mjlosch I think the change look good generally. I need to talk to @jm-c to see if there are catches. At present we don't have testreport pulling from github for different machines, but we should start that soon I think. That means its hard to check if this breaks something.
> > 
> > Best way to check this is to put in CVS fairly soon, lets see what @jm-c says first though. For a real commit though it would be good to use I9.9 for myProcId (we are running on 100,000+ cores these days). An alternative would be to use a funky internal write and macros for the format string e.g
> > in a header file (EEMACORS.h ?)
> > ```
> > #define FMT_MYPROC_ID I9.9
> > ```
> > and then
> > ```
> > WRITE(FMT, ......
> > ```
> > which is a bit annoying, but more flexible going forward. 
> > 
> > 
> > -- 
> > You are receiving this because you were mentioned.
> > Reply to this email directly or view it on GitHub:
> > https://github.com/altMITgcm/MITgcm66h/pull/11#issuecomment-317385174
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.
>