Error message for mxCompare() with boot = T

What do you mean that you "got nothing?" By using the previousRun argument, you can run replication incrementally. You can run 10 then run another 15 without losing the first 10.

I suspect you'll need to change mxOption 'Status OK' from its on-load default. This is what that option looks like on load:

> options()$mxOptions$`Status OK`
[1] OK OK/green
attr(,"mxFactor")
[1] TRUE
10 Levels: OK < OK/green < infeasible linear constraint < infeasible non-linear constraint < ... < infeasible start
> levels(options()$mxOptions$`Status OK`)
[1] "OK" "OK/green" "infeasible linear constraint"
[4] "infeasible non-linear constraint" "iteration limit/blue" "not convex/red"
[7] "nonzero gradient/red" "bad deriv" "internal error"
[10] "infeasible start"

For example, if your models involve thresholds, you might want to set the option as follows:

mxOption(NULL,"Status OK",c("OK","OK/green","not convex/red","nonzero gradient/red"))

Note that this is only a fix if your models are failing to converge in most of the bootstrap replications (which is possible, even if they do converge when fitted to your real dataset).

Dear Joshua, I respectfully believe that this interpretation can be excluded, for multiple reasons:
1) The model does arrive at the correct solution for the 2-class mixture, despite having the same starting values for both classes. (Correct solution as validated by Mplus and Mclust).
2) When I manually provide the same starting values for both mixtures, but also put a mxData() object inside both classes, mxCompare(boot = TRUE) also fails. Moreover, when I reverse the order of the models, mxCompare succeeds, but I notice that the number of degrees of freedom is incorrect. Cases from all the datasets are added up.
3) When I manually provide the same starting values for both mixtures, and do not put a mxData() object inside both classes, mxCompare(boot = TRUE) works. Thus proving that putting mxData() in the submodels breaks mxCompare(boot = TRUE)

See attached script for a demonstration.

If you do debug(OpenMx:::mxGenerateData) and then call mxCompare(..., boot=TRUE) then you will see that mxGenerateData is used (for the null model). Maybe I misunderstood something when we discussed the implementation. Rob, are you sure it can be made to work without mxData?

I'm looking over the code for `mxGenerateData()`, and yeah, I'm pretty sure that it can work without the models containing any MxData objects. It doesn't need raw data, just the expected sufficient statistics under the null model. Of course, what exactly `mxGenerateData()` does depends upon the definition of method `genericGenerateData()` for the relevant expectation class...which I notice only has definitions for MxExpectationNormal, MxExpectationLISREL, MxExpectationRAM, and MxExpectationStateSpace. There is no definition for MxExpectationMixture.