Hi,

I am trying the Beta version to run a multivariate saturated model with ordinal data. However, I am getting no estimated parameters. Could I be missing something in the script (attached)? Any help is greatly appreciated.

Here is the output message:

> SatFit<- mxRun(SatModel, intervals=F)

Running Sat

> summary(SatFit)

Summary of Sat

observed statistics: 7099

estimated parameters: 0

degrees of freedom: 7099

-2 log likelihood: NA

number of observations: 1394

Information Criteria:

| df Penalty | Parameters Penalty | Sample-Size Adjusted

AIC: NA NA NA

BIC: NA NA NA

Some of your fit indices are missing.

To get them, fit saturated and independence models, and include them with

summary(yourModel, SaturatedLikelihood=..., IndependenceLikelihood=...).

timestamp: 2014-08-22 13:59:41

wall clock time: 0.390008 secs

OpenMx version number: 2.0.0.3751

Attachment | Size |
---|---|

Sat_3var_5groups.R | 6.93 KB |

I think the top level model does not have a fit function, and that's what's causing the estimated parameters to be zero.

Replace

with

Hopefully that makes it work!

Thank you very much! I tried this and now get an error message that I don't know what means:

> SatFit<- mxRun(SatModel, intervals=F)

Running Sat

Error: The job for model 'Sat' exited abnormally with the error message: MxComputeGradientDescent: fitfunction Sat.fitfunction evaluated to 1.#QNAN0 ()

In addition: Warning message:

In model 'Sat' Optimizer 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)

> summary(SatFit)

Error in summary(SatFit) :

error in evaluating the argument 'object' in selecting a method for function 'summary': Error: object 'SatFit' not found

The first error you're seeing is saying that the fit function for the top-level model returned a value of

`NaN`

(Not a Number). This probably happened on its first evaluation, at the start values, since CSOLNP and NPSOL can both deal with`NaN`

once optimization has gotten underway. But, if it happens at the very start, they don't know what to do next, and terminate prematurely.It's a bit peculiar that you got the warning about "Mx status RED," but you can ignore it for now, since the real problem is that your model won't run.

The last error you got is just R saying it cannot find an object called

`SatFit`

. This is because`SatFit`

was never created; the line that would have created it,`SatFit<- mxRun(SatModel, intervals=F)`

, led to an error.You should change the start values for your

`CorMZM`

and`CorMZF`

, because those matrices are not positive definite at the values you're currently using. You can see this with, for example,`eigen(CorMZM$values)$values`

, which should all be positive, but that's not the case. You could try lowering the biggest off-diagonal values. Also, it looks like you're starting all of your thresholds at positive numbers. That might be suitable for your data, but it might also be something you'd want to adjust.BTW, are you running this on a Windows machine?

Excellent...Thanks so much guys! Changing the starting values for the covariance matrices of the MZ groups did the trick.

Yes, I'm running this on a Windows machine.

I thought so. For some reason, under Windows, the end of that error message gets garbled to

`1.#QNAN0 ()`

.It would be really helpful if OpenMx stringified non-finite numbers consistently across platforms.

I completely agree.

Indeed. There is a model in the test suite that spuriously throws an error on my system because

`omxCheckError()`

detects a mismatch due to the way`NaN`

gets printed.DeJa Vu, we discussed this this morning :-) This might be a good place to collect that knowledge.

From Mike "the matrix" Neale: "This message is usually caused by parameter values that lead to a likelihood of zero. A non-positive definite covariance matrix (check eigenvalues of the expected covariance matrix) or data vectors that are far from the mean, in standardized units. It may help to bound parameters, or to improve the starting values."

You can sometimes get a model to mxRun with unsafe = TRUE, that can either let it find a good solution - perhaps after another couple of runs - or at least give you something more to work with.

omxSetParameters is useful for moving start values, and free/fixing parameters. For instance

Setting checkpointing can generate a file of free-parameter estimates that might be useful if you want to see what happened before the condition arose.

For the future, having OpenMx should give a message at least this helpful, hopefully taking into account whether this problem happened on the first iteration to help shape this error message.

see below