OB9 GFE Changes

Last Updated 3/15/12

National Weather Service

Office of Climate, Water, and Weather Services

Forecast Decision Training Branch

Questions: Shannon.White@noaa.gov

Disclaimer    and   Privacy Notice




Focal Point-Specific Information

Information for Forecasters






Focal Point Information

News You MUST Use
Area-specific Cities List

Tropical Changes (required for tropical sites)
New ISC Send Scheme
Cascading Populate Menu
runProcedure Change
Links to File Diffs


News You MUST Use

A new version of GenericHazards.py has been implemented in OB9 which includes the addition of CTA markers, the baselining of the WSW attribution phrase framing code, area-specific cities list, and a fix to the attribution phrase when multiple instances of the same hazard are forecast (e.g. Freeze warning tonight and tomorrow night). All Hazard_XXX_Local overrides should be closely inspected and likely removed as most are no longer needed and could cause an incorrect hazard product to be generated.
Due to the implementation of CTA markers, if you have any local CTAs for products that do not have an automatic CTA (statement products like CF.S), you need to modify those CTAs to include the marker. For instance, if you have a CTA for rip currents that forecasters add to the CFW, it would need the "PRECAUTIONARY/PREPAREDNESS ACTIONS..." and "&&" added before and after your CTA as the CF.S does not have one by default which would place the markers in the product for the forecaster.

Several text formatter utilities and methods have been changed to fix various issues or implement new functionality, like the enhanced tropical uncertainty wording. Check all of the overrides you have of the methods below, start with the OB9 baseline and add your modifications in as needed. Green denotes methods that changed.

ConfigVariables -
1) New phrase_descriptor entry for SnowSnow: "snow accumulation"

2) Enabled the use of nonlinear thresholds for change in wind direction when combining subPhrases. Added a new vector_dir_difference_nlValue_dict which calls the original vector_dir_difference_dict. This allows for backward compatibility. If a nonlinear threshold is desired, override this new method.
WxPhrases - Made 1-line change in addEmbeddedVisibility. With the embedded_visibility_flag set to 1 and the visibility_wx_threshold set to 2, the ZFP was missing a needed WITH.
PhraseBuilder -
1) Added method consolidateLEPerPhraseInstance and called it from assembleIndentedPhrases. Fixes the problem where 24-hour trend words were missing for Max/Min Humidity results from the consolidation of sub-phrases in the FWF.
2) For some phrases (e.g. heatIndex, windChill), ignore the consolidateTrends method which appears in the standard_phraseMethods. Fixes the problem where there were no time descriptors with Heat Index/Wind Chill.
Added code to the beginning of checkVectorDifference to use the new nonlinear wind method instead of the old one for determining the direction difference. Allows different directions to be combined based on wind speed thresholds.
4) Added code to applyDisabled to fix a problem which caused the ZFP to fail for non-precip weather (such as fog, blowing snow, haze) when weather local effects were implemented.
5) Modified checkWeatherSimilarity to add new methods similarAttributesList, similarAttributes, removeSpecialAttributes, matchAttrs, and checkAttrs. Part of fix for duplicate or missing thunderstorm attribute timing wording.

CommonUtils -
modified makeAggregateSubkey to add removeSimilarAttrs as part of fix for duplicate or missing thunderstorm attribute timing wording.
SampleAnalysis -
the getDominantValues method in rankedWx was modified by removing similarAttrs when creating new subkey. This is part of fix for duplicate or missing thunderstorm attribute timing wording.

1) The checkAccumlatingWx
method was changed to ignore snow flurries and light ice crystals as accumulating weather types. Previously, the ZFP contained the phrase "no snow accumulation" when flurries are forecast. When "- -" is the intensity, no accumulation phrase will be generated.

2) The steady_temp_trend_words method was modified to eliminate double temperature phrases in the ZFP. The error was occurring because the method was not sufficiently eliminating the highs/lows phrases when it was triggered.
3) The alternate temp_trend_words method (commented out in the baseline) was updated to fix a problem where the ZFP should return either no timer phrase or a timer phrase that is further into the future when the ZFP is run at a transition time (midnight, 6 am, etc.).
DiscretePhrases - Modified timingWordTableEXPLICIT definition to fix headline wording for hazards ending at 6 pm.

Numerous other changes have been made to the text infrastructure to accommodate the full integration of the tropical expressions of uncertainty into the baseline. These include the removal of the following files:

The rest of the changes are covered in the tropical section.

