[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