Enabling ISC for 8.3 Sites and Neighbors

Last Updated 5/2/08

National Weather Service

Office of Climate, Water, and Weather Services
Forecast Decision Training Branch

Questions: Shannon.White@noaa.gov

Disclaimer    and   Privacy Notice

 

Needed Entries for 8.3 and Surrounding Sites
Changes Visible to Forecasters from 8.2.1 to 8.3
New Request Feature for 8.2.1.1
Impacts on Service Backup
Technical Information on Change

 

Needed Entries for 8.3 and Surrounding Sites

When GFE is delivered in 8.3, ISC is disabled via the serverConfig file. You will need to have overrides in /awips/GFESuite/primary/etc/SITE/localConfig.py in place prior to 8.3 installation which enables ISC.

For 8.2.1 sites, these new entries need to be added in order to exchange ISC data with 8.3 sites, but the SITEgfeConfig ISC_Sites entry needs to remain until 8.3 is installed locally and at all potential backup sites.

Required Entries
1. serverConfig.REQUEST_ISC = 1
This variable must be 1 to send and receive ISC data.

2. serverConfig.SEND_ISC_ON_SAVE = 1
This variable must be 1 to send ISC data as the forecasters create it.

Highly Recommended Entry
1. serverConfig.REQUESTED_ISC_PARMS = ['PARM1', 'PARM2', etc.]
If this variable is not set, every GFE element in the Fcst database will be sent/received (everything defined between serverConfig and localConfig). Choose which elements are important for collaboration to streamline the ISC process and reduce unnecessary traffic.

Optional Entries
1. serverConfig.REQUESTED_ISC_SITES = ['WFO1', 'WFO2', etc.]
If this variable is not set, the ifpServer will automatically determine all of the WFOs in your domain and mosaic data from them. If you wish to receive ISC data from an RFC, this list needs to be manually created. If you do set this manually, make sure to include your own site.

2. serverConfig.SEND_ISC_ON_PUBLISH = 1
This variable must be 1 to send ISC data when the forecasters publish.

When changes are complete, bounce your ifpServer for them to take effect.

This sample localConfig.py file shows most of these entries configured. It includes all forecaster-created serverConfig parms plus ApparentT, so it can be used to copy and paste into your own localConfig.

Note:
The ISC_Sites entry in SITEgfeConfig.py is no longer needed once all sites have loaded OB8.3. While it will not be acknowledged by the server in 8.3, the entry needs to remain in the event an 8.2.1.1 site needs to provide backup for an 8.3 site.

Critical Information about Non-baseline Machines
1. Under no circumstances should the above items be configured on a non-baseline/rpp machine! This can cause significant issues for both ISC as well as VTEC active table sharing. See technical section for more information.

2. In the localVTECPartners.py on the non-baseline machine, VTEC_RESPOND_TO_TABLE_REQUESTS = 0 MUST be included. This will prevent incorrect VTEC data from inadvertently being sent to neighboring sites.

 

Changes Visible to Forecasters from 8.2.1 to 8.3

Dialog changes
1. No Send ISC box on Save dialog

            
8.3 Save Dialog                                                    8.2.1 Save Dialog



2. No Send ISC box on Publish dialog

            
8.3 Publish Dialog                                                                                     8.2.1 Publish Dialog


3. ISC send/request dialog is considerably different (accessed via Consistency menu).

            
8.3 ISC Request Dialog                                                                                               8.2.1 ISC Send Dialog


Grid Editor Changes
1. All pertinent data from surrounding sites will be included. It is no longer clipped to a specific edit area. In ISC mode, your entire domain will be covered with data if you have the server identify the ISC sites (i.e. no REQUESTED_ISC_SITES entry in localConfig.py).

2. You can no longer force the send of ISC data. Surrounding sites will need to request the data from you.


New Request Feature for 8.2.1.1

1. Since 8.3 sites cannot force a send of data, a new interface has been added to 8.2.1.1. This new interface allows 8.2.1.1 sites to request ISC data from 8.3 sites. While the list of sites will include all sites registered to with the central web service, data can only be requested from 8.3 sites. Data should only be requested when beginning to provide service backup for a neighbor or when resuming service after being down.

8.2.1.1 sites continue to force a send of data to surrounding sites in these instances.

                                                   
                                           

Impacts on Service Backup

1. Scripts which populate the database from outside of GFE do NOT send grids via ISC. This is how the backup database is populated. So when starting to provide backup for someone, make sure you do NOT save any data prior to the site going down as multiple sites will be registered as the same domain.
For example, if RAH is backing up RNK, then RAH cannot save data until RNK is down or both of them will be sending data to surrounding sites as RNK.

