vastly different density estimates from secr and oSCR

71 views
Skip to first unread message

Rahel Sollmann

unread,
Apr 5, 2024, 5:05:18 AM4/5/24
to oSCR
Hi all,
I am helping someone analyze camera trap data with a multi-session SCR model. Initially, I used oSCR for the analysis but I have now re-analyzed the data with secr and am getting density estimates an order of magnitude lower.
I am taking into account the different spatial resolutions of the two packages and fitting structurally the same model to the same data. It's a 'vanilla' model: Euclidean distance, no telemetry data, Poisson observation model... 
I have more experience with secr than oSCR (the secr estimates are also much more in line with previous analyses of subsets of the same data), so am assuming I am doing something wrong in the oSCR analysis. But I have been scouring the data and code and cannot find my mistake.
I have attached an Rmarkdown report showing data comparison and model fitting for the two packages. This is only for a single-session subset of the data, to speed up computations, but the problem persists when analyzing all sessions. The data aren't mine to share publicly, but I would be happy to share the data subset and script used for the report off-list if it helps figuring out what is going wrong.
Thanks in advance!
Best,
Rahel

Analyze-season-1-data-with-secr-and-oSCR.pdf

Jeffrey Royle

unread,
Apr 5, 2024, 8:20:13 AM4/5/24
to oscr_p...@googlegroups.com
hi Rahel,
 This is interesting. I'm curious what is the area of the state-space and does the implied population size make more sense for one or the other?
 from what I can tell the other model parameters are more or less consistent, right?
 regards
andy


--
You received this message because you are subscribed to the Google Groups "oSCR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oscr_package...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/oscr_package/a92f8c2d-94ad-4582-a205-d26093a1038dn%40googlegroups.com.

Jeffrey Royle

unread,
Apr 5, 2024, 8:25:29 AM4/5/24
to oscr_p...@googlegroups.com
If my interpretation is correct, the estimated sex probability parameter is quite off
 -3.56 for oSCR and -1.37 for SECR. 

That's peculiar.

Rahel Sollmann

unread,
Apr 5, 2024, 8:31:15 AM4/5/24
to oscr_p...@googlegroups.com
Hi Andy,
it's one of those study areas where the trap array really spans the entirety of the population (a national park) and the buffer is habitat that animals use to some degree (so you can't really remove it from S) but you'd expect a much lower density. But if you calculate abundance for the area of the trap array based on the two density estimates, the secr one is quite low (apprx 1200km2 *0.3/100km for 3.6 animals) whereas the oSCR one is absurdly high (9/100km2 for >100 animals).
And you're right, even though the detection parameters look good, the sex ratio is off as well.
Best
Rahel

Chris Sutherland

unread,
Apr 5, 2024, 8:36:20 AM4/5/24
to oSCR
What is the sex ratio of the observed individuals?

Jeffrey Royle

unread,
Apr 5, 2024, 8:41:14 AM4/5/24
to oscr_p...@googlegroups.com
it's 50/50 I think:
covariates(dat.secr)[ord,] ## [1] M M F F M F F M M F ## Levels: F M dat.oSCR$indCovs[[1]]$sex ## [1] 1 1 0 0 1 0 0 1 1 0

I don't like the sex ratio parameter that oSCR is spitting out which seems very low.  But the capture probabilities of the sexes are vastly different too , and with a 50/50 observed sex ratio I'm thinking oSCR is probably finding a bad MLE.

Rahel: would be cool if you could re-run oSCR but use the SECR estimates as starting values.....


Rahel Sollmann

unread,
Apr 5, 2024, 8:42:53 AM4/5/24
to oscr_p...@googlegroups.com
I tried it with the secr starting value for density but yes, I can re-run using all secr estimates as starting values. Should have results in about 20 mins. More soon.

Rahel Sollmann

unread,
Apr 5, 2024, 8:53:31 AM4/5/24
to oscr_p...@googlegroups.com
Nope... here are the estimates from the model using secr mle as starting values

       parameters       mle    std.er
1  p0.(Intercept) -7.409839 0.5860361
2         p0.male  1.638126 0.5532573
3 sig.(Intercept)  8.373094 0.1728995
4     sig.sexmale  1.100368 0.1946630
5     t.beta.road  2.297829 0.3958878
6  d0.(Intercept) -2.345398 0.5514381
7    psi.constant -3.561123 0.7819642

Jeffrey Royle

unread,
Apr 5, 2024, 9:05:22 AM4/5/24
to oscr_p...@googlegroups.com
this is interesting.   I guess what the oSCR model is thinking is that the Pr(capture a male) is about 1.0, whereas Pr(capture a female) is very low, so the population has a whole bunch of uncaptured Females out there but not many uncaptured males. That makes sense just looking at the data.  But the SECR results are somewhat consistent in telling the same story, just less extreme. 

There's one way to get to the bottom of this, but I don't see how to do this easily:  you need to compute the likelihood either using the oSCR or SECR likelihood for both sets of parameters and see which one is best.  I think it could be done by hacking the oSCR.fit function (you use the MLE as starting values and just return the evaluation of the likelihood).  Not sure about SECR....