ISC grids can now be exchanged between WFOs and RFCs. To accomplish this, 3 steps are needed.

1) All desired RFCs and WFOs must be in the serverConfig.REQUESTED_ISC_SITES list.

2) Any element, other than QPF, that is desired from an office type different from yours needs to be added to extraISCparms in localConfig.py. For example:

extraISCparms = [([Temp, Wind, Weather, SnowAmt], 'rfc')]

for a WFO who wants those 4 elements from any requested RFC. QPF does not need to be included as it is already in serverConfig as part of a similar definition. The extraISCparms entries need to follow the element definition from serverConfig (see image below) such as Temp, Weather, MaxT, Td, etc.

3) Those elements, including QPF, need to be added to serverConfig.REQUESTED_ISC_PARMS. These new elements take the form of the traditional element name with the office type appended. For example:

serverConfig.REQUESTED_ISC_PARMS = ['T','Td','QPF','PoP','WaveHeight',Sky','Wind','Wx','Hazards','Trfc','QPFrfc','Windrfc','Wxrfc','SnowAmtrfc']

To accomplish this functionality in OB9, site definitions were changed to include an office type. The 5 types are wfo, rfc, nc, ro and other. National centers are nc and regional headquarters are ro. This new format will allow for grid exchange with national centers in the future. The office type argument at the end of the SITES[] domain is optional, so if the office type is not defined in the SITES[] line in localConfig, then it will default to the value specified in serverConfig.py. RFCs nor WFOs will need to modify their localConfig for OB9 in this area.

But this change does cause problems for ISC between WFOs and RFCs that are on different versions. So if an RFC is OB8.3.1 and a WFO is OB9, the RFC will not receive ISC data from OB9 WFOs until the RFC loads OB9. There is no impact on ISC between WFOs on different versions.

ISC grid exchange between like office types continues to operate as it did before and no change is needed by a WFO who does not wish to exchange grids with an RFC. The images below are from serverConfig which shows much of what is described.

4) The grids from a different office type will appear differently in the grid manager than grids from a like office type. They also are not assigned the same display information as like-office grids that are the same element. So a SITEgfeConfig change is needed to include specific display information for any element requested from a different office type. This display information includes color table, log factor and max and min values. For example, to display RFC QPF so that it appears as WFO QPF in the Fcst db, the following is needed:

QPFrfc_defaultColorTable = "Gridded Data"
QPFrfc_LogFactor = 0.03

5) To fully utilize the grids from a different office type, download from the STR and install CopyFromModelISC and CopyFromISC, courtesy of GSD. These allow the ISC grids to be copied into the Fcst db.

See the forecaster ISC section for more on the interface change.


With the change to ISC, the suite of ISC tools has been updated. If you have any SITE-level overrides to these ISC tools, such as the Tim Barker suite of ISC tools, those must be removed in order for the ISC Tools to run in OB9.

A New AQA formatter has been delivered. Like the rest of the hazard/CEM formatters, it consists of a Hazard_AQA and Hazard_AQA_Local pairing. An entry for AQA must be added to the a2a file and configureTextProducts run for the formatter to appear in the Launcher. Then the formatter needs to be configured to properly format the relaying air quality agency in the header. See comments in the formatter for configuration instructions.

Also the following files were changed to add the new AQ.Y code needed for the creation of the AQA product (although it is not a VTEC product).


It is very important that you merge your changes to MakeHazard and MergeHazards with the OB9 versions. If you do not, forecasters will be unable to create the new hazard. Specifically for MakeHazard, the AQ.Y hazard has been added under the Non-Precipitation section.

If you have a local Hazards.COLORTABLE, you need to add your local changes to this new version.

A new hazard, AS.O, has been added to GFE for the creation of air stagnation oulooks. Due to a delay in the transmission of the appropriate SCN, this AS.O cannot be issued until June.

To implement the AS.O, the following files have been modified:


It is very important that you merge your changes to MakeHazard and MergeHazards with the OB9 versions. If you do not, forecasters will be unable to create the new hazard. Specifically for MakeHazard, the AS.O has been added under Non-Precipitation.

With the NPW formatter, if
you have any allowedHazards override in Hazard_NPW_Local, that needs to be removed all together or modified to include AS.O.

If you have a local Hazards.COLORTABLE, you need to add your local changes to this new version.

If you are overriding the Hazards_commonValues in a SITEgfeConfig, then it needs to be updated to include the new hazard.

