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

Baylor Fox-Kemper baylor at MIT.EDU
Mon Apr 23 11:04:43 EDT 2007


Hi Mark,
   I like using the mnc_outdir_str, which specifies a name for the  
outgoing directory.  You can then name it whatever you want, (e.g.,  
run1 or novisc) and move things around that way.  You can let it add  
numbers or dates on the end (mnc_outdir_num=.true.,  
mnc_outdir_date=.true.), but I usually do that myself so I know what  
the full name of the directory will be.  I do fancier stuff with  
scripting when I submit big jobs, e.g., make soft links to fast  
drives, automatically rename the directories or edit the data.mnc  
with sed on the fly, etc.
   -Baylor


On Apr 23, 2007, at 10:33 AM, Martin Losch wrote:

> Mark,
>
> I agree that mnc not overwriting existing files is a bit odd  
> sometimes. But I think you should be fine with  
> mnc_use_outdir=.false. if you just remove all grid.t???.nc files  
> before restarting. The monitor files are not a problem as they  
> follow the name convention monitor_$pkg.$niter0.t???.nc, niter0=0  
> if you start from rest and >0 if you start from a pickup.
> If you want to use mnc_use_outdir=.true., why don't you just link  
> all files into a common directory, eg. "ln -s mnc*/*.nc ." before  
> running gluemnc?
>
> Further recommendation: Personally I have reverted to mdsio for  
> pickup-files (mnc_write/read_pickup=.false.) in conjunction with  
> useSingleCPUio = .true., (in data). This gives me one pickup file  
> per package and not, say, 72, the seaice pkg (if you are using it)  
> doesn't have netcdf pickup files anyhow. Also with this global  
> pickup file you can easily change the number of tiles for the  
> second segment, if you choose to do so. useSingleCPUio=.true. may  
> also be faster on some machines where cpus access a global file  
> system (I am told and that's also my experience).
>
>
> Martin
>
> On 22 Apr 2007, at 23:56, 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?
>>
>> -- 
>> Mark Hadfield          "Ka puwaha te tai nei, Hoea tahi tatou"
>> m.hadfield at niwa.co.nz
>> National Institute for Water and Atmospheric Research (NIWA)
>>
>>
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support




More information about the MITgcm-support mailing list