| Attachment | Size |
|---|---|
 classtest.R | 936 bytes |
Hi guys!
I copied the factor analytic example from the OpenMx main website. When I run the model both the original and the resulting model with estimates will have the class MxRAMModel.
However, if I take the same model, add an arbitrary mean structure and mxData of type "raw", the resulting model will only have class "MxModel". To my understanding, it should still be of class MxRAMModel.
Is this a bug or a feature?
I attached my sample code.
cheers,
Andy
Printer-friendly version
Well, it was a feature originally.
A RAM model that is given raw data is automatically converted into a FIML model with the appropriate RAM algebras upon fitting. When it returns, it's a regular MxModel with a FIML Objective. We figured this didn't violate the "Does Only What You Say" (DOWYS) mantra, because you've asked for a RAM model with raw data, and raw-data RAM uses a FIML calculation.
We are changing the model type out from under you, though, which might cause problems for people who aren't expecting it. For example, people who want to fit an intermediate version, add or alter paths, and then run it again starting from the previous fitted values. There are cases where that could be a reasonable strategy to find starting values for a model that takes a long time to run. Once the model returns, mxPath() no longer works on the fitted model.
This issue also came up here: http://openmx.psyc.virginia.edu/thread/821
We still need to do the conversion in order to do the calculation. But it might be possible to return the model to you as the same type it was when you ran it. There's also a question of what to do with the extra algebras that are generated. We've gotten two notes about this in two days. Maybe we should think changing it for the next version.
Okay, user community:
Is anybody actively counting on the fact that they get back a generic MxModel when they fit an MxRAMModel with raw data?
Is there anybody else inconvenienced by it?
I've checked in a patch to the trunk that adds the slots "expCov" and "expMean" to the RAM objective function. These slots are populated at the end of optimization with the expected covariance and expected means matrices. The remaining step is to implement RAM in the backend for raw data. I would prefer following that strategy, rather than convert RAM + data to FIML, and then convert the FIML objective back to RAM at the end of optimization.
For the set of users who want RAM converted to FIML, and would rather have "expCov" and "expMean" appear as MxAlgebra statements instead of as slots in the objective function, we can add an option to mxOption() that would enable the old behavior.
The RAM + raw data transformation has been fixed. See http://openmx.psyc.virginia.edu/2011/05/phasing-out-ram-fiml-transformation