[MITgcm-support] format of input files wrong in regional model with open boundary conditions?

Thu Dec 12 12:28:26 EST 2013

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

*...*
*(PID.TID 0098.0001) *** ERROR *** S/R LOAD_GRID_SPACING: No value for delX
at i =    1*
*(PID.TID 0098.0001) *** ERROR *** S/R LOAD_GRID_SPACING: No value for delX
at i =    2*
*(PID.TID 0098.0001) *** ERROR *** S/R LOAD_GRID_SPACING: No value for delX
at i =    3*
*...*

*(PID.TID 0098.0001) *** ERROR *** S/R LOAD_GRID_SPACING: No value for delX
at i =    450*
*(PID.TID 0098.0001) *** ERROR *** S/R LOAD_GRID_SPACING: found  450
invalid delX values*

The delX array/variable is defined as follow in the 'data' file

*# Gridding parameters*
* &PARM04*
* usingSphericalPolarGrid=.TRUE.,*
* delY=800*0.1,*
* delX=450*0.1,*
* delZ   = 10.00, 10.00, 10.00, 10.00, 10.00, 10.00, 10.00, 10.01,*
* 10.03, 10.11, 10.32, 10.80, 11.76, 13.42, 16.04 , 19.82, 24.85, *
* 31.10, 38.42, 46.50, 55.00, 63.50, 71.58, 78.90, 85.15, 90.18, *
* 93.96, 96.58, 98.25, 99.25,100.01,101.33,104.56,111.33,122.83,*
* 139.09,158.94,180.83,203.55,226.50,249.50,272.50,295.50,318.50,*
* 341.50,364.50,387.50,410.50,433.50,456.50,*
* ygOrigin=-70.0,*
* xgOrigin=-30.0,*
* rSphere = 6371.D3,*
*&*

... and so I am quite baffled as to what is going on. I have tried
transposing my binary input datasets in case the model was expecting
lon-lat data instead of lat-lon but this also has not fixed the issue.

It would be great to the model running in its simplest form before moving
on to the OBCS problem I guess?

Many thanks for any suggestions.

Jonny

On 10 December 2013 16:59, Jody Klymak <jklymak at uvic.ca> wrote:

> Hi Jonny,
>
> I think you are confused about your SIZE.h.
>
> sNx is how many x grid points to put on each subgrid
> nSx is how many subgrids to put on each processor
> nPx is how many processors.
>
> I usually always use nSx=1, but maybe you have some reason for having more
> than one subgrid on each processor?
>
> Anyway, Nx is the product of all three numbers.  nSx*nPx just corresponds
> to the number of subgrids in the x dimension.
>
> Cheers,   Jody
>
> On Dec 10, 2013, at  8:28 AM, Jonny Williams <Jonny.Williams at bristol.ac.uk>
> wrote:
>
> Thank you again!
>
> Those are both great suggestions and I will have a look at both.
>
> My current hypothesis is that I have gotten something wrong in SIZE.h
>
> Currently I have the following parameters
>
>
> *      PARAMETER (*
> *     &           sNx =  41,*
> *     &           sNy =  89,*
> *     &           OLx =   4,*
> *     &           OLy =   4,*
> *     &           nSx =   1,*
> *     &           nSy =   3,*
> *     &           nPx =  11,*
> *     &           nPy =   3,*
> .
> .
> .
> ... and my grid NetCDF files (which are being created correctly it seems)
> have 99 grid elements, which is equal to (nSx*nPx)*(nSy*nPy) in my current
> setup. I am currently playing around with these numbers to see if this
> makes a difference.
>
> Thanks again!
>
> Jonny
>
>
>
>
>
>
> On 10 December 2013 16:13, Patrick Heimbach <heimbach at mit.edu> wrote:
>
>>
>> Jonny,
>>
>> On Dec 10, 2013, at 10:12 AM, Jonny Williams <
>> Jonny.Williams at bristol.ac.uk> wrote:
>>
>> > Given what you have just said , would it therefore be reasonable to
>> assume that the dimensions of the input files I have created are wrong?
>>
>> That might indeed be the case.
>>
>> Either wrong dimensions or you are providing real*8 fields where the
>> model expects real*4?
>> (you'd have to look what accuracy you are prescribing).
>>
>> One way to find out is to see how many time steps the model runs
>> successfully, i.e. how many records are read successfully before the crash.
>> Perhaps that gives a clue.
>>
>> p.
>>
>> ---
>> Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
>> MIT | EAPS 54-1420 | 77 Massachusetts Ave | Cambridge MA 02139 USA
>> FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach
>>
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>
>
> --
> 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
>  _______________________________________________
> 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
>
>

-- 
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/20131212/a92df7f0/attachment.htm>