Page Menu
Home
c4science
Search
Configure Global Search
Log In
Files
F120515661
OpenBound.html
No One
Temporary
Actions
Download File
Edit File
Delete File
View Transforms
Subscribe
Mute Notifications
Award Token
Subscribers
None
File Metadata
Details
File Info
Storage
Attached
Created
Fri, Jul 4, 22:46
Size
3 KB
Mime Type
text/html
Expires
Sun, Jul 6, 22:46 (2 d)
Engine
blob
Format
Raw Data
Handle
27189059
Attached To
R2795 mitgcm_lac_leman_abirani
OpenBound.html
View Options
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.5 [en] (X11; U; Linux 2.0.34 i586) [Netscape]">
</head>
<body>
<h1>
Open Boundaries Implementation in MITgcmUV</h1>
These are some quick explanatory notes regards implementation of open boundaries
(OB) and the example configuration found in .../verification/exp4/
<br>
<h2>
Input and control of OBs</h2>
<ul>
<li>
The open boundaries code is used only if the LOGICAL parameter openBondaries
is .TRUE.</li>
<li>
Four 1-dimensional INTEGER arrays indicate the position of an OB: OB_Jnorth,
OB_Jsouth, OB_Ieast and OB_Iwest.</li>
</ul>
The values of OB_* indicate the absolute computational coordinate of an
open boundary. eg. OB_Jsouth(3)=4
<br>means that in the column I=3 there is a "southern" OB at tracer point
J=4. Similarly OB_Iwest(2)=1 means that
<br>the tracer point (2,1) is an OB point. This structure for specifying
OBs assumes that there will be only one northern and southern OB per column
and similar in the other direction. An entry of 0 (zero) means there is
now OB in that column/row.
<p>The reference to "tracer points" above introduces an important distinction
between particular boundaries due to the C-grid staggering of variables.
At a northern OB tracer point (i,j) the OB v-velocity point is at (i,j)
while at a southern OB tracer point (i,j) the OB v-velocity point is at
(i,j+1). This is all taken care of in the code but when specifying OB values
it is important to remember the physical coordinates of T,S,U and V are
not the same for a given computational index.
<br>
<h3>
Changing the type of open boundary</h3>
The supplied code simply specifies model variables at the appropriate points.
The value to be specified can (and should) be determine using a radiative
condition. A skeleton code is supplied set_obcs.F to illustrate how
<br>this might be done. This is the only routine that needs to be edited.
Edit others at your own peril!
<br>
<h3>
The examples</h3>
There are three examples in .../verification/exp4/
<ol>
<li>
A zonal channel (solid side walls) with open boundaries at either end:
data.channel</li>
<li>
A zonal channel with a Gaussian bump and open boundaries at either end:
data.bumpchannel</li>
<li>
An open domain (OBs on four sides) with a Gaussian bump: data.bump</li>
</ol>
Each data file has a corresponding topog.* file which is specified through
the variable bathyFile in data.*
<br>The physical problem has a flow of U=25 cm/s specified at all open
boundaries. The details of the experiment can be found in Adcroft's thesis
(Imperial College) and in Adcroft, Hill and Marshall, MWR 1997.
<p>The differences between the supplied data.* files also show how to turn
particular OBs on and off.
<h3>
Compiling and running the examples</h3>
The examples supplied are the barotropic zonal flow over a Gaussian bump
in a channel.
<ul>
<li>
Header files: Copy or link SIZE.h, CPP_OPTIONS.h and CP_EEOPTIONS.h from
.../verification/exp4/code/ to .../model/inc/, .../model/inc/ and .../eesupp.inc/
respectively</li>
<li>
Modified source: Copy set_obcs.F to .../model/src/</li>
</ul>
Now compile the code as usual:
<ul>
<li>
cd bin</li>
<li>
../tools/genmake -makefile</li>
<li>
make depend</li>
<li>
make</li>
</ul>
To run the code you must first choose a data file to use:
<ul>
<li>
cd ../verification/exp4/input/</li>
<li>
cp data.bump data</li>
<li>
../../exe/mitgcmuv</li>
</ul>
Happy Open Boundarying!
</body>
</html>
Event Timeline
Log In to Comment