version 0.5-4 ggof vs gof Metrics

[consumere]

Dear Mr. Zambrano-Bigiarini, i recently updated to hydroGOF version 0.5-4 and realized that the KGE,NSE... results of hydroGOF::gof hydroGOF::ggof are not the same.

This is also true while running the example from ggof {hydroGOF}. This wasnt the case in previous package versions. Best

[LuisCSerrano]

Hi Mr. Zambrano-Bigiarini,

I found the same issue but I would like to add that there are some issues with hydroGOF::R2 and hydroGOF::br2.

R2 Calculating r2 r2 <- (cor(sim1, obs, method="pearson"))^2 # r2=1 R2(sim1, obs)# R2=-13.36 ggof(sim1, obs)# R2=-0.16 gof(sim1, obs)# R2=-13.36

bR2 Calculating br2 br2(sim1, obs) # br2=-4.923445 and should be 0.3684211 according to the example 1 ggof(sim1, obs)# R2=-0.16 gof(sim1, obs)#-4.92

Cheers,

[seyounger]

I am experiencing the same. I tried the previous version and the issue starts with version 'v0.5-0'. For now I'm going back to v0.4, which works.

[hzambran]

Hi,

In the NEWS file of the new version 0.5-3, it is mentioned a change in R2 and br2:

• 'br2' : R2 is now correctly computed as 1 - SSres/SStot. Before it was computed as rPearson^2, which was only correct for linear models. Thanks to eugenioLR (https://github.com/hzambran/hydroGOF/issues/16#issue-1736556320)

Therefore, the reported change is expected.

[seyounger]

Hi,

In the NEWS file of the new version 0.5-3, it is mentioned a change in R2 and br2:

* 'br2'     : R2 is now correctly computed as 1 - SSres/SStot. Before it was computed as rPearson^2, which was only correct for linear models. Thanks to eugenioLR ([The R2 metric only works for linear models #16 (comment)](https://github.com/hzambran/hydroGOF/issues/16#issue-1736556320))

Therefore, the reported change is expected.

That is separate from the main issue, which is that the outputs of hydroGOF::gof and hydroGOF::ggof are not the same. The outputs of hydroGOF::ggof are erroneous for NSE for example (and others) as they are sometimes greater than 1.

[hzambran]

Thanks @seyounger for the clarification.

I tried the following code:

data(EgaEnEstellaQts)
obs <- EgaEnEstellaQts

# Generating a simulated daily time series, initially equal to the observed series
sim <- obs 

# Getting the numeric goodness of fit for the "best" (unattainable) case
gof(sim=sim, obs=obs)

and I didn't get any unexpected value.

Could you provide a minimum reproducible example to look into the issue?

[consumere]

require(hydroGOF) data(EgaEnEstellaQts) obs <- EgaEnEstellaQts sim <- obs sim[1:2000] <- obs[1:2000] + rnorm(2000, mean=10) gof(sim=sim, obs=obs) ggof(sim=sim, obs=obs)

The listed GOFs inside the plot are wrong....

[seyounger]

Here is an example with data

library(hydroGOF)
ggofs <- c("RMSE", "PBIAS", "NSE", "mNSE", "rNSE", "KGE", "R2")
library(readr)

data <- read_csv('https://raw.githubusercontent.com/seyounger/example_data/master/hydroGOF_example.csv')

ggof(dates = data$date, data$sim, data$obs,
     ftype = 'dm', FUN = 'mean',
     gofs = ggofs,
     pch = NA, lty = c(1, 1), lwd = c(0.75, 0.75))

paste('NSE = ', NSE(data$sim, data$obs))
paste('KGE =', KGE(data$sim, data$obs))

[1] "NSE = 0.651" [1] "KGE = 0.808"

sessionInfo()

R version 4.3.3 (2024-02-29 ucrt) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 19045)

Matrix products: default

locale: [1] LC_COLLATE=English_United States.utf8 LC_CTYPE=English_United States.utf8 LC_MONETARY=English_United States.utf8 [4] LC_NUMERIC=C LC_TIME=English_United States.utf8

time zone: America/New_York tzcode source: internal

attached base packages: [1] stats graphics grDevices utils datasets methods base

other attached packages: [1] hydroGOF_0.5-4 zoo_1.8-12

loaded via a namespace (and not attached): [1] digest_0.6.35 xts_0.13.2 fastmap_1.1.1 xfun_0.42 lattice_0.22-5 e1071_1.7-14
[7] KernSmooth_2.23-22 knitr_1.45 htmltools_0.5.7 rmarkdown_2.26 classInt_0.4-10 cli_3.6.2
[13] grid_4.3.3 proxy_0.4-27 class_7.3-22 compiler_4.3.3 rstudioapi_0.15.0 tools_4.3.3
[19] evaluate_0.23 hydroTSM_0.7-0 yaml_2.3.8 rlang_1.1.3

[hzambran]

Thank you very much @seyounger for your detailed example.

The issue was raised by the several new GoFs included in the newest CRAN version 0.5-3.

The new version 0.5-8 (only in github yet) has solved this issue. Please test it and report any problem.

[seyounger]

Thanks, @hzambran Version 0.5-8 solves the issue of discrepancies between gof and ggof.