by
Jean-Claude Cerisier and Catherine Senior
Version 2.3
November 1994
This report outlines the main characteristics of the MERGE program. This program addresses the problem of calculating the velocity vectors in the common field of view of two radars of the SuperDARN chain from the radial velocities measured by each of them, as given by the .fit files. The result is the creation of an output file (merge.dat) containing all data necessary for graphic representation of the velocity maps or for any other scientific use of these velocities.
The MERGE program is fully compatible with all the official routines found in the Leicester software depository.
The present version (Version 2) is an improvement of the previous preliminary version 1 (April 93) whose restrictions are described in Annex 3. Version 2.1 is the first one to be released into the Leicester Software Depository.
MERGE is based on the initial RADMAP algorithm developped for the Schefferville-Goose Bay radar pair and on the work carried out by the "Merging Working Group" of the SuperDARN project. Any suggestions or inquiries concerning this program should be addressed to CETP in France where the software has been developped. Jean-Claude Cerisier and Catherine Senior are the persons, at CETP, responsible for its maintenance ("Jean-Claude.Cerisier@cetp.ipsl.fr" or "Catherine.Senior@cetp.ipsl.fr")
This report describes the MERGE program itself. It does not include
the detailed description of the different options which have been
considered at each step of its elaboration. These are described
in the reports of the "Merging Working Group". Here,
we describe only the selected options and the reasons for their
selection.
2 - GENERAL DESCRIPTION OF THE PROGRAM
The MERGE program is written in Fortran.
2.1 - The grid
The grid has to satisfy several requirements (see the report of the working group to the Saskatoon meeting, April 1993). The working group decided to select the "beam radar" grid, in which the cells (called diamonds) are defined by the intersection of the radar beams. This grid contains 16x16=256 cells. The choice of this grid presents several advantages :
- the size of the diamonds increases naturally with increasing distance to the radars.
- the velocity vectors calculated in adjacent diamonds are independent.
- the beam-radar grid has a self-defining method of data selection
(attribution of a measurement to a cell of the grid).
2.2 - The hypotheses of the calculations : real and virtual
heights
The theory of backscatter tells us that the radar echoes are produced in regions where, due to refraction, the wave vector is normal to the local magnetic field (figure 1).
In the regions of interest to SuperDARN, this means that k is close to horizontal. In order to determine the position of the backscatter point, we assume free space propagation (straight line ray, velocity c) up to a virtual scattering point, and then instantaneous refraction, which brings the wave vector normal to the magnetic field. This virtual scattering point is assumed to be vertically above the real scattering point. This is something like the Breit and Tuve theorem. The virtual height can be determined if reliable information can be deduced from the interferometer (the virtual height, the time delay and the elevation angle are linked by a simple geometrical relation). If the virtual height is not known, we have to assume a model for the virtual height. Notice that the virtual height is an important parameter since it enters into the determination of the beam direction (cone angle effect) and, more important, it defines the numbers of ranges falling into each diamond. The default virtual height (in the absence of any experimental evaluation and any model) is 400 km.
For a given radar and beam number, the virtual height model is defined as a function of range. In the calculation, at a given field point, the relation between range gate and virtual height is obtained by iteration. Convergence of the iteration implies that the virtual height has to be a smooth function of the range. This will have to be remembered when using interferometer data.
Once the virtual height is known, the real height still remains unknown. The real height is necessary for the calculation of magnetic coordinates of the data point, and also when projecting all velocity vectors to a common altitude, as required for the divergence free analysis (see section 5). We have chosen the following solution to this problem: the real height is approximated by an a-priori function of the virtual height
This relation has been obtained from ray-tracing in a model ionosphere. The default real height is thus 325 km. This is also the common altitude for the projection of the velocity vectors and of the grid points, except in the case when the virtual height is constant (option 1 of the virtual height choice, see below) and different from 400 km.
This projection to a common altitude is necessary if we want to
plot velocity maps (What would be the meaning of a map representing
velocities measured at different altitudes?), or for the divergence-free
analysis (which can be made only in two dimensions). In this projection,
we assume equipotential field lines, and their geometrical divergence
is taken into account.
2.3 - The coordinates and models
The program assumes an ellipsoidal earth with an equatorial radius of 6378.16 km and a flattening of 1/298.25 (IAU 1964 oblate spheroid model). Geodetic (geographic) coordinates of the radars are transformed into geocentric coordinates. Azimuths and elevation angles measured in geodetic coordinates are also transformed into geocentric coordinates. All calculations are then made in geocentric coordinates. The correction of the azimuth with the elevation angle of the radar beam (cone angle effect) is taken into account.
The radars entering into the pair are numbered 1 (the western radar) and 2 (the eastern radar). The diamonds are numbered (i,j), i and j being respectively the beam numbers of radars 1 and 2 of the pair (0 to 15).
The model for calculating the magnetic field vector is IGRF 90.
Magnetic coordinates (subroutine CNV_COORD) are calculated from
the Baker and Wing model (J. Geophys. Res., 94, 9139, 1989), only
for later use, for example in the graphic presentation of velocity
maps.
2.4 - The structure of the program
The program consists of 2 successive phases:
- The initialisation phase. This includes: (1) choosing among the various options of the program; (2) calculating the look-up table containing the parameters which are eventually conserved from one map to the next. The look-up table parameters are not conserved in the case where the elevation angle, and the virtual height change from map to map (option 3 of the virtual height choice, see below).
- The calculation of the vector velocity maps.
3 - THE INITIALISATION PHASE
3.1 - The initialisation parameters
The initialisation of the program is done in subroutine MERGE_INFO
(annex 1). Parameters to be initialized include :
3.1.1 - the data selection parameters
the .fit files to be merged. The program checks if they belong to a radar pair by comparing with a pre-registered list (subroutine PAIR) and to overlapping time periods.
the start and end times for processing.
Frequency range to be merged. It is possible to limit merging to data obtained in a limited frequency range.
Ground-scatter elimination. Four options are possible: (1) Include all echoes identified as ground scatter by fitacf; (2) Exclude all echoes identified as ground scatter by fitacf; (3) Include all echoes identified as ground scatter by fitacf for one radar, but not for the other; (4) Other criteria of elimination (to be defined). Options 3 and 4 are not yet ready.
E-region echoes elimination. Three options are possible: (1) Include E region echoes; (2) Exclude echoes below a minimum range (standard sub-option is 900 km minimum range); (3) Exclude E region echoes by using the elevation angle information. Option (3) is not yet ready.
Minimum power.
Minimum radial velocity: Note that it may be prudent to change this value to 25 m/s to avoid contamination by ground-scatter echoes that went through the default filter in FITACF.
Maximum radial velocity.
Maximum error on the radial velocity: parameter vel_err from the
.fit file.
3.1.2 - the processing parameters
Type of maps: instantaneous (one scan) or averaged (over a selected time period)? The one-scan option is not yet ready (it now corresponds to 96 seconds average).
Virtual height h'. Three options are possible: (1) Constant virtual height; (2) h' = f(range); (3) h' determined experimentally. The default option is option 1 with h' = 400 km. This value can be changed. Options 2 and 3 are not yet ready.
Data smoothing of radial velocity maps (y/n).
Interpolation of radial velocities to recover missing isolated values (option not ready).
Increase spatial resolution by using radial velocities from individual range gates (option not ready).
Divergence free relaxation correction of the vectors (y/n).
Divergence free extension of the map to points (in the common
field of view) of the grid where zero or one velocity component
only is available (y/n). This option is possible only if the divergence
free relaxation option (above) is selected.
3.1.3 - the standard options
The user can run the program with a predetermined set of standard options. Those are the following:
Frequency range: 8 to 20 MHz
Excludes echoes identified as ground scatter by FITACF
Includes E-region echoes
Minimum power = 3 dB
Minimum radial velocity = 25 m/s
Maximum radial velocity = 3000 m/s
Maximum error on radial velocity = 50 m/s
Averaged maps over 2 complete scans (192 sec)
Constant virtual height of 400 km
Smoothing of radial velocities
No interpolation of radial velocities to recover isolated missing values
No spatial resolution increase
No divergence-free analysis (relaxation and extension)
3.2 - The Look-up table
The parameters included in the look-up table depend upon the elevation angle. If we use the information on this angle given by the interferometer (note that this option is not yet available), the look-up table has to be recalculated for each map. However, if we use "a priori " values of the virtual height (not necessarily constant), the look-up table is calculated only at the begining of the program for the chosen virtual height profile.
Also, if the distance to the first range (lagfr) or the width of range gates (smsep) changes for one of the radars during the time period requested for a MERGE run, the look-up table is recalculated. (This have however not been tested yet on .fit files containing lagfr or smsep changes).
The look-up table, which is created by the routine MAKE_TABLE, consists of: (1) a header containing several of the initialization parameters, (2) the list of slant ranges for each radar, and (3) the parameters of the grid. This look-up table is stored in the COMMON/TABLE/
The parameters of the grid consist of:
(i) the geocentric coordinates (latitude, longitude) and the real altitude of the centers of the diamonds. The center of diamond (i, j) is defined by the intersection of the two beam axes i and j. In the calculation of the geocentric coordinates, the cone angle effect is taken into account (subroutine CORR_AZIM). This explains why the coordinates of the beam centers change if the virtual height changes. Also, in the case of non constant virtual and real heights, the coordinates are projected (along the magnetic field) from the real altitude at which the measurement is assumed to a constant altitude. The real altitude of the measurement is calculated from expression (1), using the virtual height at the center of the diamond. The default real height is 325 km, corresponding to the default virtual height of 400 km. In the case when the altitude of the measurements is different for the two mean radial components at the center of the diamond, the assumed virtual height is the arithmetic mean of the two. Parameters latg(-1:16,-1:16), long(-1:16,-1:16), alt(-1:16,-1:16).
(ii) the geomagnetic latitude and longitude of the centers of the diamonds at the standard real altitude. Parameters latm(0:15,0:15), lonm(0:15,0:15).
(iii) the azimuths of radars 1 and 2 from the centers of the diamonds (figure 2).
These angles are positive clockwise from geographic North. Parameter az(2,-1:16,-1:16).
Note that, for the parameters latg,long,alt,az above, virtual beams, labelled -1 and 16, are included. These virtual diamonds are necessary in the case when the divergence free relaxation or extension are performed.
(iv) the angle between the two radar beams at the center of the diamonds. Parameter abb(0:15,0:15).
(v) the number and the list of the ranges which come into each diamond, for the 2 radars. The determination of the diamond to which a given range gate belongs is made by comparing its ground range with the ground range of the borders of the diamonds (figure 3).
Note that the geocentric position of the radar range gates is not calculated. The only geocentric positions which are calculated are those of the centers of the diamonds. Parameters n(2,0:15,0:15), rng(2,25,0:15,0:15).
(vi) the magnetic field vector b (in Gauss) at the centers of the diamonds, at the real height of the measurements. Parameters bx(0:15,0:15), by(0:15,0:15), bz(0:15,0:15).
(vii) the (unit) vectors k1 and k2 representing the direction of the radars 1 and 2 at the centers of the diamonds (see figure 2). They are defined by the intersection of the geocentric vertical plane at the diamond center containing the direction of the radar with the plane perpendicular to B. Parameters kx(0:15,0:15), ky(0:15,0:15), kz(0:15,0:15).
These vectors (k1, k2 and b) are calculated
in the local cartesian frame (x horizontal towards geographic
south, y horizontal towards geographic east, z vertical upwards)
<4 - THE CALCULATION OF THE VELOCITY VECTOR
In each diamond, the calculation of the velocity vector proceeds
as follows:
4.1 - Calculate the mean radial velocity
The mean radial velocity is calculated in the routine READ_SCAN,
with subroutines AVRG_SCAN or ONE_SCAN. For radars 1 and
2, the radial velocity for each range gate is the arithmetic mean
of the measurements made during the successive scans over which
the map is averaged. The radial velocity at the centre of the
diamond is then determined as the arithmetic mean over the range
gates falling into the diamond. This is a very crude equivalent
filter (rectangular box). Other, more sophisticated filters can
be easily implemented.
4.2 - Calculate the vector velocity
The vector velocity is calculated in the routine MERGE_VEC. The algorithm is straightforward. Assuming that the k vector of the irregularities is perpendicular to the earth magnetic field, and that their frequency is zero, the convection velocity V is determined by the following set of equations
k1.V = V1
k2.V = V2
V.b = 0
where V1 and V2 are the mean radial velocities determined for each radar and b is the magnetic field vector. This system can be written in matrix form
Solving the above Cramer system (subroutine GAUSSJ) in the local cartesian frame gives the velocity components Vx, Vy, Vz at each diamond center.
Note that a vertical velocity component is obtained. This does not indicate a vertical motion of the plasma. This vertical component results only from the fact that the plane perpendicular to the static magnetic field is not horizontal. It must be remembered that any motion along the magnetic field cannot be detected by HF radars.
The above velocity vector is then projected to the standard real
altitude. In this projection, the divergence of field lines is
taken into account. Assuming locally a dipole field behaviour,
the component in the local magnetic meridian plane and the component
perpendicular to it are respectively proportional to r2 and r
(r is the geocentric distance). In the case when the vector velocity
cannot be calculated, because one radial component is missing,
the known radial component is projected, using a hybrid projection
factor r3/2.
4.3 - Error on the vector velocity
Two evaluations of the error are calculated, one based on the "vel_err" parameter, the other based on "width". In each case, the errors on the radial velocities are first averaged
Then, assuming that the errors on the two radial components are independent, the errors on the cartesian components are given by
where the bij are the elements of the inverse of the matrix A above.
The hypothesis of zero divergence of the velocity map (Ruohoniemi et al., J. Geophys. Res., 94, 13463, 1989) can be used for two different purposes. First, it can help in defining a rule for smoothing the map (divergence free relaxation). Second, a missing velocity vector at one grid point can be recovered assuming zero divergence at the neighbouring points (divergence free extension). The divergence free analysis is only an option in the merge program, with a sub-choice between relaxation and (relaxation+extension).
The divergence free relaxation can be performed only on a two-dimensional
map (a horizontal surface). That is why the velocities have to
be projected onto the horizontal surface (subroutine HOR_PROJ).
We have chosen a projection along the magnetic field and not along
the vertical. Also the centers of the diamonds, which are not
all at the same altitude, have to be projected onto a horizontal
surface (see section 2.2 above). In this projection, the divergence
of field lines is taken into account.
5.1 - Divergence-free relaxation
The divergence-free relaxation is performed in generalized radar coordinates (beam numbers ib and jb of radars 1 and 2). The principle is an iterative method consisting in two steps: (1) is to analyze the two-dimensional velocity map and determine the point (imax, jmax) where the absolute value of the divergence is maximum (subroutines DIV_FREE and DIV_CALC); (2) the divergence at that point is reduced to zero (subroutine DIV_CORRECT) by modifying the velocity at the four surrounding points: (imax+1, jmax), (imax-1, jmax), (imax, jmax-1), (imax, jmax+1) involved (figure 4)
in the calculation of the divergence at the point (imax, jmax). The relaxation analysis stops when the mean divergence of the map is below a pre-determined value (divmin) or when the maximum number of iterations (nmax) is reached. These parameters have been chosen as
nmax = 20 (number of points where the divergence can be calculated)
divmin = 10 (earth_radius p/180)2
How are the velocity changes shared between the 8 velocity components involved in the expression of the divergence? We have chosen to modify each velocity component in proportion to the inhomogeneity of the field of this component in the 3x3 template surrounding the point. The inhomogeneity is evaluated on the cartesian components. In other words, we calculate
where the summation is on the valid velocity vectors surrounding the point, and n is the number of terms in the sum.
The formula used for calculating the divergence in generalized coordinates is (Stratton, Electromagnetic Theory, 1941, Chap1, p45)
where ni are the contravariant components of the velocity, and
is the parallelipipedic volume (in 2D) built on the unitary vectors a1, a2, a3 (not of unit length). These unitary vectors are along the ib, jb, and vertical lines. The contravariant components are calculated by
The unitary vectors a1, a2 are calculated by interpolation between grid points. It is this interpolation which makes it necessary to extend the look up table to virtual beams -1 and 16. This interpolation implies that the coordinates of the centers of the diamonds change only slightly between adjacent diamonds. In spherical coordinates, this is not the case close to the poles. Thus, in its present state, one must be careful to avoid using the algorithm for the southern radars. The a3 vector is vertical upwards and of unit length.
As already mentioned, the corrections to the velocity components are chosen proportional to the inhomogeneity on these components. Using the fact that the divergence is a linear function of the velocity components at the four neighbouring points, we obtain for the correction of the Vi component
5.2 - Divergence-free extension
The velocity map can be extended (routine DIV_EXTEND), using the zero divergence assumption, in two different situations:
(1) to recover a velocity vector at isolated points of the 16x16 grid where this vector cannot be calculated from the experimental data, because one or two radial components are missing.
(2) to extend the vector velocity map to regions covered by only one radar (i.e. one radial velocity component). Among the four possible regions, the two regions far from the radars can be eliminated because of the small number of data expected at such large ranges. Practically, this extension can concern only the two zones close to the two radars. It can be remarked that these zones are of limited interest (small geographic extension, low latitude situation, pollution by E region echoes).
Only the first situation has been considered up to now.
When considering the calculation of the velocity at a given point,
the system of equations to be solved consists of a maximum of
four equations (the velocity at one point contributes to the divergence
at four neighbouring points), with a maximum of two unknowns (the
two radial velocity components). Of course, the system can be
solved only if the number of equations is larger than (or equal
to) the number of unknowns.
6 - QUALITY INDICES
Two types of quality indices are calculated, as defined by the
working group, one for each individual point of the map, and one
characterizing the whole map.
6.1 Quality index for individual vectors (pnt_qlty)
The quality index of individual vectors is calculated in the routine QUALITY_PNT. It is a 3-digit integer, each digit increasing with the quality of the parameter it describes. The digits are defined as follows:
digit 1 (to the left). Let m x n represent a velocity determined from m range gates from one radar and n from the other. The value of digit 1 is
0 for 0 x 0 1 for 0 x n (n = 1) 2 for 1 x 1 3 for 1 x 2 4 for 1 x n (n = 3) 5 for 2 x 2 6 for 2 x n (n = 3) 7 for m x n (m = 3 , n = 3)digit 2. This represents the average spectral width of all the radial velocity measurements (from both radars) falling into the diamond, during the time period when the data are averaged. The value of digit 2 is
0 for 500 m/s = width 1 for 400 m/s = width 500 m/s 2 for 300 m/s = width 400 m/s 3 for 200 m/s = width 300 m/s for 100 m/s = width 200 m/s 5 for width 100 m/sdigit 3. This characterizes the geometry of the velocity vector determination, from the angle between the two radial velocities. The value of digit 3 is
0 for 0° = angle 15° 1 for 15° = angle 30° 2 for 30° = angleNote that a velocity vector can exist for pnt_qlty 200 in the case when the velocity vector is obtained from the divergence free extension.
This is a 4-digit integer, calculated in the routine QUALITY_MAP. The first digit (to the left) refers to the number of vector velocity points in the map. Its value is
0 for 0 = n 20The diamonds where the velocity vector is recovered by the divergence free extension are included in the calculation of the map quality index.
1 " 20 = n 40
2 " 40 = n 60
3 " 60 = n 80
4 " 80 = n 100
5 " 100 = n 120
6 " 120 = n 140
7 " 140 = n 160
8 " 160 = n 180
9 " 180 = n 256
The last three digits have the same meaning as for individual
vectors. Each of them is the closest integer to the arithmetic
mean of the values for individual vectors.
7 - THE OUTPUT FILE
7.1 - Description of the output file
The output file will contain:
7.1.1 - the general header
This header of fixed length, contains the MERGE RCS revision number
(character*40), the parameters characterizing the data set, and
the processing options. These parameters are declared in the file
INFO.INC (annex 2).
7.1.2 - the series of data sets specific to each map
Each data set consists of:
a) a sub-header for the map
This sub-header, of fixed length, contains the parameters of the map. These are:
- the start and end times of the map [sdate(2,6), edate(2,6)];
- the distance to the first range gate and the width of a range gate for each radar, in microseconds [lagfr(2) and smsep(2)];
- the quality index of the map (map_qlty);
- the number of velocity vectors in the map (ngood);
- the number of iterations in the divergence free relaxation (n_iter);
- the altitude at which the data have been projected (height_r);
b) a series of records
<
The number of the records is ngood (see before). Each record contains the data themselves. These are:
- the two beam numbers (ib, jb);
- the geocentric latitude and longitude of the centre of the diamond (latg,long);
- the geomagnetic latitude and longitude of the centre of the diamonds (latm,lonm);
- the two line of sight velocities at the common real altitude (vlos);
- the 3 components (in the local cartesian frame) of the magnetic field vector at the common real height (bx, by, bz);
- the 3 components (in the local cartesian frame) of the velocity vector at the common real height (vx, vy, vz);
- the two evaluations (based on the quality of the fit and based on the spectral width) of the "errors" on the velocity components in the local cartesian frame (vx_erv, vy_erv, vz_erv, and vx_erw, vy_erw, vz_erw);
- the quality index of the velocity vector (pnt_qlty).
7.2 - Graphic presentation of the data
Although the graphic presentation of the velocity map is not included in the merge program, the working group has recommended to use the following method for graphic presentation. We have to represent flow lines and not velocity vectors. These two quantities are different because of a different metric (different scales) along the axes of the map. The map can be drawn either in geographic or in magnetic coordinates.
The determination of a flow line is made as follows
(i) calculate (in geocentric coordinates) the final position of a point, initially at the center of the diamond, and moving during a time interval dt with the velocity V;
(ii) eventually calculate the magnetic coordinates of that point;
(iii) draw an arrow with its origin at the center of the diamond,
its length proportional to the modulus of V and passing
through the final point previously calculated.
8 - RESULTS OF MERGE
The maps presented in this section are plotted using a NCAR software
that is not included in the MERGE package. The coordinate system
is geocentric, and vectors are directed along the flow lines as
specified in section 7.2.
8.1 - Grid
A number of alternatives exist:
Figure 5a shows the grid points for the radar pair Goose Bay-Stokkseyri
(Iceland West) calculated by the MAKE_TABLE routine
5b and 5c show the mapping provided by the APL RBPOS routine for
each radar. All mappings are done for a constant virtual height
of 400 km. Superposing the three figures shows that these grid
points are at the intersections of the two sets of radar beams.
This is a very convincing test that the geometrical mappings are
the same in MAKE_TABLE and RBPOS (a test that we felt necessary
to convince the APL group!).
8.2 - Vectors
Figure 6a shows a vector velocity map computed from real data
of the Saskatoon and Kapuskasing radars on October 10, 1993. These
data have been averaged for 192 seconds (2 scans 16 beams 6 sec.
integration time), starting at 2155 UT. Start time, end time and
frequency for westernmost (easternmost) radar are indicated on
the left (right) side of the upper right corner of the figure.
The mapping is done for a constant 400 km virtual height, and
all data with V < 3000m/s and dV (calculated from vel_err)
< 200m/s are included. The processing options are (see paragraph
3.1): Ground-scatter elimination: option 2; E-region elimination:
option 1; Minimum power: 3dB; Minimum radial velocity: 25 m/s;
Maximum radial velocity: 3000 m/s; Maximum vel_err: 50 m/s; No
radial velocity smoothing; No radial velocity interpolation; No
divergence-free relaxation; no divergence-free extension (ifltr
= 0, idiv = 0, iext = 0).
Figure 6b is the same as figure 6a, except that it includes smoothing
of the radial velocities (ifltr = 1, idiv = 0, iext = 0). The
convection vortex seen in Figure 6a is smoother, as expected;
Figure 6c is the same as figure 6b, except that it includes the
divergence-free relaxation (ifltr = 1, idiv = 1, iext = 0). The
number of iterations is 27 for this particular case. One can see
the further smoothing effect of the relaxation, although the low
number of vectors in the map limits the effects of the divergence-free
analysis.
Figure 6d includes divergence-free relaxation and extension
(ifltr = 1, idiv = 1, iext = 1). The number of vectors is increased
from 71 to 97. These new vectors are not systematically smooth
compared to the initial map in Figure 6b. This can be explained
by the fact that the divergence-free relaxation is not done on
the final map. In other words, the divergence at grid points surrounding
the new vectors can be large.
9 - RESTRICTIONS TO MERGE - VERSION 2.3
Several restrictions apply to the present version 2.3 of MERGE, which will hopefully be removed in later versions :
- concerning the virtual height, options 2 (h' = f(range) ) and 3 (h' experimentally determined)) are not included.
- concerning the elimination of ground echoes, the options 3 (Include all echoes identified as ground scatter by fitacf for one radar, but not for the other ) and 4 (Other criteria of elimination) are not included.
- concerning the elimination of E region echoes, the option 3 (Exclude E region echoes by using the elevation angle information) is not included.
- the option "add missing radial velocities by interpolation " is not included.
- The divergence free extension is limited to diamonds of the 16x16 map. It does not concern the regions covered by only one radar (see remarks concerning the limited interest of this extension).
- The option "Increase spatial resolution by using radial velocities from individual range gates" is not included.
- The specific problem of the singularity at the geographic pole
is not solved. Close to the pole, the longitude can change by
a large amount when the position changes slightly. This implies
that calculations based on differential calculus are not valid.
This is the case for the determination of the metric of the generalized
radar coordinates (in the divergence free analysis), and also
for the projection of the positions (centers of the diamonds)
and velocities from the altitude of measurement to the standard
altitude. This problem is important for the southern hemisphere
radars. Practically, this means that for these radars, the following
options have to be chosen : (i) Constant virtual height (ialt
= 1); (ii) No divergence free analysis (idiv = 0).
ANNEX 1 : Program MERGE
ANNEX 2 : Subroutine MERGE_INFO
ANNEX 3 : File INFO.INC
ANNEX 4: Comparison Version 1 - Version 2
MERGE Version 2 is a development of the previous Version 1. Compared to Version 2, Version 1 contains the following restrictions:
- The Earth is assumed to be spherical;
- The azimuth of the radar beams are independent of the elevation angle (no cone angle effect);
- No error Calculation;
- No quality indices for the vectors and maps;
- No divergence-free relawation;
- No divergence-free extendion;
- No possibility of lagfr and/or smsep changes during the working time period.
MERGE - Version 1 was not released into the Leicester Software
Depository
ANNEX 5 : Makefiles for Librairies and
MERGE
Figure Note
Postscript source for these figures can be obtained from the Leicester Software
Depository (Directory darn/merge/DOC)