[MITgcm-support] scratch1.00000#### in run directory

Matthew Mazloff mmazloff at ucsd.edu
Wed Sep 26 18:54:02 EDT 2018


Hi Ivana

I think setting
#define SINGLE_DISK_IO
in CPP_EEOPTIONS will reduce it to just one set of files 

defining/undefining 
 TARGET_CRAYXT
in CPP_EEOPTIONS will also change how scratch files are written

Usually when I have a namelist error (which it sounds like you have) there is a job log output file that tiles me what line in scratch is the problem

If not you could try stripping down data.exf and adding lines back in one at a time….

Matt

Matt




> On Sep 26, 2018, at 1:20 PM, Ivana Escobar <ivana at utexas.edu> wrote:
> 
> Hi from Texas,
> 
> I’m working on debugging my data.* files to get a problem to run. When it crashes, I get two series of files in my run directory: 
> scratch1.00000#### (I get one for each processor I call for, 698 in my case)
> scratch2.00000#### (numbering goes up to 698 in my case, but file count is way less)
> 
> The contents of the files vary from being completely empty to containing data.exf content, which is where I think my bug is. I am not sure how I turned on this level of debugging, but can anyone suggest which series of flags control printing these large quantity of files?
> 
> Thank you,
> 
> Ivana Escobar
> Graduate Student
> The University of Texas at Austin
> The Institute for Computational Engineering and Sciences
> POB 3SEi4D
> ivana at utexas.edu <mailto:ivana at utexas.edu>
> (210) 788-1499
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20180926/34c1972a/attachment.html>


More information about the MITgcm-support mailing list