<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta content="text/html; charset=iso-8859-1"
http-equiv="Content-Type">
<meta
content="Mozilla/4.79 [en] (X11; U; Linux 2.4.18-27.7.xsmp i686) [Netscape]"
name="GENERATOR">
<title>serverConfig.py</title>
</head>
<body style="background-color: rgb(255, 255, 255);">
<div class="Body">
<h1><a name="serverConfig.py"></a>serverConfig.py</h1>
January 3, 2012<br>
<br>
<div class="Body"><a name="Overview"></a><!--Leave this comment in for formatting purposes-->The
serverConfig.py file is
one
of several configuration files for GFE.
The serverConfig.py file defines the general configuration of the
databases
and weather elements. The file is not intended to be
field-edited,
instead there is a <a href="localConfig.html">localConfig.py<!--Leave this comment in for formatting purposes--></a><!--Leave this comment in for formatting purposes-->
and <a href="localWxConfig.html">localWxConfig.py<!--Leave this comment in for formatting purposes--></a>
file that sites
use
to override settings in this file. The <a
href="VTECPartners.html">VTECPartners.py<!--Leave this comment in for formatting purposes--></a>
file defines VTEC-specific configuration items.<br>
<br>
There are additional files that are built-in to the GFE that define
VTEC entries for the Hazards weather element. These are not
configurable.<br>
<p><b><font color="#ff0000">This information is provided for you to
help
you understand the format of serverConfig.py. You should NEVER
change
the original serverConfig.py since your changes will be overwritten
with
the next upgrade. See the <a
href="serverConfiguration.html#ServerDatabaseConfigurationModificationOptions">server
configuration overview<!--Leave this comment in for formatting purposes--></a>
for information on how to make changes that
are supported to the server.</font></b> <br>
</p>
<p>The excerpts from the serverConfig.py may not be complete or
up-to-date; they serve as examples only. </p>
</div>
<h2 class="3Heading">
Organization</h2>
<div class="3Heading"><a href="#GeneralEnvironment">General Environment
and Common Functions<br>
</a></div>
<div class="3Heading"><a href="#WeatherElementConfigurationSection">Weather
Element Configuration</a></div>
<div class="3Heading"><a href="#WeatherConfigurationSection">Weather
Configuration</a></div>
<div class="3Heading"><a href="#ProjectionConfigurationSection">Projection
Configuration Section</a></div>
<div class="3Heading"><a href="#GridDomainConfiguration">Grid Domain
Configuration</a></div>
<div class="3Heading"><a href="#TimeConstraintConfiguration">Time
Constraint
Configuration</a></div>
<div class="3Heading"><a href="#DatabaseModelConfiguration">Database
Attribute Configuration</a>
<br>
<a href="#D2DModelFileDirectories">D2D Model File Directories</a>
<br>
<a href="#SATDIRS">D2D Satellite File Directories</a><br>
<a href="#D2DVersion">D2D Model Database Version Specification</a>
<br>
<a href="#InitializationModules">Initialization Modules</a>
<br>
<a href="#D2DAccumulativeWeatherElements">D2D Accumulative Elements</a>
<br>
<a href="#ISC">ISC Configuration Items</a><br>
<a href="#MiscellaneousConfigurationItems">Miscellaneous Configuration
Items</a></div>
<div class="3Heading"><a href="#WeatherElementGroupings">Weather
Element
Groupings</a></div>
<div class="3Heading"><a href="#DatabaseGroupings">Database Groupings</a></div>
<div class="3Heading"><a href="#GeneralServerConfiguration">General
Server
Configuration</a>
<br>
<br>
<hr width="100%"></div>
<h3>
<a name="GeneralEnvironment"></a>General Environment and Common
Functions<br>
</h3>
The general environment and common functions section of the
serverConfig.py file defines
general
information from the siteConfig file and convenience functions used
throughout serverConfig.py.
<p><tt><br>
def siteImport(modName):<br>
try:<br>
fp, path, des =
imp.find_module(modName)<br>
if fp:<br>
fp.close()<br>
except ImportError:<br>
return 0<br>
globals()[modName] = __import__(modName)<br>
return 1</tt></p>
<p><tt>#----------------------------------------------------------------------------</tt>
<br>
<tt># USEFUL DEFINES</tt>
<br>
<tt>#----------------------------------------------------------------------------</tt>
<br>
<tt>import siteConfig, LogStream, config</tt>
</p>
<p><tt>GFESUITE_SITEID = siteConfig.GFESUITE_SITEID<br>
GFESUITE_MHSID = siteConfig.GFESUITE_MHSID<br>
GFESUITE_SERVER = siteConfig.GFESUITE_SERVER<br>
GFESUITE_HOME = siteConfig.GFESUITE_HOME<br>
GFESUITE_PORT = int(siteConfig.GFESUITE_PORT)<br>
GFESUITE_LOGDIR = siteConfig.GFESUITE_LOGDIR<br>
GFESUITE_PRDDIR = siteConfig.GFESUITE_PRDDIR</tt>
<br>
</p>
<hr width="100%">
<h3><a name="WeatherElementConfigurationSection"></a>Weather Element
Configuration
Section</h3>
The weather element configuration section defines the attributes for
each
weather element. A weather element has the following attributes:
<br>
<table nosave="" border="1" width="100%">
<tbody>
<tr>
<td><b>Attribute</b></td>
<td><b>Scalar</b></td>
<td><b>Vector</b></td>
<td><b>Weather</b></td>
<td><b>Discrete</b></td>
<td><b>Description</b></td>
</tr>
<tr>
<td>weather element name</td>
<td>yes</td>
<td>yes</td>
<td>yes</td>
<td>yes</td>
<td>no punctuation or spaces are allowed with the exception of an
underscore
to denote a level for the weather element, that is different from
SFC.
To denote a weather element for the surface, you can use either
parmName
or parmName_SFC. To denote a weather element for a non-surface
element,
use the underscore notation, such as parmName_level.</td>
</tr>
<tr>
<td>type</td>
<td>yes</td>
<td>yes</td>
<td>yes</td>
<td>yes</td>
<td>defines the weather element type, must be SCALAR, VECTOR,
WEATHER,
or DISCRETE</td>
</tr>
<tr>
<td>units</td>
<td>yes</td>
<td>yes</td>
<td>yes</td>
<td>yes</td>
<td>defines the units used for this weather element</td>
</tr>
<tr>
<td>descriptive name</td>
<td>yes</td>
<td>yes</td>
<td>yes</td>
<td>yes</td>
<td>descriptive name for the weather element</td>
</tr>
<tr>
<td>maximum possible value</td>
<td>yes</td>
<td>yes</td>
<td>no</td>
<td>no</td>
<td>The maximum allowable value for scalar, and the maximum
allowable value
for the magnitude component of vector.</td>
</tr>
<tr>
<td>minimum possible value</td>
<td>yes</td>
<td>yes</td>
<td>no</td>
<td>no</td>
<td>The minimum allowable value for scalar, and the minimum
allowable value
for the magnitude component of vector.</td>
</tr>
<tr>
<td>precision</td>
<td>yes</td>
<td>yes</td>
<td>no</td>
<td>no</td>
<td>defines the resolution of the weather element in terms of the
number
of significant decimal points. For example, a precision of 0
indicates
a resolution of 1.0, and a precision of 2 indicates a resolution of
0.01.
Only applies to scalar fields and the magnitude component for vector.</td>
</tr>
<tr>
<td>rate-dependent weather element</td>
<td>yes</td>
<td>yes</td>
<td>no</td>
<td>no</td>
<td>If specified to be a rate-dependent parm, then changes in
valid time
of a grid will modify the data values in that grid to preserve the
calculated
rate. Values of 1 or 0, YES or NO are permitted.</td>
</tr>
<tr>
<td>overlapping discrete element</td>
<td>no</td>
<td>no</td>
<td>no</td>
<td>yes</td>
<td>If 1 or YES, then the discrete weather element permits
overlapping
values, i.e., a grid point may assume the value of more than 1 value.</td>
</tr>
<tr>
<td>key definition</td>
<td>no</td>
<td>no</td>
<td>no</td>
<td>yes</td>
<td>Defines the allowable keys and their definitions for the
discrete weather
element</td>
</tr>
<tr>
<td style="vertical-align: top;">sizeOfAuxDataField<br>
</td>
<td style="vertical-align: top;">no<br>
</td>
<td style="vertical-align: top;">no<br>
</td>
<td style="vertical-align: top;">no<br>
</td>
<td style="vertical-align: top;">yes (optional)<br>
</td>
<td style="vertical-align: top;">If specified, indicates the size
(as an integer) of the discrete auxiliary data field (string
size). Aux data can be from 0 to this length. If
sizeOfAuxDataField is not specified, then the discrete element will not
support auxiliary data.<br>
</td>
</tr>
</tbody>
</table>
<br>
<table nosave="" border="1" width="100%">
<tbody>
<tr>
<td><b>Weather Element Type</b></td>
<td><b>Format of Definition</b></td>
</tr>
<tr>
<td>SCALAR</td>
<td><tt>VariableName = ("name", type, "units", "descriptive
name", maxValue,
minValue, precision, rateWE)</tt></td>
</tr>
<tr>
<td>VECTOR</td>
<td><tt>VariableName = ("name", type, "units", "descriptive
name", maxValue,
minValue, precision, rateWE)</tt></td>
</tr>
<tr>
<td>WEATHER</td>
<td><tt>VariableName = ("name", type, "units", "descriptive name")</tt></td>
</tr>
<tr>
<td>DISCRETE</td>
<td><tt>VariableName = ("name", type, "units", "descriptive
name", overlapAllowed,
keyDefinition)<br>
</tt><tt>VariableName = ("name", type, "units", "descriptive
name", overlapAllowed,
keyDefinition, sizeOfAuxDataField)</tt><br>
</td>
</tr>
</tbody>
</table>
Note that the maximum value and minimum value must be floats, and the
precision
an integer.
<p>For discrete, the key definition is in this form:
<br>
<tt>keyDefName = [('keyName1', 'keyDescription1'), ('keyName2',
'key2Description'),
.... ]</tt>
</p>
<p>For overlapping discrete, the first key must be "<None>".
</p>
<blockquote> </blockquote>
Example entries for SCALAR, VECTOR, WEATHER, and DISCRETE
elements
are shown below:
<p><tt>#---------------------------------------------------------------------------</tt>
<br>
<tt>#</tt>
<br>
<tt># Weather Element configuration section.</tt>
<br>
<tt>#</tt>
<br>
<tt>#---------------------------------------------------------------------------</tt>
</p>
<p><tt>SCALAR = 'Scalar'</tt>
<br>
<tt>VECTOR = 'Vector'</tt>
<br>
<tt>WEATHER = 'Weather'</tt>
<br>
<tt>DISCRETE = 'Discrete'</tt>
<br>
<tt>NO = 0</tt>
<br>
<tt>YES = 1</tt>
</p>
<p><tt># Standard Public Weather Elements</tt>
<br>
<tt>Temp = ("T", SCALAR, "fahrenheit", "Surface
Temperature",</tt>
<br>
<tt> 120.0,
-60.0, 0, NO)</tt>
</p>
<p><tt>Wind = ("Wind", VECTOR, "knots", "Surface
Wind",</tt>
<br>
<tt> 80.0,
0.0, 0, NO)</tt>
</p>
<p><tt>Weather = ("Wx", WEATHER, "coverage, intensity, type", "Weather")</tt>
</p>
<p><tt>TestKeys = [("L", "Low"),("M",
"Medium"), ("H", "High")]</tt>
<br>
<tt>TestKey = ("TestKey", DISCRETE, "categories", "TestKey", NO,
TestKeys)</tt>
</p>
<h4><a name="ExtraWEPrecision"></a>ExtraWEPrecision</h4>
Weather Elements are stored in their specified precision in GFE,
thus if you have the precision set to 0 for a weather element, it will
effectively be stored as integers. Sometimes you might want
additional
precision available for certain weather elements in order to facilitate
computations on the data. For those cases, where you don't want
to
specify a higher precision (which affects labeling, sampling, ISC data
sizes, etc.), you can use the ExtraWEPrecision entry. The entry
is
a listing of weather elements that require extra precision, or is a
listing
of tuples that are weather elements and amount of extra
precision.
The effective precision assigned to these elements is one more than
that
defined in the weather element configuration section, if just the
weather
element name is used, or is the specified number of precision boosts,
if
a tuple form is used for (wename, extraPrec). You can mix and
match
the definitions, i.e., use the 'wename' form and the ('wename',
extraPrec)
form in the same declaration:
<p><tt># Scalar/Vector Weather Elements that Require Extra Precision
(due
to their</tt>
<br>
<tt># use in calculations)</tt>
<br>
<tt>#ExtraWEPrecision = ['T', 'Td', 'RH']</tt>
<br>
<tt>#ExtraWEPrecision = [('T', 1), 'Td', ('RH', 2)]</tt>
<br>
<tt>ExtraWEPrecision = []</tt>
</p>
<hr width="100%">
<h3><a name="WeatherConfigurationSection"></a>Weather Configuration
Section</h3>
The weather configuration section of the serverConfig.py file defines
all
of the possible characteristics of the WEATHER-type of weather
element.
The WEATHER type has five sets of characteristics:
<ul>
<li>weather type</li>
<li>coverage/probability</li>
<li>intensity</li>
<li>visibility</li>
<li>optional attributes</li>
</ul>
There is one set of visibilities for all weather types. However
for
each weather type, the user can define its list of possible
coverages/probabilities,
intensities, and optional attributes.
<br>
<h4><a name="PossibleVisibilities"></a>Possible Visibilities</h4>
The list of possible visibilities is given in the "visibilities"
parameter.
It is important that no entries contain a space. A special entry
is made to denote that no visibility has been defined. All
defined
weather types will use this set of visibilities. There is a defined
order
to these visibilities. The "no visibility" is defined first,
following
by increasing visibility. Changing this order is not recommended.
<p><tt># list of possible visibilities</tt>
<br>
<tt>visibilities = ['<NoVis>', '0SM', '1/4SM', '1/2SM', '3/4SM',
'1SM', '11/2SM',</tt>
<br>
<tt>
'2SM', '21/2SM', '3SM', '4SM', '5SM', '6SM', 'P6SM']</tt>
<br>
</p>
<h4><a name="PossibleCoveragesandProbabilities"></a>Possible Coverages
and
Probabilities</h4>
The list of possible coverages and probabilities consist of tuple
entries.
The first entry is the symbol that is used in the ugly weather string
as
well as on GFE dialogs. The second entry is the string that is
accessible
via product formatters to aid them in intrepreting the weather coverage
and/or probability.
<p>The symbol entry cannot contain spaces. This section simply
defines
all of the possible coverages and probabilities. Another section
of the configuration file relates these to each weather element.
</p>
<p><tt># list of possible coverages and probabilities</tt>
<br>
<tt>NOCOV = ('<NoCov>', 'No Coverage')</tt>
<br>
<tt>ISOD = ('Iso', 'Isolated')</tt>
<br>
<tt>SCT = ('Sct', 'Scattered')</tt>
<br>
<tt>NUM = ('Num', 'Numerous')</tt>
<br>
<tt>WIDE = ('Wide', 'Widespread')</tt>
<br>
<tt>OCNL = ('Ocnl', 'Occasional')</tt>
<br>
<tt>SCHC = ('SChc', 'Slight Chance Of')</tt>
<br>
<tt>CHC = ('Chc', 'Chance Of')</tt>
<br>
<tt>LKLY = ('Lkly', 'Likely')</tt>
<br>
<tt>DEFN = ('Def', 'Definite')</tt>
<br>
<tt>PATCHY = ('Patchy', 'Patchy')</tt>
</p>
<br>
<h4><a name="PossibleIntensities"></a>Possible Intensities</h4>
The list of possible intensities consist of tuple entries. The
first
entry is the symbol that is used in the ugly weather string as well as
on GFE dialogs. The second entry is the string that is accessible
via product formatters to aid them in intrepreting the intensity.
<p>The symbol entry cannot contain spaces. This section simply
defines
all of the possible intensities. Another section of the
configuration
file relates these to each weather element. Note the "moderate"
intensity
which is normally indicated by a space or null-character in
meteorology.
Since the software cannot have a space, the character 'm' has been
chosen
to indicate moderate. Since some weather types may not have an
intensity,
such as blowing snow, a no intensity entry has been defined. Each
weather type must have at least one intensity associated with it, even
if is the no intensity entry.
</p>
<p><tt># list of possible intensities</tt>
<br>
<tt>INTEN_NONE = ('<NoInten>', 'No intensity')</tt>
<br>
<tt>INTEN_VERYLIGHT = ('--', 'Very Light')</tt>
<br>
<tt>INTEN_LIGHT = ('-', 'Light')</tt>
<br>
<tt>INTEN_MOD = ('m', 'Moderate')</tt>
<br>
<tt>INTEN_HEAVY = ('+', 'Heavy')</tt>
</p>
<p>For convenience in defining the weather types, intensities groupings
may be created by declaring arrays. In this case an array named
PCPINTEN
has been created with the very light, light, moderate, and heavy
intensities.
There is a defined order to the groupings. They are usually
ordered
in increasing intensity.
</p>
<p><tt># special intensity groupings</tt>
<br>
<tt>PCPINTEN =[INTEN_VERYLIGHT, INTEN_LIGHT, INTEN_MOD, INTEN_HEAVY]</tt>
<br>
</p>
<h4><a name="OptionalAttributes"></a>Optional Attributes</h4>
The list of possible optional attributes consist of tuple
entries.
The first entry is the symbol that is used in the ugly weather string
as
well as on GFE dialogs. The second entry is the string that is
accessible
via product formatters to aid them in intrepreting the attribute.
<p>The symbol entry cannot contain spaces. This section simply
defines
all of the possible attributes. Another section of the
configuration
file relates these to each weather element. Note that there is no entry
for no attribute since weather elements can have zero or more optional
attributes.
</p>
<p><tt># list of optional attributes</tt>
<br>
<tt>FQTLTG = ('FL', 'Frequent Lightning')</tt>
<br>
<tt>GUSTS = ('GW', 'Gusty Winds')</tt>
<br>
<tt>HVYRAFL = ('HvyRn', 'Heavy Rainfall')</tt>
<br>
<tt>DMGWND = ('DmgW', 'Damaging Winds')</tt>
<br>
<tt>SMALLH = ('SmA', 'Small Hail')</tt>
<br>
<tt>LARGEH = ('LgA', 'Large Hail')</tt>
<br>
<tt>OUTLYNG = ('OLA','in the outlying areas')</tt>
<br>
<tt><br>
</tt></p>
<h4><a name="WeatherTypeDefinitions"></a>Weather Type Definitions</h4>
This section of the configuration file defines each possible weather
type,
including the no weather type. The definition brings together the
possible coverages/probabilities, intensities, and optional attributes
for each of the weather types. The weather types cannot contain a
space. The format of the entries are:
<p><tt>TypeSymbol = ('Symbol', 'Description', [coverages],
[intensities],
[optional attributes])</tt>
</p>
<p><tt>NOWX = ('<NoWx>', 'No Weather',<br>
[NOCOV],<br>
[INTEN_NONE],<br>
[])<br>
THUNDER = ('T', 'Thunderstorms',<br>
[ISOD, SCT, NUM,
WIDE, SCHC, CHC, LKLY, DEFN, OCNL, FQT, BRIEF,<br>
PERIODS, INTM],<br>
[INTEN_NONE,
INTEN_SEVERE],<br>
[PRIMARY,
MENTION, FQTLTG, HVYRAFL, GUSTS, DMGWND, DRY])<br>
HAIL = ('A', 'Hail',<br>
[ISOD, SCT, NUM,
WIDE, SCHC, CHC, LKLY, DEFN, OCNL, FQT, BRIEF,<br>
PERIODS, INTM],<br>
[INTEN_NONE],<br>
[PRIMARY,
MENTION, LARGEH, SMALLH])<br>
RAIN = ('R', 'Rain',<br>
[WIDE, SCHC,
CHC, LKLY, DEFN, OCNL, FQT, BRIEF, PERIODS, INTM],<br>
[INTEN_VERYLIGHT, INTEN_LIGHT, INTEN_MOD, INTEN_HEAVY],<br>
[PRIMARY,
MENTION, OR])<br>
RAINSHOWERS = ('RW', 'Rain Showers',<br>
[ISOD, SCT, NUM,
WIDE, SCHC, CHC, LKLY, DEFN, OCNL, FQT, BRIEF,<br>
PERIODS, INTM],<br>
[INTEN_VERYLIGHT, INTEN_LIGHT, INTEN_MOD, INTEN_HEAVY],<br>
[PRIMARY,
MENTION, OR])<br>
</tt><br>
</p>
<p>The "types" entry combines all of the defined types into an ordered
list. It is important to keep this list in proper meteorological order
or the display of the weather information will not use meteorological
conventions.
For example, T is the symbol for Thunder and RW is the symbol for rain
showers. Thunder appears before rain showers in the following
list.
As a result, when thunder is combined with rain showers the composite
symbol
is displayed as TRW, which is a very common symbol for the
forecaster.
If the Thunder and rain showers were reversed, thunderstorms would be
displayed
as RWT which has no meaning to the forecaster.
</p>
<p><tt>types = [NOWX, THUNDER, WATERSPOUT, HAIL, RAIN, RAINSHOWERS,</tt>
<br>
<tt> DRIZZLE, FZRAIN,
FZDRIZZLE, SNOW, SNOWSHOWERS,</tt>
<br>
<tt> SLEET, FOG,
FREEZEFOG,
ICEFOG, ICECRYSTAL ,HAZE, BLWGSNOW,</tt>
<br>
<tt> BLWGSAND, SMOKE,
BLWGDUST, SA, CAL, FROST, FQTGSTS, FRZSPRAY,</tt>
<br>
<tt> VOLASH]</tt>
</p>
<hr width="100%">
<h3><a name="ProjectionConfigurationSection"></a>Projection
Configuration Section</h3>
The map projection information defines each of the standard AWIPS
projections
in use. This section is used to define a new projection that isn't one
of the standards. The projections that are currently known by the
GFESuite software are:
<br>
<table nosave="" border="1" cols="4" width="100%">
<tbody>
<tr>
<td>Grid201</td>
<td>Grid202</td>
<td>Grid203</td>
<td>Grid204</td>
</tr>
<tr>
<td>Grid205</td>
<td>Grid206</td>
<td>Grid207</td>
<td>Grid208</td>
</tr>
<tr>
<td>Grid209</td>
<td>Grid210</td>
<td>Grid211</td>
<td>Grid212</td>
</tr>
<tr>
<td>Grid213</td>
<td>Grid214</td>
<td>Grid215</td>
<td>Grid216</td>
</tr>
<tr>
<td>Grid217</td>
<td>Grid218</td>
<td>Grid219</td>
<td>Grid221</td>
</tr>
<tr>
<td>Grid222</td>
<td>Grid225</td>
<td>Grid226</td>
<td>Grid227</td>
</tr>
<tr>
<td>Grid228</td>
<td>Grid229</td>
<td>Grid230</td>
<td>Grid231</td>
</tr>
<tr>
<td>Grid232</td>
<td>Grid233</td>
<td>Grid234</td>
<td>Grid235</td>
</tr>
<tr>
<td>HRAP</td>
<td>Grid214AK</td>
<td><br>
</td>
<td><br>
</td>
</tr>
</tbody>
</table>
<p>All of the map projection information was derived from the paper,
"Map
Projections A Working Manual," by John P. Snyder. This manual was
published
as U.S. Geological Survey Paper No. 1395. The reader is referred to
this
paper for details not included in this discussion.
</p>
<p>Eventually this section will be removed from the configuration
file.
A projection will be displayed only when a new, non-standard projection
is needed.
</p>
<p>The information that is required to define a projection is shown
below,
not all of the entries are needed for each projection type:
</p>
<ul>
<li>projection identifier</li>
<li>projection type (LAMBERT_CONFORMAL, MERCATOR,
POLAR_STEREOGRAPHIC,
LATLON</li>
<li>lower left point latitude/longitude</li>
<li>upper right point latitude/longitude</li>
<li>latitude longitude origin</li>
<li>standard parallel one</li>
<li>standard parallel two</li>
<li>grid point number for lower left point</li>
<li>grid point number for upper right point</li>
<li>latitude intersect</li>
<li>longitude center</li>
<li>longitude origin</li>
</ul>
At the end of the projection information is a list containing all of
the
projections.
<p><tt>#---------------------------------------------------------------------------</tt>
<br>
<tt>#</tt>
<br>
<tt># Projection Configuration section.</tt>
<br>
<tt>#</tt>
<br>
<tt>#---------------------------------------------------------------------------</tt>
<br>
<tt>NONE = 0</tt>
<br>
<tt>LAMBERT_CONFORMAL = 1</tt>
<br>
<tt>MERCATOR = 2</tt>
<br>
<tt>POLAR_STEREOGRAPHIC = 3</tt>
<br>
<tt>LATLON = 4</tt>
<br>
</p>
<p><tt># projectionID / projectionType / latLonLL / latLonUR /</tt>
<br>
<tt># latLonOrigin / stdParallelOne / stdParallelTwo / gridPointLL
/ gridPointUR</tt>
<br>
<tt># latIntersect / lonCenter / lonOrigin</tt>
</p>
<p><tt>Grid201 = ('Grid201',POLAR_STEREOGRAPHIC,</tt>
<br>
<tt> (-150.00, -20.826), (-20.90846,
30.0),</tt>
<br>
<tt> (0.0, 0.0), 0.0, 0.0, (1, 1), (65,
65), 0.0, 0.0, -105.0)</tt>
</p>
<p><tt>Grid202 = ('Grid202', POLAR_STEREOGRAPHIC,</tt>
<br>
<tt> (-141.028, 7.838), (-18.576, 35.617),</tt>
<br>
<tt> (0.0, 0.0), 0.0, 0.0, (1, 1), (65,
43), 0.0, 0.0, -105.0)</tt>
</p>
<p><tt># list of all projections</tt>
<br>
<tt>allProjections = [Grid201, Grid202, Grid203, Grid204, Grid205,
Grid206,</tt>
<br>
<tt> Grid207, Grid208, Grid209, Grid210, Grid211, Grid212,
Grid213,
Grid214,</tt>
<br>
<tt> Grid214AK, Grid215, Grid216, Grid217, Grid218, Grid219,
Grid221,
Grid222,</tt>
<br>
<tt> Grid225, Grid226, Grid227, Grid228, Grid229, Grid230,
Grid231,
Grid232,</tt>
<br>
<tt> Grid233, Grid234, Grid235, HRAP]</tt>
<br>
</p>
<hr width="100%">
<h3><a name="GridDomainConfiguration"></a>Grid Domain Configuration</h3>
The grid domain configuration section contains entries for each WFO in
the AWIPS system. The entries define the grid characteristics for
each site. These charactistics are:
<ul>
<li>grid size</li>
<li>grid location (origin and domain) in world coordinates</li>
<li>site time zone</li>
<li>projection identifier</li>
</ul>
The format of the entries are:
<p><tt>'siteid' : ((xdim,ydim), (xorigin,yorigin), (xextent,yextent),
'timezone',
projection)</tt>
</p>
<p>This example shows the relationship between the AWIPS Grid 211
projection
and a grid domain. The AWIPS world coordinate xorigin is 37,
yorigin
is 27, the xextent is 9, and the yextent is 9. The size of the AWIPS
grid
is therefore 9x9, but the desired size of the GFESuite grid is
73x73.
Thus the software has the capability of expanding each AWIPS grid cell
on the projection in order to increase resolution.<img
src="images/worlddomain.gif" align="middle" height="248" width="473">
<br>
<tt>#---------------------------------------------------------------------------</tt>
<br>
<tt>#</tt>
<br>
<tt># Grid Domain configuration section</tt>
<br>
<tt>#</tt>
<br>
<tt>#---------------------------------------------------------------------------</tt>
<br>
<tt>#</tt>
<br>
<tt># xdim/ydim: Defines the dimensions of the grids.</tt>
<br>
<tt>#</tt>
<br>
<tt># origin: Defines the lower-left corner of the grid (point
0,0) in</tt>
<br>
<tt># world coordinates.</tt>
<br>
<tt>#</tt>
<br>
<tt># extent: Defines the "size" of the grid in world
coordinates.
The upper</tt>
<br>
<tt># right corner is the origin+extent.</tt>
<br>
<tt>#</tt>
<br>
<tt># timezone: defines the time zone used for the site.</tt>
<br>
<tt>#</tt>
<br>
<tt># Projection: Defines the projection identifier to be used
for this domain.</tt>
</p>
<p><tt># Note that all parameters for an existing database must use the
same</tt>
<br>
<tt># projection, though not necessarily the same grid size and
location.</tt>
</p>
<p><tt># [xdim, ydim]
/
(origin) / (extent) / Projection / Office Type</tt>
</p>
<p><tt>SITES = {</tt>
<br>
<tt> 'ABQ' : ([145, 145], (36.00, 22.00), (9.0, 9.0),
'MST7MDT', Grid211, 'wfo'),</tt>
<br>
<tt> 'ABR' : ([145, 145], (45.00, 35.00), (9.0, 9.0),
'CST6CDT', Grid211, 'wfo'),</tt>
<br>
<tt> 'AFC' : ([1034/2, 423/2], (1.0, 19.0), (67.0,
28.0), 'America/Anchorage', Grid214AK, 'wfo'),</tt>
<br>
<tt> 'AFG' : ([313, 201], (27.0, 39.0), (39.0, 25.0),
'America/Anchorage', Grid214AK, 'wfo'),</tt>
<br>
<tt> 'AJK' : ([337, 241], (62.0, 23.0), (21.0, 15.0),
'America/Anchorage', Grid214AK, 'wfo'),</tt>
<br>
<tt> 'AKQ' : ([145, 145], (68.00, 25.00), (9.0, 9.0),
'EST5EDT', Grid211, 'wfo'),</tt>
<br>
<tt> 'ALY' : ([145, 145], (70.00, 33.00), (9.0, 9.0),
'EST5EDT', Grid211, 'wfo')]</tt>
</p>
<p>Note that the origin and extents are floating-point numbers and thus
must have decimal point in them.
<br>
</p>
<hr width="100%">
<h3><a name="TimeConstraintConfiguration"></a>Time Constraint
Configuration</h3>
Each weather element has a defined time constraint. The time
constraint
forces grids to be aligned on the constraint boundaries. There
are
three components to a time constraint: start time, repeat, and
duration.
Grids are aligned on a start time boundary, repeat every repeat
interval,
and have a duration of that specified. All numbers are in seconds
so a variable is declared for HOUR and DAY to make the entries more
legible.
The start time is based on 0000z. The format is:
<p><tt>timeConstraintName = (start, repeat, duration)</tt>
</p>
<p><img src="images/timeconstraint.gif" height="353" width="599"><br>
We have a standard naming convention for most of the Time Constraints
in the form of "TC", followed by the repeat in hours, followed by NG if
there aren't any gaps. So a TC3 would be a time constraint for
every
3 hours, with a grid that is only 1 hour long. A TC3NG would be a
time constraint for every 3 hours with a grid that is 3 hours
long.
NG stands for no gaps.
</p>
<p>We also have several local time-based time constraints. These
are typically prefixed with LT for local time.
</p>
<p><tt>#---------------------------------------------------------------------------</tt>
<br>
<tt>#</tt>
<br>
<tt># Time Constraint configuration section</tt>
<br>
<tt>#</tt>
<br>
<tt>#---------------------------------------------------------------------------</tt>
<br>
<tt>HOUR = 3600</tt>
<br>
<tt>DAY = 24 * HOUR</tt>
</p>
<p><tt># Start: is the number of seconds since 0000z for the first grid
of the day</tt>
<br>
<tt># Repeat: is the number of seconds from start until the next grid
starts</tt>
<br>
<tt># Duration: is the length of the grid in number of seconds</tt>
</p>
<p><tt># Examples of constraints:</tt>
<br>
<tt># Hourly temperatures</tt>
<br>
<tt># HrTemp = (0, HOUR, HOUR)</tt>
<br>
<tt># QPF that is 6 hours long, aligned on 0000z, exists for every
6 hours</tt>
<br>
<tt># Q = (0, HOUR*6, HOUR*6)</tt>
<br>
<tt>#</tt>
</p>
<p><tt># start / repeat / duration</tt>
<br>
<tt># fixed time constraints: start / repeat / duration</tt>
<br>
<tt>TC1 = (0, HOUR, HOUR)</tt>
<br>
<tt>TC3 = (0, 3 * HOUR, HOUR)</tt>
<br>
<tt>TC6 = (0, 6 * HOUR, HOUR)</tt>
<br>
<tt>TC12 = (0, 12 * HOUR, HOUR)</tt>
<br>
<tt>TC3NG = (0, 3 * HOUR, 3 * HOUR)</tt>
<br>
<tt>TC6NG = (0, 6 * HOUR, 6 * HOUR)</tt>
<br>
<tt>TC12NG = (0, 12 * HOUR, 12 * HOUR)</tt>
<br>
<tt>TC061212 = (6 * HOUR, 12 * HOUR, 12 * HOUR)</tt>
<br>
<tt>Persistent = (0, 0, 0) # special used only
for GeoWeight grids</tt>
<br>
<br>
</p>
<p>Maximum and Minimum Temperature need special time constraints since
their constraints are based on local time. Since the time
constraints
are only specified in GMT, a python mechansim is written to look at the
sites's time zone and adjusts the time constraints for local time. The
localTC macro takes four arguments: start, repeat, duration, and dst.
The
start is entered in number of seconds from midnight localtime. For
example,
6*HOUR would indicate 6am. The repeat and duration are in seconds. The
dst flag is 0 for calculation of these time constraints in standard
time
and 1 for calculation for daylight savings time. Note that the server
cannot
automatically switch these time constraints between standard and
daylight
savings time. If a site chooses to edit the entries for daylight
savings
time, be aware that the server will mark the entire database (and hence
all of the data contained within) invalid.
</p>
<p><tt>def localTC(start,repeat,duration,dst):</tt>
<br>
<tt> timezone = SITES[GFESUITE_SITEID][3]</tt>
<br>
<tt> import os</tt>
<br>
<tt> os.environ['TZ'] = timezone</tt>
<br>
<tt> import time</tt>
<br>
<tt> start = time.timezone + start</tt>
<br>
<tt> if dst == 1:</tt>
<br>
<tt> start = start - 3600</tt>
<br>
<tt> if start >= 3600 * 24:</tt>
<br>
<tt> start = start - 3600
* 24</tt>
<br>
<tt> elif start < 0:</tt>
<br>
<tt> start = start + 3600
* 24</tt>
<br>
<tt> return (start, repeat, duration)</tt>
</p>
<p><tt>MaxTTC = localTC(7*HOUR, 24*HOUR,
12*HOUR,
0)</tt>
<br>
<tt>MinTTC = localTC(19*HOUR, 24*HOUR, 13*HOUR,
0)</tt>
<br>
<tt>MaxRHTC = localTC(15*HOUR, 24*HOUR,
18*HOUR,
0)</tt>
<br>
<tt>MinRHTC = localTC(3*HOUR, 24*HOUR, 18*HOUR,
0)</tt>
<br>
<tt>LT3NG = localTC(0*HOUR, 3*HOUR, 3*HOUR,
0)</tt>
<br>
<tt>LT6NG = localTC(0*HOUR, 6*HOUR, 6*HOUR,
0)</tt>
<br>
<tt>LT12NG = localTC(6*HOUR, 12*HOUR, 12*HOUR, 0)</tt>
<br>
<tt>LTMOS = localTC(6*HOUR, 12*HOUR, 12*HOUR,
0) #special MOS local time</tt>
<br>
<tt>MaxTTCMOS = localTC(6*HOUR, 24*HOUR, 12*HOUR, 0) #special
MOS maxT</tt>
<br>
<tt>MinTTCMOS = localTC(18*HOUR, 24*HOUR, 12*HOUR, 0) #special
MOS minT</tt>
<br>
<tt>LT24 = localTC(0*HOUR, 24*HOUR,
24*HOUR,
0)</tt>
<br>
<tt>FireWx1300TC = localTC(13*HOUR, 24*HOUR, 1*HOUR, 0)
#special FireWx 1pm snap</tt>
</p>
<hr width="100%">
<h3><a name="DatabaseModelConfiguration"></a>Database Attribute
Configuration</h3>
The database or model attribute configuration section defines
characteristics
of the database. The characterstics defined are:
<ul>
<li>model name</li>
<li>model format - this is always GRID. GFESuite only uses the
GRID
format.</li>
<li>optional type - usually set to "" for no optional type. For
special
cases may be set to other strings. For example, isc virtual parm
databases
have their own set of weather elements.
Their database optional type is "V". The GFE may be configured
to
view databases based on model name and optional type.</li>
<li>singleton - a singleton database is not time-stamped.
Therefore
the
database is always in existance and is never purged. Typically
the
forecast, official, and observational-type databases (e.g., LAPS
Analysis)
are singleton databases. Typically the model databases (e.g.,
NAM)
are not singletons since the database contains a time stamp of the
model
run time.</li>
<li>official - an official database has special meaning. It is
typically
the database from which official products are generated. Official
databases
have special protocol to populate them. They cannot be "locked"
or
"edited" like non-official databases. Forecast data can only be
"published"
to the official database.</li>
<li>number of versions - number of versions of this database. Should
be 1
for
singleton databases.</li>
<li>purge age in hours - if non-zero, the grids in the database will
be
purged
once the entire grid is "older" than the purge age in hours from the
current
system time. Typically the singleton databses are grid purged
while
the model databases are not.</li>
</ul>
<p><br>
<tt>#---------------------------------------------------------------------------</tt>
<br>
<tt>#</tt>
<br>
<tt># Database/(Model) attribute section</tt>
<br>
<tt>#</tt>
<br>
<tt>#---------------------------------------------------------------------------</tt>
<br>
<tt>#</tt>
<br>
<tt># name: The model name of the database</tt>
<br>
<tt>#</tt>
<br>
<tt># format: Always 'GRID'</tt>
<br>
<tt>#</tt>
<br>
<tt># type: Optional type of the database</tt>
<br>
<tt>#</tt>
<br>
<tt># single: YES or NO. YES if this database always exists and
is not</tt>
<br>
<tt># based on model-times. NO if this database is
created/destroyed and</tt>
<br>
<tt># is based on model-runs. When created, the names
of these databases have</tt>
<br>
<tt># time stamps.</tt>
<br>
<tt>#</tt>
<br>
<tt># official: YES or NO. YES if this is an official
database
from which</tt>
<br>
<tt># products can be generated. NO if this is a
conventional database.</tt>
<br>
<tt>#</tt>
<br>
<tt># numVer: Number of versions of this database to retain.</tt>
<br>
<tt>#</tt>
<br>
<tt># purgeAge: Number of hours in the past before grids will be
automatically</tt>
<br>
<tt># purged from the database. If 0, then purging
is disabled.</tt>
<br>
<tt>#</tt>
</p>
<p><tt>YES = 1<br>
NO = 0<br>
GRID = 'GRID'<br>
# name / format / type / single / official / numVer / purgeAge<br>
<br>
Fcst =
('Fcst',
GRID, '', YES, NO, 1, 24)<br>
Restore =
('Restore', GRID, '', YES,
NO, 1, 24)<br>
Test =
('Test',
GRID, 'test', NO, NO, 1, 0)<br>
Official = ('Official',
GRID, '', YES, YES, 1, 24)<br>
ISC =
('ISC',
GRID, '', YES, NO, 1, 12)<br>
LAPS =
('LAPS',
GRID, '', YES, NO, 1, 30)<br>
SAT =
('SAT',
GRID, '', YES, NO, 1, 12)<br>
NAM12 =
('NAM12', GRID,
'', NO, NO, 2, 0)<br>
NAM40 =
('NAM40', GRID,
'', NO, NO, 2, 0)<br>
NAM80 =
('NAM80', GRID,
'', NO, NO, 2, 0)<br>
NGM80 =
('NGM80', GRID,
'', NO, NO, 2, 0)<br>
GFS40 =
('GFS40', GRID,
'', NO, NO, 2, 0)<br>
GFS190 =
('GFS190', GRID, '',
NO, NO, 2, 0)<br>
gfsLR =
('gfsLR', GRID,
'', NO, NO, 2, 0)<br>
RUC80 =
('RUC80', GRID,
'', NO, NO, 2, 0)<br>
AVNMOS =
('AVNMOS', GRID, '',
NO, NO, 3, 0)<br>
NAMMOS =
('NAMMOS', GRID, '',
NO, NO, 3, 0)<br>
MRFMOS =
('MRFMOS', GRID, '',
NO, NO, 3, 0)<br>
NGMMOS =
('NGMMOS', GRID, '',
NO, NO, 3, 0)<br>
HPCStn =
('HPCSTN', GRID, '',
NO, NO, 2, 0)<br>
HPCGrid =
('HPCGRID', GRID, '',
NO, NO, 2, 0)<br>
GWW =
('GWW',
GRID, '', NO, NO, 2, 0)<br>
HPCQPF =
('QPF',
GRID, '', NO, NO, 4, 0)<br>
HPCDelta = ('HPCdelta',
GRID, '', NO, NO, 2, 0)<br>
TPCTCM =
('TPCtcm', GRID, '',
NO, NO, 2, 0)<br>
MSAS =
('MSAS',
GRID, '', YES, NO, 1, 36)<br>
GLERL =
('GLERL', GRID,
'', NO, NO, 2, 0)<br>
AKWAVE =
('AKWAVE', GRID, '',
NO, NO, 2, 0)<br>
WNAWAVE =
('WNAWAVE', GRID, '',
NO, NO, 2, 0)</tt><br>
</p>
<hr width="100%">
<h3><a name="D2DModelFileDirectories"></a>D2D Model File Directories</h3>
EDEX automatically scans the single pre-defined D2D model file directory and provides
this data as additional grids for display, or for use in smart tools.
The user can define which model directories correspond to which GFE
model.<span style="font-family: monospace;"><br>
</span>
<pre><span style="font-family: monospace;"></span><br>D2DMODELS = [('MRF204', 'gfsLR'),
('AVN225', 'GFS75'),
'GWW233',
'GlobalWave',
('TPCWindProb', 'TPCProb'),
]</pre>
<p>The actual syntax in the serverConfig.py file looks more complicated
since it defines the D2DMODELS based on the site identifier. OCONUS
sites use a different set of directories.
</p>
<p>Note that the above example has a mixture of tuples and
strings. There is an alternative form of the D2DMODELS that is used
when the hdf5
model variable (which determines the name of the model as seen by
GFESUITE)
conflicts with another model of the same name. Each entry in the list
of
D2DMODELS can either be a string, such as above, which indicates the
directory
name, or it can be a tuple of ('directory name', 'modelName'). If the
second
form is used, then the model variable in the hdf5 file is ignored and
the given modelName is used instead.
<br>
</p>
<hr style="width: 100%; height: 2px;">
<h3><a name="SATDIRS"></a>D2D Satellite File Directories</h3>
GFE recognizes the D2D satellite data as a valid data
set. EDEX will scan the listed set of D2D directories
for satellite data for use in display, and smart initialization.
Since the satellite data is organized differently than model data, the
specification of the D2D satellite directories consist of the directory
name, plus the name of the weather element contained within that
directory. D2D stores one image (one wavelength) within each data
file.<br>
<br>
The format of the entry is a list of tuples. The tuples are of
length two and contain the D2D directory name and weather element name.<br>
<br>
<span style="font-family: monospace;">SATDATA = [("NESDIS/GOES-13(N)/East CONUS/Imager Visible", "visibleEast"),<br>
("NESDIS/GOES-13(N)/East CONUS/Imager 11 micron IR", "ir11East"),<br>
("NESDIS/GOES-13(N)/East CONUS/Imager 12 micron IR", "ir13East"),<br>
("NESDIS/GOES-13(N)/East CONUS/Imager 3.9 micron IR", "ir39East"),<br>
("NESDIS/GOES-13(N)/East CONUS/Imager 6.7-6.5 micron IR (WV)", "waterVaporEast")]</span>
<p><br>
</p>
<hr width="100%">
<h3><a name="D2DVersion"></a>D2D Model Database Version Specification</h3>
The number of available D2D model databases is defaulted to 2.
This
number can be overridden through the localConfig.py mechansism.
The
user can specify the D2D model name and the number of versions to
retain.
Note that the number is the maximum number that will be available to
the
GFESuite, not necessarily the real number of versions that are
available
since AWIPS D2D handles the purging of these databases. If you
increase
the number for the D2D databases, then you will likely want to modify
the
Database Attributes for the equivilant IFP database in order for smart
initialization to be able to create and populate it. The number
of
available databases in the Database Attributes should be greater to or
equal to the number of databases specified in the D2D Model Database
Version
specification. This definition is also used for D2D Satellite Databases
to determine the number of images that can be seen by GFE.
<p>The format of the entry is:
<br>
<tt>#D2DDBVERSIONS = {</tt>
<br>
<tt># "modelname": numVersions</tt>
<br>
<tt># }</tt>
</p>
<p>For example, the following sets the number of LAPS databases to 5,
and
the number of NAM to 3:
</p>
<p><tt>D2DDBVERSIONS = {</tt>
<br>
<tt> "NAM80": 3,</tt>
<br>
<tt> "LAPS":5</tt>
<br>
<tt> }</tt>
<br>
</p>
<hr width="100%">
<h3><a name="InitializationModules"></a>Initialization Modules</h3>
The smart initialization technique of GFESuite is initiated from EDEX.
The serverConfig.py file provides a mapping of D2D directories to
initialization
run modules. For example, here is the section in serverConfig.py:
<p><tt>INITMODULES = {<br>
"NAM40" : ["NAM40", "NAM20"],<br>
"NAM80" : ["NAM80"],<br>
"RUC80" : ["RUC80"],<br>
"gfsLR" : ["gfsLR"],<br>
"NGM80" : ["NGM80"],<br>
"NAM12" : ["NAM12"],<br>
"GFS40" : ["GFS40"],<br>
"GFS190" : ["GFS190"],<br>
"LAPS" : ["LAPS"],<br>
"HPCQPF" : ['HPCQPF'],<br>
"MSAS" : ['MSAS'],<br>
"HPCdelta" : ['HPCdelta'],<br>
"SAT" : ['Satellite']<br>
}<br>
</tt><tt><br>
</tt></p>
<p>This is standard Python syntax for a dictionary, with the keys on
the
left of the colon and the values as a list on the right side. For
example, the first line:
</p>
<p><tt>"NAM40" : ["NAM40", "NAM20"]</tt>
</p>
<p>indicates that the NAM40 initialization module will be executed
whenever
changes occur in the NAM40 and NAM20 D2D databases. The "MesoNAM"
NAM40/NAM20
is more complicated than most models since it arrives in two completely
separate hdf5 files and resolution. The syntax for the "NAM12"
model
is more straightforward:
</p>
<p><tt>"NAM12" : ["NAM12"]</tt>
</p>
<p>which indicates that the NAM12 initialization module (named NAM12.py
and
found in the /awips2/edex/data/utility/edex_static/base/smartinit) directory will be executed
whenever the
D2D NAM12 model changes. Remember that the initialization module
is
on the left, and the D2D model name files are on the right.
</p>
<p>By default, the smart initialization will run for each model run of
a particular model. This behavior can be changed by listing the
model
name and the hours to skip. For example, here is a section in
serverConfig.py:
</p>
<p><tt>INITSKIPS = {</tt>
<br>
<tt> "RUC80" :
[1,2,4,5,7,8,10,11,13,14,16,17,19,20,22,23],</tt>
<br>
<tt> }</tt>
</p>
<p>This is standard Python syntax for a dictionary. This line:
</p>
<p><tt>"RUC80" : [1,2,4,5,7,8,10,11,13,14,16,17,19,20,22,23],</tt>
</p>
<p>indicates that all runs of the RUC80 will be ignored, except every 3
hours.
</p>
<p>The default for serverConfig is to run all of the available model
runs,
except for RUC80, which is run only every 3 hours.
</p>
<hr width="100%">
<h3><a name="D2DAccumulativeWeatherElements"></a>D2D Accumulative
Weather Elements</h3>
The dictionary of accumulative weather elements is defined by model and
weather element. If a weather element is declared, then the
software
will treat that element as a duration or accumulative element.
The
model grid time will be considered as the ending time of the
grid.
Only the weather element name (not the level) is specified in the
dictionary.
<p><tt># This is a listing of D2D model name, and weather
elements.
The</tt>
<br>
<tt># weather elements defined in this list are treated as accumulative</tt>
<br>
<tt># elements, thus the snapshot time of the grid is converted to
be a</tt>
<br>
<tt># grid with timestep duration, starting the previous model timestep
and</tt>
<br>
<tt># going up to but not including the snapshot time.</tt></p>
<p><tt>D2DAccumulativeElements= {<br>
"GFS40": ["tp", "cp"],<br>
"GFS190": ["tp", "cp"],<br>
"NAM80": ["tp", "cp"],<br>
"NAM40": ["tp", "cp"],<br>
"NAM20": ["tp", "cp"],<br>
"NAM12": ["tp", "cp"],<br>
"NGM80": ["tp", "cp"],<br>
"gfsLR": ["tp", "cp"],<br>
"RUC80": ["tp", "cp"],<br>
"MSAS": ["tp", "cp"],<br>
"LAPS": ["pc"],<br>
"HPCQPF": ["tpHPC"],<br>
"HPCdelta": ["pop", "tcc"],<br>
}<br>
</tt><br>
</p>
<hr style="width: 100%; height: 2px;">
<h3><a name="ISC"></a>Intersite Coordination Configuration Items</h3>
This section defines the configuration of the intersite coordination
feature of GFESuite:<br>
<ul>
<li>ISC_ROUTING_TABLE_ADDRESS - defines the base url for the ISC
Routing Table web service as a string. If None is specified, then
the system will be unable to transmit or receive ISC data.</li>
<li>REQUESTED_ISC_SITES - defines the sites, as a list, from which
ISC data will be requested. If None is specified, then EDEX
will automatically calculate the needed isc sites by
examining the list of ISC_xxx edit areas. <br>
</li>
<li>REQUEST_ISC - overall toggle to control the ingest of ISC
data. If this flag is set to 0, then EDEX will not
register with the ISC Routing Table web server and no ISC data will be
received. If this flag is 1, then EDEX reigsters with
the web service for the data sets defined in REQUESTED_ISC_SITES.</li>
<li>SEND_ISC_ON_SAVE - toggle to turn on the transmission of ISC data
when grids are stored in the Fcst database. The list of sites to
send is obtained from other EDEX registrations with the ISC
Routing Table web service. Note that ISC grids will be sent only if
the GFE is used to save the grids. For example, if iscMosaic is used
to modify the Fcst database, those grids will not be sent via ISC at
the time of the save.<br>
</li>
<li>SEND_ISC_ON_PUBLISH - toggle to turn on the transmission of ISC
data when grids are published in the Official database. The list
of sites to send is obtained from other EDEX registrations with
the ISC Routing Table web service.</li>
<li>REQUESTED_ISC_PARMS - defines the weather elements desired to be
received for ISC, as a list. If set to None, then EDEX
will automatically set the list to be equivilant of all weather
elements in your ISC database. To receive weather elements from
an office that is the same type as yours (e.g., wfo to a wfo), then
simply specify the weather element, such as T. To receive
weather elements from an office that is of a different office type than
yoursr (e.g., rfc to a wfo), then specify the weather element followed
by the sending office type. For example, requesting QPF from an
RFC if you are an RFC is done by including QPF as the element you want,
but requesting QPF from an RFC if you are a WFO is done by including
QPFrfc.<br>
</li>
<li>TRANSMIT_SCRIPT - name of the script to send ISC messages.
The script will need to accept the following switches:<br>
</li>
<ul>
<li>-s - subject line, normally ISCGRIDS</li>
<li>-a - address list, generates comma separated addressee list,
such as "CLE,PBZ,BUF", which represents the AWIPS MHS identifiers<br>
</li>
<li>-i - id string, normally similar to TTAA0 KXXX 021232</li>
<li>-c - AWIPS MHS code, normally 11</li>
<li>-p - priority mode, 0 is lowest, 2 is highest</li>
<li>-e - enclosure list, such as "f1, f2, f3", containing the ISC
data compressed, and the ISC destination routing information <br>
</li>
</ul>
<li>EXTRA_ISC_PARMS - list of weather elements and office types to
add additional ISC weather elements into the ISC database. For
ISC to work between different office types (e.g., wfo to rfc), the list
of weather elements you wish to receive from the different office types
must be listed. This adds special renamed weather elements to the
database. The format of the entry is a list. The elements
of the list are two-element tuples with the 1st element being a list of
weather elements (the actual element definition as shown in the <a
href="#WeatherElementConfigurationSection">Weather Element
Configuration Section</a>-- NOT the weather element name), and the 2nd
element being a string representing the office type. There
is no harm in attempting to add weather elements for your own office
type, although those will be ignored.</li>
<ul>
<li>Examples: To receive T, RH, and QPF from an rfc when you
aren't an rfc: <br>
</li>
<ul>
<li>EXTRA_ISC_PARMS = [([Temp, RH, QPF], 'rfc')]<br>
</li>
</ul>
</ul>
</ul>
<br>
NOTE: Sites will have to enable SEND_ISC_ON_SAVE in order to send
intersite grids. Sites will need to configure REQUEST_ISC in
order to receive intersite grids. Sites should consider whether
the defaults for REQUESTED_ISC_SITES and REQUESTED_ISC_PARMS are
sufficient; in all likelyhood the default values will send too much
data to
too many sites. Refer to the <a href="IntersiteCoordination.html">Intersite
Coordination Guide</a> for more details.<br>
<br>
<span style="font-family: monospace;">#---------------------------------------------------------------------------</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">#</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"># Intersite Coordination
Configurations</span><br style="font-family: monospace;">
<span style="font-family: monospace;">#</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">#---------------------------------------------------------------------------</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"># base url for the ISC Routing
Table</span><br style="font-family: monospace;">
<span style="font-family: monospace;">ISC_ROUTING_TABLE_ADDRESS = "xxxx"</span><br
style="font-family: monospace;">
<br style="font-family: monospace;">
<span style="font-family: monospace;"># list of sites that from which
you want ISC data (If None, EDEX will</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"># automatically calculate the
list.)</span><br style="font-family: monospace;">
<span style="font-family: monospace;">REQUESTED_ISC_SITES = None</span><br
style="font-family: monospace;">
<br style="font-family: monospace;">
<span style="font-family: monospace;"># Overall ISC request flag.
Must be set to 1 in order to request and receive</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"># ISC data.</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">REQUEST_ISC = 1</span><br
style="font-family: monospace;">
<br style="font-family: monospace;">
<span style="font-family: monospace;"># Sending control flag. Set
to 1 to send isc when data is saved.</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">SEND_ISC_ON_SAVE = 1</span><br
style="font-family: monospace;">
<br style="font-family: monospace;">
<span style="font-family: monospace;"># Sending control flag. Set
to 1 to send isc when data is published.</span><br
style="font-family: monospace;">
<span style="font-family: monospace;">SEND_ISC_ON_PUBLISH = 1</span><br
style="font-family: monospace;">
<br style="font-family: monospace;">
<span style="font-family: monospace;"># List of weather elements to
request for ISC. If set to None, it defaults</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"># to the list of all weather
elements in the ISC database.</span><br style="font-family: monospace;">
<span style="font-family: monospace;">REQUESTED_ISC_PARMS = None</span><br
style="font-family: monospace;">
<br style="font-family: monospace;">
<span style="font-family: monospace;"></span><span
style="font-family: monospace;"></span><span
style="font-family: monospace;"># Transmission script for sending
data. This is the script that iscExtract</span><br
style="font-family: monospace;">
<span style="font-family: monospace;"># will call to perform the actual
transmission of data.</span><br style="font-family: monospace;">
<span style="font-family: monospace;">TRANSMIT_SCRIPT =
GFESUITE_HOME + '/bin/gfe_msg_send -s %SUBJECT -a %ADDRESSES -i %WMOID
-c 11 -p 0 -e %ATTACHMENTS'<br>
<br>
# Extra ISC parms (weather elements). These are a list of the
baseline<br>
# weather elements to be added as extra parms to the ISC
database. This<br>
# is necessary when receiving ISC grids from a site that is a different<br>
# office type than your own. You never need to add weather
elements<br>
# to the ISC database that is your own office type. The format of
this<br>
# entry is a list of tuples. The tuple is a list of weather
elements<br>
# objects (such as Temp and not "T"), and an office type, such as "rfc".<br>
EXTRA_ISC_PARMS = [([QPF, Temp], 'rfc'), ([QPF], 'wfo')]<br>
<br>
<br style="font-family: monospace;">
</span><br>
<br>
<p></p>
<hr width="100%">
<h3><a name="MiscellaneousConfigurationItems"></a>Miscellaneous
Configuration
Items</h3>
This section controls the following items:
<ul>
<li>number of days to retain GFESuite log files</li>
<li>auto configuration for NotifyTextProd (used with the VTECDecoder)<br>
</li>
</ul>
<p><br>
<tt># defines the number of days to keep log files</tt>
<br>
<tt>LOG_FILE_PURGE_AFTER = 6</tt>
</p>
<p></p>
<p><tt># defines a list of weather elements that will NEVER be
processed
for</tt>
<br>
</p>
<p><tt># auto configure NotifyTextProd -- set after OB6<br>
AUTO_CONFIGURE_NOTIFYTEXTPROD = 0 #0=off,1=on<br>
<br>
<br>
</tt></p>
<hr width="100%">
<h3><a name="WeatherElementGroupings"></a>Weather Element Groupings
(a.k.a.
Parm Groups)</h3>
The weather element groupings combine <a
href="#WeatherElementConfigurationSection">weather
elements</a> with <a href="#TimeConstraintConfiguration">time
constraints</a>,
and then bundle them together into groups. At this point, there is no
tie-in
with the databases.
<p>The format of these entries is:
<br>
<tt>groupName = [([we1,we2,we3], timeconstraint1), ([we4, we5],
timeconstraint2)]</tt>
</p>
<p>Example weather element groupings are:
</p>
<p><tt># Parm groups. Combine parms with time constraints</tt>
<br>
<tt># list of ([parms], timeConstraints)</tt>
<br>
<br>
</p>
<p><tt># 6 hourly</tt><br>
<tt>STD6_MODEL = [([Temp, Td, Wind, Weather, Sky, FzLevel], Std6H),</tt>
<br>
<tt>
([SnowAmt, QPF, PoP], Std6), ([MaxT], MaxTTC), ([MinT], MinTTC)]</tt>
</p>
<p><tt># Fcst and official database parameter groupings</tt>
<br>
<tt>OFFICIALDBS = [([Temp, Td, Wind, Weather, Sky, FzLevel], TC1),</tt>
<br>
<tt> ([HeatIndex,
WindChill, RH], TC1),</tt>
<br>
<tt> ([SnowAmt,
PoP], LT6NG), ([QPF], TC6NG),</tt>
<br>
<tt> ([MinT],
MinTTC), ([MaxT], MaxTTC),</tt>
<br>
<tt>
([WaveHeight,
WindGust, Swell], TC1),</tt>
<br>
<tt> ([LAL, CWR,
Haines, MixHgt, FreeWind, TransWind], TC1)]</tt>
</p>
<hr width="100%">
<h3><a name="DatabaseGroupings"></a>Database Groupings</h3>
The database groupings section lists all of the databases for a site
based
on the <a href="#DatabaseModelConfiguration">database definition</a>
and the <a href="#WeatherElementGroupings">weather element groupings</a>.
This section associates the weather element groupings with each
database.
<p><tt>DATABASES = [(Official, OFFICIALDBS + localParms),<br>
(Fcst, OFFICIALDBS + localParms),<br>
(Restore, RESTOREDBS + localParms),<br>
(NAM80, STD6_MODEL + localNAM80Parms),<br>
(RUC80, STD1_MODEL + localRUC80Parms),<br>
(NGM80, STD6_MODEL + localNGM80Parms),<br>
(GFS40, STD6_MODEL + localGFS40Parms),<br>
(GFS190, STD6_MODEL + localGFS190Parms),<br>
(NAM40, STD3_MODEL + localNAM40Parms),<br>
(NAM12, STD3_MODEL + localNAM12Parms),<br>
(gfsLR, STD12_MODEL + localgfsLRParms),<br>
(GWW, WAVEPARMS + localGWWParms),<br>
(WNAWAVE, WAVEPARMS + localWNAWAVEParms),<br>
(AKWAVE, WAVEPARMS + localAKWAVEParms),<br>
(AVNMOS, MOS_MODEL + localMOSParms),<br>
(NAMMOS, MOS_MODEL + localMOSParms),<br>
(MRFMOS, MOS_MODEL + localMOSParms),<br>
(NGMMOS, MOS_MODEL + localMOSParms),<br>
(HPCStn, MOS_MODEL + localMOSParms),<br>
(HPCGrid, MOS_MODEL + localMOSParms),<br>
(HPCQPF, HPCQPF_MODEL + localHPCQPFParms),<br>
(HPCDelta, HPCDELTA_MODEL + localHPCDeltaParms),<br>
(TPCTCM, TPCTCM_MODEL + localTCMParms),<br>
(ISC, ISCPARMS + localISCParms),<br>
(LAPS, LAPSPARMS + localLAPSParms),<br>
(SAT, SATPARMS + localSATParms),<br>
(MSAS, MSASPARMS + localMSASParms),<br>
(GLERL, GLERLPARMS + localGLERLParms),<br>
(Test, OFFICIALDBS + localParms)] + localDBs</tt><br>
</p>
<hr width="100%">
<h3><a name="GeneralServerConfiguration"></a>General Server
Configuration</h3>
This section should not be changed. It imports the parser code into
this
configuration file.
<p><tt>#---------------------------------------------------------------------------</tt>
<br>
<tt>#</tt>
<br>
<tt># General server configuration section</tt>
<br>
<tt>#</tt>
<br>
<tt>#---------------------------------------------------------------------------</tt>
<br>
<tt>from com.raytheon.edex.plugin.gfe.config import IFPServerConfig, SimpleServerConfig<br>
IFPConfigServer = SimpleServerConfig()<br>
IFPConfigServer.allowTopoBelowZero = 1</tt>
<br>
</p>
<h4><a name="ServerSettings"></a>Server Settings</h4>
The Server Settings section consolidates the entries in the
serverConfig.py
and makes them available to the Java portion of GFE.
Nothing should ever be changed in this section:
<p><tt>#----------------------------------------------------------------------------</tt>
<br>
<tt># Server settings DO NOT CHANGE THESE
DEFINITIONS</tt>
<br>
<tt>#----------------------------------------------------------------------------</tt>
<br>
</p>
<hr width="100%"><br>
<div class="Body"> <a href="#Overview">Back To Top</a>
<br>
<a href="GFESuite.html#TableOfContents">Back To TOC</a></div>
</div>
</body>
</html>