www.phidot.org

Hi all,

I'm trying to create a capthist for a multi-session model where the detector usage differs between sessions. Specifically, in the first session all detectors were used on every one of seven consecutive occasions (usage = 1111111).
However, in the second session the detectors were used over thirteen occasions, with either all or none of the detectors being used, in the pattern 1110001100011.

Following the advice of "varying effort" PDF, I've created two separate trap files for the two sessions, and listed them in a vector in the "trapfile" argument of read.capthist.

Therefore a generic version of my code is:

Code: Select all

capthist<-read.capthist(captfile.csv, c("trapfile.session1.csv","trapfile.session2.csv"),fmt="trapID",detector="single")

It's returning this error:

Code: Select all

Error in read.traps(file = trapfile.session1.csv", detector = "single",  :
  'usage' fields suggest varying number of occasions

Clearly, I have 7 occasions for the first session and 13 the second. Is this disallowed? I'm sure I remember reading somewhere that multisession models had to have the same number of occasions per session, but I can't find it now and am beginning to doubt my memory...

Hi Phil
It is no problem for different sessions to have different number of occasions. I suspect an error in your input (e.g. occasion number in captures exceeds columns in usage). I suggest you try a test using read.traps to input the trap data alone.
Murray

Looking at this again - the most likely cause is an error in the 'usage' fields of your trap layout file. However, I don't really see why you want to include 'occasions' on which no detector was used. Aren't these just non-occasions like all the other times you didn't sample? And if usage was uniform over all detectors then you may as well drop the usage fields altogether. Maybe I'm missing something.
Murray

Murray,

Thanks for the guidance. I've checked my trap files and capture files very carefully, and I'm pretty sure that my binary string corresponds correctly to the occasion numbers I've specified in the capture file.
I've also tried removing the multisession element (i.e. trying making the two sessions separate models), and in both cases read.capthist returns the same error. This is even true of the first session where all detectors were used for all of seven days (i.e. "usage" =1111111, and occasions are numbered 1-7). So it's not a problem of the number of occasions being different between sessions. It seems to a fundamental problem with how read.capthist is dealing with the usage field

I tried using read.traps to read in my trap files on their own, this worked fine:

Code: Select all

F100.2.traps.2011<-read.traps("F100.2.2011.mod.txt",detector="single",binary.usage=TRUE)
F100.2.traps.2012<-read.traps("F100.2.2012.mod.txt",detector="single",binary.usage=TRUE)

However when I use make.capthist to string them together with the capture files:

Code: Select all

f1002ch<-make.capthist("f1002ch.csv",c(F100.2.traps.2011,F100.2.traps.2012),fmt="trapID",noccasions=c(7,13))

the error returned is

Code: Select all

Error in captures[, 1] : incorrect number of dimensions

Seems like there's a fundamental problem with how read.capthist and make.capthist are relating the binary string in my usage column to the occasion numbers given in the capture file.

As for your other point, the two sessions have the same overall sampling effort (7 days) but one is spread over 13 days of actual time. It seems to me that if you ignored the "non-occasions" in the middle of the second session and collapsed it down to the same length as the other session by removing them, you'd still effectively be comparing a 13-day sampling period with a 7-day sampling period. All else being equal, I'd have thought that animals would move a greater net distance in a longer time period, and that difference in movement might affect your estimates of how detectability declines with distance from home range centres. Surely it's better to account for the quite different pattern of sampling here by having zero-effort occasions interspersed appropriately?

Phil

Your rationale for inserting null occasions doesn't wash. SECR in general, and this implementation in particular, treats detections on each occasion as independent draws from a stationary distribution i.e. there is no concept of a serially correlated movement model. So inserting those usage zeros is just asking for trouble.

I still suspect some data problem. Can you please send example capture and trap layout files that generate the error? If there is a code problem that will help me find it.

Murray