OB9 GFE Changes
Last Updated 3/15/12
National Weather Service
Office of Climate, Water, and Weather Services
|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.
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.
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
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).
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:
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.|
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
1) The following new weather
elements need to be added to the appropriate weather element group
after installing ATAN 974:
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.
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.
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.
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.
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
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):
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.
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:
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.
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.
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.
Added a -V option to the runProcedure command to allow entering variables from the command line.
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.
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 &&.
|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.
| 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:
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.
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.