It's a good idea to some extent. However, there are cases in which boundary conditions will throw things off. So if a parameter x has an lbound of zero, and if the parameter at this value is say 2.5 units of -2lnL worse than where it started, the lower CI is indeed zero. The optimizer will, however, have strayed from the ML position (only 2.5 units worse) and actually degraded the fit further (by moving the other parameters away from what their MLE's would be if x was fixed at zero). So some flagging of when parameters are at bounds would be useful in conjunction with it.
I do see a lot of folks antsy about code Red. It is a poor diagnostic, much more often false positive than true positive in my experience. So hiding this a bit from the user might be beneficial, but at the same time it should be available for inspection.
Distance of the parameter from its MLE is only helpful in cases in which it got stuck at its MLE (and this value was not its lbound or ubound). We might make use of the asymptotic standard errors as a rough check, although these are provided only for free parameters, not for functions thereof. Some matrix calculus software would help with getting SE's of functions of parameters but that's at least version 2.0 down the road, I reckon. Note also that for computed elements we may not be able to "know" that it's effectively a boundary (x^2 would have lower bound of 9 if the lbound of x was 3, for example).
I agree it is probably better not throw the optimiser warnings (code green or red) by default: just trains people to ignore them if they are mostly false.
Most people will run summary on the fit... Perhaps put a "health" parameter into the summary, which would have the model "color" in it. Then it can be seen, without being dumped into the console, and people can followup on it if necessary?
Copyright © 2007-2017 The OpenMx Project