The CWF and CWF_Pacific formatter have a change to both the issuance_List and determineTimeRanges so that it better matches other baseline formatters. Check any overrides you have of either of those methods to ensure they still work.

Tropical Changes - MUST DO for Tropical Sites

With OB9, the Tropical ZFP and CWF formatters have been integrated into the regular ZFP and CWF, and CWF_Pacific formatters. Therefore the ZFP_Tropical and CWF_Tropical files have been removed from /awips/GFESuite/primary/data/databases/BASE/TEXT/TextProduct and the file Tropical_Overrides was removed from /awips/GFESuite/primary/data/databases/BASE/TEXT/TextUtility.

Prior to OB9, the tropical formatter coding was self-contained in the Tropical_Overrides file which overrode BASE and SITE methods and/or definitions. This however, limited the flexibility when it came to fully porting over localization and/or customizations normally handled through the local Overrides files. To eliminate this limitation, the Code in Tropical_Overrides was ported over and integrated into the baseline ZFP, CWF_Pacific and CWF formatters.

So in order to ensure your Tropical Formatters are activated and in order to make sure non-tropical portions of the above formatters will work, the OB9 post-install
procedures are:

1) The following new weather elements need to be added to the appropriate weather element group after installing ATAN 974:
pwsD34, pwsD64, pwsN34, pwsN64, prob34, prob64, pws34int, and pws64int

2) Move /awips/GFESuite/primary/data/databases/SITE/TEXT/TextProduct/ZFP_Tropical.TextProduct, /awips/GFESuite/primary/data/databases/SITE/TEXT/TextProduct/CWF_Tropical.TextProduct and /awips/GFESuite/primary/data/databases/SITE/TEXT/TextUtility/Tropical_Overrides.TextUtility to a different location. These are no longer used in OB9, but don't delete them yet, simply move them so they can be referenced as you work on your new overrides.

3) Create back up copies of your current ZFP_XXX_Overrides and CWF_XXX_Overrides files by moving them out of the /awips/GFESuite/primary/data/databases/SITE/TEXT/TextUtility. Then create new versions of them. From this point on, we recommend you open on a separate window with the OB8.3.1 versions for reference. The idea is for you to rebuild the new Overrides files so that all of your overrides will be fully compatible with the latest baseline changes in OB9.

In some instances, you will be able to just copy and paste from the old file, but do not do that until you fully inspect what is in the baseline. In other cases you will need to copy and paste from the new baseline and make the modifications. If you follow these instructions, you will be able to restore all of your local effects and customizations while preserving the baseline Tropical logic.

4) To enable the Tropical flag on the ZFP and CWF dialogs that will allow you to run the Tropical Formatters from the regular formatters dialog window, do the following:

  • Copy the VariableList method from AreaFcst and paste into your new ZFP_XXX_Overrides
  • Uncomment the "Include Tropical?" line
  • Copy the VariableList method from CWF or CWF_Pacific and paste into you new CWF_XXX_Overrides
  • Uncomment the "Include Tropical?" line

After you have done the above, you will have fully functional ZFP and CWF formatters. As you execute these instructions, below is a list of files modified in order to integrate the old Tropical_Overrides file code into the OB9 ZFP, CWF_Pacific and CWF baseline code. This will help you identify pieces of code that were modified in the new baseline concerning the tropical formatters which should help you when building your new ZFP and CWF Override files.

IMPORTANT NOTE: The changes below in support of the Tropical Formatters are not be be changed. Changes that affect the Tropical Formatters are easy to identify because normally they are commented or you can see reference to the includeTropical variable. You can Override the code below in the local ZFP or CWF Override files for customization and/or local effects purposes, but the code that is part of the Tropical Formatters is not to be changed.

Changes to Utilities
for the tropical integration

Sample Analysis -
Added entries to temporalCoverage_hours_dict for pws grids
- Added tropical descriptors to phrase_descriptor_dict
PhraseBuilder - Modified assemblePhrases to check includeOnlyPhrases_list
VectorRelatedPhrases -
1) Modified simple_vector_phrase to calculate and store maxMagList
2) Modified embedded_gust_phrase with exceptions for when Tropical wording is included
3) Added tropicalBooleanConditions, windSpdProb_thresholds, firstComponentPeriod, includeOnlyPhrases_list (same as _getIncludeOnly), pws_phrase, pws_setUp, pws_words, getTropicalDescription, getPeriod description methods

Methods that are overwritten in AreaFcst, CWF, and CWF_Pacific
(In these files look for the includeTropical variable and you will see the pieces of code that concerns the Tropical Formatters. These can be ported over to your ZFP or CWF Overrides file for purposes of adding local effects, but the Tropical coding is not to be changed):

