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

[Jean-Michel Campin]

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

On Sun, Sep 29, 2013 at 04:13:50PM +0000, Menemenlis, Dimitris (3248) wrote:
> Thanks Matt, we tried what you describe below and
> it hangs the lustre file system for large processor counts.
> A temporary fix is to remove all the comments from
> the parameter files, so as to avoid having to write
> any scratch files altogether.  I was hoping to find
> a less manual solution.  But you are correct that
> what is there right now is not fool proof.
> 
> Dimitris Menemenlis
> 
> On Sep 29, 2013, at 9:03 AM, Matthew Mazloff wrote:
> 
> > Hi Dimitris
> > 
> > This won't really work as I think the problem is that the processors are slightly out of sync...
> > Letting each processor write its own scratch file is a much safer way. And its already coded -- just define TARGET_BGL or TARGET_CRAYXT
> > 
> > I set 
> > #define TARGET_CRAYXT
> > in CPP_EEOPTIONS.h
> > 
> > -Matt
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel