NA log likelihoods in a single season model - starting values or something else?

[catheri...@gmail.com]

Hi all,

I have a simulated dataset of single-season encounters at a large number of locations over a landscape. There are a fair number of detections per individual and spatial recaptures - for example, in the dataset I've attached: 55 individuals detected 355 times over 6 occasions. However I am unable to get a (null) secr model running. The troubleshooting PDF suggests that the issue is likely starting values, as the trace shows NA values for the log likelihoods. 

However, the model doesn't run even when I provide starting values from secr objects that successfully ran with datasets that had fewer detections and individuals. I have tried a variety of different initial values as well as changing the buffer argument. Nothing seems to be working, but I'm pretty convinced that it should run given the quality of detections. I can't tell if maybe it's something to do with units or a scale mismatch, but again, worse datasets seem to run without any issues. Any suggestions?

Help would be greatly appreciated. I have attached a workspace.

thanks,

Cat 

[Ian Durbach]

Hi Cat,

I think the problem is caused by your simulated data having counts up to 4 per detector per occasion, which isn't possible from a binomial distribution with the number of trials set to usage = 1. 

> table(tmp_caphist_month)
tmp_caphist_month
      0       1       2       3       4
1123996     284      21       7       2 

But even if you set number of trials to 4 (binomN = 4) it gives a few non-NA LL values and then hits some an error I've not seen before "Error: Error in function ibeta_derivative<long double>(long double,long double,long double): Overflow Error". So I wonder if the more general problem is that the simulated data is pretty extreme, with loads of detectors always on but relatively few detections and recaps, and that causes numerical problems (D and g0 both have to be tiny)

binomN = 3 is theoretically impossible but gives the same pattern as binomN = 4. binomN = 2 bombs out right away like binomN = 1. Poisson N fits but with other weird numerical warnings about integrals. I think that's all consistent with very small numbers causing numerical problems.

Not sure where that leaves you but hopefully useful.

Ian

--
You received this message because you are subscribed to the Google Groups "secr" group.
To unsubscribe from this group and stop receiving emails from it, send an email to secrgroup+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/secrgroup/5ad3f362-7a8b-4b4d-8a5a-398188dfb693n%40googlegroups.com.

[Cat Sun]

Hi Ian,

Thanks very much for taking the time to look at my problem - I appreciate it.

In my code to the google group, I forgot to include that I define ’usage’ for each occasion and trap - of either 30 or 31,  since the occasions are month-long. So my intent with binomN=1 was to apply that custom ‘usage’ rather than just the default 1. I can see how forgetting to include that would make my code seem I am using the default usage=1. 

But, your response still seems to have helped me solve the problem - which was an order of operations issue! I mistakenly created the capthist object with the traps first and only then did I define trap usage. As a result, the traps part of the capthist object still only have usage=1.

The model runs fine now when I assign usage first and then create the capthist object using the 'correctly-usaged' traps . It’s a wonder any of my previous models even ran, and gave me reasonable results!

What you observed with the various different binomN assignments make sense, too.

Time to rerun some loops. Thanks again for your help.

Cat