concurvity {mgcv} - unknown error

[Nate_L]

Is anyone familiar with this error message? I have a model that converged, but when I try to check for concurvity I repeatedly get this error. It occurs no matter which terms or how many I kick out. I know it would help if I had a reproducible example, but my data is 1,500 rows x 23 columns and I can't reproduce the error with a smaller subset of data. I've seen a similar problem here, but it's solution doesn't seem to work for generalized additive mixed models. I have also tried setting the full argument to TRUE and FALSE.

library(mgcv)

mod <- bam(num ~ 
           
           # Parametric terms
           CYR.std * Season +
             
           # Habitat covariates
           sed_depth * ave_hw +
           total_ave_ma +
           s(ave_tt) +
           
           # Structural components
           s(Site, bs = "re") +
           s(Site, fCYR, bs = "re") +
           s(Site, CYR.std, bs = "re") +
           s(Season, fCYR, bs = "re") +
           
           offset(log(area_sampled)), 

         data = toad, 
         method = 'fREML',
         discrete = TRUE,
         family = poisson,
         control = list(trace = TRUE))

Setup complete. Calling fit
Deviance = 226.280118812246 Iterations - 1
Deviance = 502.577417444367 Iterations - 2
Deviance = 576.624536857 Iterations - 3
Deviance = 685.39118817115 Iterations - 4
Deviance = 714.899394181739 Iterations - 5
Deviance = 735.575311982761 Iterations - 6
Deviance = 734.653307725508 Iterations - 7
Deviance = 735.874682895636 Iterations - 8
Deviance = 736.673618482559 Iterations - 9
Deviance = 736.861294501416 Iterations - 10
Deviance = 736.981664035411 Iterations - 11
Deviance = 737.00995853621 Iterations - 12
Deviance = 737.028133131768 Iterations - 13
Deviance = 737.032400712599 Iterations - 14
Deviance = 737.035137664603 Iterations - 15
Deviance = 737.035779699487 Iterations - 16
Deviance = 737.03619105456 Iterations - 17
Deviance = 737.036287496242 Iterations - 18
Deviance = 737.036349254884 Iterations - 19
Fit complete. Finishing gam object.
          user.self sys.self elapsed
initial        0.02     0.00    0.01
gam.setup      0.03     0.00    0.03
pre-fit        0.00     0.00    0.00
fit            7.03     0.34    7.39
finalise       0.00     0.00    0.00

concurvity(mod)

Error in forwardsolve(t(Rt), t(R[1:r, , drop = FALSE])) : singular matrix in 'backsolve'. First zero in diagonal [14]

UPDATE:
Removing the random effect "s(fSeason, fCYR, bs = "re") +..." did the trick, but I don't understand why. I'm also not sure what to do if it's an important part of faithfully representing the survey design (random intercept that captures similarity of observations within a season within a year).

[technocrat]

The error message "singular matrix in 'backsolve'. First zero in diagonal" indicates that there is a problem with the matrix inversion during the model fitting process. This is likely due to a singularity or near-singularity in the model matrix, which can be caused by collinearity or near-collinearity among the predictors, or by having too many parameters relative to the number of observations.To address this issue, you can try the following:

1. Check for collinearity among the predictors. You can use the cor() function to compute the correlation matrix of your predictors and look for high correlations. If you find collinear predictors, consider removing one of them or combining them in some way.
2. Reduce the complexity of the model. You can try removing some of the smooth terms or random effects from the model to see if the error persists. Start with a simpler model and gradually add terms to see which term is causing the issue.
3. Increase the number of observations in your dataset, if possible. Having more observations can help alleviate issues related to singularity in the model matrix.

[Nate_L]

Indeed, removing the random intercept "s(fSeason, fCYR, bs = "re") +" worked! However, if it's there to faithfully represent the sample design (capturing similarity of observations caught within the same year and season) should I still remove it?

[technocrat]

In generic time series models, autocorrelation is common and disruptive. Autocorrelation is the tendency of this fall’s flu outbreak to resemble last year’s observations plus or minus a little (most years). Depending on the resolution of your data that may be happening here on a weekly or daily basis. There are tools to feature engineer to achieve stationary model residuals that are “white noise.” For example, there are “seasonally adjusted” unemployment reports.I suspect that the collinearity problem arises from the seasonality. The {fpp3} package and its accompanying text can provide details and tools that may help in your case.