RDMultScaleOcc Encounter History and Time Intervals Question

[sobro17]

I've been working with single-season MultScalOcc models in RMark, and now am going to move into a robust design multiscale occupancy approach with multiseason data. For my spatial structure, I have 11 sites, and within those I have up to 4 sampling devices. Devices were set up twice throughout the year, and each time they were deployed, they were left out for 3 days. In the help tab in MARK, I was a bit confused by how I am supposed to organize my encounter histories for RDMultScaleOcc, and the example included with RMark does not explicitly walk you through this (though it does helpfully explain how to specify covariate name coding). For example: let's say at site #1, all the devices had a 100% detection rate for the first season, but only device #4 had detections in the second season.

Would it be written as

Option A: 111111111111000000000111
Option B: 111000111000111000111111

Or some other way?

Also, when specifying the time interval, would I be correct in assuming I should write it as time.interval=c(0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0)?

[rcscott]

I believe it should be written as Option A. You should have it so that the encounter histories are separated so that all of season 1 is together. Within seasons, sampling occasions should be paired together by device, which I believe you've already shown.

Your time interval looks correct.

[sobro17]

Thank you rcscott!

Some follow up questions- 1.how many mixtures should I specify, 4 or 3? In the RDMultScalOcc RMark example, it says the number of mixtures should be equal to the number of devices, which would mean 4 in my case. However, when I use this option, the call for ddl$p$primary puts out 111122223333, and this seems wrong, whereas if I put 3 (the number of sampling periods within a session), I get 111222333444 which seems more correct to me as that how my encounter histories are ordered. However, specifying mixtures = 4 results in my outputs making more sense, so I'm not sure where this puts me. Overall, it is a bit tough that in the RMark example, the number of devices and number of secondary sampling periods are both 3 so it's not entirely clear what the mixtures argument is referring to.

2. For theta covariates, what should the naming convention be? Is it just as simple as [Variable][Detector #], or do I have to specify it in the [Variable][Session][Primary] form even though all theta variables for primary samples at Site 1 Detect 4 would be the same?

3. For instances of missing data, RMark doesn't let you have tables with NAs for covariates of missing primary samples. Is the best way to fill in the tables by averaging the values of that covariate, or just putting in 0?

Thanks again!

[gcsOnPhidot]

Howdy, did you every get a definitive answer to your question regarding the mixture number? I haven't reached out to the author (Connor Wood), but had similar outcomes as you did; with the mixture set as the number of time replicates/sampling occasions (in my case 5) rather than the number of locations nested within sites (the worked example uses cameras ['# note: mixtures refers to the number of devices'], in my case it was a maximum 8 point sampling locations), Theta estimates actually made sense. This seems to be confirmed by the RMark output (this from a null model) when mixture was set as 5 (rather than 8 ); across two seasons, 8 theta parameters and 5 p parameters were estimated (truncated here after the second point), consistent with the sampling structure

Code: Select all

Real Parameter Theta
 Session:1
         1         2         3         4         5         6         7         8
 0.2617318 0.2617318 0.2617318 0.2617318 0.2617318 0.2617318 0.2617318 0.2617318

 Session:2
         1         2         3         4         5         6         7         8
 0.2617318 0.2617318 0.2617318 0.2617318 0.2617318 0.2617318 0.2617318 0.2617318


Real Parameter p
 Session:1
         1         2         3         4         5
 0.3363488 0.3363488 0.3363488 0.3363488 0.3363488

 Session:1
         6         7         8         9        10
 0.3363488 0.3363488 0.3363488 0.3363488 0.3363488