[MITgcm-support] format of input files wrong in regional model with open boundary conditions?
Jonny Williams
Jonny.Williams at bristol.ac.uk
Thu Dec 19 10:31:13 EST 2013
Hello there
Many thanks for all the extremely useful help received so far on my
regional model. I now have the model running, which is brilliant but
inevitably there is more to do!
At the moment I am running my model with the EXF (external forcing) package
only but eventually I want to run it with the OBCS (open boundary
conditions) package too as is the case for the Arctic regional simulation
that my model is based upon.
I am trying to run with constant forcing (unphysical sure but hopefully
simple!) but my model diverges after four timesteps. I've attached 3
figures which hopefully will show clearly enough what is going on. At the
4th timestep (4dt) the latitude-depth plots of ocean potential temperature
look fine but then there is a mega divergence at the 5th (5dt). I've
attached global plots and one which zooms in on latitude above the equator.
The latitudinal extent of the model is -70 < latitude >10. Basically my
question is *does anyone recognise this type of divergence or have any
ideas as to what I might try next to fix this?*
I am using the following syntax for the forcing in my data.exf file...
atempstartdate1 = 19780101,
atempstartdate2 = 000000,
atempperiod = 000000,
... which I believe is correct for uniform and steady forcing?
Many thanks!
Jonny
[image: Inline images 1][image: Inline images 2][image: Inline images 3]40
minute timesteps
On 13 December 2013 11:00, Jonny Williams <Jonny.Williams at bristol.ac.uk>wrote:
> Thanks for that
>
> For your information, currently I am specifying the external forcing in
> the following way in the EXF_NML_04 namelist in data.exf, following
> numerous examples in the verification examples
>
> #
> uwind_lon0 = -30.0D0,
> uwind_lon_inc = 0.1D0,
> uwind_lat0 = -70.0D0,
> uwind_lat_inc = 0.1D0,
> uwind_nlon = 450,
> uwind_nlat = 800,
> #
>
> Thank you!
>
> Jonny
>
>
>
>
>
>
>
> On 13 December 2013 03:46, Michael Schaferkotter <schaferk at bellsouth.net>wrote:
>
>> Jonny:
>>
>> This 'new' issue has nothing to do with loading the input grid values via
>> namelist or file.
>>
>> So you don't need my suggestion at this time.
>>
>> Clearly the ATM forcing is valued at points outside the domain that you
>> are specifying to the
>> inline interpolation code, ie.,exf_interp, which is enabled as a package.
>> I would check the namelist parameters associated with the inline
>> interpolation of the atmospheric forcing.
>>
>>
>>
>>
>>
>>
>> Sent from an iOS device.
>>
>> On Dec 12, 2013, at 12:36, Jonny Williams <Jonny.Williams at bristol.ac.uk>
>> wrote:
>>
>> Thanks very much for that Michael!
>>
>> I have now changed my SIZE.h file and I am now getting a different error,
>> which is good I suppose!..
>>
>> *(PID.TID 0000.0001) *** ERROR *** EXF_INTERP_UV:
>> fileU="u_992hPa.bin_1979", rec= 1*
>> *(PID.TID 0000.0001) *** ERROR *** EXF_INTERP_UV: input grid must
>> encompass output grid.*
>> *(PID.TID 0000.0001) *** ERROR *** i,j,bi,bj= 1 1 1 1
>> , xG,yG= -2.995000E+01 -6.995000E+01*
>> *(PID.TID 0000.0001) *** ERROR *** nxIn= 450 , x_in(0,nxIn+1)=
>> -3.010000E+01 1.500000E+01*
>> *(PID.TID 0000.0001) *** ERROR *** nyIn= 800 , y_in(0,nyIn+1)=
>> -7.010000E+01 -1.903000E+02*
>>
>> The key point here is that the x_in vales are seemingly correct (-30 to
>> +15 degrees) but the y_in values are completely wrong (-70 to -190 degrees
>> when they should be -70 to +10 degrees). This is not at all what I want and
>> is surely unphysical. I will try your idea of using a delXfile etc.
>>
>> Many thanks indeed for this. I feel I am getting somewhere now with all
>> this help which is hugely appreciated.
>>
>> Jonny
>>
>>
>>
>>
>>
>> On 12 December 2013 18:11, michael schaferkotter <schaferk at bellsouth.net>wrote:
>>
>>> you/ll need to have sNy to be 80 rather than 10.
>>>
>>> as SIZE.h indicates, the model thinks the domain is 450 x 100 x 50.
>>>
>>> also namelist parameter lists can be problematic for different
>>> platforms, especially when listing the elements, ie *delX=450*0.1, or **delZ
>>> = 10.00, 10.00, 10.00, 1 ....*
>>>
>>> *i would run into issues with that often. *
>>>
>>> *so to avoid those types of issues (platform), i would use *
>>>
>>> *delXfile='dx.bin',*
>>> *delYfile='dy.bin',*
>>> *delZfile='dr.bin', *
>>>
>>> *where the elements are written into the file using matlab or an f90
>>> program.*
>>>
>>> *thus avoiding the persnickety namelists with single entries (you have
>>> to get the count right, which you don't have with your current SIZE.h)*
>>>
>>> *here/s a MATLAB snippet (note the precision!)*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *prec = 'real*8';ieee = 'b';ny=800;dy=zeros(ny,1);for j=1:ny dy(j)=0.1;
>>> endfid=fopen('dy.bin','w',ieee); fwrite(fid,dy,prec); fclose(fid);michael*
>>>
>>> Begin forwarded message:
>>>
>>> Thanks for your suggestion Jody
>>>
>>> I think I have ironed out the SIZE.h aspect now, I am now using the
>>> following...
>>>
>>> * & sNx = 45,*
>>> * & sNy = 10,*
>>> * & OLx = 4,*
>>> * & OLy = 4,*
>>> * & nSx = 1,*
>>> * & nSy = 1,*
>>> * & nPx = 10,*
>>> * & nPy = 10,*
>>> * & Nx = sNx*nSx*nPx,*
>>> * & Ny = sNy*nSy*nPy,*
>>> * & Nr = 50)*
>>>
>>> However I still cannot get the model running so I have turned off the
>>> OBCS package for now only to encounter another problem, noting that my
>>> domain is 450 x 800 in total
>>>
>>>
>>>
>>
>>
>> --
>> Dr Jonny Williams
>> School of Geographical Sciences
>> University of Bristol
>> University Road
>> BS8 1SS
>>
>> +44 (0)117 3318352
>> jonny.williams at bristol.ac.uk
>> bit.ly/jonnywilliams
>>
>>
>
>
> --
> Dr Jonny Williams
> School of Geographical Sciences
> University of Bristol
> University Road
> BS8 1SS
>
> +44 (0)117 3318352
> jonny.williams at bristol.ac.uk
> bit.ly/jonnywilliams
>
--
Dr Jonny Williams
School of Geographical Sciences
University of Bristol
University Road
BS8 1SS
+44 (0)117 3318352
jonny.williams at bristol.ac.uk
bit.ly/jonnywilliams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20131219/bd4e0111/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 22394 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20131219/bd4e0111/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 25595 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20131219/bd4e0111/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 26439 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20131219/bd4e0111/attachment-0005.png>
More information about the MITgcm-support
mailing list