Single Axis OPSCR Modeling

[Eric Lyons]

Hi all,

I am currently running into a few problems with an OPSCR model I am developing. I have only worked with non-spatial JS/CJS models before, so entirely possible that the error is pretty simple to fix. The short version is that instead of working with a grid of traps, we survey in (more or less) a straight line moving up a mountain stream. As a result, our data only has one axis – the distance (in meters) from the base of the stream. When I run the model, a large portion of the nodes give me the error “: logProb of data node y[-, -, -]: logProb is -Inf.”.

I suspect it is due to the distance between the individuals and the traps reaching zero, but so far have been unable to confirm. I have tried running the model with no X-coordinate as well as a dummy X-coordinate (i.e., with a sequence from 0.99999 to 1.00001), but the errors stay the same. Model code screenshot below (we have 12 years of data, but I trimmed this to just the first 3 to shrink the image a bit). Any advice is appreciated!

Thanks in advance,

Eric 

[Perry de Valpine]

Hi Eric,

Thanks for the question. Can you tell if the message about -Inf is being produced during the MCMC sampling, or prior to that in the model building step? If you are calling nimbleMCMC, you might not be able to tell which, so you would want to first use nimbleModel directly to a build the model and see if you get those messages. If the messages appear from nimbleModel, they likely say first that it is not necessarily an error but rather incomplete or incorrect initialization. 

You can use the model object to inspect variables and calculate log probabilities for individual nodes to track down where you have invalid values. In case you haven't had a chance to check it out, the nimble user manual at r-nimble.org may be helpful. If the errors are arising only during MCMC (i.e. you can do model <- nimbleModel(...) and then model$calculate() returns a number not Inf, -Inf, NA or NaN), you can run the MCMC for only a small number of iterations (sufficient to trigger the messages) and then inspect the variables in the model object at that point. If the example is small enough you can do so with the uncompiled model and MCMC, or otherwise with the compiled MCMC and then inspect the corresponding compiled model object. 

One kind of issue that can arise in your model is numerical underflow or overflow. For example you could have tmp[t,i,j] (or pmean[i,j]) being exactly 0 or 1, rather than just very close to 0 or very close to 1. Then if the corresponding y[t,i,j] is impossible, you'll get a log probability of -Inf for it. You can check that from the values in the model (model$pmean). The solution is often to provide reasonable initial values for parameters (e.g. parameters that enter calculation of pmean), since underflows or overflows typically appear only for values that are unreasonable. If you can't get traction on what is wrong, the next steps would be to simplify the example as much as possible and send reproducible code and data.

HTH

Perry

--
You received this message because you are subscribed to the Google Groups "nimble-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nimble-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/nimble-users/e62e4f4d-82b5-4007-a822-639fdb9f7632n%40googlegroups.com.

[Eric Lyons]

Hi Perry,

Thanks so much for the quick response! It seems like the error appears before MCMC sampling. I used nimblemodel and the corresponding model$calculate gave me a value of -Inf. There is one initialization error from a column purposely left blank but setting that column to an arbitrary value eliminates the warning but does not fix the errors. From what I can tell, the logProb error occurs in every node where I captured an individual (so obviously not ideal…). I ran it with a smaller simulated dataset (also a big thank you to Olivier Giminez who wrote the simulation functions used and gave a nice example of this kind of model online) and was able to get a full calculation/parameter estimation when the grid was arranged in a small three-dimensional space.

I think that the numerical overflow is the problem here, and may have found a possible explanation, albeit one that I am not quite sure how to fix. If I constrain the simulated y coordinate such that 1 < y < 10, the model works just fine. But if I change nothing except that the simulated y coordinate is 1 < y < 20, the error appears again. I have tried using same exact grid for both simulations as well as expanding the second grid to better accommodate the larger range, but still nothing. I also tried expanding the home range parameter thinking that it might be possible that the longer grid made it so that the probability of an individual being caught in a far away trap was reaching the 2e-16 limit and causing some kind of problem, but no luck there either. Reproducible code is attached here. Apologies if it is a bit on the longer side, but it is essentially just the same model pasted 3 different times – the first two work fine, and the third is where the problems arise. The whole thing runs in ~30 minutes on my end. Thanks again!

Best,

Eric

[Perry de Valpine]

Hi Eric,

I'm having a hard time reproducing the problem. Working through 30 minutes of code was a lot to ask, so I went straight to the third case that you said was where problems arise, and it appeared to run fine on my system and produced values (no NaNs, Infs, or NAs). I'm also not sure I followed everything you were saying, so I may not have understood what I should be looking for. Here are some suggestions.

If it really is numerical underflow or overflow, the spot I'd be suspicious about is y[t,i,j] ~ dbin(tmp[t,i,j], K), where  tmp[t,i,j] <- z[i,t] * pmean[i,j]. If you ever have an initial state where z[i,t] is 0 but there is a non-zero y[t,i,j], then that y[t,i,j] has probability 0 and so log probability -Inf. We've often seen these kinds of initialization glitches in discrete ecological models where the model starts in an impossible state. The same kind of thing can happen with the sequences of dbern z[i, t] nodes. Another thing that can go wrong is if pmean[i,j] is numerically exactly 0 or 1 and that is incompatible with corresponding y[t,i,j] values. That could happen if g[i,j] is very very large (possibly due to weird initial values), for example. One can either set reasonable initial values (if they then stay reasonable) or robustify it with something like:

pmean[i,j] <- 1e-6 + 0.999999*(1 - exp(-g[i,j]))

so that pmean ranges from 1e-6 to 1-1e-6 and can never be exactly 0 or 1.

If you're still stuck, here are some suggestions for sending a reproducible example. Please add comments on what we are to look for and expect. Also add comments to highlight very clearly where you are making differences between cases. And also use a set.seed call prior to each independent segment of the reproducible example, so that we know we'll get exactly the same random draws etc (in case the problem depends on that) and so that we can start into independent segments of code without having to run the previous ones (just to maintain reproducibility of random draws from a much earlier set.seed call).

If a model differs only by a prior, e.g. sigma~dunif(0, 5) vs sigma~dunif(0, 10), you can instead say sigma~dunif(0, max_sigma) and provide max_sigma in the constants. Then you can use the same code with different calls to nimbleModel and it might be more compact to share and follow. I'm not sure if there were more differences as well.

HTH

Perry

To view this discussion visit https://groups.google.com/d/msgid/nimble-users/09074d00-fdbc-47c6-ae15-5a3ea5c28962n%40googlegroups.com.

[Eric Lyons]

Hi Perry,

Appreciate your help! I saw your suggestions this morning and was able to get it to work. There were two distinct issues. The first was indeed the g[i,j] values getting weird (I ended up turning it into an array once I got it working). Adding the strict range on pmean did the trick and made it possible to identify the actual problem nodes. I did find a few impossible starting states and it was a pretty simple fix from there. Appreciate the advice on the reproducible examples - that would have definitely saved me a bit of time (and probably made it a little easier for you to see where the errors were). Thanks again!

Best,

Eric

[Perry de Valpine]

Outstanding! Glad you're on your way and thanks for the questions.

To view this discussion visit https://groups.google.com/d/msgid/nimble-users/c665405f-8160-400e-be1e-0b6f2e045429n%40googlegroups.com.