Data Assimilation Facility¶
The data assimilation facility allows the user to specify background winds that vary in x, y, z, and time! As discussed in Data Assimilation, forcing terms are added to the equations of motion in order to steer the large-scale components of the solution to the prescribed background distributions. This page does not discuss the theory further, but rather focuses on the data assimilation implementation details.
Creating a Wind File¶
Historically users could specify one-dimensional mean wind and temperature
profiles (U(z), V(z), T(z)) via the file background.wind. This concept has
been generalized for the data assimilation facility by allowing the user to
specify background winds and temperatures that vary in all three spatial
directions and in time (e.g. U(x,y,z,t)). In what follows we shall refer to
this as 4D winds as it encompasses three spatial dimensions plus time. The
file name background.wind is still used, but the file format is different when
data assimilation is used. The user input i_read_w=2 (to be discussed below)
is used to signify that 4D-style wind file is to be read. Since the 4D wind
file typically contains much more data that the 1D variant, most of it is
written in binary format. The exception is the inclusion of a few ascii header
records at the beginning of the file that provide useful meta data in an easily
accessible format. The downside of the hybrid data structure is that the
background.wind file must be constructed following strict formatting rules in
order to be read properly by CGCAM. In order to assist users with this
aspect, a new program convert_wind
accompanies this update. This program
will convert a 1D-style background.wind file to a 4D-style, complete with all
header information, correctly formatted. The program is useful both for
testing purposes and as a template for writing your own 4D background.wind
files. Obviously the 4D background.wind file produced by convert_wind
will
not have variations in space or in time (the single profiles are simply copied
in space and time), but it does adhere to all of the
formatting conventions. In a nutshell, the 4D background.wind file consists of
three ascii header lines listing things like the number of points in each
spatial direction and in time, the time interval, the case name, etc (described
in detail below). Next comes the grid coordinates for any direction where the
sampling is non-uniform, written in single-precision binary format ( e.g. x and
y grid points excluded for uniform sampling but z_wind(1:Nzwind) listed for
non-uniform in z). The main data portion then follows and it is a
single-precision pure binary dump of the array
wind(1:Nxwind,1:Nywind,1:Nzwind,1:n_var,1:Ntwind) (in column major order),
where n_var=4 (u,v,T,p). Currently both temperature and pressure fields are
required. Double precision data can be also be used by specifying the parameter
n_prec_wind=8 in the cgcam.h header file.
Wind Grid Types¶
The point distribution and grid type must be supplied for the wind data. The sign of the grid flag indicates x-y space (+) or latitude-longitude space(-). Note: This is relative to the grid.dat references SEE: Grid File Section. Grid File
1: | Absolute altitude for z points. |
---|---|
2: | Above ground level for z points, using simulation surface elevation and fade region (z1_fade) |
3: | Above ground reference applied to underlying Cartesian grid |
Example¶
# Case = SAMPLE i_grid = -2 i_pressure = 1 Time[ 0.00: 47.00] |
# Nxwind = 21 Nywind = 26 Nzwind = 205 Ntwind = 48 |
# x_range[ 160.: 180.] y_range[ -57.5: -32.5] z_range |
Explanation: The number of characters is strictly 240. Here grid type -2 indicates an above ground reference from surface elevation in latitude-longitude space. The Pressure field is required (i_pressure=1). The time range (hrs) will start from from t0=0. Uniform latitude-longitude distributions are signified by the numerical inputs for x_range and y_range, whereas the missing inputs for z_range signifies that this direction is non-uniform. The z-point distribution is then specified immediately following the header in single-precision binary. Non-uniform samplings for either x or y are also supported, and these are signified by omitted range values. Any required non-uniform point distributions will be listed immediately following the header as [x_wind(1:Nxwind),y_wind(1:Nywind),z_wind(1:Nzwind)]. Uniform ranges are specified in either decimal degrees or kilometers (depending on the sign of i_grid). Although kilometers are used for the specification of a uniform Cartesian wind grid layout, you must use meters when listing non-uniform grid distributions in x, y, or z.
A complete background.wind file used for the example case (cgcam/examples/4Dwind) can be downloaded here http://boulder.gats-inc.com/background.wind
Climatology¶
A climatology data base is available for users BUT should only be used for preliminary analysis or profile approximation due to its limitations. The data set contains zonal winds and temperature at 1 degree lines of latitude. It encompasses [-80:80] degrees with an approximate altitude range of [0:120] km.
To generate CIRA profiles build and run the program climatology
.
New Input Options¶
i_read_w: | 2-read 4D, 1-read 1D, 0-generate internally |
---|---|
dt_ramp: | Time between ramping segments (Recommended = dt0) |
t_adjust_wind: | Time to start data time variation (Use: ramping with fixed winds) |
n_skip_b: | Skip factor for background output (Testing) |
Note input options for boundary conditions, diffusion, hydrostatic balance, and ramping function (hyperbolic tangent) are strict for terrain cases.
Grid File¶
Similar to the background.wind file, the format of the grid.dat file has been altered for data assimilation cases. The alteration amounts to the addition of meta data-containing ascii header records at the beginning of the file, which allow for easy consistency checking between the simulation grid and the wind-data grid. The grid file header records will be included for a terrain grid if the input i_header=1 is added to the terrain_mesh.inp file:
i_header: | 1-write header, 0-no header (default) |
---|
Older grid files without the header records can still be used for data assimilation cases, but full consistency may not be guaranteed.