RE: Errors when adding telemetry in oSCR
Chris Sutherland
Just a quick addition – I updated the specification of the start values so that you can provide values for specific parameters only by providing a named vector. The fitting function will scan the vector provided in the ‘starts=’ argument and pick out elements that match parameters in the model.
Thanks Dan for your efforts getting the telemetry model working and for David for being willing to help with the troubleshooting. There are a lot of moving parts, so don’t hesitate to ask if something isn’t working and we will be happy to help out!
Chris
From: spatialcapt...@googlegroups.com [mailto:spatialcapt...@googlegroups.com] On Behalf Of Daniel Linden
Sent: Saturday, May 9, 2020 3:05 PM
To: spatialcapt...@googlegroups.com
Subject: Re: Errors when adding telemetry in oSCR
Hi Kylie,
David poses some good questions here, but I think the problem you're having is one that he and others have experienced. The starting values for sigma are based solely on the trapping, and I need to incorporate a calculation of mmdm (mean maximum distance moved) for the telemetry data. In the meantime, setting your sigma start to be something larger could help. Folks have often found that their fix data suggest a larger sigma and the likelihood function does not like when the starting value is too far off. It has actually been incredibly sensitive to it, for some reason.
If you specify getStarts = TRUE, then oSCR.fit will show you the starting values for each parameter (and their order, which could depend on how many covariates you have). With a null model for the sex-specific likelihood, it's p0, sigma, d0, and psi. Look at the values provided and then add this argument to the fit function again with the proper starting values:
start.vals = c(p0.start, sig.start, d0.start, 0)
The starting values are all on the relevant link scale (log always for sigma and d0). The psi parameter is logit link, so 0 usually works fine.
Anyway, try bumping sig.start up. Better yet, you could calculate the mmdm from your telemetry fixes and then use log(mmdm*0.5) for the starting value.
On Sat, May 9, 2020 at 1:18 PM Kylie C. <kylie.m...@gmail.com> wrote:
Hi all,
I am working on adding telemetry data to my multi-session oSCR models and I am running into some issues. I have the telemetry data subset to the respective session and then listed in the telemetry object. Some of the telemetered individuals were also captured in our sampling array so I also included a cap.tel object. I am just trying to run my initial null model while including telemetry data and I keep getting the error
Warning message:
In oSCR.fit(model = list(D ~ 1, p0 ~ 1, sigma ~ 1), scrFrame = deer_sftel, :
Something went wrong! Try better starting values.
So I was wondering if anyone has some insight. Thanks!
I am including my code below:
# create the individual by pixel frequencies of fixes
# I ensured that deer_sess1_telem has collared deer that were captured sorted first
nfix1 <- telemetry.processor(list(deer_ss_r150telem_final[[1]]),list(deer_sess1_telem))$nfreq
nfix2 <- telemetry.processor(list(deer_ss_r150telem_final[[2]]),list(deer_sess2_telem))$nfreq
# create the telemetry object for oSCR (note, nfix already a list)
deer_telem_thinned <- list(fixfreq=c(nfix1,nfix2), cap.tel=list(cap.tel1, cap.tel2),indCovs=list(data.frame(sex=deer_telem_sex1[,2]),data.frame(sex=deer_telem_sex2[,2]))) # this would not run if fixfreq=list(nfix1,nfix2)
deer_scrdata_wtelem <- data2oscr(deer_edf, sess.col=1,id.col=4,occ.col=2,trap.col=7,sex.col=5,
tdf=list(deer_tdf1,deer_tdf2),K=c(6,6),ntraps=c(122,84),remove.zeros=T,
telemetry=deer_telem_thinned) # telemetry bc it is already a list
deer_sftel <- deer_scrdata_wtelem$scrFrame
deer_sftel$mmdm
deer_sftel$mdm
## Models
deer_m_nulldens.nullp.nullsig.dep <- oSCR.fit(model=list(D ~ 1,
+ p0 ~ 1,
+ sigma ~ 1),
+ scrFrame=deer_sftel, ssDF=deer_ss_r150telem_final,
+ DorN="D", encmod="CLOG",
+ rsfDF=deer_ss_r150telem_final,RSF=TRUE,telemetry="dep",
+ trimS=deer_sftel$mdm)
Fitting model: D~1, p0~1, sigma~1, asu~1
Telemetry: dep
Using ll function 'msLL.sex'
Hold on tight!
2020-05-07 12:54:41
p0.(Intercept) | sig.(Intercept) | d0.(Intercept) | psi.constant |
Warning message:
In oSCR.fit(model = list(D ~ 1, p0 ~ 1, sigma ~ 1), scrFrame = deer_sftel, :
Something went wrong! Try better starting values.
--
You received this message because you are subscribed to the Google Groups "Spatial Capture-Recapture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialcapturerec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialcapturerecapture/1e26e554-aadc-4cc3-9790-a549558c7fdc%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Spatial Capture-Recapture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialcapturerec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialcapturerecapture/CAFWOE77U2qC4xNqPTXXiCiHunbmRr0%3DK94jxR3TaYqGuX2duyA%40mail.gmail.com.
Chris Sutherland
Ah, no, actually that was just some pseudo code from Dan I think. Here is an example using the multi-session simulation function:
#simulate MS data
data<- sim.SCR.ms(sessions=2, sex=TRUE, sex.ratio=0.5, N = 100, K = 3,
alpha0 = -1.5, sigma = 0.5, discard0 = TRUE,
array3d = FALSE, ssRes = 0.5)
#model to fit
mod <- list(~session, ~session, ~session)
#get the parameter names (for not the null model, its model its situation specific)
oSCR.fit(mod, scrFrame = data$sf,ssDF = data$ssDF, getStarts = TRUE)
$parameters
[1] "p0.(Intercept)" "p0.session2" "sig.(Intercept)" "sig.session2" "d0.(Intercept)" "d.beta.session2" "psi.constant"
$values
[1] -3.03 0.00 -0.59 0.10 -2.35 0.10 0.00
#now set specific starting values:
specific.starts <- c("sig.(Intercept)" = 10,
"sig.session2" = 0) #contrast!
#have at it J
oSCR.fit(mod, scrFrame = data$sf,ssDF = data$ssDF, start.vals = specific.starts)
Hope that helps!
From: spatialcapt...@googlegroups.com [mailto:spatialcapt...@googlegroups.com] On Behalf Of Kylie Curtis
Sent: Saturday, May 9, 2020 5:04 PM
To: spatialcapt...@googlegroups.com
Subject: Re: Errors when adding telemetry in oSCR
Hi Chris,
Just to make sure I understand, the names of variables in start.vals should be p0.start, sig.start, d0.start or should they be D, p0, sigma, and asu? So if I just wanted to change sigma, I could put start.vals = c(sig.start=6.92)?
Thanks for the clarification!
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialcapturerecapture/007301d6263b%242bb75750%24832605f0%24%40gmail.com.
--
Kylie Curtis
MS Candidate
Conservation Ecology Lab
San Diego State University
--
You received this message because you are subscribed to the Google Groups "Spatial Capture-Recapture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialcapturerec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialcapturerecapture/CAH5svEp4FcfX2FwrGgiX0VQjMUg%3DFqEdrOewk21YBOyF6pkpcw%40mail.gmail.com.
Chris Sutherland
I guess it depends. For efficiency I usually make the statespace ~4 pixels per (assumed) home range size (or there abouts). This would be a a little (too?) course for a rsfDF. So it depends what the ssDF looks like. I could be off-base here though - Dan can speak to this more.
From: spatialcapt...@googlegroups.com [mailto:spatialcapt...@googlegroups.com] On Behalf Of Kylie Curtis
Sent: Monday, May 11, 2020 2:39 PM
To: spatialcapt...@googlegroups.com
Subject: Re: Errors when adding telemetry in oSCR
Chris,
1. Yes it works and the outputs make sense
2. I am using the same SS for both ssDF and rsfDF, so yes - is that a problem?
And Dan, I will try a bit more trouble shooting today with a single session model but if a successful run eludes me I will reach out, I appreciate the offer!
On Mon, May 11, 2020 at 11:34 AM Chris Sutherland <chris...@gmail.com> wrote:
Hi Kylie,
A few things:
1. Does the model *without* the telemetered individuals work?
2. Does the state space completely contain the rsfDF?
Chris
From: spatialcapt...@googlegroups.com [mailto:spatialcapt...@googlegroups.com] On Behalf Of Kylie C.
Sent: Monday, May 11, 2020 2:26 PM
To: Spatial Capture-Recapture <spatialcapt...@googlegroups.com>
Subject: Re: Errors when adding telemetry in oSCR
Okay, so after updating my sigma starting value to log(telemetry mmdm *0.5) I am still getting the same warning message. I am starting to trouble shoot with changing other starting values based on the outputs of my scat models but I am wondering if you had any additional suggestions.
Things I have tried:
- Modelling with telemetry="ind" to see if it was something to do with my cap.tel object but that model also failed with the same warning message.
- Increasing my buffer size and that caused my R session to abort. This did bring up the question, should I be buffering telemetry locations the same amount that I am buffering scat trap locations? When I first started modeling I did not buffer telemetry locations by much considering the AC of those individuals will be interior to all their telemetry locations, but is there some reason that the model would treat these telemetry locations like scat individual captures where the AC could be further out?
Things I am thinking of trying:
- Setting a fixed sex ratio - the sex ratio of my telemetered individuals is different from the scat individuals because we had a set number of male and female collars.
- Try to get a single session model to work first
- Try with fewer telemetered individuals
Another thought, since p0 is 1.0 for telemetered individuals, am I somehow miss-specifying that in my model, or is the oSCR.fit() function accounting for that when I include telemetry data?
Finally, I currently do not have any spatial covariates on my rsfDF because I am just running a null model with telemetry data to improve sigma and density estimation. Could this be causing my failed models?
Thank you for any and all suggestions! I know that the final solution to this problem will be specific to my system and data but I am definitely interested to hear what others have tried that has worked for them.
- Kylie
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialcapturerecapture/cae17e7d-0992-48ee-9080-f969427dee14%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Spatial Capture-Recapture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialcapturerec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialcapturerecapture/008801d627c2%24dc0397d0%24940ac770%24%40gmail.com.
--
Kylie Curtis
MS Candidate
Conservation Ecology Lab
San Diego State University
--
You received this message because you are subscribed to the Google Groups "Spatial Capture-Recapture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialcapturerec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialcapturerecapture/CAH5svEo_%3DGN7eVLLb14cTHuobLzBfMdVbkLh9Q%2B23BNMS57qbA%40mail.gmail.com.
Daniel Linden
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialcapturerecapture/00ca01d627c8%247edf8a90%247c9e9fb0%24%40gmail.com.
Chris Sutherland
Thanks Dan.
In terms of this particular situation, or others, though: making sure the data have been constructed at a sensible scale/resolution is a good first step. I think you could to a quick check to see, for each individual, how many ‘used’ pixels you have as a first indicator of whether the resolution might be an issue?
--
You received this message because you are subscribed to the Google Groups "oSCR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oscr_package...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/oscr_package/CAFWOE76G2yT3ay4LmatM2g%2BVD7ziEk9LcRmfeKWoXq%2BXYwyJOA%40mail.gmail.com.
Chris Sutherland
Ah, yes, that comment, as with the cost surface models, should read “with a resolution AT LEAST matching the state space. Okay, so worth developing the (my!) intuition a bit here:
I think of SCR as consisting of several scales of selection (e.g., 1st 2nd 3rd sensu Johnson 1980: https://esajournals.onlinelibrary.wiley.com/doi/abs/10.2307/1937156). And the various model components can, in certain situations, be linked to these orders of selection. The SCR model for density (or where individuals center their home ranges) is explicitly related to the definition of the state space, in particular the resolution. We can construct a coarse state space to approximate (infer) where an individual’s activity center is located - finer better approximates continuous space, but in the SCR book (Table 6.1) you see a coarse state space (½ sigma) is as good as a much finer grid but far more efficient, I think you can go coarser still and see estimates remain insensitive. So, I take back the 4 pixel rule for now, and replace it with a multiple of sigma: 0.5 sigma seems sufficient, and perhaps even 1 sigma spacing is fine.
Now, for the other important SCR sub model – the detection, or space use, model, once you start using the cost or resource selection function, the focus shifts from where individual home ranges are located, to how animals use the space *within* that area. This led to me stating in the 2015 MEE non-Euclidean distance paper (https://besjournals.onlinelibrary.wiley.com/doi/10.1111/2041-210X.12316) “We make the distinction between the region of interest S, and the cost covariate surface V, because it is not necessary for the resolution of both to be identical, although the resolution of landscape V must be at least as fine as that of S.” I said this, and in fact always use a *finer* resolution cost surface, because the two are approximations of space for two different processes, each with different relevant scales. I assume this is also the case for the rsf model too.
So, my recommendation, which will slow things down, would be to choose resolutions for the xxDF objects (ssDF, costDF, rsfDF) that are sensible relative to the process, or, closing the loop, scale of selection.
More of a ramble here, and more than you asked, but hope its of some use.
Chris
From: spatialcapt...@googlegroups.com [mailto:spatialcapt...@googlegroups.com] On Behalf Of Kylie Curtis
Sent: Monday, May 11, 2020 5:33 PM
To: spatialcapt...@googlegroups.com
Subject: Re: [oscr] Re: Errors when adding telemetry in oSCR
Just to clarify, Chris do you mean 4 used pixels per individual for the ssDF or the rsfDF? I followed recommendations from your 2019 oSCR paper: setting resolution to be ~1/2 of approximate sigma (so since sigma is 256m from the scat data I set resolution to be 150m) and making the rsfDF have the same resolution as the ssDF per:
oSCR allows both independent and dependent telemetry data and various options for the degree of telemetry integration. In all cases, fixes need to be summarized as pixel counts within the state space (with functions provided to achieve this) and RSF integration requires an additional data frame, rsfDF, similar to the costDF, with a resolution matching the state space
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialcapturerecapture/00ed01d627d5%243f15d100%24bd417300%24%40gmail.com.
--
Kylie Curtis
MS Candidate
Conservation Ecology Lab
San Diego State University
--
You received this message because you are subscribed to the Google Groups "Spatial Capture-Recapture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialcapturerec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialcapturerecapture/CAH5svEpFcT59GxxBh%2BnpFi30tGmQNj9H9je4K3d8Be32FtXthw%40mail.gmail.com.
Daniel Linden
To view this discussion on the web visit https://groups.google.com/d/msgid/oscr_package/003c01d627e2%24e12b1ec0%24a3815c40%24%40gmail.com.