[Reddyproc-users] REddyProc 0.8.2

[Ladislav Šigut]

Dear REddyProc developers, 
thank you very much for your great work on porting this code to R and for adding further functionalities! I am running Win 10, R-3.2.4revised, REddyProc 0.8.2 and made the code run succesfully on my data. I would have some questions and comments about the R package and its comparison to online tool (OT; also 0.8.2). I hope this channel is appropriate because other users could find it interesting too. 
1) I noticed the ustar filtering is not removing halfhours when ustar is missing. I would say the conservative approach would be to remove the halfhours because they are compromised. I will solve it by removing the NEE halfhours in input file. Would you implement this as part of ustar filtering in future version of REddyProc? 
2) The original OT implemented ustar filter only for the nighttime data. Of course, oppinions might differ about this but do you also plan to include this option in future versions? This would allow better consistency with the older processing method. 
3) I find it confusing that sPlotHHFluxes() and sPlotFingerprint() show axis label in the middle of the month. I think it is more informative when it marks the start of month. 
4) EddyProc.C$sPlotDailySums() seems like it is plotting daily averages instead. OT example ( ver. 0.6.0 ) seems to have some kind of summing, although the units were not clear as I saw previous conversation on the mail list. What kind of solution do you plan here? 
5) Only a minor issue is with the custom seasonFactor specification in vignette("DEGebExample") . Centering of timestamp by 15 min shift is implemented only within EddyProc.C object, therefore DEGebExample$DateTime should be manually corrected by user. Also the seasonFactor marks the season starting from midnight, not noon. Therefore seasonStartsDate should be created by fConvertTimeToPosix(..., Hour = 0.25 ). 
6) What is the difference between isUsingCPT and isUsingCPTSeveralT in usControlUstarEst()? SeveralT takes the same (default 7) temperature classes as Moving point test? But then I would expect there would be only one ustar threshold estimate for all temperature classes when using isUsingCPT which is not the case when I check the plots from sPlotNEEVersusUStarForSeason(). Which CPT implementation is prefered? 
- It also seems it is possible to set both isUsingCPT and isUsingCPTSeveralT = TRUE 
7) Is the reference temperature really changed to 15 °C in sMRFluxPartition()? The original Tref was 10 °C in the old OT. Is there an option to change this? Could you please comment why you decided to change this? 
8) What is the significance of OT using 200 bootstraps instead of default 100? 
9) Why is the OT definition of seasons using startMonth = c(2, 5, 8, 11) instead of default startMonth = c(3, 6, 9, 12)? 
10) Could you please comment why you give preference to 'uStar' estimate (without bootstrapping) instead of 50% (median) ustar threshold (resulting from bootstrapping)? I would assume 50% (median) ustar threshold should be more robust. 
11) There is some inconsistency in annual estimate of ustar threshold using sEstUstarThresholdDistribution(). The annual estimate is usually a bit higher than any of the seasonal estimates although it should be their maximum. 
12) Plotting functions that have output to the console miss some features, e.g. colour scale for fingerprint plot and labels defining the plotted variable. Do you plan to change this in future versions? 
13) There is a mistake in function name usGetSeaonalSeasonUStarMappingFromDistributionResult() (...Seaonal...) 
Sorry for the long list but I hope it also helps you. 
Best wishes 

Ladislav Šigut, M.Sc. 
Department of Matter and Energy Fluxes 
Global Change Research Institute CAS 
Bělidla 986/4a, CZ-60300 Brno, Czech Republic 
+420 511 192 286 / +420 606 641 694 
www.czechglobe.cz 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/reddyproc-users/attachments/20160418/ac8e9265/attachment.html>