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

Corrected relative humidity (rh_cor) being reassigned too liberally? #109

Closed PennyHow closed 1 year ago

PennyHow commented 1 year ago

We have had an enquiry from Asiaq Greenland Survey regarding the Level 3 data from NUK_K.

There seems to be some discrepancies with relative humidity when compared to the L0 raw and Level 3 Edition 3 (IDL) processing.

Figure from Asiaq: thumbnail_image002 Green= Level 3 (Edition 3 IDL processed) data used in JoG paper DOI: 10.1017/jog.2019.4 Black=raw card data, Level 0 raw Cyan=download from the GEUS Dataverse 01 March 2023 Just disregard the red line

Our current processing seems to be (over-)liberally correcting valid rh values to 100%. I seem to remember this reassignment happening in the pypromice filtering process here, so I think it may be related to this:

https://github.com/GEUS-Glaciology-and-Climate/pypromice/blob/d17403b9759daab7b858c9c725b67405f5f5469f/src/pypromice/process/aws.py#L524-L526

PennyHow commented 1 year ago

I just checked the rh_u from NUK_K and see a discrepancy in the data shown in the original example. Editon 4 data downloaded from thredds this morning does not show this excessive 100% reassignment in the humidity processing.

Our current processing of Edition 4 rh_u_cor vs. Edition 3 RelativeHumidity(%) nuk_k_edition3_edition4_pre-fix

We thought this new fix #110 from @BaptisteVandecrux would show us a little clearer what was going on, but actually rh_u_cor appears unaffected.

This new developmental processing (ran with Fixing-RH-correction) rh_u_cor vs. Edition 3 RelativeHumidity(%) nuk_k_edition3_edition4_post-fix

PennyHow commented 1 year ago

Issue closed as it appears this is now resolved