CSU-Radarmet / CSU_RadarTools

A module of independent functions to do precipitation retrievals from polarimetric radar data
GNU General Public License v2.0
88 stars 43 forks source link

Add CSU HCA functionality to CSU_RadarTools. #65

Closed bdolan44 closed 3 years ago

bdolan44 commented 3 years ago
  1. I tried to cut down on the number of “extra” function files, but I didn’t want to merge the melting layer detection with the fuzzy logic scoring of the winter categories, so we are left with csu_fhc_winter, csu_melt, and csu_fhc_ml1. There is also csu_t_traps for the trapezoidal functions.

  2. I made the architecture so you call either “csu_fhc.run_winter” or “csu_fhc.csu_fhc_summer” In order to streamline the two algorithms, I changed what is returned from the old HID. Remember how you have to take the argmax in order to get the HID numbers? I now just return the actual HID number (basically added that line to csu_fhc.py), unless you set the return_scores flag. This is the way that the winter HCA setup (this is because the scoring of the winter HCA isn’t as easy as taking the argmax of an array). However this changes things for anyone who ran the HID before. Someone who downloads this new version would either need to set the return_scores flag or delete the line in their code that takes argmax.

The trapezoidal functionality is a flag you can pass (use_trap) when calling the summer HID, and in that case you can change the scoring to ‘linear’ rather than ‘hybrid’. The nice thing about this is reflectivity and temperature are weighted less so the polarimetric variables “shine” more.

  1. I put together some “easy” example notebooks for running all of these on radial and gridded data. I was testing on OLYMPEX data, so I also included those files in the notebooks directory as zipped files. This also means there are additional dependencies needed to run those including netCDF4 and SkewT. I think they are nice examples and that way people can run it themselves (and possibly from GitHub), but it makes the repository large and more complicated.
tjlang commented 3 years ago

I was able to install and run OK. The notebooks were very helpful and ran OK, with one issue: the skewPy import. I am not familiar with that package. I had to use https://github.com/tjlang/SkewT instead (from skewt import SkewT) and change sounding[key] to sounding.soundingdata[key] to get the correct info out of the sounding.

Apart from the notebooks, I ran the case on a mixed-phase storm from IMPACTS: 5 Feb 2020. The NEXRAD mosaic from ~2100 UTC is below:

image

You can see pretty obvious snow-to-rain transition from north to south. The KILX radar is right in the middle of all that, here's the base reflectivity around 2100 UTC:

image

Running the algorithm on KILX around 2100 UTC, with the 00 UTC 6 Feb ILX sounding, I get the following winter HCA:

image

There is a warning spit out during the processing:

image

Note sure what to make of that. Overall the algorithm seems to sense the N-S transition, but overall the azimuthal split doesn't seem quite right. I think in terms of just software, this PR is good to merge with some updates to the notebooks to make them more usable out of the box (no major crashes, etc.).

However, I'd like to get your input on this retrieval for the IMPACTS case. What controls the azimuthal limits we are seeing here?

tjlang commented 3 years ago

Hell with it, merging. :)