UPP User Release Version 4.1.0

Release Date:

The UPP User Release Version 4.1.0 was released on March 31, 2020.

Release Notes

Major Improvements and New Features include:

  • GOES 16 products
  • Fields related to HRRR-smoke (e.g. smoke tracers, visibility, etc.)
  • FV3GFS model data in netcdf formal
  • Code access via GitHub repository 

New Directory Structure & Build Dependencies:

  • Removal of several supporting NCEP libraries from the UPP package and making them a pre-install library dependency
  • Removal of copygb code to its own individual repository to be installed and used as a separate utility (https://github.com/NCAR/copygb)
  • Reorganization of the directory tree to align with EMC code
  • New dependencies required to be pre-installed prior to building UPP code
    • NCAR/NCEPlibs (https://github.com/NCAR/NCEPlibs)
      • Note that this repository is seperate from the authoritative NOAA NCEPLibs repositories; it is maintained by DTC staff and may have minor code changes from that of NOAA maintained libraries.  This is necessary to ensure continued support for current features. Work is underway to transition to the authoritative NOAA repository in effort to remove this redundancy.

** Please carefully read the new procedures on the UPP Users webpage or in the V4.1 Users’ Guide for building the software. 

Additional release notes:

  • Serial builds are no longer supported.
  • This will be the last supported version for WRF model data.
  • This will be the last supported version of GRIB1 output format.

 


Known Issues and Fixes

The run_unipost and run_unipostandgempak scripts fail for FV3GFS runs

Posted: 2020-04-03
Problem: A bug in a couple of the provided sample run scripts was found that causes an error and the script to exit with a message about input format when trying to process FV3GFS data.  Using the scripts to process WRF model data is unaffected.  Only run_unipost and run_unipostandgempak scripts were impacted.  Another bug linking an existent error was also identified and fixed, though this should not have impacted users.
Solution: Updated sample run scripts are provided here.
MET does not use the Fortran-like fixed width format in its ASCII output file. Instead, the column widths are adjusted for each run to insert at least one space between adjacent columns. The header columns of the MET output contain user-defined strings which may be of arbitrary length. For example, columns such as MODEL, OBTYPE, and DESC may be set by the user to any string value. Additionally, the amount of precision written is also configurable. The "output_precision" config file entry can be changed from its default value of 5 decimal places... up to 12 decimal places. That too would impact the column widths of the output. 
Due to these issues, it is not possible to select a reasonable fixed width for each column ahead of time. The AsciiTable class in MET does a lot of work to line up the output columns, making sure there's at least one space between them. 
If a fixed-width format is needed, the easiest option would be writing a script to post-process the MET output into the fixed-width format that is needed.
If a fixed-width format is needed, the easiest option would be writing a script to post-process the MET output into the fixed-width format that the code expects.