pacificclimate / climdex.pcic Goto Github PK
View Code? Open in Web Editor NEWRoutines to compute ETCCDI Climdex indices
License: GNU General Public License v3.0
Routines to compute ETCCDI Climdex indices
License: GNU General Public License v3.0
I wish to compute the Consecutive wet and dry days with custom threshold of 2.5 mm. The default threshold is 1 mm. Is it possible ?
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]
good_ci@data$tmin[360:365]
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).
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 :
What can i do, where i'm wrong ?
Thanks in advance
ERROR: dependencies ‘ncdf4’, ‘ncdf4.helpers’ are not available for package ‘climdex.pcic.ncdf’
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'.
The note says:
* checking compiled code ... NOTE
File ‘climdex.pcic/libs/climdex.pcic.so’:
Found no calls to: ‘R_registerRoutines’, ‘R_useDynamicSymbols’
It is good practice to register native routines and to disable symbol
search.
See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.
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.
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.
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))
These releases exist in the commit history (1.1-10 is 19f4f2e and 1.1-11 is daf4790) but have not been tagged. See https://github.com/pacificclimate/climdex.pcic/tags
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.
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"))
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
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.
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.
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.
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])
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...
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
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
This package was recently removed from CRAN, https://cran.r-project.org/web/packages/climdex.pcic/index.html
Package ‘climdex.pcic’ was removed from the CRAN repository.
Formerly available versions can be obtained from the archive.
Archived on 2020-01-16
Comparison: climdex vs icclim(https://github.com/cerfacs-globc/icclim/releases - the version 4.0.0 with implemented bootstrapping)
Base period: 1961-1970
The difference was only inside base period.
So, I recomputed WSDI without using bootstrap procedure, and I got this:
(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).
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.