glmmTMB / glmmTMB

glmmTMB
298 stars 61 forks source link

refit behavior #549

Open florianhartig opened 4 years ago

florianhartig commented 4 years ago

Hi guys,

up to now, I had used my own refit function in DHARMa to link to glmmTMB, but since you have now implemented a refit function, I wanted to switch to that. I have, however, been running into some strange errors with that switch. It's hard to pin down what the problem is, because I get the errors in my unit tests, but I can't reproduce them in when running the code in the console. In any case, it seems that the refit sometimes does not work.

I have therefore tried to play around with the refit function, and there is one strange behavior that I wanted to ask about: check out the following code: an object that was refit cannot be refit again - is that expected?

library(DHARMa)
library(glmmTMB)
library(lme4)

testData = createData(sampleSize = 200, randomEffectVariance = 1.5, family = poisson(), numGroups = 20)
m1 <- glmmTMB(observedResponse ~ Environment1 + (1|group), family = "poisson", data = testData)

m2 = refit(m1, newresp = simulate(m1)[,1])
# m2 looks like a normal glmmTMB object. But this doesn't work
m3 = refit(m2, newresp = simulate(m1)[,1])

# no problem with lme4
m1 <- glmer(observedResponse ~ Environment1 + (1|group), family = "poisson", data = testData)
m2 = refit(m1, newresp = simulate(m1)[,1])
m3 = refit(m2, newresp = simulate(m1)[,1])
bbolker commented 4 years ago

Just to say that this is neither expected nor desirable, but also not terribly unsurprising since refit depends on update(), which in turn relies on re-evaluating an expression, and because there is some messing around with the 'data' argument to set the new response variable ...