Coder Social home page Coder Social logo

climdex.pcic's People

Contributors

bronaugh avatar corviday avatar jameshiebert avatar romainfrancois avatar rposselt avatar tylere avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

climdex.pcic's Issues

Climdex excludes last date of timeseries if not recorded at midnight

Hi folks,

When the input data have a timeseries that records observations at a time other than midnight, the last day of the timeseries is excluded from the climdex calculations. This happens in the climdexInput.* functions during the checks for timeseries presence; when get.last.monthday.of.year() gets the last present month-day in the timeseries it doesn't check for a corersponding time for the observation, and thus the effective time of that obs is midnight, the default value for date creation. Then, when you build date.series out of new.date.range and return the resulting climdex object, you get a timeseries that will exclude the last date when compared against the original data passed in from the tmax.dates, tmin.dates, or prec.dates.

dvals <- 0:364
bad_origin <- as.PCICt("1950-01-01 12:00:00", cal='365_day')
good_origin <- as.PCICt("1950-01-01 00:00:00", cal='365_day')

bad_dates <- bad_origin + (dvals * 86400)
good_dates <- good_origin + (dvals * 86400)

tx_vals <- c(-13.2264,-21.9066,-23.5033,-18.5307,-20.3314,-17.0860,-11.3756, -9.9083,-16.4480,-20.8689,-19.8821,-20.6430,-25.4341,-23.0985,-24.5649,-25.1936,-30.8322,-30.9141,-22.9431,-19.5981,-18.3166,-18.6143,-15.2141,-12.4404, -9.2612, -2.3836, -6.3939,-13.2837,-19.5425,-20.8688,-11.6357,-11.5852,-20.1436,-14.9506, -9.0480, -3.9262, -4.5282, -4.0509, -5.0221,-17.5509,-10.6378, -1.1876,-10.9321,-17.5218,-21.8704,-16.3821, -6.6366, -1.6671,  0.7595, -1.6152, -4.1655,-12.6717, -6.2720, -0.1628, -1.9122, -7.8311,-10.3809,-17.0585,-16.9257,-17.2465,-19.3295,-20.5165,-16.1532,-15.2424,-13.4426, -6.9774, -3.8728, -3.3317, -5.0462, -5.7957,-10.3581, -3.9735, -4.0325, -2.5948,  0.0527, -0.9765, -7.1494, -7.2262, -6.0090, -0.7502,  0.0329, -0.3068, -1.9092, -3.4711, -5.5933, -3.8504, -1.9808, -3.1178, -1.4956,  0.3871,  1.3040,  2.0782,  3.5615,  4.6416,  5.3785,  3.3277,  0.9613,  0.4652,  4.6457,  5.7247,  2.6408,  6.0294,  4.1356,  6.7348,  7.2484,  9.2355, 10.9016, 11.0097, 14.4750, 11.1746, -0.3785,  2.2083,  1.6172,  1.8711,  0.7203,  0.3579,  4.3855,  4.8626,  3.5513,  0.8733,  3.5147,  5.1806,  7.8817, 10.1947,  8.9178,  8.0417,  5.2500,  9.6710, 13.2337, 12.1818, 13.7958, 12.3425, 10.0217,  8.0065, 10.4575, 17.9395, 20.2073, 17.4538, 10.9713,  7.0088, 12.4727, 14.6087, 15.7057, 15.4002, 13.4274,  7.1753,  8.1142, 11.2934,  9.7822,  6.0289,  6.5265,  8.3596, 11.3997, 12.7346, 14.8430, 17.3144, 20.2174, 24.3375, 21.4928, 24.4396, 27.3378, 27.8392, 28.9833, 29.6897, 28.7159, 27.3353, 26.6471, 24.8466, 13.5965, 17.8687, 20.5753, 21.6617, 22.9480, 21.2123, 12.1544, 12.8316, 17.2741, 16.7999, 14.0017, 10.3469, 12.9102, 16.5582, 24.8777, 24.0519, 18.1378, 13.6339, 17.3246, 21.6421, 20.0001, 23.2039, 24.7799, 24.1712, 22.9126, 24.9325, 18.7071, 15.8320, 14.8004, 14.5217, 15.9027, 15.6273, 15.5377, 15.9363, 19.5688, 21.3377, 21.6562, 22.1099, 20.6815, 17.9167, 20.7020, 23.3151, 24.3984, 24.1073, 24.0583, 27.0810, 27.4463, 26.5555, 28.1498, 25.7686, 24.0041, 22.8128, 28.3679, 26.3796, 21.3111, 20.4708, 21.6742, 23.6510, 27.3115, 26.4073, 19.4582, 18.2295, 16.4445, 12.9655, 14.2412, 13.2205, 10.8842, 11.3202, 15.3772, 20.4002, 19.9495, 17.9794, 11.3816, 16.7198, 13.6700, 10.1560, 10.8999, 16.9979, 16.0137, 15.6911, 13.4684, 10.7050,  7.6629, 10.9237, 10.6365, 12.6482, 12.9109, 15.1210, 19.3038, 23.7522, 20.8716,  5.4969, 11.0693, 17.2961, 17.7506, 13.8554, 11.4969, 10.0743, 12.6688, 11.3720, 11.3969, 11.4339, 15.6554, 13.0771, 12.1788, 14.0207, 12.7640, 13.8946, 13.2681, 16.6384, 14.0275,  8.3640,  8.1767,  5.7048,  5.0823,  3.3285,  2.2377,  1.6497,  3.4320,  4.0160,  2.1556,  2.7022,  8.2064,  8.0891,  4.6675,  2.6251,  3.3145,  1.4476,  2.2165,  8.4356,  6.3633,  6.6286,  5.1590,  2.4342,  6.2242,  7.2180,  3.2244,  8.6773,  8.4218, 12.1111,  6.2167, -0.1805,  0.9938,  3.2967,  2.3852,  3.0964,  1.5071,  1.9203,  0.0832,  1.2409,  0.6768, -1.5301,  0.1672,  0.3671,  0.0035, -2.5390, -3.8010, -7.7359, -8.7969, -8.6596, -8.7958, -5.7739, -7.5598, -2.0814, -0.4828, -1.5534, -4.5269, -1.0193,  0.0581, -0.2959, -1.7161, -3.8526, -6.1638, -8.3235, -8.1882, -7.9895, -8.0109, -1.0751, -0.1078, -5.3024, -7.7940, -0.1877,-13.9689,-16.5386,-17.5747,-17.5375,-17.3951, -8.3610, -2.2299, -3.9048, -7.6121,-12.3502,-16.2987,-15.3880,-11.8617, -9.5922, -9.5582)
tn_vals <- c(-24.264,-25.161,-30.020,-24.553,-26.736,-28.066,-17.799,-15.966,-30.314,-30.612,-28.739,-26.562,-37.448,-30.395,-31.620,-30.653,-35.657,-35.082,-32.402,-23.225,-20.541,-27.137,-27.581,-20.363,-15.370, -9.047,-13.098,-19.483,-22.105,-24.535,-27.405,-20.412,-27.665,-34.875,-27.809,-12.074,-12.030, -7.687,-18.598,-22.058,-18.032,-14.325,-16.772,-27.289,-30.027,-30.695,-17.485, -6.638, -4.012, -4.338,-16.817,-25.702,-16.411, -6.457, -8.390,-15.019,-16.730,-21.678,-24.381,-20.268,-23.672,-28.120,-23.253,-22.962,-23.472,-20.819,-10.142,-12.744, -7.536,-13.061,-16.410,-14.538,-16.495,-17.597, -5.977, -6.942,-14.291,-13.384,-10.678, -9.944, -3.868, -4.291, -5.883,-10.807,-13.865,-10.203,-10.232, -8.353, -7.072, -6.741, -9.732, -5.083, -0.242,  0.531, -2.125, -1.438, -5.484,-10.846,-10.056, -6.406, -2.230, -6.000, -2.812, -8.739,  0.877, -0.931,  1.803, -3.508,  4.296, -0.686, -4.525, -5.401, -5.391, -8.625, -3.297, -6.553,-11.815, -0.078, -6.376, -5.001, -8.953, -3.775,  1.914, -5.867,  1.282, -0.075, -3.043, -7.725,  1.541,  4.509,  8.000,  3.514,  1.337, -1.446,  3.135,  5.772,  7.247, 10.747, -2.825, -4.904,  2.247,  2.591,  7.666, 12.469,  6.981,  2.159,  2.466, -1.328,  5.207,  0.230,  2.212,  3.074,  2.485,  4.591, -1.812, -1.207,  6.503,  7.902,  9.697,  6.335, 10.121, 12.821, 14.205, 16.451, 17.426, 18.129, 19.003,  7.790,  5.558,  4.897,  2.913, 11.097, 13.621, 11.653,  6.073,  3.621,  2.826,  3.691,  6.858,  6.355,  7.218,  4.035, 11.037, 16.426,  7.379,  7.798,  2.152,  9.713, 10.067,  7.850, 10.742, 14.934, 14.416, 17.109, 11.281,  7.965,  7.159,  5.877,  1.350,  9.441,  7.007,  1.920,  5.709,  9.268, 11.592, 14.743, 10.889,  7.756,  4.651, 11.616, 12.758, 14.548, 13.868, 14.439, 17.980, 19.241, 18.980, 16.637, 16.026, 13.653, 19.450, 15.628, 14.094, 14.203, 15.334, 13.058, 14.648, 19.828, 13.273, 10.660, 10.535,  7.515,  7.523,  7.526,  7.463,  6.877, -0.816,  9.064, 14.790,  8.635,  7.629,  9.563,  9.232,  6.799,  6.896,  6.021, 12.297,  9.322,  6.519,  5.212,  5.473,  5.468, -0.373,  2.856,  9.219,  6.962,  9.938, 14.598,  5.644,  4.245,  4.071,  7.678,  8.183,  9.810,  7.294,  3.216, -4.113, -0.795,  6.054,  0.734,  5.371,  9.599,  5.164,  6.223,  8.716, 12.542,  9.827,  1.811,  5.846,  2.086,  5.630,  2.856,  2.663,  0.829, -1.712, -2.546, -5.369, -1.831, -1.569, -4.802, -4.927,  2.679,  2.748, -0.211, -1.146, -0.837,  0.201,  1.203,  3.502,  0.187,  0.232, -3.500, -0.372,  3.960, -1.986, -0.045,  3.505,  6.295, -1.323, -2.926, -3.828, -3.064, -2.467, -0.378, -2.986, -0.525, -2.876, -0.901, -2.178, -2.645, -1.914, -0.202, -2.947, -3.679, -9.595,-10.195,-11.960,-14.866,-18.468, -8.816,-12.269,-10.679, -3.926, -6.620, -7.220, -4.436, -1.628, -1.672, -4.117, -6.029, -9.123,-13.035, -9.858,-12.132,-12.083, -8.288, -4.984, -8.942,-14.480,-15.078,-17.932,-21.336,-22.250,-21.339,-27.962,-20.281, -7.984, -9.580,-12.259,-19.965,-26.692,-29.682,-22.617,-13.118,-13.650)

