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

Tue Jan 28 11:30:47 EST 2014

Hi Martin

Currently, the top of my data.obcs file reads...

&OBCS_PARM01
 OB_Jnorth=   450*-0.1,
 OB_Jsouth=   450*0.1,
 OB_Ieast=   800*-0.1,
 OB_Iwest=   800*0.1,
 OBCS_u1_adv_T=1,
 OBCS_u1_adv_S=1,

Have I got this the wrong way round as you suggest that I should have...

OB_Ieast = 450*-1,
OB_Iwest = 450*1,

?

I have checked that my OBCS boundary conditions are indeed constant in time
as you suggest.

Jonny

On 28 January 2014 16:15, Martin Losch <Martin.Losch at awi.de> wrote:

> Hi Jonny,
>
> I am assuming that your boundaries are specified like this:
>  OB_Ieast = 450*-1,
>  OB_Iwest = 450*1,
> or something like that to have the open boundary on the first and the last
> (Nx'th) grid point. The boundary conditions are implemented in such a way
> that you are supposed to have exactly the prescribed value on the boundary.
> You can easily check that when you prescribe bcs that are constant in time.
> Your figure suggests to me that theses values on the boundaries are not
> exactly the same (although I cannot be sure). Rather because the velocity
> is opposite to the remaining domain and the color scale of matlab
> automatically accomodates the high negative (westward) velocities, the
> values look similar. Is that possible? I would check if you haven't made a
> sign error when generating the boundary values.
>
> For more, I'd have to have a closer look at your configuration (data.*
> files and the "code" directory).
>
> Martin
>
>
> On Jan 28, 2014, at 5:02 PM, Jonny Williams <Jonny.Williams at bristol.ac.uk>
> wrote:
>
> > 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
> > <MITgcm_u.png>_______________________________________________
> > 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/c0283349/attachment.htm>