Nimble does not work

[Peiyun LI]

Hi all,

I had a problem about Nimble. I could run the example of Nimble compile successfully. And I also analyzed my own data with JAGS successfully. But when I tried to use Nimble to calculate the same data with same settings, it showed hundres of errors like below and never worked:

Could anybody know why Nimble does not work? 

Thanks in advance!

Kind regards,

Peiyun

[Juergen Niedballa]

Hi,

do you have NAs in your detection histories? I believe that is the issue. The models don't allow NAs / missing data in the detection histories, so the data structure differs a little from normal occupancy models in unmarked / ubms. Try replacing the NAs in the detection history with 0, and provide the effort matrix (which may contain NAs) as an observation covariate.

JAGS and Nimble don't allow NAs in the detection histories, hence the NAs must be introduced via the effort matrix as a observation covariate. The model will set the detection probability of all occasions with effort = NA to 0, thus ensuring that the 0s in the detection history doesn't bias detection probabilities.

The warning about the deterministic assignment can be ignored. It happens when the rOcc_v function is used to generate a new detection history (new.y), which is then compared to the actual detection history for calculating model residuals.

I will add the issue with NAs in the detection histories to the vignette.

Best regards,

Jürgen

--
You received this message because you are subscribed to the Google Groups "camtrapR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to camtrapr+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/camtrapr/ab0d2b08-a5a7-4b5b-a92f-46b8635b8c58n%40googlegroups.com.

[Peiyun LI]

Dear Jurgen,

Thank you so much for your response! I checked my data and it is true that I have many NAs in my detection history... But I still have one question about detection history preparation for occupancy analyses.

Our camera traps had some problems during our monitoring period. So in cameraOperation() function I set "hasProblems = TRUE". Then in detectionhistory() function, I set "includeEffort = TRUE". I thought that the record history should only contain 0 and 1 and no NAs. However, my detection history matrix still contains lots of NAs. Until your previous email reminded me to check my data, I just found this problem. And I find that only I set "hasProblem=FALSE", then the record history will only contain 0 and 1, but the effort matrix contains lots of negative values which the true value should be NAs. 

I am wondering why "includeEffort" does not work unless "hasProblem=FALSE" ?  Is it possible that I had any other setting errors in my detection history processing? Or as you said, I can just replace NA with 0 then introducing the right effort matrix (contains NAs) as an observation covariate?

Kind regards,

Peiyun

[Peiyun LI]

And I am very curious why my JAGS could run successfully even though I have lots of NAs in my dection history?

[Jürgen Niedballa]

Hi,

apologies, my previous message was not correct. In JAGS models, NAs in detection histories are handled without problems. In Nimble, NAs in the detection history lead to problems in calculation of the residuals (hence the warnings about res, R2, R3), but you still get model results. So these errors still allow fitting of models in Nimble. To get rid of these Nimbler errors, something like:

data_list$ylist <- lapply(data_list$ylist, FUN = function(x) {x[is.na(x)] <- 0; x})

can be used to replace NAs with 0 in the detection histories of all species at once. The additional 0s in the detection history should not change detection probabilities since all occasions with NA in the effort matrix will have detection probability fixed at 0.

