FAQ
Where do I get an introduction to REddyProc?
A good place to start are the vignettes provided with the R package, especially the useCase vignette. At the R command prompt type:
library(REddyproc) vignette("useCase")
Please also read
How to handle error: "Missing specified columns in dataset (#inputColumns)"
Most often, the input is not provided in correct format. Carefully reread the documentation on required input format, including case, type, and units of the columns. Also note to provide "tab-delimited or space-delimited ASCII file".
Why do I get warnings about the timestamp of the first or last row of my data? (#timestampsStartEnd)
Flux data are specified with the "end of period" timestamp convention, i.e. the time stamp of the half-hour from 00.00 to 00:30 is 00:30. You need to take care in preparing the input data.
If the first row of your dataset has time stamp "2001-01-01 00:00:00" this corresponds to the last half-hour of year 2000. This is prone to cause problems with the processing where subsets according to year have few data.
Similarly, take care that the last record in your dataset corresponds to the last hour of the day.
One can filter timestamps by year or day with subtracting 15 minutes from the "end-of-period" beforehand so that the R-function POSIXlt give correct answers for the period. E.g. as.POSIXlt(myPOSIXVar - 15*60)$year
Which output columns should I use? (#outputColumns)
REddyProc produces a multitude of outputs for different u*thresholds and different methods. The outputs are described at section Data Formates/Output format.
We recommend computing statistics across the outputs for different u* thresholds. However, its also save to use output generated using the 50% quantile of u* thesholds, e.g. NEE_U50_f. There are pros and cons for both using nighttime based and daytime based flux partitioning. For comparing to past results, the nighttime based option is probably more suitable: GPP_U50_f and Reco_U50_f.
Why does negative NEE define an net uptake of the ecosystem? (#NEEsign)
NEE was defined by meteorologists from an atmosphere perspective. Positive flux goes into the atmosphere and out the land ecosystem. Negative fluxes go into the ecosystem. GPP on the other hand is defined as a positive allocation to the ecosystem, and Ecosystem respiration is defined as a loss of carbon from the ecosystem. For mosts ecologists it helps to argue with the -NEE flux: net uptake -NEE = GPP - Reco.
Why does daytime GPP - Reco does not match -NEE? (#daytimeGPP)
With nighttime partitioning, GPP is computed by difference of NEE and modeled Reco. However, with daytime partitioning, both GPP and Reco are model predictions of two different models. Both have an prediction error, hence, they do not exactly match up to original NEE.
I obtained some negative GPP, should I remove it? (#negativeGPP)
Due to the random uncertainties in the eddy covariance measurements, the derived GPP fluxes can result in negative fluxes. This is due to the stochastic nature of turbulence and noise in the measurement signal.
With nighttime partitioning, in addition if modelled respiration is too high, GPP might become negative. If this is within the range of NEE uncertainty its normal. If its larger then the fitted respiration~temerature model was not adequate for the data. The partitioning methods only work at sites where respiration is primarily controlled by temperature. They will not work e.g. at some tropical sites, sites controlled by moisture, or at frozen soils.
In other words, though GPP cannot be negative by definition, GPP values derived from EC measurements may also contain (some small) negative values, since these are the GPP values plus their random uncertainty. Hence, the negative values are also correct and should NOT be removed when using the partitioned results. Removing the negative GPP values (e.g. by setting them to zero after processing) would introduce a bias in the derived GPP.
How can I compute uncertainty of daily or annual aggregates? (#uncertaintyAggregation)
There are several kinds of uncertainty. First, random uncertainty that decreases in relative terms by aggregating many records. Second, there is systematic uncertainty of using a biased u* threshold that does not decrease during aggregation.
For the random uncertainty, use the equations for error propagation of sums of random variables (adding variances NEE_uStar_fsd^2), but take care for autocorrelations among records (see aggUncertainty vignette).
For systematic uncertainty, repeat all the computation with different values of the distribution of the u* threshold (The default processing setup) including the aggregation for each output columns. Next, compute statistics, i.e. the mean and standard deviation) across the different estimates of the aggregates (see end of use case vignette).
Both kinds of uncertainty are independent of each other and hence, variances add. On annual time scale, often the systematic u*-threshold associated uncertainty dominates and the random uncertainty can be neglected.
Can I process hourly data? (#hourlyData)
Yes. Use DTS = 24.
Usually, the high-frequency raw measurement are processed to derive half-hourly fluxes, but at some sites aggregation across longer period can capture larger and slower eddies. Such hourly aggregated fluxes can be post-processed with REddyProc.
You can provide the number of timesteps per day when creating the REddyProc class with new (see help of ?sEddyProc_initialize) from the input data. For hourly data this is 24 hours per day.
EProc <- sEddyProc$new(mySite, myData, ..., DTS = 24)
Note, however, that several checks for plausible data in REddyProc are used experience with half-hourly data. Hence, you may get warnings or may need to adjust some of the thresholds.
I have no incoming solar radiation (Rg) - What can I do? (#noRg)
Global radiation (Rg) is incoming short wave (~0.3-3µm) radiation measured on a horizontal plane comprising direct and diffuse components.
It is used for different purposes in REddyproc. The answer depends on which purpose.
Option 1: Estimate Rg by measured PAR
This should give reasonable results for gap-filling, nighttime partitoning, and daytime partitioning Rg = PAR/0.47
References e.g. Yu 2015 et al. 10.1016/j.enconman.2014.09.038, Britton & Dodd 1976, 10.1016/0002-1571(76)90080-7
Option 2: Use Rg of a geographically not to distant site
- ok for night-time partitioning,
- probably reasonable for gap-filling unless the periods where conditions differ much between the sites, and
- do not use daytime partitioning.
Option 3: net radiation
is not an option for us, but try to convince us with your results.
How to handle error in partitioning "relationship between respiration and temperature could not be established" (#E0Error)
Night-time based flux-partitioning estimates respiration by its relationship with temperature. If there is no good relationship you cannot apply night-time partitioning (E.g. with frozen soil, snow cover, or tropical sites with no pronounced temperature differences.)
Sometimes, the relationship is there also with a low temperature variability. Then you can try tuning the the required temperature range constraint to lower than 5 Kelvin:
YourEddyClass$sMRFluxPartition( parsE0Regression = list(TempRange = 3) )
Sometimes, there are just too few good-quality night-time records to estimate the existing relationship. Then you can provide a user-specified temperature sensitivity E0 to use, and be very cautios in interpreting results:
YourEddyClass$sMRFluxPartition( debug = list(fixedE0 = <yourE0Value>) )
Note, that this is an option implemented for debugging. Hence, only use this with great caution.
You can use a value determined at another year at the same site or a value from a very similar site. Or you can specify low, medium, and high values of E0 and inspect how this effects your results.
For daytime flux partitioning you can use a fixed temperature sensitivity by
ctrl = partGLControl(fixedTempSens = data.frame(E0=<yourE0Value>,sdE0=<yourE0Uncertainty>)) EProc$sGLFluxPartitionUStarScens(controlGLPart=ctrl)
What does error message "object '.self' not found" mean? (#selfError)
The functions starting with sEddyProc_, e.g. sEddyProc_sPlotNEEVersusUStarForSeason are methods of the REddyProc Reference class.
They are not to be called directly. They are called by EProc$sPlotNEEVersusUStarForSeason(...) where EProc is the object, created before by calling new (see ?sEddyProc_initialize).
The .self within the method refers then to the EProc object and allows the method to access information stored by previous calls of EProc$<somemethod>.
More information on Reference classes is provided by ?ReferenceClasses
How to handle warning "Duplicated columns found! Please specify different suffix"? (#duplicatedColumns)
REddyProc stores information of previous processing inside the class. If this information is already there from a previous call to a similar function, it warns you that it may get confused.
Hence, if something went wrong during processing or when processing different scenarios, do not repeat call to a function, but start again from initializing the REddyProc class by EProc <- sEddyProc$new(...).
For processing several scenarios with different uStar thresholds, one can use argument uStarSuffix in sMDSGapFillAfterUstar (see halp at ?sEddyProc_sMDSGapFillAfterUstar). This is the approach taken when calling EProc$sMDSGapFillUStarScens('NEE') after EProc$sEstimateUstarScenarios(...). There will be several output columns, one for each uStar scenario, with a suffix in column name to distinguish the scenarios.
How can I specify the same color palette for different fingerprint plots (#colorpalette)
You can specify the same custom color legend by using arguments colors and valueLimits.
?sEddyProc_sPlotFingerprint
?sEddyProc_sPlotFingerprintY
EProc$sPlotFingerprintY('NEE', Year = 1998, colors = rainbow(50), valueLimits = c(-300,300))
How can I display the R help page for REddyProc class methods/functions (#methodHelp)
R help can be request by typing ?functionName at the R command prompt. However, EddyProc is an R5 class and has its functions attached to the class as so called methods.
Use prefix sEddyProc_ before the method name to display the help page. E.g. for sMRFluxPartition type
?sEddyProc_sMRFluxPartition
The help for initializing the class with the call to new is displayed by typing:
sEddyProc_initialize
Can I provide time recorded in UTC? (#timezone)
No, REddyProc requires local time (true time, i.e. without daylight savings) using timestamps without explicit time zone. This is because we do not want require users to be familiar with all the R timezone-specific routines.
The timezone is told to REddyProc separately with method sSetLocationInfo(TimeZoneHour=offset, ...). R Users working with timezone-aware timestamps usually know how to convert timestamp data to timezone "Etc/GMT+offset" and feed this data to REddyProc.