morrowcj/remotePARTS

Fatal error that aborts R

morrowcj opened this issue · 7 comments

morrowcj commented

Occasionally, using some functions in this package can cause a fatal errorthat aborts R.

As far as I've been able to tell, these errors occur when input to the functions are improper (e.g., incorrect dimensions) or when there is insufficient memory.

They appear to only occur with functions that use C++ (via Rcpp).

morrowcj commented

If anyone knows of a consistent way to reproduce this bug, I would very much like to know.

kelewinska commented

Try to run fitGLS_partition with formula = AR_coef ~ 0 and formula0 = AR_coef ~ 1

morrowcj commented

I thought I fixed this... :( I'll look into it.

morrowcj commented

Following the examples for fitGLS_partition, using 0-intercept only does cause a crash.

library(remotePARTS)
data(ndvi_AK10000)
df = ndvi_AK10000[seq_len(1000), ] # first 1000 rows
pm = sample_partitions(nrow(df), npart = 3)

partGLS = fitGLS_partition(formula = AR_coef ~ 0, partmat = pm, data = df) # causes crash

And this is because it doesn't make sense to use a zero-only intercept. The typical intercept results in a model matrix with a single column, where a 0-intercept version has a 0-column model matrix (which is nonsense):

modmat1 = model.matrix(AR_coef ~ 1, data = df)
modmat0 = model.matrix(AR_coef ~ 0, data = df)

dim(modmat1)  # 1000  1
dim(modmat2)  # 1000  0

I'll add some functionality to prevent 0-intercept models from being run and I will also create a warning about the intercept-only model.

  • 👍1
arives commented
  • 👍1
morrowcj commented

I've implemented a fix in the development branch. I'll test it after compiling and then push to master ASAP.

morrowcj commented

I've patched the specific issued mentioned by @Erfea in PR #21. I'm going to close this issue. If a new crash-condition arises, we'll create a new one.