[MITgcm-support] a problem with EXF

[Matthew Mazloff]

Hi Ming,

I am a bit surprised; I just looked at the EXF & MNC package and I don't 
the model is able to read in NetCDF format input files.  Maybe someone 
in the know can tell us what the status is of using NetCDF input. 

Anyway, I know the model can read in binary input files and the 
precision is given by exf_iprec = 32 (or 64).  I actually sent an email 
under the thread name "Starting with MITgcm" that was about generating 
input files a few weeks ago which I'll append below.  You should easily 
be able to tell if the forcing fields are being read in correctly.   
Check the monitor statistics for your forcing fields and see if they 
seem reasonable.  Also, if the model crashes because it cannot find an 
input file, it should give an error message that includes the name of 
the file it last looked for.  Remember that if you give the input file 
name exf_input.data and the model can't find this file it may append a 
".data" on it and try again.  So if the error says it can't find 
exf_input.data.data that's why. 

And just in case you were referring to the previous issue of array 
precision, I'll add that exf_yftype refers to the precision with which 
the exf package should read arrays.  Your choices are RL for REAL*8 or 
RS for REAL*4. 

once again hoping I'm giving accurate info,
Matt


Here's the old email:

Hi Matej,

As Ed said, the verification experiments have matlab scripts that 
describe preperation of input files. For example, in MITgcm / 
verification / exp5 / input / gendata.m
a surface forcing file is made:

Q=Qo*(1+0.01*rand([nx,ny]));

it is size [nx,ny]
if it were 3-d (e.g. and initial theta file) it would be size [nx,ny,nz]

then it is written with

fid=fopen('Qnet.circle','w','b');
fwrite(fid,Q,'real*8');
fclose(fid);

The data is written by fwrite down the matrix columns.

it is written translated into real*8 because the mitgcm data file given 
in the verification experiment has
readBinaryPrec=64,

it is read in as a surface heating file by putting
# Input datasets
&PARM05
surfQfile='Qnet.circle',
&
in the data file
other possible initial files you can give the model are (as seen in  
MITgcm / model / src / ini_parms.F )
C--   Input files
     NAMELIST /PARM05/
    & bathyFile, topoFile,
    & hydrogThetaFile, hydrogSaltFile,
    & zonalWindFile, meridWindFile,
    & thetaClimFile, saltClimFile,
    & surfQfile, surfQnetFile, surfQswFile, EmPmRfile, saltFluxFile,
    & lambdaThetaFile, lambdaSaltFile,
    & uVelInitFile, vVelInitFile, pSurfInitFile,
    & dQdTFile, ploadFile,tCylIn,tCylOut,
    & eddyTauxFile, eddyTauyFile,
    & mdsioLocalDir,
    & the_run_name
CEOP



-matt



Ming Guo wrote:

> Hi, Matt,
>
> just wonder the format of the focing files, such as ustress and 
> vstress, should be NetCDF file, or something else?
>
> thanks,
> Ming
> **********************************
> Ming Guo,
> Physics and Physical Oceanography Department,
> Memorial University of Newfoundland,
> Office Phone:709-737-2407
> E-mail:gming at karluk.physics.mun.ca
> ***********************************
>
>
> On Mon, 5 Sep 2005, Matthew Mazloff wrote:
>
>> Hi Ming,
>>
>> The problem is
>>
>> yftype_exf='RL',
>>
>> in data.exf
>>
>> I looked in MITgcm/pkg /exf/exf_readparms.F
>> and found
>> exf_yftype but not yftype_exf.
>>
>> You should switch this.
>>
>> -Matt
>>
>>
>>
>>
>>
>> Ming Guo wrote:
>>
>>> Hi, Ed,
>>> I just set the files, but the errors still there,
>>>
>>> "
>>> namelist read: variable not in namelist
>>> apparent state: unit 11 named /tmp/tmp.FA6VrWo
>>> last formate: list io
>>> latey reading sequential formatted external IO
>>> Abort (core dumped)
>>> "
>>>
>>> The attachments are my "EXF" files.
>>> Can you help me to find out the problem?
>>> By the way, is there any spectial format needed for the force file?
>>>
>>> thanks,
>>> Ming
>>>
>>>
>>>
>>
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20050907/4637fa00/attachment.htm>