serverConfig.py

May 23, 2005

The serverConfig.py file is one of several configuration files for the ifpServer (common database server). 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 localConfig.py and localWxConfig.py file that sites use to override settings in this file. The VTECPartners.py file defines VTEC-specific configuration items.

There are additional files that are built-in to the GFE that define VTEC entries for the Hazards weather element. These are not configurable.

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 server configuration overview for information on how to make changes that are supported to the server.

The excerpts from the serverConfig.py may not be complete or up-to-date; they serve as examples only.

Organization

General Environment and Common Functions

Weather Element Configuration

Weather Configuration

Projection Configuration Section

Grid Domain Configuration

Time Constraint Configuration

Database Attribute Configuration
D2D Model File Directories
D2D Satellite File Directories
D2D Model Database Version Specification
Initialization Modules
D2D Accumulative Elements
Miscellaneous Configuration Items

Weather Element Groupings

Database Groupings

General Server Configuration

General Environment and Common Functions

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.

def siteImport(modName): try: fp, path, des = imp.find_module(modName) if fp: fp.close() except ImportError: return 0 globals()[modName] = __import__(modName) return 1

#----------------------------------------------------------------------------
# USEFUL DEFINES
#----------------------------------------------------------------------------
import siteConfig, LogStream, config

GFESUITE_SITEID = siteConfig.GFESUITE_SITEID
GFESUITE_HOME = siteConfig.GFESUITE_HOME
GFESUITE_PORT = int(siteConfig.GFESUITE_PORT)
GFESUITE_DATDIR = siteConfig.GFESUITE_DATDIR
GFESUITE_LOGDIR = siteConfig.GFESUITE_LOGDIR
GFESUITE_PRDDIR = siteConfig.GFESUITE_PRDDIR
GFESUITE_SHPDIR = siteConfig.GFESUITE_SHPDIR
GFESUITE_TOPODIR = siteConfig.GFESUITE_TOPODIR

Weather Element Configuration Section

The weather element configuration section defines the attributes for each weather element. A weather element has the following attributes:

Attribute	Scalar	Vector	Weather	Discrete	Description
weather element name	yes	yes	yes	yes	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.
type	yes	yes	yes	yes	defines the weather element type, must be SCALAR, VECTOR, WEATHER, or DISCRETE
units	yes	yes	yes	yes	defines the units used for this weather element
descriptive name	yes	yes	yes	yes	descriptive name for the weather element
maximum possible value	yes	yes	no	no	The maximum allowable value for scalar, and the maximum allowable value for the magnitude component of vector.
minimum possible value	yes	yes	no	no	The minimum allowable value for scalar, and the minimum allowable value for the magnitude component of vector.
precision	yes	yes	no	no	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.
rate-dependent weather element	yes	yes	no	no	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.
overlapping discrete element	no	no	no	yes	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.
key definition	no	no	no	yes	Defines the allowable keys and their definitions for the discrete weather element
sizeOfAuxDataField	no	no	no	yes (optional)	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.

Weather Element Type	Format of Definition
SCALAR	`VariableName = ("name", type, "units", "descriptive name", maxValue, minValue, precision, rateWE)`
VECTOR	`VariableName = ("name", type, "units", "descriptive name", maxValue, minValue, precision, rateWE)`
WEATHER	`VariableName = ("name", type, "units", "descriptive name")`
DISCRETE	`VariableName = ("name", type, "units", "descriptive name", overlapAllowed, keyDefinition)VariableName = ("name", type, "units", "descriptive name", overlapAllowed, keyDefinition, sizeOfAuxDataField)`

Note that the maximum value and minimum value must be floats, and the precision an integer.

For discrete, the key definition is in this form:
keyDefName = [('keyName1', 'keyDescription1'), ('keyName2', 'key2Description'), .... ]

For overlapping discrete, the first key must be "<None>".

Example entries for SCALAR, VECTOR, WEATHER, and DISCRETE elements are shown below:

#---------------------------------------------------------------------------
#
# Weather Element configuration section.
#
#---------------------------------------------------------------------------

SCALAR = 'Scalar'
VECTOR = 'Vector'
WEATHER = 'Weather'
DISCRETE = 'Discrete'
NO = 0
YES = 1

# Standard Public Weather Elements
Temp = ("T", SCALAR, "fahrenheit", "Surface Temperature",
120.0, -60.0, 0, NO)

Wind = ("Wind", VECTOR, "knots", "Surface Wind",
80.0, 0.0, 0, NO)

Weather = ("Wx", WEATHER, "coverage, intensity, type", "Weather")

TestKeys = [("L", "Low"),("M", "Medium"), ("H", "High")]
TestKey = ("TestKey", DISCRETE, "categories", "TestKey", NO, TestKeys)

ExtraWEPrecision

Weather Elements are stored in their specified precision in the ifpServer, 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 faciliate 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:

# Scalar/Vector Weather Elements that Require Extra Precision (due to their
# use in calculations)
#ExtraWEPrecision = ['T', 'Td', 'RH']
#ExtraWEPrecision = [('T', 1), 'Td', ('RH', 2)]
ExtraWEPrecision = []

Weather Configuration Section

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:

weather type
coverage/probability
intensity
visibility
optional attributes

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.

Possible Visibilities

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.

# list of possible visibilities
visibilities = ['<NoVis>', '0SM', '1/4SM', '1/2SM', '3/4SM', '1SM', '11/2SM',
'2SM', '21/2SM', '3SM', '4SM', '5SM', '6SM', 'P6SM']

Possible Coverages and Probabilities

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.

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.

# list of possible coverages and probabilities
NOCOV = ('<NoCov>', 'No Coverage')
ISOD = ('Iso', 'Isolated')
SCT = ('Sct', 'Scattered')
NUM = ('Num', 'Numerous')
WIDE = ('Wide', 'Widespread')
OCNL = ('Ocnl', 'Occasional')
SCHC = ('SChc', 'Slight Chance Of')
CHC = ('Chc', 'Chance Of')
LKLY = ('Lkly', 'Likely')
DEFN = ('Def', 'Definite')
PATCHY = ('Patchy', 'Patchy')

Possible Intensities

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.

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.

# list of possible intensities
INTEN_NONE = ('<NoInten>', 'No intensity')
INTEN_VERYLIGHT = ('--', 'Very Light')
INTEN_LIGHT = ('-', 'Light')
INTEN_MOD = ('m', 'Moderate')
INTEN_HEAVY = ('+', 'Heavy')

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.

# special intensity groupings
PCPINTEN =[INTEN_VERYLIGHT, INTEN_LIGHT, INTEN_MOD, INTEN_HEAVY]

Optional Attributes

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.

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.

# list of optional attributes
FQTLTG = ('FL', 'Frequent Lightning')
GUSTS = ('GW', 'Gusty Winds')
HVYRAFL = ('HvyRn', 'Heavy Rainfall')
DMGWND = ('DmgW', 'Damaging Winds')
SMALLH = ('SmA', 'Small Hail')
LARGEH = ('LgA', 'Large Hail')
OUTLYNG = ('OLA','in the outlying areas')

Weather Type Definitions

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:

TypeSymbol = ('Symbol', 'Description', [coverages], [intensities], [optional attributes])

NOWX = ('<NoWx>', 'No Weather', [NOCOV], [INTEN_NONE], []) THUNDER = ('T', 'Thunderstorms', [ISOD, SCT, NUM, WIDE, SCHC, CHC, LKLY, DEFN, OCNL, FQT, BRIEF, PERIODS, INTM], [INTEN_NONE, INTEN_SEVERE], [PRIMARY, MENTION, FQTLTG, HVYRAFL, GUSTS, DMGWND, DRY]) HAIL = ('A', 'Hail', [ISOD, SCT, NUM, WIDE, SCHC, CHC, LKLY, DEFN, OCNL, FQT, BRIEF, PERIODS, INTM], [INTEN_NONE], [PRIMARY, MENTION, LARGEH, SMALLH]) RAIN = ('R', 'Rain', [WIDE, SCHC, CHC, LKLY, DEFN, OCNL, FQT, BRIEF, PERIODS, INTM], [INTEN_VERYLIGHT, INTEN_LIGHT, INTEN_MOD, INTEN_HEAVY], [PRIMARY, MENTION, OR]) RAINSHOWERS = ('RW', 'Rain Showers', [ISOD, SCT, NUM, WIDE, SCHC, CHC, LKLY, DEFN, OCNL, FQT, BRIEF, PERIODS, INTM], [INTEN_VERYLIGHT, INTEN_LIGHT, INTEN_MOD, INTEN_HEAVY], [PRIMARY, MENTION, OR])

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.

types = [NOWX, THUNDER, WATERSPOUT, HAIL, RAIN, RAINSHOWERS,
         DRIZZLE, FZRAIN, FZDRIZZLE, SNOW, SNOWSHOWERS,
         SLEET, FOG, FREEZEFOG, ICEFOG, ICECRYSTAL ,HAZE, BLWGSNOW,
         BLWGSAND, SMOKE, BLWGDUST, SA, CAL, FROST, FQTGSTS, FRZSPRAY,
         VOLASH]

Projection Configuration Section

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:

Grid201	Grid202	Grid203	Grid204
Grid205	Grid206	Grid207	Grid208
Grid209	Grid210	Grid211	Grid212
Grid213	Grid214	Grid215	Grid216
Grid217	Grid218	Grid219	Grid221
Grid222	Grid225	Grid226	Grid227
Grid228	Grid229	Grid230	Grid231
Grid232	Grid233	Grid234	Grid235
HRAP	Grid214AK

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.

Eventually this section will be removed from the configuration file. A projection will be displayed only when a new, non-standard projection is needed.

The information that is required to define a projection is shown below, not all of the entries are needed for each projection type:

projection identifier
projection type (LAMBERT_CONFORMAL, MERCATOR, POLAR_STEREOGRAPHIC, LATLON
lower left point latitude/longitude
upper right point latitude/longitude
latitude longitude origin
standard parallel one
standard parallel two
grid point number for lower left point
grid point number for upper right point
latitude intersect
longitude center
longitude origin

At the end of the projection information is a list containing all of the projections.

#---------------------------------------------------------------------------
#
# Projection Configuration section.
#
#---------------------------------------------------------------------------
NONE = 0
LAMBERT_CONFORMAL = 1
MERCATOR = 2
POLAR_STEREOGRAPHIC = 3
LATLON = 4

# projectionID / projectionType / latLonLL / latLonUR /
# latLonOrigin / stdParallelOne / stdParallelTwo / gridPointLL / gridPointUR
# latIntersect / lonCenter / lonOrigin

Grid201 = ('Grid201',POLAR_STEREOGRAPHIC,
(-150.00, -20.826), (-20.90846, 30.0),
(0.0, 0.0), 0.0, 0.0, (1, 1), (65, 65), 0.0, 0.0, -105.0)

Grid202 = ('Grid202', POLAR_STEREOGRAPHIC,
(-141.028, 7.838), (-18.576, 35.617),
(0.0, 0.0), 0.0, 0.0, (1, 1), (65, 43), 0.0, 0.0, -105.0)

# list of all projections
allProjections = [Grid201, Grid202, Grid203, Grid204, Grid205, Grid206,
Grid207, Grid208, Grid209, Grid210, Grid211, Grid212, Grid213, Grid214,
Grid214AK, Grid215, Grid216, Grid217, Grid218, Grid219, Grid221, Grid222,
Grid225, Grid226, Grid227, Grid228, Grid229, Grid230, Grid231, Grid232,
Grid233, Grid234, Grid235, HRAP]

Grid Domain Configuration

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:

grid size
grid location (origin and domain) in world coordinates
site time zone
projection identifier

The format of the entries are:

'siteid' : ((xdim,ydim), (xorigin,yorigin), (xextent,yextent), 'timezone', projection)

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.
#---------------------------------------------------------------------------
#
# Grid Domain configuration section
#
#---------------------------------------------------------------------------
#
# xdim/ydim: Defines the dimensions of the grids.
#
# origin: Defines the lower-left corner of the grid (point 0,0) in
# world coordinates.
#
# extent: Defines the "size" of the grid in world coordinates. The upper
# right corner is the origin+extent.
#
# timezone: defines the time zone used for the site.
#
# Projection: Defines the projection identifier to be used for this domain.

# Note that all parameters for an existing database must use the same
# projection, though not necessarily the same grid size and location.

# [xdim, ydim] / (origin) / (extent) / Projection

SITES = {
    'ABQ' : ([145, 145], (36.00, 22.00), (9.0, 9.0), 'MST7MDT', Grid211),
    'ABR' : ([145, 145], (45.00, 35.00), (9.0, 9.0), 'CST6CDT', Grid211),
    'AFC' : ([1034/2, 423/2], (1.0, 19.0), (67.0, 28.0), 'America/Anchorage', Grid214AK),
    'AFG' : ([313, 201], (27.0, 39.0), (39.0, 25.0), 'America/Anchorage', Grid214AK),
    'AJK' : ([337, 241], (62.0, 23.0), (21.0, 15.0), 'America/Anchorage', Grid214AK),
    'AKQ' : ([145, 145], (68.00, 25.00), (9.0, 9.0), 'EST5EDT', Grid211),
    'ALY' : ([145, 145], (70.00, 33.00), (9.0, 9.0), 'EST5EDT', Grid211)]

Note that the origin and extents are floating-point numbers and thus must have decimal point in them.

Time Constraint Configuration

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:

timeConstraintName = (start, repeat, duration)

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.

We also have several local time-based time constraints. These are typically prefixed with LT for local time.

#---------------------------------------------------------------------------
#
# Time Constraint configuration section
#
#---------------------------------------------------------------------------
HOUR = 3600
DAY = 24 * HOUR

# Start: is the number of seconds since 0000z for the first grid of the day
# Repeat: is the number of seconds from start until the next grid starts
# Duration: is the length of the grid in number of seconds

# Examples of constraints:
# Hourly temperatures
# HrTemp = (0, HOUR, HOUR)
# QPF that is 6 hours long, aligned on 0000z, exists for every 6 hours
# Q = (0, HOUR*6, HOUR*6)
#

# start / repeat / duration
# fixed time constraints: start / repeat / duration
TC1      = (0, HOUR, HOUR)
TC3      = (0, 3 * HOUR, HOUR)
TC6      = (0, 6 * HOUR, HOUR)
TC12     = (0, 12 * HOUR, HOUR)
TC3NG    = (0, 3 * HOUR, 3 * HOUR)
TC6NG    = (0, 6 * HOUR, 6 * HOUR)
TC12NG   = (0, 12 * HOUR, 12 * HOUR)
TC061212 = (6 * HOUR, 12 * HOUR, 12 * HOUR)
Persistent = (0, 0, 0)     # special used only for GeoWeight grids

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.

def localTC(start,repeat,duration,dst):
    timezone = SITES[GFESUITE_SITEID][3]
    import os
    os.environ['TZ'] = timezone
    import time
    start = time.timezone + start
    if dst == 1:
    start = start - 3600
    if start >= 3600 * 24:
        start = start - 3600 * 24
    elif start < 0:
        start = start + 3600 * 24
    return (start, repeat, duration)

MaxTTC     = localTC(7*HOUR, 24*HOUR, 12*HOUR, 0)
MinTTC     = localTC(19*HOUR, 24*HOUR, 13*HOUR, 0)
MaxRHTC     = localTC(15*HOUR, 24*HOUR, 18*HOUR, 0)
MinRHTC     = localTC(3*HOUR, 24*HOUR, 18*HOUR, 0)
LT3NG     = localTC(0*HOUR, 3*HOUR, 3*HOUR, 0)
LT6NG     = localTC(0*HOUR, 6*HOUR, 6*HOUR, 0)
LT12NG    = localTC(6*HOUR, 12*HOUR, 12*HOUR, 0)
LTMOS     = localTC(6*HOUR, 12*HOUR, 12*HOUR, 0) #special MOS local time
MaxTTCMOS = localTC(6*HOUR, 24*HOUR, 12*HOUR, 0) #special MOS maxT
MinTTCMOS = localTC(18*HOUR, 24*HOUR, 12*HOUR, 0) #special MOS minT
LT24      = localTC(0*HOUR, 24*HOUR, 24*HOUR, 0)
FireWx1300TC = localTC(13*HOUR, 24*HOUR, 1*HOUR, 0)   #special FireWx 1pm snap

Database Attribute Configuration

The database or model attribute configuration section defines characteristics of the database. The characterstics defined are:

model name
model format - this is always GRID. GFESuite only uses the GRID format.
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.
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.
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.
number of versions - number of versions of this database. Should be 1 for singleton databases.
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.

#---------------------------------------------------------------------------
#
# Database/(Model) attribute section
#
#---------------------------------------------------------------------------
#
# name: The model name of the database
#
# format: Always 'GRID'
#
# type: Optional type of the database
#
# single: YES or NO. YES if this database always exists and is not
#   based on model-times. NO if this database is created/destroyed and
#   is based on model-runs. When created, the names of these databases have
#   time stamps.
#
# official: YES or NO. YES if this is an official database from which
#   products can be generated. NO if this is a conventional database.
#
# numVer: Number of versions of this database to retain.
#
# purgeAge: Number of hours in the past before grids will be automatically
#   purged from the database. If 0, then purging is disabled.
#

YES = 1 NO = 0 GRID = 'GRID' # name / format / type / single / official / numVer / purgeAge Fcst = ('Fcst', GRID, '', YES, NO, 1, 24) Restore = ('Restore', GRID, '', YES, NO, 1, 24) Test = ('Test', GRID, 'test', NO, NO, 1, 0) Official = ('Official', GRID, '', YES, YES, 1, 24) ISC = ('ISC', GRID, '', YES, NO, 1, 12) LAPS = ('LAPS', GRID, '', YES, NO, 1, 30) SAT = ('SAT', GRID, '', YES, NO, 1, 12) NAM12 = ('NAM12', GRID, '', NO, NO, 2, 0) NAM40 = ('NAM40', GRID, '', NO, NO, 2, 0) NAM80 = ('NAM80', GRID, '', NO, NO, 2, 0) NGM80 = ('NGM80', GRID, '', NO, NO, 2, 0) GFS40 = ('GFS40', GRID, '', NO, NO, 2, 0) GFS190 = ('GFS190', GRID, '', NO, NO, 2, 0) gfsLR = ('gfsLR', GRID, '', NO, NO, 2, 0) RUC80 = ('RUC80', GRID, '', NO, NO, 2, 0) AVNMOS = ('AVNMOS', GRID, '', NO, NO, 3, 0) NAMMOS = ('NAMMOS', GRID, '', NO, NO, 3, 0) MRFMOS = ('MRFMOS', GRID, '', NO, NO, 3, 0) NGMMOS = ('NGMMOS', GRID, '', NO, NO, 3, 0) HPCStn = ('HPCSTN', GRID, '', NO, NO, 2, 0) HPCGrid = ('HPCGRID', GRID, '', NO, NO, 2, 0) GWW = ('GWW', GRID, '', NO, NO, 2, 0) HPCQPF = ('QPF', GRID, '', NO, NO, 4, 0) HPCDelta = ('HPCdelta', GRID, '', NO, NO, 2, 0) TPCTCM = ('TPCtcm', GRID, '', NO, NO, 2, 0) MSAS = ('MSAS', GRID, '', YES, NO, 1, 36) GLERL = ('GLERL', GRID, '', NO, NO, 2, 0) AKWAVE = ('AKWAVE', GRID, '', NO, NO, 2, 0) WNAWAVE = ('WNAWAVE', GRID, '', NO, NO, 2, 0)

D2D Model File Directories

The ifpServer automatically scans the D2D model file directories and provides this data as additional grids for display, or for use in smart tools. The user can set the search path to include certain models. The search paths specified define the top of the tree -- all subdirectories are included. For example, simply specifying /data/fxa/Grid/SBN will get all files, but many of the directories will be bogus since the files will not necessarily be in a compatible netCDF format.


    D2DDIRS = [('/data/fxa/Grid/SBN/netCDF/CONUS212/GFS', 'GFS40'),
               ('/data/fxa/Grid/SBN/netCDF/CONUS211/NAM', 'NAM80'),
               ('/data/fxa/Grid/SBN/netCDF/CONUS211/NGM', 'NGM80'),
               ('/data/fxa/Grid/SBN/netCDF/CONUS202/MRF', 'gfsLR'),
               ('/data/fxa/Grid/SBN/netCDF/CONUS211/RUC', 'RUC80'),
               ('/data/fxa/Grid/SBN/netCDF/CONUS212/MesoEta', 'NAM40'),
               ('/data/fxa/Grid/SBN/netCDF/CONUS215/MesoEta', 'NAM20'),
               '/data/fxa/Grid/FSL/netCDF/MSAS',
               ('/data/fxa/Grid/FSL/netCDF/LAPS_Grid/LAPS', 'LAPS'),
               '/data/fxa/Grid/SBN/netCDF/REG233/GWW',
               '/data/fxa/Grid/SBN/netCDF/GRID218/HPCQPF',
               '/data/fxa/Grid/SBN/netCDF/CONUS215/HPCdelta',
               '/data/fxa/Grid/SBN/netCDF/LATLON/GLERL',
               '/data/fxa/Grid/SBN/netCDF/GRID238/GWW',
               '/data/fxa/Grid/SBN/netCDF/CONUS226/TPCtcm',
               ('/data/fxa/Grid/SBN/netCDF/GRID218/Eta', 'NAM12')]

The actual syntax in the serverConfig.py file looks more complicated since it defines the D2DDirs based on the site identifier. OCONUS sites use a different set of directories.

Note that the above example has a mixture of tuples and strings. There is an alternative form of the D2DDIRS that is used when the netCDF 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 D2DDIRS can either be a string, such as above, which indicates the directory path, or it can be a tuple of ('directory path', 'modelName'). If the second form is used, then the model variable in the netCDF file is ignored and the given modelName is used instead.

D2D Satellite File Directories

The ifpServer recognizes the D2D satellite data as a valid data set. The ifpServer 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.

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.

SATDIRS = [("/data/fxa/sat/SBN/netCDF/westCONUS/conus_vis", "visibleWest"),
           ("/data/fxa/sat/SBN/netCDF/westCONUS/conus_i11", "ir11West"),
           ("/data/fxa/sat/SBN/netCDF/westCONUS/conus_i12", "ir13West"),
           ("/data/fxa/sat/SBN/netCDF/westCONUS/conus_i39", "ir39West"),
           ("/data/fxa/sat/SBN/netCDF/westCONUS/conus_iwv", "waterVaporWest"),
           ("/data/fxa/sat/SBN/netCDF/conusC/conus_vis", "visibleCentral"),
           ("/data/fxa/sat/SBN/netCDF/conusC/conus_i11", "ir11Central"),
           ("/data/fxa/sat/SBN/netCDF/conusC/conus_i12", "ir13Central"),
           ("/data/fxa/sat/SBN/netCDF/conusC/conus_i39", "ir39Central"),
           ("/data/fxa/sat/SBN/netCDF/conusC/conus_iwv", "waterVaporCentral"),
           ("/data/fxa/sat/SBN/netCDF/eastCONUS/conus_vis", "visibleEast"),
           ("/data/fxa/sat/SBN/netCDF/eastCONUS/conus_i11", "ir11East"),
           ("/data/fxa/sat/SBN/netCDF/eastCONUS/conus_i12", "ir13East"),
           ("/data/fxa/sat/SBN/netCDF/eastCONUS/conus_i39", "ir39East"),
           ("/data/fxa/sat/SBN/netCDF/eastCONUS/conus_iwv", "waterVaporEast")]

D2D Model Database Version Specification

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 the ifpServer.

The format of the entry is:
#D2DDBVERSIONS = {
# "modelname": numVersions
# }

For example, the following sets the number of LAPS databases to 5, and the number of NAM to 3:

D2DDBVERSIONS = {
      "NAM80": 3,
      "LAPS":5
      }

Initialization Modules

The smart initialization technique of GFESuite is initiated from the ifpServer. The serverConfig.py file provides a mapping of D2D directories to initialization run modules. For example, here is the section in serverConfig.py:

INITMODULES = { "NAM40" : ["NAM40", "NAM20"], "NAM80" : ["NAM80"], "RUC80" : ["RUC80"], "gfsLR" : ["gfsLR"], "NGM80" : ["NGM80"], "NAM12" : ["NAM12"], "GFS40" : ["GFS40"], "GFS190" : ["GFS190"], "LAPS" : ["LAPS"], "HPCQPF" : ['HPCQPF'], "MSAS" : ['MSAS'], "HPCdelta" : ['HPCdelta'], "SAT" : ['Satellite'] }

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:

"NAM40" : ["NAM40", "NAM20"]

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 netCDF files and resolution. The syntax for the "NAM12" model is more straightforward:

"NAM12" : ["NAM12"]

which indicates that the NAM12 initialization module (named NAM12.py and found in the release/etc/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.

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:

INITSKIPS = {
"RUC80" : [1,2,4,5,7,8,10,11,13,14,16,17,19,20,22,23],
}

This is standard Python syntax for a dictionary. This line:

"RUC80" : [1,2,4,5,7,8,10,11,13,14,16,17,19,20,22,23],

indicates that all runs of the RUC80 will be ignored, except every 3 hours.

The default for serverConfig is to run all of the available model runs, except for RUC80, which is run only every 3 hours.

D2D Accumulative Weather Elements

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.

# This is a listing of D2D model name, and weather elements. The
# weather elements defined in this list are treated as accumulative
# elements, thus the snapshot time of the grid is converted to be a
# grid with timestep duration, starting the previous model timestep and
# going up to but not including the snapshot time.

D2DAccumulativeElements= { "GFS40": ["tp", "cp"], "GFS190": ["tp", "cp"], "NAM80": ["tp", "cp"], "NAM40": ["tp", "cp"], "NAM20": ["tp", "cp"], "NAM12": ["tp", "cp"], "NGM80": ["tp", "cp"], "gfsLR": ["tp", "cp"], "RUC80": ["tp", "cp"], "MSAS": ["tp", "cp"], "LAPS": ["pc"], "HPCQPF": ["tpHPC"], "HPCdelta": ["pop", "tcc"], }

Miscellaneous Configuration Items

This section controls the following items:

number of days to retain GFESuite log files
maximum number of simultaneous smart initialization processes
maximum number of simultaneous background processes (user-initiated from GFE)
number of hours to retain GFESuite generated product files; these are files found in the products/... directories
Daily Forecast Critique update interval
maximum number of ISC grids to send in a single transmissions
listing of weather elements to not be processed during incoming ISC (Intersite Coordination).
auto configuration for NotifyTextProd (used with the VTECDecoder)

# defines the number of days to keep log files
LOG_FILE_PURGE_AFTER = 6

# defines the maximum number of simultaneous smart init processes
MAX_INIT_PROCESSES = 1

# defines the maximum number of simultaneous user background task processes MAX_USER_BACKGROUND_PROCESSES = 1 # defines the number of hours to keep product files
PROD_FILE_PURGE_AFTER = 6

# defines the update frequency in minutes of Daily Forecast Critique
# set to 0 to disable DFC
DFC_UPDATE_INTERVAL = 10

# defines the maximum number of grids to send in a single AWIPS WAN
# transaction
MAX_ISC_GRIDS_PER_TRANSACTION = 400

# defines a list of weather elements that will NEVER be processed for
# incoming ISC traffic.
ISC_RECEIVE_NEVER_PROCESS_PARMS = []

# auto configure NotifyTextProd -- set after OB6 AUTO_CONFIGURE_NOTIFYTEXTPROD = 0 #0=off,1=on

Weather Element Groupings (a.k.a. Parm Groups)

The weather element groupings combine weather elements with time constraints, and then bundle them together into groups. At this point, there is no tie-in with the databases.

The format of these entries is:
groupName = [([we1,we2,we3], timeconstraint1), ([we4, we5], timeconstraint2)]

Example weather element groupings are:

# Parm groups. Combine parms with time constraints
# list of ([parms], timeConstraints)

# 6 hourly
STD6_MODEL = [([Temp, Td, Wind, Weather, Sky, FzLevel], Std6H),
([SnowAmt, QPF, PoP], Std6), ([MaxT], MaxTTC), ([MinT], MinTTC)]

# Fcst and official database parameter groupings
OFFICIALDBS = [([Temp, Td, Wind, Weather, Sky, FzLevel], TC1),
          ([HeatIndex, WindChill, RH], TC1),
          ([SnowAmt, PoP], LT6NG), ([QPF], TC6NG),
          ([MinT], MinTTC), ([MaxT], MaxTTC),
          ([WaveHeight, WindGust, Swell], TC1),
          ([LAL, CWR, Haines, MixHgt, FreeWind, TransWind], TC1)]

Database Groupings

The database groupings section lists all of the databases for a site based on the database definition and the weather element groupings. This section associates the weather element groupings with each database.

DATABASES = [(Official, OFFICIALDBS + localParms), (Fcst, OFFICIALDBS + localParms), (Restore, RESTOREDBS + localParms), (NAM80, STD6_MODEL + localNAM80Parms), (RUC80, STD1_MODEL + localRUC80Parms), (NGM80, STD6_MODEL + localNGM80Parms), (GFS40, STD6_MODEL + localGFS40Parms), (GFS190, STD6_MODEL + localGFS190Parms), (NAM40, STD3_MODEL + localNAM40Parms), (NAM12, STD3_MODEL + localNAM12Parms), (gfsLR, STD12_MODEL + localgfsLRParms), (GWW, WAVEPARMS + localGWWParms), (WNAWAVE, WAVEPARMS + localWNAWAVEParms), (AKWAVE, WAVEPARMS + localAKWAVEParms), (AVNMOS, MOS_MODEL + localMOSParms), (NAMMOS, MOS_MODEL + localMOSParms), (MRFMOS, MOS_MODEL + localMOSParms), (NGMMOS, MOS_MODEL + localMOSParms), (HPCStn, MOS_MODEL + localMOSParms), (HPCGrid, MOS_MODEL + localMOSParms), (HPCQPF, HPCQPF_MODEL + localHPCQPFParms), (HPCDelta, HPCDELTA_MODEL + localHPCDeltaParms), (TPCTCM, TPCTCM_MODEL + localTCMParms), (ISC, ISCPARMS + localISCParms), (LAPS, LAPSPARMS + localLAPSParms), (SAT, SATPARMS + localSATParms), (MSAS, MSASPARMS + localMSASParms), (GLERL, GLERLPARMS + localGLERLParms), (Test, OFFICIALDBS + localParms)] + localDBs

General Server Configuration

This section should not be changed. It imports the parser code into this configuration file.

#---------------------------------------------------------------------------
#
# General server configuration section
#
#---------------------------------------------------------------------------
import ifpServerConfig

Server Settings

The Server Settings section consolidates the entries in the serverConfig.py and makes them available to the C++ portion of the ifpServer. Nothing should ever be changed in this section:

#----------------------------------------------------------------------------
# Server settings DO NOT CHANGE THESE DEFINITIONS
#----------------------------------------------------------------------------