Model failures: default starting values and trap covariates in oSCR

[Sarah Carroll]

Hello all, 

I am aware there is a separate Google Group for oSCR, but I haven't been able to get access to the oSCR group, so I am positing here. I have a large SCR dataset, and I'm using the latest version ( 0.42.0) of the package oSCR to analyze these data with hopes of producing density weighted connectivity estimates. I have 1914 trap locations, 303 individuals and 425 spatial detections. Thus the state-space is quite large  

I am using the oscr.fit function to fit models and get default starting values for my parameters, but this has proven challenging so far. I was able to successfully fit a null model, which took about 8 hours to run with this dataset. I am now trying to run detection sub-models. However, whenever I add covariates on detection (p0) and use default starting values provided by the oscr.fit function the models run initially, but then fail after several hours or even days, with the error message: warning ( "Something went wrong! Try better starting values.") 

I have double checked my scr.Frame, and checked to make sure that all covariates are scaled and/or centered. I have both continuous covariates and binary covariates (e.g., 1 or 0 representing the trap type). I reduced my UTM coordinates to kilometers as well. I don't get any errors or warnings with oSCR functions, including oscr.fit prior to actual model fitting, so I am somewhat stumped on what is going wrong here. I have started to comb through the source code for oscr.fit, but I can't quite untangle the syntax to understand what is happening mathematically when the models fail at this stage.  

What I did notice was the oscr.fit (get starts = T) returns a default starting value of 0 for all of the covariates on p0, which seems uninformative. Currently I am experimenting with replacing those 0's with a more informative starting value based on general hypotheses, e.g. an increase in forest cover increases probability of detection to see if this could possibly help with model convergence. 

Any insight would be greatly appreciated! 

- Sarah 

 

[John]

Chris Sutherland is the expert on that software (and hopefully he sees this), but something that generally helps regardless of package is using estimates from a fit null model as the starting values for the sigma, g0, density intercepts. No idea what the specific error means, but if it uses nlm to optimize(?), the underlying algorithm takes occasional big exploratory jumps that can cause things to crash.

John

[John]

I should clarify before making a problem worse: estimates on the *link* scale.