"maxg stop in simsecr" message using secr.test

[Amanda Zak]

Hi secr group,

I have a fitted model and was hoping to use some assessment of goodness of fit. My traps are transects, and I have a large study area with 120 transects across about 130 square km. Naturally, the mask object is pretty big and the model fitting was slow.

From documentation, it appears that MCgof() will not work due to the transect detectors. Secr.test will work, though the default metric of first detections isn't appropriate because animals could be detected more than once per occasion. I decided to try secr.test with the deviance metric provided in the example code (I also tried the default metric because I was curious how off it might be).

bothfn <- function(object) {
  CH <- object$capthist
  f1 <- sum(apply(abs(CH) > 0, 1, sum) == 1) / nrow(CH)
  devdf <- deviance(object) / df.residual(object)
  c(f1 = f1, devdf = devdf)
}

test <- secr.test(mod, nsim = 1, seed = 102, ncores = 23,
          statfn = bothfn)

I tested this function on just one single simulation, and with a simpler model than the one I'd actually like to evaluate. Even still, after 24 hours, the single simulation was not complete. The only output was the message "maxg stop in simsecr". I haven't been able to find this message in any of the underlying function code for secr.test or sim.secr, so I'm guessing it's a C++ thing? I can't tell if it's an error message or just normal reporting, but something doesn't seem right if I can't even get one simulation done in 24 hours with a simplified model - there's no way I'd be able to do 99 with my full model.

Does anyone have insight on this "maxg stop in simsecr" message?

[Murray Efford]

Amanda

I can confirm that the message is from the C++ simulation code. I can't easily see what triggers it. Possibly it happens when there are no simulated detections on a transect (yes, that would be a bug).

Apart from the possibly unhelpful advice that goodness-of-fit tests for SECR never illuminate much and I don't use them,  my first impulse is to reduce the size of the problem. If the transects are a constant size and shape and you are not modelling spatial variation in D, then they can be modelled as multiple instances of one transect. Discretisation as multiple point detectors is more robust and flexible. I hope you are using type = 'trapbuffer' in make.mask, and setting a suitable spacing e.g. 0.5 sigma.

I'll test the simulation code when I get time, maybe later this week.

Murray

[Amanda Zak]

"Goodness-of-fit tests for SECR never illuminate much and I don't use them" is a perfectly good answer to me. A goodness-of-fit test was suggested to me, but was not originally in my plans. Unfortunately I am modeling spatial variation in density. I did use 'trapbuffer' and a spacing of 0.5 sigma. If it's not necessarily an error message, and the simulation could potentially succeed if given long enough, then it still wouldn't be feasible for me to run 99+ simulations - it would take months - so I think I have my answer here.

Thanks Murray!