You are here

SEM without free parameters troubles OpenMX (and myself)

9 posts / 0 new
Last post
brandmaier's picture
Offline
Joined: 02/04/2010 - 20:45
SEM without free parameters troubles OpenMX (and myself)

Hello!

Today, I felt like fixing all my free parameters and call mxRun() on my model. I expected the optimizer to converge instantly or rather not to be invoked. Instead, it seems the backend is running into an infinite loop somehow. Maybe the backend needs to check the condition of no free parameters in the model.

I did this (admitted, a rather strange setting) because I intended to evaluate the -2LL of dataset "A" on a model that I ran previously on dataset "B". I thought if I fixed all parameters, set the dataset to "A" and mxRun() it, I'd get the desired -2LL of "A" under the model estimated by "B" as a result. So, I wonder what you suggest as the standard way to obtain a likelihood of a different dataset given an estimated model.

best,
Andreas

mspiegel's picture
Offline
Joined: 07/31/2009 - 15:24
I'd like to address one of

I'd like to address one of the two issues that you've raised. The model is taking a long time to run with no free parameters. That sounds like a bug. Do you mind posting the script as an attachment to the forum post? Or a simplified script that reproduces the same behavior? You should use the fakeData function to generate synthetic data: http://openmx.psyc.virginia.edu/wiki/generating-simulated-data.

tbrick's picture
Offline
Joined: 07/31/2009 - 15:10
Hmm. Fixing all the

Hmm.

Fixing all the parameters in the model and calling mxRun() on it should work.

In the back-end, the optimizer should never be called if there are no free parameters, so all the algebras and objective values should simply be computed at the starting values. So it should be a few quick calculations and you should get a result back like any other model.

This may be a bug in OpenMx. Could you post code and data (or simplified code and simulated data) that exhibits the behavior? The fakeData command (described on the Generating Simulated Data page) is a good way to simulate some data for posting.

Also, what versions of OpenMx and R are you running, and on what operating system?

Thanks! We'll try to get this fixed as soon as we can.

brandmaier's picture
Offline
Joined: 02/04/2010 - 20:45
Thanks for your quick

Thanks for your quick replies. I tried to reproduce the described problem in a new script which I can publish here. Please find the script attached.

description of the script:
The script estimates the mean of a variable with unit variance. The data is generated from a standard normal distribution. Running the model works fine. Then I fix all parameters and rerun the model. This time, the optimizer seems to get stuck.

I use openmx version number: 999.0.0-1448 and R version 2.11.1 (2010-05-31) on OSX 10.6.4

thanks for your help,
Andreas

tbates's picture
Offline
Joined: 07/31/2009 - 14:25
here's a more compact

here's a more compact version... confirm: it hangs up

require("OpenMx")

create a dummy model which estimates the mean of an observed variable with unit variance

data <- data.frame(rnorm(1000,0,1))
manifest = c("Y")
names(data) <- manifest
model1 <- mxModel("One Factor", type="RAM",
manifestVars = manifest,
mxPath(manifest, arrows=2, free=T, values=1.0, label="lat_var"),
mxPath("one", to=manifest, arrows=1, free=T, values=1, labels="mean"),
mxData(data, type="raw", numObs=dim(data)[1])
);
fit1 <- mxRun(model1);

fix free parameters

model2 = mxRename(omxSetParameters(fit1, labels=c("lat_var", "mean"), free=F, value = 0),"fixed")
fit2 = mxRun(model2)

you will be waiting a long time here :-)

mxCompare(fit1, c(fit2))

Ryne's picture
Offline
Joined: 07/31/2009 - 15:12
I also get the slow-down. If

I also get the slow-down. If I rewrite the second model (that is, write a fresh model with matrices rather than paths, still using RAMObjective), I don't get the error. Flipping the parameter any way I try gets the error, including when I clear the output from the model.

mspiegel's picture
Offline
Joined: 07/31/2009 - 15:24
Whoops. We have a bug in the

Whoops. We have a bug in the objective function transformation process. Objective function transformation takes one type of objective function (such as RAM) and checks if certain conditions are met (like raw data is used for model fitting). If the conditions are met, then the objective function is transformed into another type. Or sometimes goes into an infinite loop.

I'm working on a patch for this issue. Should have OpenMx 1.0.3 out by the end of the night. Thanks to Andreas for spotting the bug. And Tim Bates and Ryne for testing out scripts. And Tim Brick for tracking down the bug.

mspiegel's picture
Offline
Joined: 07/31/2009 - 15:24
Fixed in version 1.0.3.

Fixed in version 1.0.3.

brandmaier's picture
Offline
Joined: 02/04/2010 - 20:45
excellent! You're great,

excellent! You're great, guys!