Camera trapping example analysis does not converge

[lenthomas]

The uniform + 3 cosine adjustment example in the camera trapping example never converges (well, I waited 45 minutes and it hadn't yet) in Distance 1.0.6 mrds 2.2.7.

DuikerCameraTraps <- read.csv(file="https://datadryad.org/stash/downloads/file_stream/73221", 
                              header=TRUE, sep="\t")

library(Distance)
conversion <- convert_units("meter", NULL, "square kilometer")
trunc.list <- list(left=2, right=15)
mybreaks <- c(seq(2, 8, 1), 10, 12, 15)

#Never converges
uni3 <- ds(DuikerCameraTraps, transect = "point", key="unif", adjustment = "cos",
           nadj=3,
           cutpoints = mybreaks, truncation = trunc.list)

One solution is to use the output of the previous analysis as the input to this one

#Set start points and then it converges
uni2 <- ds(DuikerCameraTraps, transect = "point", key="unif", adjustment = "cos",
           nadj=2,
           cutpoints = mybreaks, truncation = trunc.list)
uni3 <- ds(DuikerCameraTraps, transect = "point", key="unif", adjustment = "cos",
           nadj=3,
           cutpoints = mybreaks, truncation = trunc.list, 
           initial_values = list(adjustment = c(as.numeric(uni2$ddf$par), 0)))

I guess this should be standard practice for now? In the longer term, is there anything we can do to improve the convergence properties of the algorithm? Starting values of 0 for adjustment terms seems reasonable, which is what the first one does.

[dill]

Worth noting that if you don't specify the number of adjustments (run the above without nadj), the AIC-based model selection is used and this will then work as in this case parameters are passed on from one model to the next in the selection process. This is probably how most users would (should?) use the function?

[dill]

(Though I guess we should be using QAIC in the camera trap case?)

[lenthomas]

Yes, that's right, QAIC should be used in the camera trap case, and in order to use the QAIC function in Distance one needs to first manually fit all the models in your candidate model set.
It seems to me that using the fitted values from the previous lower-nadj analyis as starting values for the next one (with a zero for the new adjustment term) is good standard practice for this kind of manual incremental analysis. Do you agree @dill and @erex? If so, I'm happy to update the example analysis, to increase robustness for future iterations of the software, and demonstrate good practice. Thoughts?

[erex]

happy for the exercise to use starting values taken from less-complex fitted models.

…

On Mon, 10 Oct 2022 at 18:21, Len Thomas ***@***.***> wrote: Yes, that's right, QAIC should be used in the camera trap case, and in order to use the QAIC function in Distance one needs to first manually fit all the models in your candidate model set. It seems to me that using the fitted values from the previous lower-nadj analyis as starting values for the next one (with a zero for the new adjustment term) is good standard practice for this kind of manual incremental analysis. Do you agree @dill <https://github.com/dill> and @erex <https://github.com/erex>? If so, I'm happy to update the example analysis, to increase robustness for future iterations of the software, and demonstrate good practice. Thoughts? — Reply to this email directly, view it on GitHub <#132 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQX6C7DZUOSWGMIPUY6JLWCRGCJANCNFSM6AAAAAARA2QZHY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Eric Rexstad 20 West Braes Crescent Crail Fife KY10 3SY

[dill]

Agree but probably worth allowing for QAIC-based selection in ds() in the future?

[lenthomas]

Yes, I think this is an excellent idea for a feature enhancement. One could imagine fitting all the models up to max_adjustments (so that the fitted values of one are used as the start values for the next, except for the new parameter), and then calculating c_hat1 using the most complex one, and then doing model selection. It'd be good if it stored the c_hat1 somewhere as well (perhaps an attribute) and adds that to the printed output from the print and summary methods. Happy to discuss further - perhaps mark this topic as a feature enhancement - or I (or someone) could raise a new issue with this on it?

[dill]

Yes, shall I close this and start a new issue?

[lenthomas]

Sure, thanks.