Debugging help: How can I trace an error that occurs before a model restart?

[billdenney]

I have a model where I get the following error:

Error in names(object) <- nm : 
  'names' attribute [14] must be the same length as the vector [0]

and, after the error, I see "Restart 1" (or 2 or 3). I'd like to trace where that error occurs, but my normal method of options(error = recover) doesn't work because it's not an error (or I think more accurately, it's captured internally). Is there a way that I can trace the error to its source?

[mattfidler]

options(nlmixr2.retryFocei=FALSE)

Would probably work.

[billdenney]

Thanks, that helped.

My error is coming from here:

nlmixr2est/R/focei.R

Line 1397 in 74a732e

.ret$thetaIni <- setNames(.thetaReset$thetaIni + 0.0, .nm)

The error message from foceiFitCpp_() appears to be "theta reset0" which seems to indicate a zero gradient.

Looking more into the code, my best guess is that thetaReset is not being assigned within inner.cpp. My guess is that doAdjust is not set to true before here, so it's never calling thetaReset00 below here:

nlmixr2est/src/inner.cpp

Line 1988 in 74a732e

if (!doAdjust) return false;

Any insight into how I could troubleshoot more (realizing that I can't share the model/data itself)?

P.S. I may be able to make a reproducible example, eventually because the underlying issue is a parameter that is not informed by any of the data.

[billdenney]

P.P.S. My attempt to replicate the error in a model I could share gave a different zero gradient error. I don't know of a simple replication method.

[mattfidler]

This is probably the hardest part to debug, but perhaps I can do something...

[billdenney]

Is there a sprinkling of printfs that may help (without being too much noise in the inner loop)?

[mattfidler]

You could add where it is wherever the thetaReset is called, but you would need to use something like REprintf() instead of printf.

I can't simply look at the code and figure out what is going on in your case (sorry).

[billdenney]

I just changed the function so that it moved the doAdjust test to the bottom of the function. Specifically, I moved this line

nlmixr2est/src/inner.cpp

Line 1988 in 74a732e

if (!doAdjust) return false;

To just above this line

nlmixr2est/src/inner.cpp

Line 2009 in 74a732e

return true;

Then, I got the following message, and estimation continued:

Theta reset (zero/bad gradient values); Switch to bobyqa

That seems like the desired behavior when there is a zero derivative, but maybe I'm missing something important. Would that be a good fix? It does appear to be related to not calling the thetaReset00() function, but I don't know what is happening in that part of the code well enough to be sure that it's a good fix.

[mattfidler]

Well if there is a zero gradient then yes that is a good fix.

But, the adjust readjusts the parameters to the correct scale sometimes changing from an eta drift to modifying the theta and then continuing the estimation

[billdenney]

(TL;DR: Should I move line 1988 to just before 2009 as a PR for this? I'm not sure.)

My real issue with this model is that there is a zero gradient that does not appear until after the initial estimation; I don't know exactly the cause (I would have thought that one of the parameters would have a zero gradient on the first estimation step), so I can't readily make a reproducible example that I can share.

The "But..." part makes me wonder/worry that I shouldn't make the suggested fix. It looks like the code after line 1988 is possibly shifting the etas around, and then thetaReset00() is called to send those results back out to R.

I don't think that doing the work of the lines after 1988 would be a problem, but I'm also not sure if I may be missing something.

[mattfidler]

I don't think that is the right solution. Without the adjustment you may not continue the optimization at the same point.

[mattfidler]

Could try #384