bad_ci <- climdexInput.raw(tmax=tx_vals,
                                tmin=tn_vals,
                                prec=NULL,
                                tmax.dates = bad_dates,
                                tmin.dates = bad_dates,
                                prec.dates=NULL,
                                base.range = c(1950, 1950),
                                n = 5,
                                northern.hemisphere = T,
                                tavg = NULL, quantiles=NULL)

good_ci <- climdexInput.raw(tmax=tx_vals,
                                 tmin=tn_vals,
                                 prec=NULL,
                                 tmax.dates = good_dates,
                                 tmin.dates =good_dates,
                                 prec.dates=NULL,
                                 base.range = c(1950, 1950),
                                 n = 5,
                                 northern.hemisphere = T,
                                 tavg = NULL, quantiles=NULL)

bad_ci@data$tmin[360:365]

-19.965 -26.692 -29.682 -22.617 -13.118      NA

good_ci@data$tmin[360:365]

-19.965 -26.692 -29.682 -22.617 -13.118 -13.650

This technically occurs for all calculations, but it's most likely to register a difference in calculation for tnn (at least in the northern hemisphere).

Quantiles error

Hi to everyone. I know that was a topics for the same issue in 2015 but, using the lastest version of 1.1.9.1 i receive a similar error:

clix.hist <- climdexInput.raw(tmax.hist, tmin.hist, prec.hist, tmax.dates, tmin.dates, prec.dates, base.range=c(1981, 2010))