includeEffort and hasProblems should not affect the results. Irrespective of the settings of these two parameters you can still get NAs in the detection histories. IncludeEffort must be set to TRUE in order to obtain the effort matrix (needed as an observation covariate). Negative values in effort suggest that scaleEffort = TRUE, and indicate low effort. Personally I don't normally scale effort and don't have problems with parameter estimation (and the parameter estimates for effort on detection refer to "1 day", not "1 standard deviation of effort"). So feel free to try setting scaleEffort = FALSE (it's the default).

Side note, for reasons I don't understand, response curves and predictions usually look "better" (i.e., smoother, less artefacts) when fitting in JAGS compared to Nimble. In my tests Nimble also was not really much faster (it can be much faster than JAGS if vectorized properly, but the models would need to be specified differently, without the station loop).

Sorry again for the confusion in my first message.I hope it's clearer now.

If you can share a minimal reproducible example (e.g. from AHMbook output as in vignette 5) it would be easier to discuss these things.

Best regards,

Jürgen

To view this discussion on the web, visit https://groups.google.com/d/msgid/camtrapr/a4ebf70c-3526-4a75-b275-59cd0488189en%40googlegroups.com.

[Peiyun LI]

Dear Juergen,

First of all, thank you so much for your detailed explanation and sorry for my late respose. I am doing my field work and irregularly get the signals...  I set scaleEffort=FALSE as default and my JAGS still working well. And when I replaced NA with 0, the problem of Nimble solved.

Now I have another question about the number of NAs in my detection history for multi-species occupancy model. Someone suggests me that I should reorganize  the detection history, which put all the cells with values in the first few columns and reduce the number of NAs as much as possible (Please find attached the example of the orgin detection history and the reorganized detection history form). They said that the less NAs could let the model fit better. I am wondering if it is necessary to do that? Is it ture that more NAs might negatively influence the model fitting? Before my prior and inits setting like below and I could run the model successfully: 

prior_list <- list(dnorm = "dnorm(0, 0.5)",
                   dgamma = "dgamma(0.1, 0.1)")

# define inits
inits_list <- list(
  inits_runif_mean_low = list("runif", list(1, -4.5, 0)),   
  inits_runif_mean_0 = list("runif", list(1, -1, 1)),
  inits_runif_tau  = list("runif", list(1, 0.01, 0.1)),
  inits_runif_omega = list("runif", list(1, 0, 1))
)

 BUt now my model unsatisfied the prior and inits I set and I am not able to run my model anymore when I reorganized the detection history...

Thanks in advance!

Kind regards,

Peiyun

[Peiyun LI]

And also……I reorganzed the detection history of each species, effort matrix and detCovObservation data in the same way. And I checked the lists in data_list, the structure of my data is just as same as before, except the cells with values in the first few columns and I deleted some columns with full of NAs. And I don't know why my model is not satisfied my previous settings...

Peiyun

[Juergen Niedballa]

Hello Peiyun,

especially for data from long surveys it makes sense to have the effort of all stations begin in occasion 1. this results in much more compact detection matrices and faster model fitting (since there are less occasions to loop over). Normally you don't need to do this manually. Please have a  look at the argument "day1" in detectionHistory. By setting day1 = "station", all detection histories and their effort matrices should automatically be left aligned. That also avoids the mismatch between detections and effort in the example you shared.

I don't know if the NAs affect model fit. Conceptually they should not since the effort_binary matrix ensures that all detections without effort (where effort = NA) have detection probability 0. But less occasions lead to faster model fitting, especially in large dataets like your (>180 occasions).

Regarding the priors and inits, normally they are set automatically. Unless you want to change them (e.g. do different prior distributions) it should run automatically with fit(). Changing the detection history should also not affect the priors and inits.

I suggest you create the detection histories with day1 = "station", then see if you can fit a simple model. Maybe also try in JAGS, it sometimes seemed a little more forgiving than Nimble, and with the current implementation Nimble doesn't really have a speed advantage either.

Best regards,

Jürgen

To view this discussion on the web, visit https://groups.google.com/d/msgid/camtrapr/3f9a8591-9602-4113-951c-efcaef952536n%40googlegroups.com.

[Peiyun LI]

Dear Juergen,

Thank you for your quick response. 

The reason I set day1=“survey” is because my camera traps started from different dates, but I want to analyze all the data together. I am afraid if I set day1="station" it is too hard to match the detCovsObservation matrix since each camera started at different date.  The value of each occaasion of detCovsObservation matrix will be different and it might lead to mistake... And for the priors, the default priors indeed did not work for my database. The prior and inits setting I showed in my previous email is the one I could use it and run JAGS successfully. 

So in summary, if NAs will not stronly affect model fit, the results I got probably are final results as long as the MCMC diagnose looks good, right? Except reducing NAs, I am wondering if WAIC is necessary before I use spatial prediction? It is also the reason I want to use Nimble since only Nimble provide WAIC function...

Kind regards,

Peiyun