[MITgcm-support] MNC usage comment & more powerful version of gluemnc

Jill N Schwarz jschwarz at awi-bremerhaven.de
Mon Apr 23 03:02:36 EDT 2007


Hey Mark,

You can comment out/switch off the option in  /input/data.mnc to create 
new input directories - that way, all output is dumped in the run 
directory.  Eg:

 &MNC_01
#mnc_use_outdir=.TRUE.,
#mnc_outdir_str='mnc',
#mnc_outdir_date=.TRUE.,
 snapshot_mnc=.true.,
#monitor_mnc=.false.,
 pickup_write_mnc=.false.,
 pickup_read_mnc=.false.,
 &

Hope that helps a little,
jill.

Mark Hadfield wrote:

> I'm trying to set up some reasonably large model runs with MNC output. 
> It's not clear to me how to arrange things for efficient management of 
> the output files and I'd appreciate some advice.
>
> It seems to be a fundamental design decision of the MNC package that 
> it will not overwrite existing netCDF files. This seems a little odd 
> to me, but there you go.
>
> OK, so I am running the model in two segments, the second being 
> started from the pickup files of the first. If I set MNC_USE_OUTDIR to 
> .FALSE. then the second run fails when trying to write monitor_grid 
> files, so I set MNC_USE_OUTDIR to .TRUE. and MNC_OUTDIR_DATE to 
> .FALSE. and I get my netCDF output in a bunch of directories, one per 
> processor per model run. These happen to be 72-processor MPI runs, so 
> the two model runs generate 144 directories.
>
> At the end I want to combine all the state files from these runs, so I 
> cd to the parent of the MNC output directories and type
>
> gluemnc mncout*/state*.nc
>
> This fails because gluemnc can't handle input file names with 
> directory separators in them. I have hacked gluemnc to avoid this 
> limitation. This hacking involved liberal use of the basename command 
> and I *think* it's working OK now.
>
> But this all seems awfully hard. Am I doing it wrong? Is there an 
> easier way of setting these things up?
>




More information about the MITgcm-support mailing list