[MITgcm-devel] mnc error message
Ed Hill
ed at eh3.com
Tue Mar 28 11:09:07 EST 2006
On Tue, 2006-03-28 at 16:26 +0200, Martin Losch wrote:
> Hi Ed,
>
> this problem is clearly not (directly) connected to the mitgcmuv
> executable, but to the run-time environment. I have come to this
> (unsupported) conclusion: somehow the buffers of the machines got
> corrupted and tried to write the buffer again (e.g. my STDOUT files
> ended way before the end of the model config summary, so that buffer
> was not flushed either). As I anticipated, I could not reproduce this
> problem: in an exact repetition the runs is now way beyond the
> previous crashpoint.
> The only thing that would help, would be an mnc behaviour that allows
> overwriting existing mnc-files, but then the may be other problems.
Hi Martin,
Well, I'm glad its (probably) not a bug in MITgcm per se.
And in regards to file overwriting, I think its a very sloppy practice.
A number of folks have complained about how easy it is to accidentally
delete things (esp. results that have taken a long time to generate!)
using the default-overwrite behavior of MDSIO.
Are you aware that MNC can either create output directories or use
pre-existing directories? The default is to create directories with an
ordinal number appended which is very safe and simple for repeated runs
(it just keeps creating more directories) but it can cause some
confusion on MPI runs where a lot of directories (one per MPI process)
are the result. So, for the MPI case, you can set:
# in data.mnc:
mnc_use_outdir=.TRUE.,
mnc_outdir_str='some/path/name',
mnc_outdir_date=.FALSE.,
mnc_outdir_num=.FALSE.,
which tells MNC to create no output directories and use the one you
specify within mnc_outdir_str. So, before running MITgcm, you'll need to
either create the directory manually or within your run scripts. And
this dir you specify may be an absolute path (that is, starting from the
root of the file system) or relative path from the current working
directory. Its very flexible and it allows you to write scripts that
can, even in the MPI case, easily keep track of all the output files.
Plus, it can help you keep your output cleanly separated from the input
files and from the results of previous runs.
Ed
--
Edward H. Hill III, PhD
office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave.
Cambridge, MA 02139-4307
emails: eh3 at mit.edu ed at eh3.com
URLs: http://web.mit.edu/eh3/ http://eh3.com/
phone: 617-253-0098
fax: 617-253-4464
More information about the MITgcm-devel
mailing list