first draft of zipzap vignette

[dmi3kno]

I would like to initiate the vignette on ZIP and ZAP models. These are very useful in my field of work and I would appreciate learning more about them through the contribution of others.

[finnlindgren]

Made a small language tweak to counteract the somewhat sloppy INLA&inlabru terminology; most places inla/inlabru says likelihood (e.g. like()) we are really referring to an observation model. I will likely introduce a new function in inlabru with more appropriate name than like().

[dmi3kno]

worse scores for ZAP than for the other two (across all four scores; they're all negatively oriented, and the ZAP scores are the largest, i.e. worst):

Isn't MDS lowest for ZAP?

will likely introduce a new function in inlabru with more appropriate name than like()

Yeah, maybe model() or model_spec(), or bru_model()

[finnlindgren]

No, note the - sign in front of the MDS scores; the ZAP value is larger than that for ZIP, which is larger than the one for Poisson.

[finnlindgren]

In the document, all four scores are "negatively oriented", i.e. closer to -Inf is better than closer to +Inf. Only The AE and SE scores are bounded below (by zero). The other two can take any real value.

[finnlindgren]

A new "nzpoisson" model has now been added to INLA, that implements the y|y>0 conditional Poisson model, removing the need for the zero-adjusted-with small-fixed-probability "hack".

[dmi3kno]

Yes, I saw nzPoisson added in version 23.10.14, documented here. Since you are preparing a new release of inlabru, are you going to bump the INLA version dependence to the newest version? If so, I would like to update the models to take advantage of the new functionality.

[dmi3kno]

One more question, when predicting does inlabru rely on the global environment to resolve components? I am using targets and my model and predictions are in two different targets, saved as rds in between.

I noticed that if I run the model and the prediction targets in the same batch, then all components are found successfully, buf if i restore the model object from rds, then the predict function loses track of the location of covariate rasters. I suspect that it has something to do with how terra operates on disk, so when my rasters are read again within the predict target, the hash isn't the same (the temp file is gone), so the rasters are not located properly.

Something is happening at the interface of terra and inlabru, which does not work well within targets (cached) environments. Perhaps I need to force terra to use the same tempfile between the model and predict function...

[finnlindgren]

You need to explicitly create the terra objects in the R session in which they are used. That is a terra specific issue, as the terra objects for data on disk is (normally) kept on disk, and the objects aren't directly storeable in R object files, unless one uses special methods to wrap them. So in targets, one needs to deal with it differently. I'm sure others have dealt with terra objects in targets, so there should be some usable examples out there somewhere.

The predictor evaluation should have access to the environment of the R session they run in, but in this particular case it's likely they validity (or not) of the available objects that is the issue.

[finnlindgren]

This is also why the covariates for gorillas_sf are referred to only by a filename in the gorillas_sf object, and one has to use that information (or the provided helper function) to actually create the terra::rast() object before using them,

[finnlindgren]

Instead of increasing the formal INLA version dependence, protect the vignette itself by making the computations conditional on the installed version. Something like this in the setup chunk:

knitr::opts_chunk$set(
  collapse = TRUE,
  comment = "#>",
  eval = package_version(getNamespaceVersion("INLA")) >= "2023.10.19-1"
)

And also add a note to the text about what INLA version is required to access the feature.

With this approach, only those who need the specific feature need to upgrade their INLA version. Since many are on systems where upgrading INLA may not be practical, I prefer to only increase the formal version requirement for features that inlabru itself directly uses.

[finnlindgren]

I realised the INLA version dependency could be done locally where the like() call is made; it doesn't affect the rest of the code, so I edited the text to mention both options, and the code to pick nzpoisson for new INLA versions. If the checks go through, I'll merge the PR before doing the inlabru release, as I've added it to the pkgdown listing. However, since it uses INLA the actual vignette text will be mostly visible via the github.io page, where further edits will show up even if the CRAN version isn't updated. That way, it can be changed/improved further without worrying about the CRAN release schedule.