Rahel Sollmann

unread,
Apr 5, 2024, 9:09:45 AM4/5/24
to oscr_p...@googlegroups.com
Hi Andy,
ok, thanks, I will look into that. As a side note, this data subset was analyzed previously using JAGS and results were pretty consistent with what secr is producing.
Best
Rahel


Jeffrey Royle

unread,
Apr 5, 2024, 9:10:10 AM4/5/24
to oscr_p...@googlegroups.com
just fyi I think the likelihood is very flat in the psi.sex dimension and the algorithm is stopping too soon (one or the other) or else there's multi-modes to the likelihood which would NOT be surprising given the sparsity of F captures and the fact that you have 3 parameters to describe the F data!

Jeffrey Royle

unread,
Apr 5, 2024, 9:11:52 AM4/5/24
to oscr_p...@googlegroups.com
that's interesting and good to know. 

Rahel Sollmann

unread,
Apr 5, 2024, 9:19:48 AM4/5/24
to oscr_p...@googlegroups.com
Hi Andy,
I agree about the sparse data but - in the full analysis we have 4 years of data and we're not estimating session specific sex ratios or detection parameters, and still, the estimates from oSCR are 10x higher than those from secr.
Cheers
Rahel

You received this message because you are subscribed to a topic in the Google Groups "oSCR" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/oscr_package/VyDN3inkv3E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to oscr_package...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/oscr_package/CAE%2BwgF3KLX9fyqqffLKDWNP9%3D32UV51ZunB3F3y3oNn%3DbTTTeg%40mail.gmail.com.

Jeffrey Royle

unread,
Apr 5, 2024, 9:29:18 AM4/5/24
to oscr_p...@googlegroups.com
eeek, ok, very strange then!   

Daniel Linden

unread,
Apr 5, 2024, 9:30:59 AM4/5/24
to oscr_p...@googlegroups.com

I’m wondering if there is a problem with the ndays offset. That appears to be one difference between the model fit approaches right now…

Rahel Sollmann

unread,
Apr 5, 2024, 9:37:15 AM4/5/24
to oscr_p...@googlegroups.com
Hi Daniel,
I was wondering about that. The secr vignette about varying effort states that in a Poisson model, the usage (here, number of active days for each camera) is used as an offset in the linear predictor for encounter rate lambda such that
lambda= lambda0*usage (ignoring additional covariates)
I assumed that oSCR does the same when using +offset(ndays), where ndays is log(number of active days). Is that not the case?
Best
Rahel

Rahel Sollmann

unread,
Apr 5, 2024, 10:25:58 AM4/5/24
to oscr_p...@googlegroups.com
Hi Andy,
so I think I calculated the log-LL values under secr and oSCR for estimates from both model versions (no guarantee that I got the oSCR hacking right, it is Friday afternoon...):
The nice thing is, secr outputs the LL values as it runs the model so that one was easy.
secr LL:
         (1) for estimates from secr: -258.723
         (2) for estimates from oSCR: -29489.761
oSCR LL (assuming oSCR spits out the negLogLik, I multiplied the output by -1):
         (1) for estimates from secr: -1951.324
         (2) for estimates from oSCR: -1710.763
So... very weird, no?
Any other thoughts?
Thanks and happy weekend,
Rahel  


Daniel Linden

unread,
Apr 5, 2024, 10:26:08 AM4/5/24
to oSCR
It should be the same, but I recall some strange behavior in the past with the offset function (maybe something oSCR specific).

What happens if you fit an estimated coefficient for log(ndays)?

Rahel Sollmann

unread,
Apr 5, 2024, 10:41:56 AM4/5/24
to oscr_p...@googlegroups.com
OMG that's it!
parameters        mle    std.er
1  p0.(Intercept) -15.953186 9.8017950
2         p0.male   1.616551 0.5768182
3 sig.(Intercept)   8.354778 0.1645539
4     sig.sexmale   1.191043 0.1847156
5    t.beta.ndays   3.020891 2.2159025
6     t.beta.road   2.351929 0.3994432
7  d0.(Intercept)  -5.827147 0.3793804
8    psi.constant  -1.376643 0.6428632

> exp(-5.827147)*100
[1] 0.2946471

Thanks so much! So better stay away from offsets in oSCR then...
Best
Rahel

Daniel Linden

unread,
Apr 5, 2024, 10:49:06 AM4/5/24
to oSCR
Sweet!  Yeah, the offset seems like a reasonable constraint that obviously saves you a parameter.  But is also makes an explicit assumption about the relationship between effort and encounter, which may not turn out to be reasonable.

There must be some bug in how formulas are used in oSCR that causes problems for the offset.  But again, given your estimate is very different from 1, I'd be hesitant to use an offset either way.

Jeffrey Royle

unread,
Apr 5, 2024, 12:24:34 PM4/5/24
to oscr_p...@googlegroups.com
thanks Dan, I'm glad you figured this out!   I remember now that it came up once a few years ago.


Reply all
Reply to author
Forward
0 new messages