-- if includeTropical is on, periodCombining is turned off and directiveType is forced to 10-503
Component Period_# and CWFPeriod definitions: Call addTropical for analysisList and phraseList
Added addTropical for analysisList and phraseList in product components for CWF, CWF_Pacific and ZFP

Special Note about the issuance_list: If you change the issuance list naming in the dialog box from "Morning with Pre-1st Period" and "Afternoon with Pre-1st Period" as well as "Morning" and "Afternoon", then you must change getVariables accordingly. As designed, when you activate the Tropical Formatters in the dialog box to run them, no pre-1st periods are allowed because there are no Period component definitions for those periods. This is the case because when in tropical cyclone mode, the forecast update cycles usually follow TPC advisory cycles.

Steps 5 and 6 were added after the Baseline OB9 code was delivered. They are not needed for the tropical formatters to function. But they were changes identified to optimize the performance of the formatters based on a validation study that was conducted through early 2009. So these recommended changes should be added to SITE overrides prior to the start of the 2009 season.

5) The validation study for wind speed probability thresholds has triggered an update for 2009. The values for the 3 areas were averaged to minimize potential inconsistencies between the areas. Sites should place the following windSpdProb_thresholds def from Vector_Related_Phrases in ZFP_XXX_Overrides and CWF_XXX_Overrides:

def windSpdProb_thresholds(self, tree, node):
return [
((55.0, 80.0), (30.0, 60.0)), # Per 1
(45.0, 25.0), # Per 2
(40.0, 20.0), # Per 3
(35.0, 15.0), # Per 4
(30.0, 10.0), # Per 5
(25.0, 7.0), # Per 6
(20.0, 6.0), # Per 7
(15.0, 5.0), # Per 8
(12.5, 4.0), # Per 9
(10.0, 3.0), # Per 10

6) The next step lowers the threshold in the extended periods which would allow for an expression of uncertainty to be triggered if the probabilistic threshold is exceeded. To do this, overwrite the getPeriod_5_9_Desc and getPeriod_10_14_Desc definitions in ZFP_XXX_Overrides and CWF_XXX_Overrides by replacing every instance of maxMag >= 20 with maxMag >= 15.

ATAN 974 brings a new version of PWS Procedure. This new version creates the new interval grids needed for the HLS. If you have a SITE-level version of PWS Procedure, it will need to be removed when ATAN 974 is installed.

For the web point-and-click, pwsD34, pwsD64, pwsN34, and pwsN64 need to be addded to the elements sent to region. This allows the correct web graphics to appear when a tropical cyclone conditions may occur.

Added pws weather elements to OFFICIALDBS in serverConfig.py. All pws elements must be removed from localConfig as serverConfig contains the correct definitions.



Area-specific Cities List

OB9 has added the ability for 5 of the hazard products to only contain cities that are within the hazard as determined by the Hazard grid. This eliminates the issue with cities not in a hazard being listed in the product segment. This functionality is mainly for areas of complex terrain who are already configured to issue multiple hazards in a zone.

In order to ensure the cities chosen for the product are located where they are expected, check the CityLocation.TextUtility for the cities in your domain. If needed, modify this file as SITE and make sure the same changes are made to AreaDictionary. Even if dozens of cities are added to these files for various zones, it will not impact hazards that are in effect for an entire zone. There is a limit on the number of cities per zone.

After the CityLocation file has been verified, the Hazard_Local files will need to be modified to use this file. The 5 hazards that can be modified are the CFW, FFA, NPW, RFW, and WSW. So as SITE, modify the pertinent file (e.g. Hazard_WSW_Local) to uncomment the line:
Definition["accurateCities"] = 1 # If 1, cities are determined from grids

Again, there should also be an allowedHazards method override which allows for multiple hazards in a zone in order for this functionality to be truly useful. Then, once the forecaster has created a hazard for an edit area rather than the whole zone, the resulting product will only include those cities that are in the affected edit area.



New ISC Send Scheme

The option is given in OB9 to have the forecasters manually send all ISC data. This is not recommended as it would be very easy for no data to ever be sent. To configure this, set serverConfig.SEND_ISC_ON_SAVE = 0 or comment out the entry in localConfig.py. Also, serverConfig.SEND_ISC_ON_PUBLISH = 0 must be set.

Then when the forecasters are ready to send data to those requesting it, they must go through the steps outlined in the forecaster ISC section.




