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.
3) 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.
ScalarPhrases -
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:
ZFP_Tropical
CWF_Tropical
Tropical_Overrides

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.

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

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).

MakeHazard.Procedure
MergeHazards.Procedure
Hazards.COLORTABLE

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:

MakeHazard.Procedure
MergeHazards.Procedure
Hazard_FPNPW.TextProduct
Hazards.COLORTABLE
gfeConfig.GFECONFIG

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.

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) 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.

2) 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.

3) 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 the "Include Tropical?" line
• Copy the VariableList method from CWF or CWF_Pacific and paste into you new CWF_XXX_Overrides
• Uncomment the the "Include Tropical?" line
  

4) At this point, you have fully functional ZFP and CWF formatters, both regular as well as Tropical. But you will not have any of your local customizations. In order to restore those without interfering with the integrated Tropical Formatter logic, you will need to go through the process described in step 2. As you do, here 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
ConfigVariables - 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):

gust_wind_difference_nlValue
temporalCoverage_hours_dict
moderated_dict
maximum_range_nlValue_dict
_getVariables -- 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.

Added pws weather elements to OFFICIALDBS in serverConfig.py.

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 &&.

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.