OpenCR- varying trends

[Clayton Lamb]

Hello

Foreword: I am reposting so Murray and I can continue this conversation here where it can be documented/used by others. So far he has suggested that I shouldn’t run a model where Lamba0 varies by trap_type without doing the same for sigma. This confuses me a bit, as I don’t expect the spatial scale of the detections to differ between the traps, I just know that one of the two trap types has ~1/4 the detection probability. Does that make sense or am I missing something? Murray also asked why I am using ~b, when I say ~bk usually fit well in our density models, which I only did because I didn’t see a bk option, only b, based on table 5 from the vignette (https://cran.r-project.org/web/packages/openCR/vignettes/openCR-vignette.pdf)

Two questions/observations as I work with the new openCR package:

1) I fit simple models for detection: ~1, ~b, ~ trap_type, ~trap_type+b. We know that our trap types (bait sites and rub trees) differ largely in their detection probability, and we often see the bk variable come out in density models, so these seemed like good candidate models. I found the results (screenshot attached) a bit confusing, as the trap_type variable drops out, and we know that this has a big effect on detection (Lamb et al. 2016 and work by others). I see that the trap variables add much information over the null, but somehow this b variable alone is better explaining the variation in detection than trap type. This seems odd to me. Do you have any insight?

2) My main goal is to estimate trend, and any variation in the trend through time. Just for illustrative purposes, I ran models that allowed for two values of population growth to be estimated, one in the early portion of the study (2006-2012) and one in the later (2012-2013). I ran these models with the ~ trap_type and ~trap_type+b detection variables . Surprisingly (which I say because I find density results from ‘secr’ to be rather insensitive to different detection covariates in my experience), the trend flips either increasing then decreasing, or decreasing then increasing, depending on the detection covariates used (results in screenshot, I use the derived density just to show the trends). This too seemed odd to me, and I found the sensitivity in the results concerning. Previously, we had shown a decline, using non-spatial open models between 2006-2013, so I am surprised to see a possible increase during this period with the inclusion of the b variable. Again, any thoughts on this?

Appreciate it,

Clayton

--
Clayton Lamb, PhD Candidate
South Rockies Grizzly Bear Project
S.Boutin and S.Nielsen Labs
Biological Sciences, University of Alberta 
e: ctl...@ualberta.ca
p: 778-215-0334
t: @ClaytonTLamb
w: www.lamb-eco-research.ca

[John]

For trend estimation only, I wonder (leaving any answers for Murray) whether the benefits of an open model (I guess Markovian constraints on changes in N?) outweigh the benefits of tackling this from a multi-session/strata perspective (the ability to explicitly model changes in D as spatial, temporal effects).

I'm also curious about compensation between lam0 and sigma for trap covariates. I think I follow the logic when it applies to individual variation (or say, landscape variation and RSF betas vs. lam0/sigma)--moving further distances suggests spending less time at any one location--but as a source of trap/point variation, I'm confused. Detectable space is so small for a hair-catch, camera, etc. that it seems to me that there could plausibly be an effect on lam0 without compensation in sigma because for some of these detectors, detection might be more sensitive to factors other than broad-scale movement. For a rub tree, lam0 seems to be a product of the frequency of being next to the tree and the likelihood or frequency of choosing to rub. Some jaguar studies suggest that females use less space than males, but also don't use big trails where the researchers are placing cameras. Certainly, females have to be spending more time off-trail, but for the purposes of detection given the design, female sigma and lam0 might be smaller. I'm curious as to what I'm missing or misunderstanding.

[Murray Efford]

For the record, my original offlist reply was

"Nothing much to say here - you are the one close to the data who can figure this out! It is inherently risky (and in my view illogical) to model lambda0 as a function of trap type while keeping sigma constant. Why if ~bk is a good model do you fit ~b?"

I stand by my statement about lambda0 and sigma, which was not directly about compensation. Detection probability is a function of both parameters (not lambda0 alone). Fixing sigma across types only makes sense if you are sure there no broad-sense behavioural effects. In Clayton's case it is entirely possible that the probability of interacting with a detector, given presence at the point, depends on where the detector is in the home range and differs between the two detector types; that would lead to a difference in sigma between types. Remember I was just throwing out cheap advice. Compensation is another story (both relevant and a perhaps red herring).

