Page 1 of 1

Estimate is tiny and lambda is huge

PostPosted: Tue Dec 07, 2021 4:26 pm
by JohnNettles
Hello,
I'm working on a transect SECR and have run into some issues with fitting the model. I'm not using any covariates at the moment, just trying to get a general idea. We have 18 transects/detectors, 37 unique individuals, 3 occasions, and 135 detections. When I run the model using method='Nelder-Mead' I get a density estimate of 1.7e-21 and a lambda0 of 1.48e+40. I tried with the default model and received a much more realistic density estimate (~0.02) but lambda is still huge and the variances fail to compute for both lambda and sigma. Any suggestions?

Here is the code I'm using:
layer <- readOGR('OG_Transects.shp')
transects <- read.traps("OG_Detections_Scat.txt",detector='transect')
detections <- read.table("OG_Events_Scat.txt")
detections <- detections[,c(1:5)]

CH <- make.capthist(detections,transects, fmt="XY",tol=50,snapXY=T,noccasions=3)
transectmask <- make.mask(transects, type='trapbuffer',buffer=740, spacing=185)
results <- secr.fit(CH,mask=transectmask,binomN=0,method='Nelder-Mead',trace=FALSE,verify=F, start=list(D=0.001, g0=0.1, sigma=200))

Thank you!

Re: Estimate is tiny and lambda is huge

PostPosted: Tue Dec 07, 2021 4:35 pm
by murray.efford
Hi
As I understand, you fitted the _same_ model with different methods for maximisation?
There does seem to be a fundamental problem in your data (and transect methods can be greedy). If you want to send me the data offline I can perhaps see where it's going wrong.
Murray

Re: Estimate is tiny and lambda is huge

PostPosted: Tue Dec 07, 2021 4:44 pm
by JohnNettles
Hi Murray, that is correct.
If you're okay doing that, that would be very helpful. Thanks!

Re: Estimate is tiny and lambda is huge

PostPosted: Tue Dec 07, 2021 9:39 pm
by JohnNettles
Hi Murray, just let me know how you'd like me to send the data and I'll get it ready for you. Thanks again

Re: Estimate is tiny and lambda is huge

PostPosted: Wed Dec 15, 2021 3:24 pm
by murray.efford
Thanks to John for flagging the problem and sending data.
secr.fit() was not working with multi-part transect data. Also, it was unclear from the documentation whether the 'snapXY' functionality of make.capthist() worked for transects (some detections were recorded off-transect, but snapXY didn't apply to transect data). Also, snip() needed an additional 'tol' argument to make discretize() work in this case. These issues have been fixed (I hope) in the pre-release version secr 4.4.9 available as Windows binary and as the source code.
Murray