New Use Case: Convective Triggering Potential - Humidity Index

[anewman89]

Replace italics below with details for this issue.

Describe the New Feature

This use case will compute the Convective Triggering Potential (CTP) and Humidity Index (HI). These values will be passed to MET pointstat via the python embedding capability and METplotpy (or other plotting capability) to generate scatter plots of HI versus CTP to determine the land-atmosphere coupling regime (Findel and Elthair 2003 a,b).

See this short overview of CTP-HI for more details.

Acceptance Testing

Data needs include observations and model atmospheric profiles of temperature and humidity of the lowest 300 hPa above ground during early morning local time.

Radiosonde profiles, AMDAR profiles, profiles from other sources such as satellite or microwave radiometer if deemed high enough quality by user.

Basic functionality will be python should include ability to read in some user provided profile from any source and describe our required input format, then compute CTP and HI. Model ingest should be able to read UFS output at appropriate levels, compute CTP and HI on grid. The observed and modeled CTP-HI values will be passed to MET pointstat to compute model-obs differences across both metrics. Capability should also include the ability to produce scatter plots of modeled and observed HI versus CTP.

Describe tests required for new functionality.
Test computation of CTP for example observation
Test computation of HI for example observation
Test computation of CTP for example UFS file
Test computation of HI for example UFS file
Test model-observation comparison output in MET pointStat
Test plotting capability for model and observed CTP-HI data

Time Estimate

3 days

Sub-Issues

Consider breaking the new feature down into sub-issues.

• Observed atmospheric profile format definition and ingest
• Computation of observed CTP and HI
• Computation of model CTP and HI
• Python embedding MET pointStat output
• Basic plotting capabilities

Relevant Deadlines

31 Dec 2023

Funding Source

7750034 (UAlbany-NCAR METplus JTTI)

Define the Metadata

Assignee

• Select engineer(s) or no engineer required
• Select scientist(s) or no scientist required

Labels

• Select component(s)
• Select priority
• Select requestor(s)

Projects and Milestone

• Select Repository and/or Organization level Project(s) or add alert: NEED CYCLE ASSIGNMENT label
• Select Milestone as the next official version or Future Versions

Define Related Issue(s)

Consider the impact to the other METplus components.

• METplus, MET, METdataio, METviewer, METexpress, METcalcpy, METplotpy

New Feature Checklist

See the METplus Workflow for details.

• Complete the issue definition above, including the Time Estimate and Funding source.
• Fork this repository or create a branch of develop.
  Branch name: feature_<Issue Number>_<Description>
• Complete the development and test your changes.
• Add/update log messages for easier debugging.
• Add/update unit tests.
• Add/update documentation.
• Add any new Python packages to the METplus Components Python Requirements table.
• Push local changes to GitHub.
• Submit a pull request to merge into develop.
  Pull request: feature <Issue Number> <Description>
• Define the pull request metadata, as permissions allow.
  Select: Reviewer(s) and Development issues
  Select: Repository level development cycle Project for the next official release
  Select: Milestone as the next official version
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Close this issue.

[DanielAdriaansen]

I created this graphic as a visual to help see what the CTP looks like visually. I have some questions about details like how to define the "ground" level in the sounding and what to do if specific pressure levels aren't available (nearest? interpolate?). Also not sure on the units of this, but overall pretty close to having CTP code working for a single sounding (here for 12 UTC on 20200805 at Birmingham, AL). Need to apply it to some UFS data, and decide on what sounding formats to support for obs.

[KathrynNewman]

@DanielAdriaansen - unrestricted gdas prepbufr data are staged at /glade/work/knewman/Land-Atmos/gdas_prepbufr. These are 6-hrly global upper air and surface observation files in prepbufr format from June - August 2020, covering the summer period of the gfs prototype runs. See https://rda.ucar.edu/datasets/ds337.0/# for a detailed description.

[DanielAdriaansen]

