www.phidot.org

Is there a way to specify g0 and sigma values for detector-level covariates in secrdesign (or, directly in sim.capthist)?

In a previous study, we've used three different collection devices to snag bear hair for DNA samples. In order to model the effects of these different devices, we included a detector-level covariate in the model for both g0 and sigma. This worked out really well, and we'd like to use these same detectors in a different area. We are working to design an optimal layout for the new area using the secrdesign package, but I cannot figure out how to specify the g0 and sigma levels for the different detector covariate levels.

What I've started out with is:

Code: Select all

scen6 <- make.scenarios(D = c(0.0025, 0.005, 0.0075, 0.001), sigma = 5115, g0 = 0.0054,
                        noccasions = 4, detectfn = "HN")
scenarioSummary(scen6, trapset = traps.all)
sims6 <- run.scenarios(nrepl = 50, trapset = traps.all,
                       scenarios = scen6, seed = 99801, fit = FALSE,
                       fit.args = list(detectfn = 0, model = list(g0~trap.type,
                       sigma~trap.type)), det.args = list(binomN = 1), ncores = 4)

But what I really want to do is somehow specify values for the different trap types (i.e., g0.snag, g0.corral, g0.rubtree, sigma.snag, sigma.corral, sigma.rubtree).

Thanks!

Assuming all your detectors work independently (i.e. they're not traps) then I think you get the result you want by notionally operating them on successive occasions, controlled by the 'usage' attribute, and giving sim.capthist a vector of time-specific g0 or sigma.

Here's an example with two types of detector. Not sure how it will go with secrdesign, but worth a try.

Code: Select all

grid <- make.grid(5,5, spacing = 20, detector = 'proximity')
circ <- make.circle (25,100, detector = 'proximity', origin=c(40,40))
usage(grid) <- cbind(matrix(1, nrow=nrow(grid), ncol=3), matrix(0, nrow=nrow(grid), ncol=3))
usage(circ) <- cbind(matrix(0, nrow=nrow(circ), ncol=3), matrix(1, nrow=nrow(circ), ncol=3))
layout <- rbind(grid,circ)
usagePlot(layout)

ch <- sim.capthist(layout, popn=list(D=10, buffer=100), noccasions = 6,
    detectpar = list(g0=rep(c(0.1,0.6), c(3,3))))
plot(ch, border=10, vary=F, tracks=T)
summary(ch)$counts
                   1  2  3  4  5  6 Total
n                  4  3  7 43 41 47   145
u                  4  3  4 41 10  7    69
f                 18 27 23  1  0  0    69
M(t+1)             4  7 11 52 62 69    69
losses             0  0  0  0  0  0     0
detections         6  3  8 62 61 67   207
detectors visited  6  3  6 24 23 24    86
detectors used    25 25 25 25 25 25   150


Thanks, Murray. That is the same approach I took in a different project and it worked great. I hadn't made the leap to simulating capture histories like that, and your example was very helpful. I'm still not sure I can easily use this with secrdesign, but it is relatively easy to manually code up my own simulations and fit multiple capture histories directly with secr.fit.

Everything runs without a hitch using a single detector type, but what I really have are 2 different detector types: a baited corral with a detector type of "count", and a single-catch hair snare, with a detector type of "capped". Actually, I'll have a third (rubtree, detector = "count"), but that's for later. I've used designs with multiple detector types before (count and multi) with no problems, but this time I am receiving the following error:

Code: Select all

> summary(traps2.all)
Object class       traps
Detector type      count, capped, count, capped, count, capped, count, capped
Detector number    253
Average spacing    3277.859 m
x-range            620000 745000 m
y-range            795024 875000 m

 Usage range by occasion
     1  2  3  4  5  6  7  8
min  0  0  0  0  0  0  0  0
max 10 10 10 10 10 10 10 10

> ch <- sim.capthist(traps2.all, popn=list(D=densities[4], buffer=100), noccasions = 8,
                   detectpar = list(sigma = rep(c(sigma.yak, sigma.snare), 4),
                                    g0 = rep(c(g0.yak, g0.snare), 4)))
> summary(ch)
Object class       capthist
Detector type      count, capped, count, capped, count, capped, count, capped
Detector number    253
Average spacing    3277.859 m
x-range            620000 745000 m
y-range            795024 875000 m

 Usage range by occasion
     1  2  3  4  5  6  7  8
min  0  0  0  0  0  0  0  0
max 10 10 10 10 10 10 10 10

Counts by occasion
                    1   2   3   4   5   6   7   8 Total
n                  60  43  55  44  64  36  60  32   394
u                  60  41  38  32  34  26  28  20   279
f                 189  67  21   2   0   0   0   0   279
M(t+1)             60 101 139 171 205 231 259 279   279
losses              0   0   0   0   0   0   0   0     0
detections         70  44  58  47  71  37  69  32   428
detectors visited  47  44  43  47  53  37  43  32   346
detectors used     81 172  81 172  81 172  81 172  1012

> fit <- secr.fit(ch, model = list(g0 ~ type, sigma ~ type), mask = mask, detectfn = 0)

Error in reduce.capthist(capthist, outputdetector = "count", by = "all") :
  reduce.capthist does not yet handle mixed input detector types

I didn't get that in a previous study that also used mixed detector types. I suppose it isn't a big deal to set them all to "count" detectors. The single-use hair snags only allow a single detection, but doesn't restrict movement, so "capped" seemed more appropriate. Can I bypass that reduce.capthist step, or do you think the difference between "count" and "capped" isn't all that important if I'm also using a "trap type" covariate?

You're making me think... The 'capped' detector type is underdeveloped and under-documented - it ceased to be a priority when I found it made little difference. However, as far as I can see reduce.capthist is called by secr.fit only with the (default) fastproximity method; that can be suppressed with details = list(fastproximity = FALSE). I suggest you try that and let me know if 'capped' causes further problems.

Yes, that did the trick! Except, the processing time rose to 515 seconds, compared to 12 seconds if I use all "count" detectors and keep fastproximity=TRUE. So, for purposes of simulation, I'll keep all of the detectors set to a single type.

Thanks for all the help.

Poking around, I see that 'capped' was never expected to work in combination with other detector types (there was a bug in the check supposed to stop it). I'm glad you left that idea behind.