Error in validObject(.Object) :
invalid class "climdexInput" object: 1: Quantiles for tmax are missing.
invalid class "climdexInput" object: 2: Quantiles for tmin are missing.
invalid class "climdexInput" object: 3: Quantiles for prec are missing.

---------- where :

  • tmax.hist, tmin.hist, prec.hist are vectors with TMAX, TMIN and Precipitation data, meanwhile the *.dates contains the vectors with dates.

What can i do, where i'm wrong ?

Thanks in advance

Declare (or replace) C++11 functions

From Professor Brian D. Ripley:

[climdex.pcic] use[s] functions/macros which are not part of C++98: see the logs
at http://www.stats.ox.ac.uk/pub/bdr/C++Solaris .

Functions

 erf expm1 floorf fmin fminf fmax lgamma lround loglp round snprintf
 strcasecmp trunc

were introduced in C99 and so are part of C++11 but not C++98 and the
Solaris C++ compiler does not provide prototypes for them: unfortunately
g++ does not warn of this. (R is currently including from R.h legacy
headers such as math.h to work around this, but that will be changed
for R 3.4.0.)

R's Rmath.h provides fmax2 fmin2 fround ftrunc gammafn : please use
them as appropriate. Also, erf can be replaced by a call to R's pnorm (the
translation is in the R help file for pnorm).

