search

GEUS-Glaciology-and-Climate / pypromice

Process AWS data from L0 (raw logger) through Lx (end user)
https://pypromice.readthedocs.io
GNU General Public License v2.0
14 stars 4 forks source link

RH_cor OOL is clipped, not NaN'd #23

Closed mankoff closed 1 year ago

mankoff commented 4 years ago

https://github.com/GEUS-PROMICE/PROMICE-AWS-processing/blob/a1508a6b06dc1ce749b0fa95c43a7879cb0993f1/IDL/AWSdataprocessing_v3.pro#L588-L603

All OOL flagging in the IDL code sets the variable (and secondary variable) to -999, except RH_cor is treated differently.

 if total(RHcor_bad) ne -1 then RH_cor[RHcor_bad] = 100

RH_cor is clipped to 100 rather than set to -999. Just checking that this special treatment should remain in the new code.

Dirk-van-As commented 4 years ago

Just above it RH_cor is set to -999 where RH_bad. So invalid RH_cor values are already taken out based on temperature and whatever. But from the corrected RH I expect them not to exceed saturation values (100%) because the sensor is incapable of measuring those. If RH_cor > 100: wrong. Although this procedure only eliminates saturation values that randomly are too high, not those that are too low.

Dirk-van-As commented 4 years ago

RH should perhaps be called RH_wrt_water. RH_cor is trickier: RH_wrt_water&ice? Better just keep RH_cor.

PennyHow commented 1 year ago

This is the current implementation in pypromice:

https://github.com/GEUS-Glaciology-and-Climate/pypromice/blob/2331c02e1e121648c06dd054d370f0b99a6a8f6d/src/pypromice/aws.py#L410-L416

So values above 100 are clipped to 100, and values below 0 are clipped to 0. Then invalid corrections are masked out using the original RH values (this is a bug fix).

We call these rh_u_cor and rh_l_cor, as suggested.