active Check to include Clear and return to menu Close Closed captions. Press the spacebar to toggle captions on and off. Continue Continue Exit Filter FINISH finish Definition definition Glossary Terms Menu Please rotate your device NEXT next Notes Notes Bio More info Captions pause play Send an email PREV previous Question List replay Resources resources Restart Resume Search... search Search in: Search Results Skip navigation. Press enter to return to the slide. Slide Text SUBMIT ALL submit all SUBMIT submit volume Welcome to this module on major changes associated with the WSR-88D RDA/RPG Build 19. I’m Sarah Borg of the Warning Decision Training Division on behalf of the WDTD 88D build team. Headlines of this release include: the introduction of the new VCP 112 and removal of VCP 121 Updates to the way QPE products are created and processed Updates to the 2-D Velocity Dealiasing algorithm Changes to data archiving Sites that have new supplemental low elevation angles And updates to the MSCF. Lastly, we will discuss a ZDR overview. When it comes to build 19, one of the most notable changes will be the addition of a new volume coverage pattern. VCP 112. VCP 112 is an interesting new addition to our toolbox. This VCP replaces VCP 121. It features the use of the multi-PRF dealiasing algorithm using a high and low PRF SZ-2 cut to create an improved velocity product. Similar to the technique used in the now discontinued VCP 121 – but with the volume coverage and approaching the speed of the VCP 212 scan. It conducts three separate cuts on the 0.5, 0.9, and 1.3 degree beam angles and any supplemental lower elevation angles, two of which are Doppler cuts. And it allows manual or Auto-PRF selection for batch cuts. This matches the elevation angles of VCP 12 and 212, and allows for the use of AVSET and one SAILS cut. Also note the need to update the RPS list. Guidance for this will be presented in an upcoming slide. A table specifying more VCP 112 characteristics is available in the resources tab. The Multi-PRF Dealiasing algorithm (MPDA) works like this, by generating an initial cut on PRF mode 4, and a second on PRF mode 8. It then takes the results of both of those to create what should be a much cleaner velocity picture for you to interpret. Given the strengths and weaknesses of the PRFs in play, VCP 112 will probably give you the most advantage for weather returns in the 60 to 120 nautical mile range from the RDA. Because of the dual cuts used by the MPDA it takes a little longer to execute 112 than the other 12 series VCPs. But as you can see from this example table, with AVSET enabled – which would be pretty likely for storms in the further ranges which this VCP is expected to excel in – you can get the VCP time down to about 4 and a half minutes. With the longest VCP time - with SAILS activated, AVSET inactive, and a supplemental below zero point five degree beam angle, this time would be 7 and a half minutes. When issuing a VCP change request within AWIPS, which you can do from the radar pulldown menu under VCP change request, you must check all parameters (AVSET, SAILS, and MRLE). In the MSCF it will keep the same settings as were used in the past. For sites with supplemental low-elevation angles the full complement of MRLE scans will be available. With Build 18.2, even for sites that had the supplemental low elevation angle, they could only run what was equivalent to MRLE x2 or MRLE x3. Build 19 now lets them run MRLE x4. The Radar Operations Center (ROC) has put together guidance on how to adjust your RPS lists to accommodate MRLE. The detailed instructions are available at this link. Changes have also been made to QPE displays and processing. As a quick reminder, legacy PPS rainfall accumulation bias information is calculated by comparing hourly gauge totals to co-located radar returns. For legacy precipitation products, bias information is shown in the bottom left hand corner. Unlike legacy precipitation products, bias information for Dual-Pol products is not calculated or applied. However, until now, legacy bias is incorrectly displayed on Dual-Pol QPE products, which can be quite confusing. This error has been corrected in Build 19 and Dual-Pol bias information will now correctly be displayed as “N/A.” There are also improvements in KDP based rain rates for rain mixed with hail. In prior builds, the same relationship was used for heavy rain and rain mixed with hail. This relationship was based on the algorithm for heavy rain, leading to frequent overestimates in rain rate when hail was present. Build 19 incorporates two conditions which must be met for the new rain/hail relationship to be used instead of the default heavy rain relationship from before. The first condition is that the Hydrometeor Classification Algorithm must be rain/hail. The second is a correlation coefficient less than 0.97, because if CC is greater than .97, it is assumed that rain dominates the signal. The Dual-Pol precip menu comes with several changes intended to improve QPE or help forecasters make better decisions to allow QPE to be as accurate as possible. A few of these will be discussed in the coming slides. For example, you’ll see the familiar option for “Precip type used for R(Z,ZDR)” at the top of this Build 18 Dual-Pol precip menu. In the Dual-Pol precip menu, the options for this parameter change from “tropical” and “continental” to “strat/trop” and “continental”. “Strat/trop” here implies “stratiform or tropical”. The intention of this change is to encourage forecasters to use the “tropical” (or now: stratiform/tropical) option for stratiform rainfall, even when not associated with a land-falling tropical system, because in many cases this will provide more accuracy than the continental option. In many cases, stratiform rain resembles tropical rainfall based on the drop size distribution in each, making the “tropical” relationship more appropriate for many stratiform events. When trying to decide whether to choose the “strat/trop” option or the “continental” option, consider the drop size distribution of your event! If DSD is large, you will likely get more out of the continental option than the “strat/trop” option. You will also now have the option to enable use of supplemental scans in QPE calculation. This refers to the addition of SAILS and MRLE tilts in the dual-pol rainfall products, which were not included in prior builds. It will still only generate one accumulation product per volume scan, but it will include the returns from those supplemental scans. The left image shows the common artifacts of QPE due to the time gaps between low level scans. The right image shows the same product using Build 19, including additional SAILS tilts. With the addition of these low-level scans, you get more continuous and physically representative QPE. Note: Later SAILS updates within the same volume scan are ignored when the hybrid scan is filled, so be aware that there still may be some discontinuities in QPE if not all SAILS tilts are included in a volume scan. The final addition to the Dual-Pol Precip menu in Build 19 is the rain rate estimation from Specific Attenuation, or R(A) method. This method has been shown to improve the performance of the QPE algorithm but has not been implemented operationally until Build 19. Users will have the option to turn this on or off within the Dual-Pol precip menu. With specific attenuation rainfall rate becoming operational in Build 19, there are a few important things to know. Specific attenuation estimates rainfall rate from total differential phase. Unlike reflectivity, differential phase is unaffected by partial beam blockage, so R(A) is useful in areas where beam blockage prevents the use of R(Z) relationships. Other benefits of R(A) include its immunity to system calibration issues of ZDR and its low sensitivity to drop size distribution as compared to reflectivity-based rain rate algorithms. While using R(A), beware of some caveats. The biggest is that R(A) is a function of drop shape and therefore does not work for non-liquid hydrometeors. Because of this, it can only be used in areas that are below the melting layer. Lastly, while R(A) is immune to ZDR calibration issues, it can be affected by other ZDR issues such as hardware or extreme cases of partial beam blockage, because ZDR does appear in a part of the calculation. If impacts are too large, however, QPE will revert back to using R(Z,ZDR). As mentioned, this algorithm is appropriate and beneficial for use in areas of beam blockage that are BELOW the melting layer. The example here shows the KLTX radar, which suffers from beam blockage in the southwest quadrant as shown in the left image which uses the standard Build 18 Tropical rain rate relationship. In the right image, you will see this area filled in by the attenuation rain rate algorithm, and you will notice that it only extends to the range of the melting layer. An important note regarding the attenuation rainfall rate: this algorithm is helpful in areas of beam blockage, but can sometimes cause underestimates in non-blocked areas. You can see this occurring by comparing the northeast quadrant of the QPE in the left and right images, where the right image shows slightly lower rainfall than the same region on the left. As a final note about R(A), recent testing has found that use of R(A) in the event of hurricanes can cause CPU usage to exceed its 50% threshold, therefore causing the QPE algorithm to fail. If your site is expecting a hurricane type event, it is recommended to turn R(A) off in the Dual-Pol QPE menu. This will be corrected in a future software build. You can find the official release note on this issue in the resources tab. There have been some updates to the 2DVDA in Build 19. It has shown notable improvements for environments with high shear when using lower PRFs. However, there are still difficulties being observed in dealiasing errors along shear boundaries in high vertical shear environments and errors involving large range from radar with weak signal. This image illustrates dealiasing errors where there is a weak signal at a far range. The white line represents 100 nautical miles from the RDA, the white circle is the area of interest, and the white star is the radar position. The image on the right illustrates dealiasing errors as a result of weak signal at a far range shown in the reflectivity image at 0.9 degrees. The 0.5 degree velocity image shows a transitioning flow while the 1.3 degree velocity image shows no velocity returns with some outbound velocity signatures. The 2DVDA error occurs at elevation 0.9 degrees as the algorithm isn’t sure what to do at that transition point. This image illustrates shear at range. During this time of error (middle image at 17:11) the site used VCP 21 and PRF 2. The issue here is caused by shear at the leading edge of the squall line. This error doesn’t usually occur when closer to the radar and it generally produces cleaner results. In this case, the site changed PRFs (and VCP) at 17:16, which immediately corrected the error. So, the easiest way to correct these issues if they arise is to raise the PRF. The RPG menu has been updated to remove the product generation list – with improved comms and stable systems all product requests will be honored. RDA status logs will now be sent to the radar operations center (ROC) – which will help ROC personnel when a site calls in for assistance. Additionally, the base data display on the MSCF will be removed with Build 19. These sites were employing a supplemental low elevation angle, that is an angle below 0 point 5 degrees, prior to Build 19. For Build 19, the bold sites have been added to the list. So while your site may not be impacted, check to see if your neighbors have a lower elevation angle as it might be useful for your tasks. Here is a map with the current MRLE sites and Build 19 sites with a supplemental low elevation angle. It is also available in the resources tab. This elevation angle can be disabled in the VCP and Mode Control window.  The feature “Base Tilt” is referring to the supplemental angle. This is only visible by sites with supplemental low elevation angles available, and will be on by default. You will also need to update your AWIPS RPS list to accommodate the low elevation angle. Select Level III products from the supplemental low elevation angle will be added to NOAAPORT (planned to begin adding sites in mid-June, https://www.weather.gov/media/notification/scn20-42base_tilt.pdf).  These will be added to the NDM files National RPS lists.  The RSP removable drive at RDA sites is a 2 terabyte drive that can store more level 1 data than a DVD. The partition will now be used to add the capability for the RDA to have nearly continuous recording of data, essentially making it a level 1 recorder for itself. In Build 19, the RPG was updated to generate the Power Removed Control (or PRC) product. This will replace the old clutter filter control product. The PRC shows where clutter filtering was applied, and how much suppression was applied in dB. The Power Removed Control Product can be found in the radar data menu under the Data Quality sub-section on AWIPS. It is listed as PRM in AWIPS. Shown here is an image of the Power Removed Control Product (PRC) as it will be seen at the RPG HCI. In the resources tab you will find a document that references each of the following categories of the PRC: BYPASS MAP, NO FILTER, ALL BINS, POINT CLUTTER, and DP FILTERED. For Build 19, the Shift Change Checklist product was updated for items requested from the field and for new or updated RPG features. In the RDA Status section there is one new entry: Last Downloaded Clutter Region File The Archive Level II section now includes whether model data was included in the level II file The RDA Performance/Maintenance Data section now includes the Horizontal and Vertical Noise for Short and Long Pulse as well as Noise Temp The Algorithm Status/Data section includes several new lines of data and information. The ZDR scale has also been increased, from minus 8 to 8 db to minus 13 to 20 dB.  This is mainly in response to biological research needs but it may impact how ZDR appears on your color tables. Note: Level III ZDR products are unchanged and users of GR2 Analyst will need to update their color table (*.pal file) to display the higher ZDR values. Lastly, while this isn’t directly related to build 19, it is something we want to bring to your attention. There are a number of sites that are out of tolerance with their Zdr biases. While we still can generally make sense of the signals for NWS usage, this does have a big impact on our FAA partners that use the Hydrometeor Classification Algorithm and other derived products sensitive to Zdr bias for air traffic management. It also has a negative impact on QPE products. So we want to encourage offices to be aware of this and help keep ZDR biases in check. New to build 19, you can now take a quick glance at not only your overall ZDR data quality, but the anticipated error to rainfall estimations being generated by the ZDR Bias. That is available in the data quality dashboard. If you have problems viewing the DQD check the notes page of this slide for a possible fix."An update was made to a default setting in Firefox version 68 that prevents local files from reading files in the same directory. This prevents DQD from loading because it cannot read nearby files such as the data to display. When clicking on DQD, the application will launch to the load screen, but it will never move past the load screen because it cannot read the "ready" flag. It is currently unclear if this will be corrected in Firefox 69. Changing the setting of privacy.file_unique_origin to "false" from about:config allowed DQD to load repeatedly with no issue."  For longer term trends you can access ZDR Shade charts semi-regularly. You can do this by going to the applications menu and pulling up the data-quality dashboard, which is the easiest way to view the site’s weighted mean ZDR bias. For a closer examination, select the 3-panel overview from the menu in the top right. That will pull up a 3-panel shade chart. Each of the plots will have 6 months worth of data displayed, with the tolerance limits of 0.2 db marked. A warm, or positive, bias might look something like this. A cold, or negative, bias may look like this. You would aim for your site to stay in tolerance, particularly over the last few months. We’ve included more detail on reading these in the resources tab. Use the dashboard to stay aware of how your site is performing. Your site will be contacted by your region if ZDR work is needed. Keep in mind, resolving ZDR bias can be challenging. It may require multiple attempts and ongoing communication with the ROC, initial attempts may make the bias worse, and there may be an underlying issue that must be resolved first. Despite challenges, we are caretakers of this national asset and want to generate the best products. That concludes the beta test training for NEXRAD Build 19. Please send any questions or feedback on this training to Justin Gibbs.