NOAA/National Weather Service's Warning Decision Training BranchUnited States Department of Commerce

WES-2 Bridge News

WDTD has released WES-2 Bridge version 16.2.2. All WFOs will need to uprade to this build to support GOES-R and many other recent AWIPS upgrades. We are working on a new build to include GFE functionality.
Looking for training? Click here to access our current training schedule
Confused by winter weather watches, warnings and advisories? Click here to help simplify our 		products.

Warning Decision Training Division

Office of Chief Learning Officer

WES-2 Bridge Support > Warning Decision Training Division > Tools > WES-2 Bridge > Support

Installation Confirmation

WES-2 Bridge Software Installation Completion Form (NOAA Credentials Required)

SIFT Installation on WES-2 Bridge Completion Form (NOAA Credentials Required)


Questions and Support

Users Can't See Cases

When users can't see cases that have been prepared on the WES-2 machine, it means that their Case Path Preferences (Preference menu) have not been set. We will be implementing a centralized, system-wide case-path preference in a future build.

Warngen Issues

Two issues associated with Warngen are defects associated with how AWIPS-2 handles issuing warnings at a time previous to the current system time (as in a Case Review or Simulation). The first issue is that the "10-minute warning" message that an issued warning is about to expire appears immediately after the warning is issued rather than at the appropriate time. The second issue is the logic used by Warngen to determine the future locations the storm centroid is based on the system time; consequently, it cannot find locations inside the polygon based on time when the warning time is before the system time. Therefore, the pathcast option with Warngen cannot be used with WES-2 Bridge at this time. We are working on addressing these problems.

Text Database

The text database currently does not have a simulation function, so the text database is populated with data for an entire case but data are not progressively revealed during a simulation. We will be addressing this in an upcoming build.

We also are not cleaning up the text database after a simulation.  There are two ways to approach this:

METHOD 1:  Get rid of warnings from the WFO that was simulated:

psql fxatext -p 543X -U awips -c "delete from stdtextproducts where site='KOUN' and nnnid in ('TOR','SVR','SVS');"

In this command the 543X is the port number which is 5433 for EDEX_01; 5434 for EDEX_02, 5435 for EDEX_03, and 5436 for EDEX_04.

METHOD 2: Get rid of any product from a recent simulation. In this example, you may be running a simulation for a 2015 case on March 25, 2016. You can delete any products in the database with an inserttime after today's date:

psql fxatext -p 543X -U awips -c "delete from stdtextproducts where inserttime > '2016-03-25 00:00:00';"


Case Loading Is Slow

Cases should not take more than an hour to load. If the time is slower than that, likely the file permissions on the database have been changed which prevents the database from correctly starting. The EDEX instance must be reinstalled to fix this problem, and contact us for specific instructions.

MRMS Archiving Issue

At some WFOs, an issue was observed where only the first ten minutes of MRMS data per hour were archived in that hour's .bin files. This has been traced to purge rules for MRMS that were too aggressive. The purge rules for MRMS will be modified in an upcoming AWIPS build, but it is possible to modify your site's purge rules by following the workaround that is listed in the AWIPS 2 Living Release Notes under DR 18861, targeted for OB16.2.2. For archving purposes, it's important that at least 2-4 hours of MRMS data remain on the operational AWIPS system.

New Case Fails to Create Radar Data

A WES-2 Bridge issue was found with New Case that prevents the software from populating a case with radar data. This happens after rawPlay has been run on data created from an RPG where the data contained certain products including but not limited to GSM (radar product 2). This bug has been fixed in our code and will appear in the next (16.X) release. In the meantime, there is a workaround, which removes the offending products from the database:

psql metadata -p 5432 -U awips -c "delete from radar where volscantime IS null;"

FFMP Basin Synchronization

When FFMP basins are updated, a number of cascading effects occur. One of these is that any previously archived FFMP data become unusable unless the FFMP localization files that correspond with the previous basin configuration were also saved and changed out. This issue has occured at a field site, and we need to design a mechanism to synchronize FFMP localization files and archived data.

Additional Frequently Asked Questions and Solutions for Field Problems will be posted here. Until this content is developed, feel free to use this contact information for support:

WES-2 Bridge Support Information