I think there are two issues here, both resulting from the fast option for 'proximity' and 'count' data that is the default in secr 4.0.2 (details = list(fastproximity = TRUE); see secr-version4.pdf).
The first is that the fastproximity option causes sampling occasions to be collapsed, and as a result these models are not comparable by AIC to those with fastproximity = FALSE. The catch is that while fastproximity is the default, certain models (~b, ~bk, ~t etc.) silently override that default. The user can take control by setting details = list(fastproximity = FALSE) for all models to be compared. I'm sorry to have laid this trap for users - will see what can be done to warn or correct this.
The second issue is that the fx functions fail with models in which the details component has fastproximity=TRUE. This bug will be fixed in the next release, but meantime there is a simple workaround
- Code: Select all
fit$details$fastproximity = FALSE
fx.total(fit) # etc.
The model fit is fine in itself, it's re-application of fastproximity that is the problem. Although the fx functions tested fine with multicatch data, they had not been tested recently against proximity data. Thanks again for reporting this.
Murray