C++98's floor has a method for floats, so floorf is not needed in C++ .

Constants M_LN2 (gmp), M_SQRT2 (mixAK) and M_PI4 (simLife) are not
C++98. You can get them by including Rmath.h (or copy them from there).

For wtcrsk, isnan is not C++98, but R provides ISNAN for use in C++.

For SSN, strdup is a GNU/POSIX extension to C and not in any C++
standard hence not declared in according to the standard.
Substitutes are widely available: we suggest you use one.

For the rest, the best solution would seem to be to declare that C++11
is used: see 'Writing R Extensions'.

`nday.consec.prec.max()` fails for even `ndays`

From @heroldn

The nday.consec.prec.max() function seems to only handle odd numbers for the parameter ndays. When I try even numbers I get an error "arguments must have same length". Looking at the function I can only imagine it's talking about the last return line which uses tapply.fast. Perhaps the padded data in new.series are a different length to date.factor, but then I can't imagine why it would only complain on even numbers.

Quantiles

This is more of a recommendation. Currently, it seems that percentiles for tavg are not computed by default in climdex.raw. This becomes a problem when wanting to save calculated percentiles for use in later calculations as the software requires percentiles for ALL variables to be provided (see check.quantile.validity function).

So one could either remove the requirement of having percentiles for all variables or calculate percentiles for tavg.

Cheers

Nick.

Inbase calculations occur for insufficient data in percent.days.op.threshold

Hi guys, when there is insufficient base period data (as determined by min.base.data.fraction.present when creating the climdex object) no values should be returned for any month/year of a percentile index. However, I find in such cases that months/years inside the base period that do have data still get values reported back. Specifically by the function percent.days.op.threshold.
e.g. I'm calculating tx90p and base period is 1971-1990 but only 1971 has data and I set min.base.data.fraction.present=0.5, so I expect no calculations to be made for any year. But I'm finding I'll still get a non-NA value for 1971 (a zero). So the treatment of the mask inside the base period isn't quite right. Basically what I think is happening is that sum(c(NA,NA),na.rm=TRUE) equals zero when we want it to equal NA in the case where ALL values are NA.

The following replacement in percent.days.op.threshold seems to fix it.
dat[inset] <- rowSums(f.result, na.rm=TRUE) / (byrs - 1)

replaced by

dat[inset] <- apply(f.result,1,function(x) if (all(is.na(x))) x[NA_integer_] else sum(x, na.rm = TRUE) / (byrs - 1))

Write better docs for the behaviour of `max.missing.days` thresholds

The max.missing.days parameter is a named vector ('monthly', 'annual') which controls how many missing values in a timeseries will invalidate a time range. The docs don't make it clear that invalidating a month will also invalidate the whole year for annual indices. Fix this in the docs.

R CMD Check Warning - Use inherits() or is() Instead of class()

Running R CMD Check on the package produces the following warning:
Found if() conditions comparing class() to string: File ‘climdex.pcic/R/climdex.r’: if (class(quantiles) != "list") ... Use inherits() (or maybe is()) instead.

