[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