Cascading Populate Menu

The Populate menu can now be configured to cascade which will allow forecasters to view all of the possible choices. To accomplish this, add the following to SITEgfeConfig:

ProcedureCascadeDepth = 12

where 12 is the maximum number of populate choices that will be shown before cascading to another menu. This number can be whatever is desired locally.


runProcedure Change

Added a -V option to the runProcedure command to allow entering variables from the command line.


Links to File Diffs

Raytheon-created diffs between OB8.3 and OB9 which are updated weekly during the beta period. Requires your NOAA email username and password. Choose the last in the list to get the latest information.

Link to diffs which was created by Paul Jendrowski (RNK). Shows diffs from 8.3.1 to OB9.




Information for Forecasters

CTA Markers in all Hazard Products
New Hazards
ISC Changes
Hazard-specific Cities List


CTA Markers in all Hazard Products

As part of an ongoing effort to assist internal and external customers with parsing of our text warnings, call-to-action markers are being included in ALL VTEC hazard products. Marine offices will already be familiar with these markers as the MWW became the first product to contain the markers. In GFE, this means the CFW, FFA, HLS, MWW, NPW, RFW, WSW will all contain these markers.

These new markers, the pairing of "PRECAUTIONARY/PREPAREDNESS ACTIONS..." and "&&", surround all CTAs which enables these instructions to be parsed by machines, including NWR. These markers are required whenever there is a CTA in the product. So while they are editable in order to allow sites who choose not to include CTAs to remove the entire section, they are to remain in the product whenever a CTA is present.

Also, if additional CTAs are being added to the product, they must go between the markers with a blank line between the end of the CTA and the &&.


New Hazards

Both AS.O and AQ.Y are available under the NPW section of the MakeHazard tool. The AS.O is air stagnation outlook and is the first outlook VTEC being issued. It is used to provide the public with a longer term look at air quality conditions. It goes into the NPW just like the air stagnation advisory (AS.Y). Due to a delay in the transmission of the appropriate SCN, this AS.O cannot be issued until June.

AQ.Y is a hazard grid placeholder for relayed air quality messages from external groups, such as state or local environmental/air quality agencies. The associate product is the new AQA which must be set up locally before it will appear in the formatter launcher. This product behaves like the CEM messages as it has a "relayed by NWS" line in the MND header.


ISC Changes

OB9 brings the abiltiy to view ISC data from an office of a different type. So a WFO can view RFC grids and visa versa. If this is configured to occur by your office, then the different type office's grids will appear if the element is loaded from the ISC database. It will appear as WxElementofficetype. For instance, if you are a WFO receiving QPF grids from surrounding RFCs, the grid will appear as QPFrfc below the ISC grids from other WFOs. Again, the ISC grids must be loaded via the browser to be visible.

You will not be able to edit the data as you can with ISC data of a like office type (i.e. no pencil tool, etc.) when in Show_ISC mode.



A new way to share ISC grids has been made available in OB9. While this option is not recommended, it offers control over which grids are shared and when. This abillity must be configured by the focal point in order to work. But the forecaster must ALWAYS manually send the grids every time they are deemed ready to share. This send option is not recommended for that reason.

If this option if configured, the forecaster must follow these steps to send ISC data:
1) Save grids
2) Click Consistency on Menu Bar
3) Click Send Intersite Grids
4) Choose either Auto or Manual
       Auto sends all grids which have not already been sent by forecaster by this same process
       Manual brings up an additional dialog which allows the forecaster to choose which elements and times to send

5) Click SendISCGrids

If your site is still configured to send on save, you will receive an error message if the above send is attempted.

For sites surrounding a site who is utilizing this new scheme, if the site forgets to send grids, the data can be requested through the ISC Request/Reply feature. Always ping the site on 12Planet or call before resorting to requesting as there are serious performance impacts of running that procedure.


Hazard-specific Cities List

If your site is configured to allow hazard-specific cities list in the hazard products, you will only receive the cities that are in the edit area of the hazard. For instance, if you create an edit area with WS.A that is a subset of a zone (e.g. elevations above 5k ft.), the cities list in the segment will only contain those cities that fall within that edit area. In previous builds, all of the cities in the zone would be included, regardless of whether they were in the hazard.

As part of this new feature, GFE determines the appropriate cities every time the formatter is run. If for any reason GFE cannot safely determine the list of cities, then the entire cities list will appear in framing code for you to determine which to keep prior to transmitting. This event will rarely occur.