When I try to use RunModel_CemaNeige alone (without GR models) at the hourly time step, the following error appear:
UH1' must be numeric of length 480 (20 * 24)
The error appear because in CreateIniStates, the following condition if ("CemaNeige" %in% ObjectClass & ! "GR" %in% ObjectClass)
leads to a UH1
set to rep(Inf, UH1n)
instead of rep(Inf, UH1n*k)
. This error appear also with UH2
. Note that the k
value is defined later in the script as:
if ("hourly" %in% ObjectClass) {
k <- 24
} else {
k <- 1
}
I suggest therefore to move this part at the beginning of the function CreateIniStates and after that to define everywhere UH1 and UH2 as rep(Inf, UH1n*k).
PS: The examples with CemaNeige at the hourly time step can't be run, the U2345030 catchment is not included in the package (and we can't use another catchment included in the package because they either have temperature data or hourly data, but never both).
I have some issues with the use of epsilon in CreateInputsCrit.
The RDocumentation says: (optional) [numeric (atomic or list)] small value to add to all observations and simulations when "log" or "inv" transformations are used [same unit as Obs]. See details
However when we go to the details the epsilon value have an effect on every transformation except for "boxcox".
It's a bit contradictory...
In addition, only "log" and "inv" transformations are checked for the warning "zeroes detected in Obs: the corresponding time-steps will be excluded by the 'ErrorCrit*' functions as the epsilon argument was set to NULL". We should expand this warning to any power function < 0 (ex: transfo = -0.5).
I also checked, indeed it works well!
Thank you for this first version, I ran the examples and it seems to work !
However I have some questions on the "CreateInputsCrit_DeLavenne". Indeed, I thought this criterion was designed for calibration of the Intermediary Contributing Area (ICA) and when I check the example it looks like a validation of any catchment. However, the vignette is more explicit and gives a good understanding of the use of this criterion. Then, I was wondering if, when we have several upstream subcatchment, the choice of a priori parameters (according to their contribution to the flow at the outlet) is already implemented or not ? Finally, I tried to use the regularisation on one of my catchment (semi-distributed with 1 upstream, and 1 intermediary) but I'm working with hourly data with GR5H and I have an error when I'm doing :
InputsCrit <- CreateInputsCrit_DeLavenne(FUN_CRIT = ErrorCrit_KGE, InputsModel = InputsModel,
RunOptions = RunOptions_Cal, Obs = tmp$Qmm[Ind_Run_Cal],
VarObs = "Q",
AprParamR = Qamont[[1]]Calib
ParamFinalR,
AprCrit = Qamont[[1]]Calib
CritFinal)
Error in FUN_GR(ParamIn[, 2:NParam], Direction) : the GR5H model requires 5 parameters
Qamont[[1]]Calib
ParamFinalR
[1] 219.331 -0.179 289.823 5.906 0.189