Suggested solution:
if(!inherits(quantiles, "list"))

c_quantile may use the wrong formula for nppm

I'm working on a similar libraries in python (Icclim/Xclim) and I'm currently on the computation of percentiles.
I noticed you rewrote the 8th method of Hyndman&Fan from R but I found an unusual -1 in your formula so I wanted to notice you.
In zhang_running_quantile.cc::c_quantile method.
you compute the virtual index of the percentile with const double nppm = a + quantile * (n + 1 - a - b) - 1;
Because a and b are always 1/3 in this case this can be simplified:

nppm = 1/3 + quantile * (n + 1 - 1/3 - 1/3) - 1;
nppm = quantile * (n + 1/3) - 2/3;

This is quite different from the other implementation I came across (Scipy, R and Icclim in it's current state).
When developed, they all came down to:

nppm = quantile * (n + 1/3) + 1/3

If this behavior is not intended, I would suggest to simply remove the -1 in the formula.

For reference you can find theses implementations there:
Scipy
R
Icclim

Compute tn10p and tx10p with custom threshold

I wish to change the threshold of tx10p and tn10p to 5%. I tried to edit(climdex.tn10p) in RStudio, changed the code to "ci@quantiles$tmin$outbase$q05, ci@quantiles$tmin$inbase$q05",but it did not work after running. What should I do? Thanks for your help.

Has the problem caused by poorer precision in the original daily temperature data been solved

Recently, I read a paper titled "The influences of data precision on the calculation of temperature percentile indices" (Zhang et al.2009). The paper showed that when the data precision is insufficient, it will affects the estimation of means and trends of percentile-based indices. And, in this paper, it claimed that "... we have updated RClimDex to eliminate the problem caused by poorer precision in the original daily temperature data" (Page 6). I want to konw if this problem has been solved in the R package climdex.pcic ?
Thank you.

Monthly frequency for precipitation indices?

Thanks for this awesome package, it is really useful.

From the 27 indices, there are 16 for temperature and 11 for precipitation. Currently, for the precipitation ones, only Rx1day and Rx5day can be calculated on a monthly basis.

Would it be possible to calculate some of other precip indices (for instance, PRCPTOT and CWD) on a monthly frequency as well?

Thanks in advance,
T.

`climdexInput.csv()` fails to use fully formatted date columns

The get.date.field() utility function used by climdexInput.csv() is supposed to take a set of date component columns, paste them together and then use the pasted dates to construct the climdexInput object.

However, there is a bug here https://github.com/pacificclimate/climdex.pcic/blob/master/R/climdex.r#L204 where if there is only one date field (e.g. a field that contains the full date in %Y-%m-%d format), R downgrades the return object to a vector and then do.call() fails.

The solution is simply to add the drop=FALSE argument to the indexing as such:

date.strings <- do.call(paste, input.data[,date.type$fields,drop=FALSE])

Remove dependency on caTools

From Kurt Hornik, with respect to caTools:

We have repeatedly asked for an update fixing the check problems
shown on
https://cran.r-project.org/web/checks/check_results_caTools.html
with no reply from the maintainer thus far.

Thus, package caTools is now scheduled for archival on 2018-07-19, and
archiving this will necessitate also archiving its strong reverse
dependencies.

Please negotiate the necessary actions.

I believe that the only thing we use caTools for is to calculate a moving average. This isn't that hard to do ourselves, and there may be other packages that easily give us this simple functionality. Swap out the functionality and discontinue use of caTools.

July 19 is the deadline, and that's not very far away...

Update docs with various package installation instructions

Please how do I install climdex.pcic package? I have just installed climpact in R and when I runApp I got this message
Error in library(climdex.pcic) :
there is no package called ‘climdex.pcic’

I tried
install.packages('climdex.pcic') but i get this Warning in install.packages :
package ‘climdex.pcic’ is not available for this version of R

A version of this package for your version of R might be available elsewhere,
see the ideas at
https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#Installing-packages

Fix multi-paragraph roxygen documentation

As discussed in #5, a large percentage of the written docs are not being properly compiled by roxygen2. Read the "Basic Documentation" section here, and ensure that any block elements (in particular the "Details" sections) which span multiple paragraphs have their block type explicitly stated.

For example change this:

#' Growing Season Length                                                                                                                          
#'                                                                                                                                                
#' This function computes the growing season length (GSL) given the input.                                                                        
#'                                                                                                                                                
#' Details paragraph 1                                                                    
#'                                                                                                               
#' Details paragraph 2                                                                                                                                               

to this:

#' @title Growing Season Length                                                                                                                          
#'                                                                                                                                                
#' @description This function computes the growing season length (GSL) given the input.                                                                        
#'                                                                                                                                                
#' @details
#' Details paragraph 1                                                                    
#'                                                                                                               
#' Details paragraph 2                                                                                                                                               

It seems like WSDI and CSDI do not use bootstrapping...

Comparison: climdex vs icclim(https://github.com/cerfacs-globc/icclim/releases - the version 4.0.0 with implemented bootstrapping)

Base period: 1961-1970

year climdex icclim abs(diff)
with_bs

The difference was only inside base period.

So, I recomputed WSDI without using bootstrap procedure, and I got this:

year climdex icclim abs(diff)
without_bs

(The same was for CSDI.)

That made me think that climdex does not use bootstrapping for these two indices (for TX10p, TX90p, TN10p and TN90p it is ok - the results converge).

Abort and core dump under R 3.5.0, Fedora 28

After upgrading R and reinstalling all packages, my previously working code fails with an abort and core dump. This is reproducible using the example in the package documentation for climdex.tx10p.

>      library(climdex.pcic)
Loading required package: PCICt
>      
> sessionInfo()
R version 3.5.0 (2018-04-23)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: Fedora 28 (Server Edition)

Matrix products: default
BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

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

other attached packages:
[1] climdex.pcic_1.1-6 PCICt_0.5-4.1     

loaded via a namespace (and not attached):
[1] compiler_3.5.0 Rcpp_0.12.17   caTools_1.17.1 bitops_1.0-6  
> 
>      ## Create a climdexInput object from some data already loaded in and
>      ## ready to go.
>      
>      ## Parse the dates into PCICt.
>      tmax.dates <- as.PCICt(do.call(paste, ec.1018935.tmax[,c("year", "jday")]), format="%Y %j", cal="gregorian")
>      tmin.dates <- as.PCICt(do.call(paste, ec.1018935.tmin[,c("year", "jday")]), format="%Y %j", cal="gregorian")
>      prec.dates <- as.PCICt(do.call(paste, ec.1018935.prec[,c("year", "jday")]), format="%Y %j", cal="gregorian")
>      
>      ## Load the data in.
>      ci <- climdexInput.raw(ec.1018935.tmax$MAX_TEMP, ec.1018935.tmin$MIN_TEMP, ec.1018935.prec$ONE_DAY_PRECIPITATION, tmax.dates, tmin.dates, prec.dates, base.range=c(1971, 2000))
>      
>      ## Create a monthly timeseries of the TX10p index.
>      tx10p <- climdex.tx10p(ci)
/usr/include/c++/8/bits/stl_vector.h:950: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = double; _Alloc = std::allocator<double>; std::vector<_Tp, _Alloc>::const_reference = const double&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.
Aborted (core dumped)

The problem lies with the tmax and tmin elements of the quantiles environment in ci: simply accessing one of them causes the same abort (prec is fine), eg

> str(ci@quantiles$tmax)
/usr/include/c++/8/bits/stl_vector.h:950: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = double; _Alloc = std::allocator<double>; std::vector<_Tp, _Alloc>::const_reference = const double&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.
Aborted (core dumped)

Working backwards, the root cause of the abort is something in
"running_quantile_windowed_bootstrap"
called by
zhang.running.qtile

I can reproduce this on two independent computers running Fedora 28, but NOT on one running CentOS.

# works on this system

> sessionInfo()
R version 3.5.0 (2018-04-23)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

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

other attached packages:
[1] climdex.pcic_1.1-6 PCICt_0.5-4.1     

loaded via a namespace (and not attached):
[1] compiler_3.5.0 Rcpp_0.12.17   caTools_1.17.1 bitops_1.0-6  

which means it probably has something to do with the update to gcc 8 (CentOS 7 is still using gcc 4.8). I know that there are some compiler flags that change, but I do not know the details. I can poke into it more if you don't have access to a current linux distro to test on.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.