2. When a site is being backed up, the surrounding sites no longer have to route their ISC grids to the site providing backup. The grids automatically route to the appropriate office.

3. When you begin providing backup, you will need to populate the ISC database with data from the appropriate sites. To do this:



ONLY use this dialog to request data when beginning service backup or resuming operations after being down. Using this dialog during normal operations can cause a serious drain on system resources which results in compromised GFE performance.

Note: Even though 8.2.1 sites appear in this list, data cannot be requested from them. ISC will still be received from them as they save while the neighboring site is being backed up. Those 8.2.1 sites can force a send of the database, if that is desired.

4. VTEC active table sharing also is routed in this fashion, so nothing special needs to occur to have hazard/VTEC information shared during backup.


Technical/Background Information
8.3 Sites

1. In 8.3, the way ISC work changes to use a central web service utilizing XML to route grids to sites requesting data, rather than each office deciding to whom to push grids. This allows for the removal of the ISC routing info/files on dx1 as all contact happens with the ifpServer. All needed ISC files are now part of /awips/GFESuite/primary.

2. ISC log files have also been moved to /awips/GFESuite/primary/data/logfiles making all GFE log files together in the same location.

3. This interaction with the web service is done using the GFE site ID, not MHS as ISC used to work (since it used dx1). This allows for the correct routing of data when one site is backing up another. The site performing backup registers with the web service as the failed site which ensures ISC for that site is correctly routed to the site performing backup. The same holds true for VTEC active table sharing.

4. The ISC configuration shown above only applies to OB8.3 sites. So OB8.3 sites cannot control what is sent to them from OB8.2.1 sites. This is due to data from the OB8.2.1 sites missing the XML routing information. Therefore, when received by OB8.3 sites, the data will be routed to ALL potential ifpServers on dx4 and px3 (AFC only) with the result that many error messages may appear in the logs as px3 will not be found anywhere other than AFC. This will unfortunately be the case until all surrounding sites load 8.3.

5. Local programs which utilize ISC data on a non-baseline box will likely be affected by this new ISC routing scheme. Please be very cautious when setting up routing of ISC data to non-baseline boxes. While serverConfig.REQUEST_ISC = 1 can be added to the localConfig on the non-baseline machine, serverConfig.SEND_ISC_ON_SAVE = 0 and serverConfig.SEND_ISC_ON_PUBLISH = 0 must also be configured or those variables not configured as the routing is dependent upon GFE ID and those machines can send out data and corrupt ISC and VTEC data at other sites. See Critical Info about Non-Baseline Machines in the first section. Also, the non-baseline machine will need to be 8.3 in order to process the ISC data being sent to it.

6. A web interface is available to the central web service. The web interface, accessible via Mozilla on AWIPS at http://165.92.30.69:8080, can be used to tell which ifpServers are currently registered and what elements are requested by each site. Again, what you are requesting and what you may receive from 8.2.1 sites could be different as ISC is still routed from 8.2.1 sites based on the SITEgfeConfig entries.

When you bring up the web interface, it looks like:


Just choose Site/Domain Configuration and leave the entry blank and click enter. It will show ALL of the sites registered with the server, the elements requested and sites with which ISC will occur.

7. Great care needs to be exercised when testing service backup. All sites need to update their configuration on the central server after getting all of the 8.3 items set. This allows real backup to work properly. But due to these ISC changes, testing service backup for an 8.3 site can cause ISC grids to be sent. You can no longer "toggle off" the send as you save. So while populating the database upon initiating service backup will not send grids, any edits thereafter will. Great care needs to be taken when testing service backup so that real operations are not affected.

The backup GFE client can be started in PRACTICE mode and the digital database copied using Copy All Grids From and choosing Fcst . That is the safest testing option if formatters/tools/procedures are to be tested for your backup site.

8.2.1 Sites

1. While the additions to the localConfig.py file on 8.2.1 systems is primarily to correctly receive ISC data from 8.3 sites, it also allows service backup to occur between 8.2.1 and 8.3 sites. Without those entries in the localConfig and having it uploaded to the central backup server, the backup server could fail to start.

2. Existing ISC routing files on dx1 are still used for OB8.2.1 sites. This means that the XML routing information received from OB8.3 sites will be ignored. It is possible while in service backup that duplicate ISC transmissions are received and processed from OB8.3 sites.