Enabling ISC for 8.3 Sites and Neighbors
Last Updated 5/2/08
National Weather Service
Office of Climate, Water, and
Forecast Decision Training Branch
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.
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.
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.
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.
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 188.8.131.52 site needs to provide backup for an 8.3 site.
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.
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.
1. Since 8.3 sites cannot force a send of
data, a new interface has been added to 184.108.40.206. This new interface allows
220.127.116.11 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.
18.104.22.168 sites continue to force a send of data to surrounding sites in these instances.
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
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.
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://22.214.171.124: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
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.
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.