I had forgotten that openCR does not offer ~bk, but ~b is not a substitute - they are different models usually leading to quite different estimates (~bk often gives estimated densities close to null-model densities). There are also tricky questions about the duration of a learned response - I would skip it.

We have a lot to learn about the behaviour of open spatial models!

Murray

[John]

Thanks for the clarification:  ~bk is a great example for thinking about this. Yeah, an effect on lam0 seems to imply a very specific type of behavioral response to bait, etc.

Cheers,

John

[Michelle McLellan]

Hi, 

I am also interested in this topic.

I have run similar analyses using long term monitoring data where grizzly hair was collected from baited hair traps and rub trees.  The top models for g0 and sigma were the same for two different populations with different trends for density over time.  In both cases the top model (AIC weight>0.96)  had g0~ sex * traptype and sigma ~ sex. This seemed biologically logical because females and males rub with different probabilities and have different home range sizes. Other candidate models did  include sigma~ sex *trap type and various responses to previous capture (b and bk). 

A reviewer suggested that I remove models using sigma ~ traptype (even though it wasn't the top model ) because they could see no biological hypothesis for this. What do you think about that comment? In my example it ended up moot but I could see how there might be an effect.

Thanks,

Michelle

--
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.
For more options, visit https://groups.google.com/d/optout.

[Clayton Lamb]

Thanks for the information Murray, and additions from Michelle and John.

Michelle, my top models are the same as yours, lambda-~sex*Trap and sigma~sex, and the sigma~sex*Trap model is running right now. All resulting growth rates are comparable regardless of the model, so long as I don’t include the ~b..

Cheers,

CL

[Murray Efford]

I can't remember why there is no bk model in openCR. For fun I generated one with the custom design data option (see vignette):

makedf.bk <- function (ch, nmix = 1) {
    ch <- squeeze(ch)
    # Construct array of logical values TRUE iff caught at k on or before s
    detected.at.k <- apply(abs(ch), c(1,3), cumsum) > 0
    # TRUE only if detected at k before occasion s
    bk <- apply(detected.at.k, 2:3, function(x) {x[which.max(x)] <- FALSE; x})
    bk <- aperm(bk, c(2,1,3))
    n <- nrow(ch)
    S <- ncol(ch)
    K <- dim(ch)[3]
    data.frame(bk = insertdim(bk, 1:3, c(n,S,K,nmix)))  
}

## test against auto bk in secr.fit
msk <- make.mask(traps(captdata), buffer = 100, type = 'trapbuffer')
openCR.bk <- openCR.fit(captdata, type = 'secrCL', detectfn = 'HHN', model = lambda0~bk, mask = msk, dframe = makedf.bk(captdata))
secr.bk <- secr.fit(captdata, CL = TRUE, detectfn = 'HHN', model = lambda0~bk, mask = msk, trace = FALSE)

coef(openCR.bk)
# beta    SE.beta       lcl        ucl
# lambda0        -1.2307701 0.12603152 -1.477787 -0.9837529
# lambda0.bkTRUE  0.1709865 0.19772481 -0.216547  0.5585200
# sigma           3.3719294 0.04819498  3.277469  3.4663898
coef(secr.bk)
# beta    SE.beta        lcl        ucl
# lambda0        -1.2331212 0.12628479 -1.4806348 -0.9856075
# lambda0.bkTRUE  0.1782056 0.19810530 -0.2100737  0.5664848
# sigma           3.3725295 0.04825689  3.2779477  3.4671113

## close, but not identical (probably a minor numerical issue)

This effect persists from one primary session to the next. The capthist passed to makedf.bk() must already be 'joined' (cast as a single session)

On Tuesday, October 23, 2018 at 9:13:59 AM UTC+13, Clayton Lamb wrote:

Thanks for the information Murray, and additions from Michelle and John.

Michelle, my top models are the same as yours, lambda-~sex*Trap and sigma~sex, and the sigma~sex*Trap model is running right now. All resulting growth rates are comparable regardless of the model, so long as I don’t include the ~b..

Cheers,

CL

To unsubscribe from this group and stop receiving emails from it, send an email to secrgroup+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Murray Efford]

The discrepancy between results from the custom (openCR.bk) and secr.bk models turns out to be real - the custom bk option is not quite right for anything but a CJSsecr model. Technically - the parameter index array (PIA) was incorrect for naive animals. A canned bk predictor is in openCR 1.3.0 due out soon; 1.3.0 also enables valid custom predictors with learned responses (the naive PIA problem).