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

[Jean-Michel Campin]

Hi Martin,

two things:
1) I've checked that MPI_COMM_RANK is not blocking (can be called
  by only a subset of procs) so I added this call in the OASIS block
  and add argument "procId" to EESET_PARMS as suggested before.
  This should make your coming set of changes simpler.
2) the set of changes you propose seems good to me. And for now,
 I would set this USE_FORTRAN_SCRATCH_FILES in CPP_EEOPTIONS.h 
 and not worry about genmake_local.

Cheers,
Jean-Michel

On Wed, Jul 26, 2017 at 10:16:45AM +0200, Martin Losch wrote:
> Hi Jean-Michel,
> 
> I suggest to test this now as you say, i.e. check in an eeset_parms.F where only the appropriate close statements are ammended with STATUS=???DELETE??? (which in my opinion should always work, since this option is F77 standard, but you never know ???), but also have (at least) one testreport-verification-experiment use the USE_FORTRAN_SCRATCH_FILES flag, so that it is always tested (that???s a bit annoying, since it would be the only experiment with it???s own CPP_EEOPTIONS.h file, or can this be put into some genmake_local?)
> 
> Martin
> 
> > On 25. Jul 2017, at 18:17, Jean-Michel Campin <jmc at mit.edu> wrote:
> > 
> > An other thing:
> > Are we 100% sure that closing a scratch unit file with status "delete" 
> > is completly standard on all platforms & compilers ? If not, we could
> > test just this independently (i.e., check-in and see how daily test run). 
> > The reason is that when someone chose to use USE_FORTRAN_SCRATCH_FILES,
> > (which is not going to be the default and therefore not tested) we need to be 
> > sure that the close instruction is OK.
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel