The localConfig.py file is one of several
configuration
files for GFE. The localConfig
file is optional, and is not provided with the install or
release.
It is added by the field site to override certain features of the GFE
database configuration that are defined in the
serverConfig.py
file.
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 localConfig.py file can be used to override many of the
definitions
in serverConfig.py, but not all of
them.
This document will describe what you can, and what you cannot
override.
If you need to override an element that is not supported by
localConfig.py
or localWxConfig.py, then refer to
the
server
configuration overview for details.
The localConfig.py file is not used to
override
the map background definitions, refer to the methods
of modifying map definitions to do this.
Adding Your Own
localConfig.py
File
If you want to make changes to the server database definitions, then
you will want to add your own localConfig.py file. Refer to the
server
configuration overview file location section for details on
where the localConfig.py file should be located.
The first lines of the localConfig.py must have the
following
format. Failure to do so will not let you refer to any of the
definitions
in serverConfig.py:
from serverConfig import *
import serverConfig
The syntax appearing in localConfig.py varies depending whether you
are adding new definitions, or changing existing definitions.
Typically
when changing existing definitions you will need to prefix the
serverConfig
to the name of the variable. For example,
var = (a,b,c,d) refers to a local copy of this definition
and
doesn't override the definition in serverConfig.py
serverConfig.var = (a,b,c,d) refers to the variable in the
serverConfig and overrides it.
The localConfig.py file can be created in the CAVE Localization perspective by expanding
GFE Server->Server Config Files, right clicking on serverConfig.py and selecting Override...
Example localConfig.py file
Testing Your localConfig.py File
The recommended way to test your localConfig.py file is to start
EDEX while running a tail command on the /awips2/edex/logs/edex-request-date.log.
If no exceptions result from the changes, you should be fine to proceed into GFE
for further testing.
What
can
you control from your custom localConfig.py file?
The following table describes what can be done using a custom
localConfig.py
file. If the override capability is marked as "NO" and you still
need the modification, you will need to review
methods
of modifying database configurations for alternative choices.
| Item |
localConfig.py override |
Link to serverConfig info |
| Add a new weather element |
YES
|
weather
element configuration |
| Remove an
existing weather
element* |
NO
|
weather
element configuration |
| Modify
an existing
weather element's attributes (name, type, units, descriptive name,
maximum possible value, minimum possible value, precision) |
YES
|
weather
element configuration |
| Change the weather
configuration
(coverages, types, intensities, visibilities, optional attributes) |
NO, but you can change this through localWxConfig.py
|
weather
configuration |
| Add a new projection |
YES
|
projection
configuraton |
| Modify an existing
projection |
NO
|
projection
configuraton |
| Remove an existing projection* |
NO
|
projection
configuraton |
| Adding a new site (Grid Domain
Configuration
Section) |
YES
|
grid
domain configuration |
| Change
the
site's domains (grid sizes, grid location and extent, time zone,
projection,
adjusting the site's resolution) |
YES
|
grid
domain configuration |
| Removing a site* |
NO
|
grid
domain configuration |
| Adding a new time
constraint |
YES
|
time
constraint
info |
| Modifying an
existing
time constraint |
YES
|
time
constraint
info |
| Removing an
existing time
constraint* |
NO
|
time
constraint
info |
| Adding a database attribute
configuration |
YES
|
database
attribute
configuration |
| Modifying a database attribute
configuration
(name, singleton flag, official flag, number of versions to keep, purge
age) |
YES
|
database
attribute
configuration |
| Removing a database attribute
configuration* |
NO
|
database
attribute
configuration |
| Modifying
the list of D2D directories to search for model data |
YES
|
D2D model
list |
Modifying the
list of D2D directories to search for satellite data
|
YES
|
SATDIRS list
|
| Modifying the list of
initialization
modules |
YES
|
Initialization
Modules |
| Modifying the number of available D2D
databases |
YES
|
D2D Model Database
Version Specification |
| Adding Parm Groups (mapping
of weather
elements to time constraints) |
YES
|
Parm
Group configuration |
| Modifying Existing
Parm Groups |
YES
|
Parm
Group configuration |
| Removing Existing Parm Groups* |
NO
|
Parm
Group configuration |
| Adding new Databases
(database configuration
and parm group mapping) |
YES
|
database
groupings |
| Modifying existing Databases
(other
than adding weather elements to Fcst/Official) |
NO
|
database
groupings |
| Removing existing Databases |
NO
|
database
groupings |
| Modifying the Number of Days to keep Logs |
YES
|
Misc.
Configurations |
| Defining Extra Precision for
Certain Weather
Elements |
YES
|
weather
element configuration |
| Defining D2D Accumulative Weather Elements |
YES
|
D2D
Accumulative
Elements
|
Intersite
Coordination Grids Configuration
|
YES
|
Intersite
Coordination Configuration Items
|
*There usually is no need to remove definitions from
serverConfig.py.
They generally do not take up an significant space.
Adding a new Weather Element
Defining the New Weather Element
You can define a new weather element to add to the Fcst and Official
database,
or add to a new database, or both. You can also use
localConfig.py
to add a new weather element to the model databases, e.g., NAM.
The format of the entry in localConfig.py is identical to that
described
in the weather
element section of serverConfig.py.
Example localConfig.py file
The following example defines a relative humidity element with the
following
characteristics:
| Element Name |
"RH", which defines "RH" at the SFC, this element name may
also be
written "RH_SFC". |
| Data Type |
SCALAR |
| Units |
% |
| Descriptive Name |
Relative Humidity |
| Maximum Possible Value |
100.0 |
| Minimum Possible Value |
0.0 |
| Precision |
0 |
| Time Constraints |
TC1 (as defined in either serverConfig.py or localConfig.py) |
| Rate-Dependent Parm |
NO |
rh = ("RH", SCALAR, "%", "Relative Humidity",
100.0, 0.0, 0, NO)
Simply defining the new weather element has no affect. You
need
to add it to the Fcst/Official databases or a new database for that
weather
element to truly be created.
The format of the weather element line is different for WEATHER and
DISCRETE-type weather elements. In particular, DISCRETE type
elements
require a overlapping/non-overlapping flag, as well as the discrete key
definitions. WEATHER and DISCRETE-type elements do not allow
specification
of a maximum possible value, minimum possible value, precision, or
rate-dependent
parm. Here is an example entry for a new discrete element called
SevereWx, which has two possible values, YES and NO. It is
non-overlapping,
since you can't have both YES and NO at the same time. We want an
auxiliary data field with a maximum of 2 characters in length:
| Element Name |
"SevereWx" |
| Data Type |
DISCRETE |
| Units |
cat |
| Descriptive Name |
Severe Weather |
| Time Constraints |
TC1 (as defined in either serverConfig.py or localConfig.py) |
| Overlapping |
NO |
| DiscreteKey |
YES, NO
|
AuxDataFieldSize
|
2
|
severewxKeys = [('NO', 'no'), ('YES', 'yes')]
severewx = ("SevereWx", DISCRETE, "cat", "Severe
Weather", NO, severewxKeys, 2)
Adding the New Weather Element to the Fcst and Official Databases
To add the new weather element to just the Fcst and Official databases,
include a line similar to that below after all of the weather element
definitions
(and any
new time constraint
definitions).
The line is in the standard
parm
grouping format, with the exception that the name of the parm group is
"parm".This format consists of a list of new weather elements and
their
time constraint. The time constraint can be an existing one in
the
serverConfig.py, or a
new one
defined
earlier in localConfig.py.
Be sure that
the name to the left of the entry is "parms".
parms = [([rh], TC1)]
If you choose to add multiple parms using the same time constraint,
then the second line needs to be modified to be in this format:
parms = [([parm1, parm2, parm3], tc1)]
If you choose to add multiple parms using different time
constraints,
then the second line needs to be modified to be in this format:
parms = [([parm1], tc1), ([parm2], tc2), ([parm3, parm4], tc3)]
Note: There can only be one "parms =" line in the localConfig.py
file. If you use more than one, then only the last one will be
used.
Adding the New Weather Element to a New Database
If you only want to add a new weather element for a new database, and
not
the Fcst and Official databases, then do not include your weather
element
in the parms statement. However, if you add it to a new database,
then you will usually want to add it to the Fcst and Official databases
so you can edit it. You will include the list of weather elements
when you
define a new database.
Adding The New Weather Element to a New Database and the
Fcst/Official
Databases
If you want to add the new weather element to both new databases, and
the
Fcst/Official databases, then include the weather elements in the parms
line, and include it in the list of weather elements when you
define
a new database.
Adding the New Weather Element to one of the standard model
Databases
You can add new weather elements to one of the standard model
databases.
The syntax is identical to that described above, except that the Python
object name is not "parms", instead it is different depending upon the
model you are modifying. The following table relates the standard
models and the Python object name that is required:
| Standard Model |
Python Object Name |
| Fcst, Official, Restore |
parms |
| NAM80 |
parmsNAM80 |
NAM40
|
parmsNAM40
|
NAM12
|
parmsNAM12
|
| RUC80 |
parmsRUC80 |
GFS80
|
parmsGFS80 |
GFS40
|
parmsGFS40 |
GFS190
|
parmsGFS190
|
GFS75
|
parmsGFS75
|
| LAPS |
parmsLAPS |
| gfsLR |
parmsgfsLR |
| GWW |
parmsGWW |
| MSAS |
parmsMSAS |
| GLERL |
parmsGLERL |
| AKWAVE |
parmsAKWAVE |
| WNAWAVE |
parmsWNAWAVE |
| MOS |
parmsMOS |
RFCQPF
|
parmsRFCQPF
|
| HPCQPF |
parmsHPCQPF |
| HPCGuide |
parmsHPCGuide |
| HPCDelta |
parmsHPCDelta |
| TPCtcm |
parmsTCM |
SAT
|
parmsSAT
|
ISC
|
parmsISC
|
NAM95
|
parmsNAM95
|
MOSGuide
|
parmsMOSGuide
|
OPCTAFBE
|
parmsOPCWavE
|
OPCTAFBSW
|
parmsOPCWavSW
|
OPCTAFBNW
|
parmsOPCWavNW
|
Keep in mind that adding a new element to one of the standard model
databases does not cause that field to be automatically generated by
the
initialization routines. You will have to also write a smart
initialization
algorithm for that database. Refer to the Smart
Initialization Configuration and User's Guide for more details.
Here is an example of adding the relative humidity weather element
with
a three-hour time constraint to the NAM12 database:
rh = ("RH", SCALAR, "%", "Relative Humidity",
100.0, 0.0, 0, NO)
parmsNAM12 = [([rh], TC3)]
Removing an existing
Weather
Element
This is not supported through localConfig.py.
Modify an
existing
Weather Element's Attributes
An existing weather elements attributes can be modified by duplicating
the entry in serverConfig.py, modifying the particular attributes, and
prefixing 'serverConfig.' to the beginning of the definition:
serverConfig.Temp = ("T", SCALAR, "F",
"Surface
Temperature",
120.0,
-30.0, 0, NO)
The entry above changes the definition of temperature to range from
-30 to +120 degrees. The minimum possible value was
changed.
This will affect all databases that use the "Temp" weather element.
You can modify the association between an existing weather element
and
its time constraints (parm groups) through localConfig.py. If you
simply want to change the time constraints associated with an existing
weather element, refer to Modifying
Existing Parm Groups.
Example localConfig.py file
Changing the Weather
Configuration
The changing of the weather configuration is not supported through
localConfig.py
but is supported through
localWxConfig.py.
If you do change the weather configuration, you may find that your
weather
grids are not compatible with weather grids from other sites.
Add a new Projection
Adding a new projection is straight forward once you figure out all of
the constants that are required. Refer to the
projection
configuration information in serverConfig.py for more details.
Here is an example of adding a Local211 projection, which is similar
to the Grid211 except that the 'North is up' has been changed from 95
degrees
west longitude to 116 degrees west longitude:
Local211 = ('Local211', LAMBERT_CONFORMAL,
(-133.459, 12.190), (-49.385,
57.290),
(-116.0, 25.0), 25.0, 25.0, (1,
1), (93, 65), 0.0, 0.0, 0.0)
If you do create your own projection, you should strive to name it
differently
from the standard projections provided with the system. In the
above
example we created a Local211 projection and named it 'Local211' in the
first argument.
Adding a new projection does no good unless you use it in a new or
modified
site definition. Therefore if you add a new projection for your
site,
you also will want to update the site definition (grid size, location,
and projection) information.
For example, changing Boise from Grid211 to the Local211 projection
would require the following lines in localConfig.py.
from serverConfig import *
import serverConfig
Local211 = ('Local211', LAMBERT_CONFORMAL,
(-133.459, 12.190), (-49.385,
57.290),
(-116.0, 25.0), 25.0, 25.0, (1,
1), (93, 65), 0.0, 0.0, 0.0)
SITES['BOI'] = ([45, 45], (25.00, 34.00), (11.0, 11.0), 'MST7MDT',
Local211))
Note that when changing a projection, you will also be changing the
AWIPS world coordinate systems as defined. This can result in a
distorted
map background.
Example localConfig.py file
Modify an existing
Projection
Modifying an existing projection is not
supported.
Attempts to do so will result in EDEX failing to initialize GFE successfully.
Remove a Projection
The removal of a projection is not supported through localConfig.py.
There
is no harm in leaving unused projections in the serverConfig.py file.
Adding a new Site
Adding a new site is not supported through localConfig.py. You
should
use an existing entry and then reset its domain and grid size to that
appropriate
for your new site.
Changing
the
Site's Domains, Resolution, Time Zone, Office Type
A existing site's definition may be changed in the localConfig.py
file.
The format of the entry in localConfig.py is identical to that
described
in the
grid domain
section of serverConfig.py.
The following example modifies a existing site's definition to the
following
characteristics:
| Site Name |
ABQ |
| Grid Size |
x=70, y=70 |
| Grid Origin in AWIPS world coordinates |
x=36.25, y=22.25 |
| Grid Extent in AWIPS world coordinates |
x=8.5 y=8.5 |
| Time Zone |
MST7MDT |
| Projection |
Grid211 |
Office Type
|
wfo
|
SITES['ABQ'] = ([70, 70], (36.25, 22.25), (8.5, 8.5), 'MST7MDT',
Grid211, 'wfo')
If your modified site is using a new or modified projection, then be
sure to define the new or modified projection BEFORE you redefine the
site's
characteristics.
Adjusting the Grid Resolution
The numbers that define the grid resolution are not particularily
obvious.
The grid resolution is determined from the grid location on Earth
(defined
by Grid Origin, Grid Extent, and Projection), and the Grid Size.
The nominal resolution of the common AWIPS projections are shown in the
table below. They are equivilant to a grid box of (1,1) in
size.
The approximate resolution of your domain entry can be figured by:
approx resolution = projectionResolution * (extent / (grid size
- 1))
Solving for your grid size results in the following equation; enter
your desired resolution:
grid size = (projectionResolution * extent / desiredResolution)
+ 1
The resulting grid size defines the number of grid cells in each
direction
for the given resolution. For example, if you were on the Grid211
projection
with an AWIPS world coordinate extent of 9.0, and would like a
resolution
of approximately 2.5 kilometers, the approximate grid size you would
use
would be:
grid size = 80 * 9.0 / 5.0 + 1
grid size = 145
Therefore an example entry would change from this:
SITES['AAA'] = ([145, 145], (23.00, 22.00), (9.0, 9.0),
'MST7MDT',
Grid211, 'wfo')
to this:
SITES['AAA'] = ([289, 289], (23.00, 22.00), (9.0, 9.0),
'MST7MDT',
Grid211, 'wfo')
You can get different resolutions in the x and y direction which is
generally not recommended. To avoid this, make sure that the
ratio
of extent and grid size are identical.
| AWIPS Projection |
Nominal Resolution (km) |
| Grid211 |
80 |
| Grid212 |
40 |
| Grid214 |
47 |
| Grid210 |
80 |
| Grid208 |
80 |
| Grid215 |
20 |
Example localConfig.py file
Removing a Site
Removing a site is not possible through the localConfig.py. Generally
it
is not necessary to remove a site from serverConfig.py since the site
definitions
do not take up significant space.
Adding a new Time Constraint
Adding a new time constraint is straight forward. It has the same
format as described in the
time
constraint section of serverConfig.py. You can make use of
the
localTC() script defined in serverConfig.py if desired.
The following line adds a new time constraint with the name of TC8,
that starts at 0200z, repeats every eight hours, and has a duration of
four hours. The second line adds a new time constraint with the
name
of LT9 that starts at 900am local time, repeats every 24 hours, and has
a duration of 3 hours:
TC8 = (2*HOUR, 8*HOUR, 4*HOUR)
LT9 = localTC(9*HOUR, 24*HOUR, 3*HOUR, 0)
Simply adding a new time constraint by itself provides no benefit,
unless
you also define new parm groupings and a database. Any new time
constraints
to be used with new weather elements need to be defined before the
definition
is used.
Example localConfig.py file
Modifying an
existing Time
Constraint
Modifying an existing time constraint is fairly easy. Simply copy
the definition from serverConfig.py and put it in localConfig.py, then
modify it. This modifies the maximum temperature time constraint
so it starts at 500am local time and runs until 800pm local time
(start=5,
repeat=24, duration=15); the daylight savings flag is set to zero.
serverConfig.MaxTTC = localTC(5*HOUR,
24*HOUR,
15*HOUR, 0)
Modifying the TC6 time constraint to have grids every 6 hours, but
with
grid lengths of 2 hours (2 hour grid, 4 hour gap) is accomplished by:
serverConfig.TC6 = (0, 6 * HOUR,
3*HOUR)
Modifying an existing time constraint can have
far-reaching effects. Every subsequent use of this time
constraint
in serverConfig.py (and localConfig.py) will use this new definition.
This
can affect all of the model time constraints for all of the
models.
Be sure you know what you are doing! It is much better to simply
create
a new tme constraint and use it.
Removing an existing
Time
Constraint
It is not possible to remove an existing time constraint through
localConfig.py.
Having unused definitions of Time Constraints in serverConfig.py does
no
harm.
Adding a new Database
There are several steps to adding a new database:
Defining Database Attributes
The database attributes for the new database are defined in the same
format
as those in the
serverConfig.py.
If you were adding a new database with the following characterstics:
| Model Name |
Climo |
| Format (always GRID) |
GRID |
| Optional Type, simply used to filter viewable databases by
the GFE
through gfe
configuration file |
"" |
| Singleton |
YES |
| Official |
NO |
| Number of Versions |
1 |
| Grid Purge Age |
48 hours |
then you would use the following syntax to define this database
attribute:
Climo = ('Climo', GRID, '',
YES, NO, 1, 48)
However, if you are modifying an already defined database, then be
sure
to prefix your entry with serverConfig. For example, to modify
the
NAM12 database to retain 4 versions, the entry in localConfig.py will
be:
serverConfig.NAM12 = ('NAM12', GRID, '', NO, NO, 4, 0)
Defining New Parm Groupings
Now you need to define the list of weather elements and their time
constraints.
The list of weather elements can include previous definitions from
serverConfig
and your new definitions. The composite list of weather elements and
time
constraints is done in an identical manner to that described in
serverConfig.py.
Of course, you will first need to define any new time constraints that
you plan to use.
In this example, we have assumed to already add the definitions for
the the following weather elements: NormalMax, NormalMin. We plan
to use existing local time definitions for max and min temperature so
we
don't need to redefine or define new ones.
CLIMO_MODEL = [([NormalMax], MaxTTC), ([NormalMin], MinTTC)]
Adding the
Database
to the list of new databases
The final step is to relate the parm groupings to the database
attributes
and then append those to a list of new databases. This is done in
the simliar format to
database
groupings in serverConfig.py. The Python variable that is
expected
is 'localDBs'.
dbs = [(Climo, CLIMO_MODEL)]
If multiple local databases were required, the format of the entry
would
be:
dbs = [(dbattr1, dbParmGroup1), (dbattr2, dbParmGroup2)]
Example localConfig.py file
Modifying a Database
There are only a limited number of items that can be changed on an
existing
database. You can
add new
weather
elements (to Fcst and Official databases, or any of the standard
model
databases),
change
the weather element definitions, change the
database
attribute information, and
change
weather element time constraints using different methods outlined
in
this file. If you really need to make additional
modifications,
then you will need to copy the entire serverConfig.py and make changes
to it as described in the
server
configuration guide.
Removing a Database
The removal of databases are not supported through the
localConfig.py.
If a database really needs to be removed, then you will need to make a
copy of the serverConfig.py and change it, and place it in the correct
directory. See
server
configuration options for details.
Modifying Existing Parm
Groups
Modification of existing parm groups through localConfig.py is used to
change the mapping between weather elements, and their time
constraints.
You can modify existing parm groups for the Fcst and Official
databases,
or any of the standard model databases, through this method.
Modifying an existing parm group is accomplished by linking new or
existing
weather elements to new or existing time constraints. This is
similar
to the technique in Adding A New
Weather
Element.
To modify the existing parm group for the Fcst and Official
databases,
include a line similar to that below after all of the weather element
definitions
(and any new time constraint
definitions).
The line is in the standard parm
grouping format, with the exception that the name of the parm group is
"parm".This format consists of a list of new weather elements and
their
time constraint. The time constraint can be an existing one in
the
serverConfig.py, or a new one
defined
earlier in localConfig.py. Be sure that
the name to the left of the entry is "parms".
parms = [([rh], TC1)]
If you choose to add multiple parms using the same time constraint,
then the line needs to be modified to be in this format:
parms = [([parm1, parm2, parm3], tc1)]
If you choose to add multiple parms using different time
constraints,
then the second line needs to be modified to be in this format:
parms = [([parm1], tc1), ([parm2], tc2), ([parm3, parm4], tc3)]
For example, if you want the T, Td, Wind, Wx, and Sky parameters to
all be 3 hours in length, with no gaps, you would use the existing
TC3NG
time constraint. If you wanted the MaxT and MinT parameters to be
18 hours in length instead of 12, then you would need to create two new
time constraints. The lines that would be placed in localConfig.py
would
be:
MaxTTC18 = localTC(4*HOUR, 24*HOUR, 18*HOUR, 0)
MinTTC18 = localTC(16*HOUR, 24*HOUR, 18*HOUR, 0)
parms = [([T, Td, Wind, Wx, Sky], TC3NG), ([MaxT], MaxTTC18),
([MinT],
MinTTC18)]
Example localConfig file
Note: There can only be one "parms =" line in the localConfig.py
file. If you use more than one, then only the last one will be
used.
Likewise, you can modify existing parm groupings for the models
through
localConfig.py. Instead of the "parms =" statement, you need to
use
the correct statement for the model. Refer to the table under Adding
a New Weather Element for the proper syntax for the parm groupings
for the models.
For example, if you wanted to modify the RUC80 T (temperature) and
Td
(dew point) time constraint to TC1, then you would do the following.
parmsRUC80 = [([T,Td], TC1)]
Removing Parm Groups
The removal of parm groups is not supported through the
localConfig.py.
There is no need to remove parm groups since by themselves, they do not
take up any storage space.
Modifying
the list of D2D Directories for model access
The standard list of D2D directories may not include all of the D2D
models
that you wish to use in the GFE. The entry in
serverConfig.py
can be overriden using the following syntax:
serverConfig.D2DMODELS = [('directory1', 'model')]
This definition will completely override the one in serverConfig.py
so you will probably want to include those original definitions.
Here is an example of adding an SREF model on
projection SREF12:
serverConfig.D2DMODELS = [('SREF212', 'SREF')]
Note that overridding the
complete D2DMODELS is not recommended, since you will
miss baseline updates with each release. Instead, you should use the
append feature to simply add a new entry without
modifying existing entries as:
serverConfig.D2DDIRS.append(('CONUS212', 'NAM20'))
Note that GFE simply cannot see and
intrepret every type of hdf5 file in existance. Even if the hdf5
files are D2D-displayable, there may be some missing information in the
files that make GFE ignore the file. Refer to the EDEX
hdf5 format requirements document for more details.
Example localConfig file
Modifying
the list of D2D Directories for satellite data access
The standard list of D2D directories for satellite access may not
include all of the D2D directories
that you wish to use in the GFE, or may contain weather element names
that are not desirable. The entry in
serverConfig.py
can be overriden using the following syntax:
serverConfig.SATDATA = [('directory1', 'weather element name
1'), ('directory2', 'weather element names 2')]
This definition will completely override the one in serverConfig.py
so you will probably want to include those original definitions.
Here is an example of redefining the complete list of SATDATA; this
technique is not the best, since you will miss updates to serverConfig
and is not recommended:
serverConfig.SATDATA =
[("NESDIS/GOES-13(N)/East CONUS/Imager Visible", "visibleWest"),
("NESDIS/GOES-13(N)/East CONUS/Imager 6.7-6.5 micron IR (WV)", "waterVaporEast")]
You can also use the append feature to simply add a new entry
without
modifying existing entries as:
serverConfig.SATDATA.append(("NESDIS/GOES-13(N)/East CONUS/Imager 3.9 micron IR", "ir39East"))
Note that GFE simply cannot see and
intrepret every type of satellite hdf5 file in existance. Even
if the satellite hdf5
files are D2D-displayable, there may be some missing information in the
files that make GFE ignore the file. Refer to the EDEX
satellite hdf5 format requirements document for more details.
Example localConfig file
D2D Model Database Version Specification
You can override the default number of retained (available) D2D
model versions through localConfig.py. This can also be used to define
the number of D2D Satellite images that can be seen through GFE.
Further information, including restrictions,
is provided in the
serverConfig.py
D2D Model Database Version Specification section. The format to
override all entries (not recommended) is:
serverConfig.D2DDBVERSIONS = {
"modelname" : numberOfVersions,
"modelname2": numberOfVersions2
}
For example, to override the number of available NAM12 versions,
which
is called NAM12 on the D2D, and to set the available versions to 3, the
following
syntax is used:
serverConfig.D2DDBVERSIONS = {
"NAM12" : 3
}
The above will completely overwrite all of the definitions of
D2DDBVERSIONS
in serverConfig.py, which may not be what you have intended. The
preferred way to make a modification is by individual items. For
example, in
order to just affect the NAM12, you could do
this:
serverConfig.D2DDBVERSIONS["NAM12"] = 3
Modifying the list of
Initialization
Modules
The standard list of initialization modules (smart initialization) may
be modified to include, or exclude certain models from producing
IFP-type
databases, or for adding new model databases or modifying algorithms
from
existing databases. You can also choose to skip certain model runs for
each model if desired. Refer to the
Smart
Initialization
documentation for more details on smart initialization. The
entry
in serverConfig.py can be completely overridden using the following
syntax (which is not recommended):
serverConfig.INITMODULES = {
moduleName : ["d2dmodelname",
"d2dmodelname"],
modulename :
["d2dmodelname"]
}
An example is shown in the following example, where the NAM
initialization
(D2D modelname NAM12) is now going to be controlled by module name
MyNAM.
serverConfig.INITMODULES = {
"NAM40" : ["NAM40", "NAM20"],
"RUC80" : ["RUC80"],
"GFS40" : ["GFS40"],
"MyNAM" : ["NAM12"],
"gfsLR" : ["gfsLR"]
}
There are alternate ways of adding an entry, modifying an entry, or
deleting an entry.
The method of completely redefining INITMODULES as shown above is not
recommended.
Adding An Entry
The format is:
serverConfig.INITMODULES["newModuleName" = ["d2dmodel",
"anotherd2dmodel"]
Example of adding a new initialization module for LAPS, which we
assume
that a user has created a LAPS.py and placed it into
/awips2/edex/data/utility/edex_static/site/SITE_ID/smartinit:
serverConfig.INITMODULES["LAPS] = ["LAPS"]
Modifying An Entry
Modifying an entry uses the adding and deleting entry syntax.
First
you add the new initialization module, then you delete the old
one.
In this example we are changing the initialization module from NAM12 to
MyNAM
for the NAM12 model:
serverConfig.INITMODULES["MyNAM"] = ["NAM12"]
del serverConfig.INITMODULES["NAM12"]
Deleting An Entry
The format is:
del serverConfig.INITMODULES[moduleName]
Example of deleting the RUC is:
del serverConfig.INITMODULES["RUC"]
Skipping Model Runs
The user can choose to skip model runs for any of the initialization
modules.
The entry in serverConfig.py can be overriden using the following
syntax:
serverConfig.INITSKIPS = {
modelname : [skiptime1,
skiptime2,
skiptime3],
modelname : [skiptime1,
skiptime2],
}
Note that unlike the INITMODULES, the key in this dictionary is the
modelname, and not the module name. An example is shown in the
following
example, where the RUC80 initialization is skipped except for every 3
hours,
and the NAM40/NAM20 run is skipped for the 00z run:
serverConfig.INITSKIPS = {
"NAM40" : [0],
"NAM20" : [0],
"RUC80" :
[1,2,4,5,7,8,10,11,13,14,16,17,19,20,22,23],
}
There are alternate ways of adding an entry, modifying an entry, or
deleting an entry which are similar to that described above in the
INITMODULES
section which should be used.
Modifying the Number of Days to Keep Logs
You may override the serverConfig.py's definition of the number of days
to keep the GFESuite logs with this syntax:
serverConfig.LOG_FILE_PURGE_AFTER = 6
Defining Extra Precision for Certain
Weather
Elements
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 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. The
effective
precision assigned to these elements is one more than that defined in
the
weather element configuration section in serverConfig, if the string
version
of the definition is used, or the precision increase value, if the
tuple
(wename, extraprecision) form is used.. To declare an additional
weather element to contain extra precision, use this format:
serverConfig.ExtraWEPrecision.append('parmname')
serverConfig.ExtraWEPrecision.append(('parmname', extraPrec))
To redefine the entire list, use this format:
serverConfig.ExtraWEPrecision = ['parmname1', 'parmname2',
'parmname3',
...]
serverConfig.ExtraWEPrecision = [('parmname1', exPrec1),
'parmname2',
('parmname3', exPrec3), ...]
The forms of 'parmname' and ('parmname', extraPrecAmount) may be
contained
in the same statement.
Defining 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
rather
than a snapshot time. Through localConfig.py, you can modify and
entry, add a new entry, or delete an entry. You may also redefine
the entire dictionary. The element names do not include the level
definition.
It is recommended that you follow the technique to add, remove, and
modify entries, rather than redefining the entire dictionary.
To add a new model entry:
serverConfig.D2DAccumulativeElements["modelName"] = ["elem1",
"elem2",
"elem3"]
To remove an existing model entry:
del serverConfig.D2DAccumulativeElements["modelName"]
To modify an existing entry:
serverConfig.D2DAccumulativeElements["modelName"] = ["elem1",
"elem2",
"elem3"]
To redefine the entire dictionary:
serverConfig.D2DAccumulativeElements= {
"GFS40": ["tp", "cp"],
"NAM80": ["tp", "cp"],
"RUC80": ["tp", "cp"],
"NAM40": ["tp", "cp"],
"NAM20": ["tp", "cp"],
"MSAS": ["tp", "cp"],
"LAPS": ["pc"],
"HPCQPF": ["tpHPC"],
"HPCdelta": ["pop"],
"NAM12": ["tp", "cp"],
}
Automatic Configuration of
NotifyTextProd
NotifyTextProd is a AWIPS D2D process that routes certain text
bulletins to the VTECDecoder. The pattern file is automatically created when GFE
is loaded in EDEX and is customized to the configured site. This
reduces the amount of traffic being sent to the VTECDecoder by 90%.
Due to the staging of the GFESuite and AWIPS softwares, a configuration
item is required to tell GFE to begin generating the custom
pattern file. This is done through a simple localConfig.py
addition:
serverConfig.AUTO_CONFIGURE_NOTIFYTEXTPROD
= 1
Intersite
Coordination Grids Configuration
The Intersite Coordination Grids configuration can be overridden in the
localConfig.py file.
ISC Routing Table Address
The base url for the ISC Routing Table web server may be changed from
the default. This is normally only done for isolated
testing. The baseline value of this entry is sufficient.
The value of None indicates no ISC Routing Web Service, which precludes
the transmission and reception of ISC data. To modify the default
value, use this syntax:
serverConfig.ISC_ROUTING_TABLE_ADDRESS
= "http://exampleurl.nws.noaa.gov"
Requested ISC Sites
The default is to have EDEX calculate the list of sites to
request ISC data from based on the generated ISC_xxx edit
areas. This is accomplished by setting the value to None.
If you wish to override this value, then use this syntax:
serverConfig.REQUESTED_ISC_SITES
= ["CLE", "PBZ", "CTP", "BUF"]
Be sure to always include your own site; if you don't you won't see
your own ISC data in the ISC database.
Request ISC
Setting the value to 0 disables the request of ISC data and
EDEX will not register with the ISC Routing Table Web
Server. To enable the reception of ISC data, you use this
syntax in the localConfig.py file:
serverConfig.REQUEST_ISC = 1
Send ISC On Save
Setting the value to 0 disables sending of ISC data when data is saved
to the Fcst database. Setting the value to 1 will send ISC data
when data is stored to the Fcst database.
serverConfig.SEND_ISC_ON_SAVE = 1
Send ISC On Publish
Setting the value to 0 disables sending of ISC data when data is
published
to the Fcst database. Setting the value to 1 will send ISC data
when
data is stored to the publish database.
serverConfig.SEND_ISC_ON_PUBLISH
= 1
Requested ISC Parms
The default is to have EDEX calculate the list of weather
elements to be requested from the list of available weather elements in
the Fcst database. This is denoted by setting the variable to None.
The site can override this and specify a list of weather
elements desired from ISC as a list. If you wish to override
this value, then use this syntax:
serverConfig.REQUESTED_ISC_PARMS
= ["T_SFC", "Td_SFC", "Wx", "Wind"]
You can just specify the weather element name (e.g., T), or the weather
element name and the level (e.g., T_SFC, T_MB700).
Transmit Script
The transmit script is used to move the data from the server machine to
the destination. For AWIPS, this is the msg_send
program. For testing or other purposes, you can override
the entry and specify your own program. The program you
specify should expect the following switches:
- -s - subject line, normally ISCGRIDS
- -a - address list, generates comma separated addressee list, such
as "CLE,PBZ,BUF"
- -i - id string, normally similar to TTAA0 KXXX 021232
- -c - AWIPS MHS code, normally 11
- -p - priority mode, 0 is lowest, 2 is highest
- -e - enclosure list, such as "f1, f2, f3", containing the ISC
data compressed, and the ISC destination routing information
Use this syntax to specify a different program:
serverConfig.TRANSMIT_SCRIPT =
"/awips/bin/msg_send"
Extra ISC Weather Elements
The Extra ISC Weather Elements allows you to configure your ISC
database to store weather elements received from a different office
type, such as receiving rfc grids at a wfo. You never need to add
an entry for your own "office type", just others. Use this syntax
to specify the set of weather elements and office types:
To completely replace the serverConfig definition:
serverConfig.EXTRA_ISC_PARMS =
[([T,Wind], 'rfc')]
To augment the serverConfig definition:
extraISCparms = [([RH, QPF], 'rfc')]