[MITgcm-support] mnc questions

[Martin Losch]

Ed,
I think what Michael is looking for (appart from limiting the netcdf 
file size) is the capability to store each variable in a separate 
netcdf file, such as
Eta.timestep.tilenumber.nc or just Eta.tilenumber.nc
T.*.nc
S.*.nc
etc.
just like the mdsio-file. This is how MOM does it sometimes, as far as 
I know. This capability makes sense, when the domains become terribly 
large so that one snapshot may be larger than 2GB. (I think this 
happens in Dmitites hr_cube, doesn't it? When the state snapshot 
requires som 1.5GB and the diagnostics (old timeave) 3.5GB just for the 
state.)

Michael,
I think in your case you still don't need to worry about file sizes. 
The MNC-pkg is so clever that it starts a new file, once the old one 
reaches the file size limit (which is below 2GB by default). So you'll 
get a series of files each containing less than 2GB (or mnc_max_fsize), 
which you can than manipulate to extract the variables you are 
interested in as Ed has pointed out.

Martin

On Dec 16, 2005, at 8:02 AM, Ed Hill wrote:

> On Fri, 2005-12-16 at 00:03 -0600, Michael Schaferkotter wrote:
>> hi ed:
>>
>> the genmake tells the story:
>>
>> ===  Checking system libraries  ===
>>   Do we have the system() command using pgf77...  yes
>>   Do we have the fdate() command using pgf77...  no
>>   Do we have the etime() command using pgf77...  yes
>>   Can we call simple C routines (here, "cloc()") using pgf77...  no
>>   Can we use stat() through C calls...  no
>>   Can we create NetCDF-enabled binaries...  yes
>>
>> 'no' to 'Can we use stat()...'.
>>
>> the mnc_max_fsize should have been set to around 20MB. i/m trying to 
>> get one set of variables per dump per .nc file.
>>
>> the remark about the .nc files being the same size was in regard to 
>> the fact that i had altered mnc_max_fsize and the
>> 'before' and 'after' sizes didn/t change. now we know why...because 
>> 'we cannot use stat() through C calls...'.
>>
>> am i now to point of customizing the mnc pkg code?
>
> Hi Michael,
>
> No, I don't think it requires any coding.  I think we just need to
> figure out how to coax your PGI compiler into calling C subroutines 
> from
> Fortran.  And I think all that means is editing your optfile so that it
> either uses the PGI C compiler by setting:
>
>   CC='pgcc'
>
> or by setting the correct name-mangling syntax such as:
>
>   FC_NAMEMANGLE="#define FC_NAMEMANGLE(X) X ## _"
>
> when using another C compiler such as gcc.  Please see the syntax in 
> the
> existing optfiles in:
>
>   MITgcm/tools/build_options/*
>
> for examples of the above settings.
>
> Ed
>
> ps - We have v5.2 of the PGI compiler suite (which includes the Fortran
> and C compilers) installed on some of our Fedora Core 3 systems and I
> just confirmed that it is able to use the C-provided stat() function
> (and is correctly tested by genmake2) when using the PGI C compiler.  
> So
> it certainly *can* be done with the PGI compilers on at least some 
> Intel
> systems with the optfile:
>
>   MITgcm/tools/build_options/linux_ia32_pgf77+authors_fc3
>
>
> -- 
> 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
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support