search

ARM-DOE / pyart

The Python-ARM Radar Toolkit. A data model driven interactive toolkit for working with weather radar data.
https://arm-doe.github.io/pyart/
Other
513 stars 266 forks source link

BUG: NEXRAD Level3 DPR product reading #1114

Closed jaypotnis closed 2 years ago

jaypotnis commented 2 years ago

I am doing project on Quantitative Precipitation Estimation using WSR 88D Radar. I am comparing NEXRAD L3 Digital Precipitation Rate with actual Rain Rate from TRMM GV Rain Gauges.

Looks like the data being read in the below snippet does not scale the rain rate data correctly. https://github.com/ARM-DOE/pyart/blob/a68bed26f6380eecbf1042c94bd4da0b60fb2da7/pyart/io/nexrad_level3.py#L297-L300

The way I am seeing the data, I need to multiply the whole data by 10. To convert it to the proper scale (i.e. inch/mm).

Below are some Z-RR plots at a constant height. Z is obtained from NEXRAD L2 data. Additionally I am also multiplying the Pyart read DPR data by 25.4 to convert it to mm/hr. But that is not expected by pyart as L3 DPR data is supposed to have default unit as inch/mm.

L3 DPR data after reading it through pyart and converting to mm/hr. 2015_rr_vs_z_0 5_gauge_SFL_068

L3 DPR data after reading it through pyart, multiplying by 10 and converting to mm/hr. 2015_rr_vs_z_0 5_gauge_SFL_068 (1)

I hope this explanation helped. This is not a significant issue but would still be good to avoid confusion while reading the DPR data.

Btw, thanks for creating this wonderful tool for reading L3 data. There are not a lot of tools that do that. Found it very helpful. :)

mgrover1 commented 2 years ago

Thank you @jaypotnis for pointing this out. We will look into implementing a solution to this, or you are welcome to submit a pull request (PR) with the fix if you are interested. Happy to help with this process!

dopplershift commented 2 years ago

I'm confused, why isn't it expected? In the XDR product, the unit are encoded:

Unit = inches/hour

So it seems to me that needing to multiply by 25.4 to get mm/hr is correct?

is supposed to have default unit as inch/mm.

...that's not a sensible unit for rainrate?

mgrover1 commented 2 years ago

Thanks @dopplershift !

The units pyart returns are wrong - it is supposed to inches/hour.

Also, I think I found the issue... we are assuming the data is an 8 bit integer

https://github.com/ARM-DOE/pyart/blob/main/pyart/io/nexrad_level3.py#L219

but according to the Level3 documentation, this field is a 16 bit integer

Screen Shot 2022-04-18 at 3 38 41 PM

Currently working on a PR to fix both of these issues, and add some tests...

mgrover1 commented 2 years ago

Alrighty - I tested this out on one of the TRACER cases (a field campaign coordinated by ARM), which includes disdrometers/other ground precipitation measurements.

The laser disdrometer (ld), located near the airport, measured a maximum precipitation rate of 95 mm/hr, which corresponds to 3.7 inches/hour.

Screen Shot 2022-04-18 at 4 22 43 PM

NEXRAD data shows rain rates similar, with a few values a little higher (>7 inches/hour)... here is the rain rate (DPR) field at the time closest to that peak disdrometer data (the disdrometer location is the black dot):

Screen Shot 2022-04-18 at 4 51 34 PM
mgrover1 commented 2 years ago

Keeping this open for now (until we get a confirmation this is fixed) - here is the figure from the previous method (before the merged PR)

Screen Shot 2022-04-18 at 5 01 47 PM

@dopplershift / @jaypotnis does this look like it's solved this issue?

dopplershift commented 2 years ago

It certainly looks more sensible to me. With the old code, you simply could never get bigger than 0.25 in/hr (and it looked noisy because you were only keeping the low bits).

And no prob @mgrover1, taking a look at this has led me to fix a different bug in MetPy's own support for this product.

jaypotnis commented 2 years ago

The rain rate certainly looks better now. Thanks for a quick resolution on this @mgrover1