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

Tue Jan 28 12:12:27 EST 2014

Thank you for this Jean-Michel. I had already had a reply from Renske at
Oxford informing me of this and the results now look MUCH better, which is
great news!

As always, the group's help is much appreciated!

All the best and thanks again

Jonny

On 28 January 2014 17:00, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:

> Hi Jonny,
>
> >  OB_Jnorth=   450*-0.1,
> >  OB_Jsouth=   450*0.1,
> >  OB_Ieast=   800*-0.1,
> >  OB_Iwest=   800*0.1,
> This is not right. All these 4 vectors are integer (indices), they cannot
> be specified as real.
>
> Cheers,
> Jean-Michel
>
> On Tue, Jan 28, 2014 at 04:30:47PM +0000, Jonny Williams wrote:
> > 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
>
> > _______________________________________________
> > 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/e8d143f7/attachment-0001.htm>