A Primer on Crashing INLA Models

This post was originally written 09/28/2015 copied from my old blog.

There seems to be at least something to the fact that the models seem harder to fit with bigger data. Our theory is that INLA crashes the model isn’t a good fit. Luckily, if you search “crash,” I’m far from the only one who has had this problem. I’m not sure yet if this is an answer, but so often in the GLMM and R world, it has something to do with an optimizer. I tried the “new” (as of April 2015) inla.control(correct=TRUE,correct.factor=10) which the authors say may become standard in a later version.

The thread I mentioned before even contains the same perplexing output I see when I run the models “verbose.” This person seems to be in a similar vein of thinking as some of my prior thoughts: he notices the models ran fine when the data set was smaller, but then the bigger set crashes. This is where I translated (maybe not correctly) the comment that follows suggesting “adding the option control.inla(diagonal=100) …also try values other than 100, such as 10 and 10000” into what they now have as a new feature (this post after all is from 2011). The author further qualifies that this option adjusts the Hessian optimization so as to make it more robust.

Further down this thread, there is a suggestion for giving INLA better starting values. That author builds on the prior suggestion by “complicating” the control.inla call like such…

 control.inla = list(diagonal = 100, strategy = "gaussian", int.strategy = "eb")  

This is the “cheapest” (his words) approximation, but it will do to at least point INLA in the right direction in the “real” call.

The things you could put in the option control.inla = list(strategy = “…”) when making your call to INLA can be…

• laplace – this is the “full Laplace,” and is the most intense computationally. should be used if you need e.g. higher accuracy in the tails
• simplified Laplace – default
• Gaussian – the least intense
  • can be used if you’re having problems with models crashing
  • the “old way”
  • simplest approximation
  • “cheap”

 control.mode = list(result = starting.value, restart = TRUE)   

…to the normal INLA call. He further suggests “cooling” the diagonal if 100 is too small, and adjusting such that you start with, e.g. 1000, then down to 100, then down to 10. In the meantime, also found a few workarounds to make the INLA crashing process less painful on Windows.

• temporal
  • an idea to scale time
  • alternatively code as integers (1,2,3…)
• when there aren’t random effects, glm() is a good sub
• control.inla = list(reordering = “metis”)
• INLA:::inla.dynload.workaround()
  • maybe this is to use the static build for the testing version on Ubuntu?
• make a sparse matrix
• try the testing version of INLA
• restart your computer and immediately run to free up memory
• select good starting values
  • control.mode=list(theta=c(   <starting values in internal scale>   ), restart=TRUE)
• make sure factor names don’t include []
• better priors for fixed effects
  • f(…, model=”linear”, prec.linear = 1)
  • control.fixed = list(prec.intercept = 0.001)
• advice for SPDE models
  • might use different functions based on size of model
  • large grid problems
  • graph example
• ecology examples
  • bird count data problem
  • pesticides
• consider a binary variable as a factor?
• zero-inflated binomial advice
• range of response too wide?
• when you have lots of prediction points
• CPO might use too much memory
• HPC problems
  • ulimit
• spatial: f(ID.road, …., adjust.for.con.comp = FALSE)
• Knorr-Held Type IV