[MITgcm-support] OBCS (open boundary forcing) problem

Jonny Williams Jonny.Williams at bristol.ac.uk
Tue Jan 28 11:02:21 EST 2014


Thanks very much for that Martin

Your explanation of the periodic boundary conditions makes sense so that's
much appreciated.

What I still do not understand however is why when I move from 1 degree to
0.1 degree resolution why the periodic boundary conditions seems to impinge
on both sides. The attached figure should make this clear for the u
velocity in the horizontal direction. The only things which are different
in the two runs are the resolution dependent factors in data and data.exf
and the resolution of the initial condition T and S and the OBCS forcing
files. This seemingly strange behaviour does not happen when I run at 1
degree resolution.

Thanks again.



On 28 January 2014 11:22, Martin Losch <Martin.Losch at awi.de> wrote:

> Hi Jonny,
>
> there is probably no problem at all: The default boundary condition is
> double periodic and the (FORTRAN) field sizes are the same for all of  your
> fields, so even for u and v you have 45x80 grid points. In the netCDF
> output, however, the extra column (for u) and row (for v) for the vector
> components on the u and v-points in added for convenience, so that you
> don't have to wrap around your self when you want to compute, say averages
> on C-points or gradients, etc. These columns/rows are just copies of i/j=1.
> In the  case of OBCS that does not make too much sense, because the default
> period boundary conditions are overruled. You can safely ignore Nx+1/Ny+1
> and focus on Nx/Ny.
>
> The penultimate colum/row (I had to look that up) are probably constant
> because here you prescibe constant u/v ? If not, you should be worried.
>
> Martin
>
> On Jan 28, 2014, at 11:46 AM, Jonny Williams <Jonny.Williams at bristol.ac.uk>
> wrote:
>
> > Hi there
> >
> > I am currently running two separate regional versions of the MITgcm, one
> at 1 degree resolution (45 longitudes x 80 latitudes) and one at 0.1 degree
> resolution (450 longitudes x 800 latitudes) with both EXF and OBCS packages
> turned on.
> >
> > They are essentially identical in that they use the same forcing data,
> albeit regridded to differing resolutions.
> >
> > My problem is essentially that although the temperature and salinity
> forcing seem to be behaving themselves, the forcing of the u (zonal) and v
> (meridional) velocities are not. In the output NetCDF files I get, T and S
> of dimension 45 x 80, u of dimension 46 x 80 and v of dimension 45 x 81.
> This makes sense since velocities and tracers are usually on staggered
> grids in GCMs. What is strange however is that the 1st, 2nd and last
> columns/rows of data for u/v are identical and constant, that is, the open
> boundary conditions seem to be being applied at BOTH sides of the geometry.
> The penultimate row/column of u/v are also constant throughout the
> simulation. This constancy is good as it shows that two different sets of
> OBCS boundary conditions are being applied at least!
> >
> > Does anyone have any ideas about what could be going on? I can provide
> more details if need be!
> >
> > Many thanks
> >
> > Jonny
> >
> > --
> > 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/20140128/c3d79d26/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MITgcm_u.png
Type: image/png
Size: 8782 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140128/c3d79d26/attachment-0001.png>


More information about the MITgcm-support mailing list