chengsiliu
commented
4 months ago I agree with the proposed code change.
I'd like to highlight a practical aspect concerning the direct assimilation of negative dBZ values using variational techniques. We've observed that including a significant number of negative dBZ values tends to slow down the convergence of the cost function significantly. Adjusting from 10 dBZ to -20 dBZ, compared to adjusting from 30 dBZ to 0 dBZ, results in a relatively minor change in the mixing ratio. Yet, it occupies a similar portion of the cost function adjustment effort. To ensure faster convergence and efficient iteration, we typically treat negative dBZ (except for missing value) values as zero dBZ in our preprocessing procedures in practice. This approach may compromise accuracy slightly, but it significantly enhances efficiency.
gthompsnJCSDA
fabiolrdiniz
BenjaminRuston
PatNichols
Description
The MRMS converter was chopping off data with reflectivity less than -25 dBZ. Instead, we can capture the special values of -99 as valid data areas at below detectable signal limits. That leaves only the other missing value of -999 in areas that are not covered by the radar composite - either terrain blocked or geometry of radar scans. This Bugfix now allows users to include or exclude based on the lower limit of reflectivity (variable called
min_dbzcan be set using the--skipcommand line option during data conversion). By default it is set to -35 dBZ and the special value of -99 is changed to be -34.5 for keeping those points for the output file. In practice, it appears there is never echo in the MRMS product below -30 dBZ so the special value keeps data in a tighter range than -99.Issue(s) addressed
Resolves #1474
Dependencies
Should be no dependencies
Impact
Should be no impact to other repos.
Checklist