From http://openmx.psyc.virginia.edu/thread/1443:

I wrote a simple OpenMx script to do LCA on ordinal variables. It works fine on simulated data. When I run it on real data, the estimated thresholds are not in order. I then included constraints on the thresholds (simple enough to do) so that they are monotonically increasing. This seems to work as the threshold estimates monotonically increase. From reading the manual, I was sure constraints weren't necessary.

Reporter:

Created:

Fri, 07/13/2012 - 11:12

Updated:

Sat, 04/23/2016 - 09:59

- Log in or register to post comments
- Printer-friendly version

## Comments

## #1

While it was believed interations that disordered the thresholds be rejection), this is not the case: they routinely get out of order.

Need to re-open this issue, and either fix it, build in the lower 1s solution to OpenMx internally (convert the input thresholds matrix to an algebra which multiplies some increments by lower 1 matrix) or tell users to implement the neale "increments x lower1s" solution to guarantee threshold order (and give them a way to do this in RAM type as well).

We do check that start values are ordered:

What don't error on adjacent thresholds which are identical: Seems to me this should be an error, as it makes it arbitrary which threshold a given latent score will lead too...

Perhaps set a minimum delta or something?

## #2

Believed to be fixed.

## #3

## #4

I don't think that this problem was ever fixed. It can be difficult to reproduce, however. Internally we had considered automagically adding linear inequality constraints, which in some optimizers can be specified so as to never be violated. However, this has not been implemented afaik, and would be optimizer specific.

The general and infallible solution is to respecify the model for the thresholds and use bounds on the parameters. Let L be lower triangular with the diagonal and sub diagonal elements set to 1 (the upper triangle elements are zero). Let D be a matrix of threshold deviations. The first row of this matrix should be unbounded, but rows 2...nrow are set to have a lower bound close to zero (say .001). Then the matrix product L%*%D will result in row i having elements that always are at least .001 greater than the element above it in row i-1. A code snippet illustrates: