You are here


3 posts / 0 new
Last post
manu's picture
Joined: 10/08/2009 - 12:36

Dear all,
first of all, I love the new release - thank you so much!
However, when playing with the mxConstraint function, I encountered the following peculiar problem. When imposing the constraint
mxConstraint(varF1 == varF/(1-beta2))
I get the error message:
In model 'FAwithin' NPSOL returned a non-zero status code 6. The model does not satisfy the first-order optimality conditions to the required accuracy, and no improved point for the merit function could be found during the final linesearch (Mx status RED).
However, when turning the equation around and imposing the exact same constraint that way:
2)*(varF1)-varF == 0)
the model runs smoothly, the constraint works and I do not get any error message (but the SE seem to be incorrect). Are there some restrictions on how I have to impose a constraint?
Thank you!

tbrick's picture
Joined: 07/31/2009 - 15:10
It's tough to say what's

It's tough to say what's going on without seeing the actual code, but I can put forward a hypothesis, at least.

Your first formulation of the constraint is undefined when beta becomes very close to 1 or -1, while your second formulation does not. My guess is that your starting value is on one side of that boundary, and the solution is either very near the boundary or on the other side. The Code 6 might be a result of the optimizer getting stuck against the boundary.

You could try putting upper and lower bounds on beta if you have some idea of where your solution is, or simply try the optimization again from a few different starting points, some on every side of the boundary. The best bet, however, is to avoid formulations that have undefined regions.

Constraints, especially equality constraints, change the likelihood space and make the interpretation and calculation of standard errors somewhat ambiguous and difficult.

We recommend using likelihood-based confidence intervals as a better estimate of confidence boundaries. The CI interface for OpenMx is still in testing (although available in the latest SVN version if you'd like to try it). In the meantime, you can use the formulation in this thread:

manu's picture
Joined: 10/08/2009 - 12:36
that was a good guess! Indeed

that was a good guess! Indeed the starting values were at the boundary, so changing that resolves the problem. The standard errors remain incorrect, but I agree that likelihood based CI's are better and look forward to their implementation in OpenMx 1.0. At present they are not important to me. THANKS A LOT!