Telemetry in SECR

[Prashant Mahajan]

Hi all,

I’m currently running spatial capture–recapture models in secr using a dataset that includes both genetic recaptures and telemetered individuals. Here's summary of the combined data:

Object class       capthist 
Detector type      count, telemetry 
Telemetry type     concurrent 
Detector number    331 
Average spacing    999.6544 m 
x-range            694753.8 734394.7 m 
y-range            5356750 5399730 m 

Usage range by occasion
    1 2
min 0 0
max 1 1
                    1     2 Total
n                  39    18    57
u                  39    10    49
f                  41     8    49
M(t+1)             39    49    49
losses              0     0     0
detections         85 14945 15030
detectors visited  58     0    58
detectors used    331     0   331

Empty histories :  10 
18 telemetered animals, 8 detected
76-2801 locations per animal, mean =  830.28, sd = 672.52 

Where I have 18 collared individuals with around 15000 fixes in total. Whenever I try to run the model using the full telemetry dataset, I get the following error: "Error: c,m,t combinations exceed 1e8 in gethr". I was able to run the model successfully only after reducing the number of telemetry fixes to around 70 per individual. I also tried removing the 3 individuals with fewer than 300 fixes and then limited the others to 300 fixes each. While the model ran in those cases, the estimates returned were NA, even when I tried scaling the telemetry contribution from 1e3 up to 1e30.

I would like to include the full telemetry dataset in the analysis without reducing the number of fixes. I’d appreciate any guidance or suggestions on how to do this.

Best Regards,

Prashant

-------------------------

[Murray Efford]

The problem (product c.m.t) is too big as you have defined it. Here I think

c = number of distinct levels of the detection parameters (determined by model which is not shown in the post)

m = number of mask points (not shown but probably several thousand)

t = number of telemetry fixes (14945)

You could try reducing any of these. I would start by asking whether there is any value in using telemetry fixes like this. You already have a fair number of 'genetic' recaptures (46), and I always suspect that telemetry data introduce uncertainty (Is the time window the same? Were the telemetered animals truly representative? Is imprecision of sigma-hat really limiting? etc.). Using 70 fixes per individual sounds like a good compromise.

[Prashant Mahajan]

Thank you for your response. I used a constant detection model (fit.combined <- secr.fit(com, mask = mask2, detectfn = 'HHN', trace = FALSE, details = list(telemetryscale = 1e9))) without specifying any additional parameters. Initially, the mask contained approximately 8,000 points. I reduced this to around 5,000, which allowed the model to run, but I still received parameter estimates as NA—even after testing multiple values for telemetryscale.

I have genetic data for three years, with two distinct seasons per year. The telemetry data covers the same time period. I am estimating density separately for each season within each year and have pooled the telemetry data across all three years for each respective season, as only two individuals were collared during the first year. Including the telemetry data in the model resulted in sigma estimates that were roughly half the value of those obtained using only the genetic data.

How can I estimate the parameters without obtaining NA values? Would it help to further reduce the number of mask points, or should I consider including only those individuals that were collared during the specific season and year being analyzed?

[Murray Efford]

Your original summary showed one session, but now you imply six? Does it work without telemetry? Does it work with telemetry alone? NA values indicate that the model did not fit for which there are several possible explanations. See, for example, the troubleshooting appendix in the SECR book. That does not deal with telemetry, but it may give hints. One is to try starting values based on the non-telemetry data. Sometimes adding telemetry just doesn't work because of incompatibility with the capture data or telemetry overpowers the more important capture-recapture component. Are you sure that telemetry adds significantly to the capture-recapture analysis? I remain sceptical.

[Prashant Mahajan]

I’m running each session separately, one at a time. The models worked well without telemetry data, but when I try using telemetry data alone, the model doesn’t fit—even with around 70 location fixes per individual. I also tried fixing the initial values, but the fit still wasn’t satisfactory. I’m including telemetry data because some sessions have very few recaptures, and I was hoping the telemetry information could help compensate for that.

[Murray Efford]

OK. Thanks for spelling that out. As you can tell, I am not a fan of telemetry used like this - partly because telemetry often adds little, partly because the models become hard to fit, and partly because I think the results are unreliable (yes, I should document that sometime).  I'm sorry I can't be more helpful.

[Prashant Mahajan]

Thank you so much for the clarification and highlighting the challenges involved.