Notes on Quality Control


No changes were needed aside from the slope-intercept values which were applied. "Dir.base.10m" had an intercept of 229.0, "Dir.far.10m" was 227.1, and "Dir.flr.10m" was 174.0.


KH2O, Kryptons

Logbook entries specifying times servicing or cleaning the sensors were removed from the data set. The krypton at the floor location was changed on Oct 11th from serial number 1101 to 1394 <>.  There was an instance of a glitch with kh2o far on Oct 17th at ~12:30 which was removed <>. On Oct 30th from 08:00 to 09:55 at the far station, there was some erratic behavior with the data that could not be quantified and so it was removed. Erratic data was also encountered at the floor location on Oct 13th between 11:50 and 12:40 which could not be explained and was therefore removed.

With the aid of the leaf wetness sensor, all rain and moisture events were removed including those on Oct 10th, 11th, 12th, 29th, and 30th. Next, the main indicator of krypton failure was the state of the sensors voltage, kh2oV. A threshold of 1.2 volts was determined as the median operating voltage for the project and used as a prompt for sensor malfunction (usually the voltage would plummet toward zero during wetness events or similar instances of sensor failure and so almost all times where the voltage was below 30% of this median voltage were flagged as suspect). The closest "H2O" sensor in proximity to each kh2o in addition to a theoretically calculated H2O with RH equal to 100% was used as a final indicator for plausibly measured kh2o values.

After completing these tasks, it was determined that the quality control should be re-approached with the intent to retain more data with a higher regard towards flux measurements rather than scalar-correct kh2o values. The near station data prior to Sep 30th at 12:00 remained removed from the dataset, and then despite a reading of 16 g/m^3, the data was retained up to 13:00 on Oct 2nd where the sensor began reading closer to the 5 g/m^3. A similar approach was taken with the kh2o data from the far station. Despite reading 20 g/m^3, data was retained from Sep 29th at 12:30 to a similar transition of Oct 2nd where data began reading closer to 5g/m^3 as well. Data from the floor station was not as easily salvaged. The earliest reading with a sensible flux measurement from the floor station wasn't until Oct 7th at 09:40 and it wasn't until Oct 16th at 08:00 after off-and-on readings that the sensor began to fully function properly.

A final run-through of the data focused on potential outliers in the 5-minute covars which in turn revealed underlying spikes in the high rate data (several for example on Oct 8th between 12:20 and 14:20); the spikes were removed while surrounding data was able to be retained in most instances.



For the most part data was correct, but there were a couple erroneous events that needed to be removed (see P.sw.flr on Oct 10th as well as P.nne.flr on Oct 10th at 05:00). Possible sources for those errors were probably moisture related but no definitive reasons were determined (see <> and <>).



No edits were made to Qsoil aside from the removal of some times during setup. Instances of wetness events were maintained within the dataset.



Instances related to servicing and cleaning the sensors as noted from the logbook were removed from the dataset. RH.25m.near prior to Oct 8th read anomalously high, so an offset of -2.9 was applied to the data to reconcile its relation with the tower profile. On Oct 14th Ifan.30m.near started acting irregularly with respect to other fan currents and so 4 days of data were removed before the sensor was finally visited for repair on Oct 18th at 13:40. Also, Ifan.20m.rim had an irregular current which eventually led to the sensor finally dying around Oct 9th (it resumed normal function on Oct 12th at 12:30 <>). That same 20m.rim sensor was replaced a couple days later on the 15th with notes from the logbook stating that the fan was running in the wrong direction <>. Even after this replacement the RH seemed high with respect to the profile and therefore an offset of -3.0 was applied to the data for the remainder of the project (from Oct 15th at 08:40 onwards) to remedy this. There were instance of “sensor lockup” noted for RH.40m.rim on Oct 10th from 02:05 to 12:30, RH.35m.rim from Oct 9th to the 12th at 12:25, which required restarting the system <>. With RH.40m.rim, there was an instance where that same sensor needed to be restarted on Oct 25th at 04:40 because an error in the system had jumbled the data from the previous night <>.



Rpile.out.far was flat lined for most of the time between Oct 7th at 08:15 to 21:00 as well as Oct 8th from 07:50 to Oct 12th 17:30. It failed again from Oct 13th 16:20 until it was replaced on Oct 15th at 10:05 <>. In addition to regular maintenance and cleaning events noted in the logbook, the major wetness events during the project were removed; those around Oct 10th, 11th, 12th, 29th, and 30th. There were some instances of spikes in the high-rate data that were removed from (for example, see Oct 3rd 07:55 to 15:50 as well as others noted in the QC files), Rpile.out.far, and Rpile.out.flr during instances that were obvious enough to distort the data as viewed from the 5-minute covars. The spikes were removed from the high-rate data such that as much surrounding data could be retained.


Shortwave Radiation

Aside from typical maintenance/cleaning visits and the main wetness events, there was only one addition to the quality control. This was for where between Oct 14th and 19th there are notes that bird droppings on the sensor may have obscured the data, and so there are several blacked out time periods between those dates.



Times where the sensors were being cleaned/serviced were removed from the data set. Ifan.25m.near died from Oct 08th 14:25 until Oct 09th 12:00, but only the first hour of that period needed to be removed. Ifan.30m.near started acting erratically between Oct 15th 03:25 and Oct 18th 16:00 and so the data was removed during that period.

Ifan.20m.rim died on Oct 9th at 08:00 and did not recover until Oct 12th at 12:17; the data during this timeperiod was removed. T.20m.rim previous to 0ct 06th 19:25 was reading outside the profile, so an offset of -0.6 was applied to the data prior to that time. There was also a sizable portion of data missing between Oct 10th at 02:05 until Oct 12th 12:15 when the sensor was replaced (see <> and <>). T.40m.rim experienced “sensor lockup” on Oct 10th from 02:05 to 12:30, and Oct 24th from 22:05 to the 25th at 04:40. T.35m.rim was also noted as having this lockup from Oct 10th at 3:45 until 15:25.



Data were monitored with respect to the profile of heights. Instances of wetness events were not removed from the data set. Also, Tsoil.5cm.far was usually more in agreement with Tsoil.3.1cm.near than Tsoil.4.4cm.near.