@anewman89 can you provide some clarity of the verification task? I see "CTP-HI" referred to together as one entity/diagnostic but the equations are separate for CTP and HI. Will point_stat verify CTP from obs vs. fcst, and then separately verify HI from obs vs. fcst? Or is there some way CTP-HI should be created and point_stat verifies a single diagnostic? Maybe all we are doing with point_stat is creating fcst/obs MPR values for CTP, and then separately fcst/obs MPR values for HI, so downstream the fcst/obs MPR for both can be visualized together? I think that's right but just checking in as I construct the workflow. Thanks.

[anewman89]

@DanielAdriaansen I think the last version you state is the way to go. We want a unique CTP and unique HI from point_stat and merge downstream for post-processing/plotting. Thanks!

[DanielAdriaansen]

@anewman89 Looking at the cheat-sheet for CTP, I can't quite tell whether it's physically meaningful or correct for CTP to be <0. In the CAPE world, it is possible for negative values and this is "CIN". Thus, maybe negative CTP has a physical meaning? Just double checking as I am seeing some negative CTP values when debugging and testing. If it's useful, I can pull out a graphic from an observed sounding with negative CTP just LMK.

[DanielAdriaansen]

@KathrynNewman I have not worked directly with output from PB2NC before. I was looking through some of the data, and I don't understand why the geopotential height values are not present at significant levels. Here is an example from International Falls, MN:

PROCESSING FOR SITE: 72645
72645
                hgt   var          lvl           obs
12220    184.248154   HGT  1000.000000    184.000000
12221    209.281876  SPFH   997.000000      0.001701
12222    209.281876   TMP   997.000000    266.250000
12223    209.281876   HGT   997.000000    209.000000
12224    209.281876   DPT   997.000000    262.457794
12225  -9999.000000  SPFH   990.000000      0.001494
12226  -9999.000000   TMP   990.000000    266.850006
12227  -9999.000000   DPT   990.000000    260.731201
12228  -9999.000000  SPFH   981.000000      0.001743
12229  -9999.000000   TMP   981.000000    268.649994
12230  -9999.000000   DPT   981.000000    262.561951
12231  -9999.000000  SPFH   957.000000      0.002193
12232  -9999.000000   TMP   957.000000    272.250000
12233  -9999.000000   DPT   957.000000    265.192047
12234  -9999.000000  SPFH   940.000000      0.002001
12235  -9999.000000   TMP   940.000000    271.850006
12236  -9999.000000   DPT   940.000000    263.778961
12237    803.081665  SPFH   925.000000      0.001762
12238    803.081665   TMP   925.000000    272.049988
12239    803.081665   HGT   925.000000    802.000000
12240    803.081665   DPT   925.000000    261.953156

I only see HGT (geopotential height I believe) at the 997 hPa (the surface??) and the first significant level (925 hPa), but not the levels in between. Is it safe to use the other data (TMP/DPT) despite the HGT value being missing data? Does the GDAS prepbufr data not include geopotential height from significant levels? Maybe there is a problem with the HGT data at the significant levels making it into the output? Any info you can provide would be helpful. Thanks!

[anewman89]

@DanielAdriaansen - Yep, negative CTP, or CIN is perfectly fine. I'm glad you're seeing this in your testing actually!

For the PB2NC data, I don't have a good feel for this... I would say go ahead and use the data, it seems reasonable in this case at least. Is there a QC flag in the PB2 NC output that we could use?

[DanielAdriaansen]

@anewman89 we will have to discuss how to handle situations where CTP is computed but HI is unable to be computed or vice-versa. I think this can probably be handled downstream at the MPR stage, since the way it works now there's no way to know whether either occurs in the point_stat and Python stage without actually coupling the functions and calling both each time. The primary issue I see is that CTP only requires temperature, where HI requires temperature and dewpoint. In the PREBUFR data, I've encountered some soundings where some levels have TMP but are missing DPT. While maybe not at the levels needed for HI (i.e. 950/850 hPa), in theory it could happen at those levels. I have lots more questions about the quality and utility of the PREPBUFR data but for now this is something I wanted to document here.