[MITgcm-devel] [MITgcm-cvs] MITgcm/eesupp/src CVS Commit

[Jean-Michel Campin]

Hi Dimitris,

On Sun, Sep 29, 2013 at 07:21:34PM +0000, Menemenlis, Dimitris (3248) wrote:
> Jean-Michel thanks for taking a look.
> I am still experimenting with this on lustre and pleiades
> so will wait until it works before I modify again.
> But I will definitely follow your advice below,
> or revert  to old version if I don't succeed.
> 
> Two questions:
> 
> 1- Do we need to write scratch2 to disk?
> Seems to be identical to original parameter files.

scratch2 seems to be used to report on STDOUT. My impression (but I 
can be wrong; may be Chris remembers why it's coded this way)
is that, since what is written to STDOUT (scratch2) is processed the 
same way (through temp scratch copy) as what is realy loaded (scratch1),
this also allows to check (by looking to STDOUT) that this temp scratch
write/read works.

> 2- Is it OK to use
> CALL MPI_BARRIER( MPI_COMM_MODEL, mpiRC )
> in open_copy_data_file.F?
I think it's what you want (no thread barrier but an MPI barrier),
and, as I can see, you already made this change.

Just a detail (no effect since, as I mentionned, S/R OPEN_COPY_DATA_FILE
is generally called from master thread only): I would limit MPI call to
only master thread (my experience is that it does not work very well to 
allow all threads to do MPI calls), which means the _END_MASTER / _BEGIN_MASTE
inside #ifef SINGLE_DISK_IO could be removed.

> Sorry I thought this would be a trivial change
> but seems like I opened a small can of worms.
> I should not have checked in code so carelessly.
> 
> Dimitris Menemenlis

There is no problem here. I think that it would be nice to find a way to
continue to have all procs reading eedata (I am not concerned about other
data* files, just eedata) but if this prevent to run your set-up, we clearly 
need to do something.

Cheers,
Jean-Michel

> On Sep 29, 2013, at 9:51 AM, Jean-Michel Campin wrote:
> 
> > Hi Dimitris,
> > 
> > I took a quick look at the pieces you added:
> > 1) in open_copy_data_file.F:
> > this S/R is always (from what I know) called by master thread only,
> > so that adding a _BARRIER in it will always break the multi-threaded
> > run. 
> > Also, does not seems to use "mpiRC" that you added, and 
> > not sure why we need to add #include "EESUPPORT.h"
> > 2) in eeset_parms.F:
> > this S/R is sometimes called directly from eeboot_minimal.F,
> > before myProcId being set. 
> > Could you a STOP like this:
> >  IF ( .NOT.doReport ) STOP 'ABNORMAL END: S/R EESET_PARMS: myProcId unset'
> > within #ifdef SINGLE_DISK_IO / #endif
> > before using myProcId
> > 
> > Cheers,
> > Jean-Michel
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel