Low uncertainty

[bgctw]

• provide function filterLongRuns for filtering long runs of equal values, to be applied before class construction
• check for long runs during gapfilling
• abort day-time partitioning with too many cases of zero NEE uncertainty (sdNEE)

closes #21

[lsigut]

I am missing some background here. It is hard for me to understand what you consider as "run" and thus at which level would you implement the function. But I do not think I would have much to comment on. The only thing is the support of hourly/half-hourly data. You are testing against threshold of 24 records which you consider half of the day. In hourly data that would be 12 records. Maybe if you used mean(diff(x$timestamp)) you could get the actual time resolution of measurements and accomodate the threshold accordingly.

[bgctw]

A run is sequence of records that are numerically equal. E.g. a run of zeros of length 34 would be a zero followed by 33 additional zeros within a sequence of values. I explained this now better in the docu of filterLongRuns.

Thanks Ladislav for hinting to the varying time step. I changed the default runLength in test during gaprilling to minNWarnRunLength = <nHours>*.self$sINFO$DTS/24, where DTS is daily timesteps.

In the basic functions to replace values in runs, still the user has to specify a reasonable length. This is because at this level there is no notion of time spacing yet. For NEE i think 4 hours is a good choice. Temperature and VPD can, depending on the resolution of the measurement values, stay for some longer time at constant values.