Wiki home pagePlease add material here as you learn...

If you have questions not answers, then add those here: That's how a wiki works.

There are a number of changes between Mx and OpenMx, mostly easy to learn.

You will still need to read in data, propose algebra, possibly create more than one group, estimate the model, and post-process and display the results. Much of the structure of an mx script translates easily into OpenMx, just with more structure. COnstraints becomes mxConstraint(), data statements such as SElect are replaced with calls to mxData(), and DEfinition-variables are implemented by . COvariance and MEans statements are replaced with calls to mxAlgebra(), mxMLObjective(), mxRAMObjective(), or mxFIMLObjective.. etc.

R has much more powerful access to data than did mx, including reading a range of formats, not barfing on names, and accessing data from a range of locations, including over the web etc.

You will need to replace Mx1.x Data, Missing, file, and SELECT statements with some R code to read in the data and a call of mxData()

This, for instance:

Data NInput_vars= 13 ! nr of inputvars per family Missing=-1.000 ! missing values = -1.000 RE file=example.dat ! read in raw datafile, must be in same directory

would become:

data <- read.table("example.dat", header=TRUE, sep="\t") #read in data ... mxData(data, type="raw") # apply the dat

In mx 1.x, variables to be modeled at the individual level were specifically DEfined as such from among the SElected set. In OpenMx, the user no longer needs to define explicitly DEfine the set of variables in this role, but rather prefixing the name of a path or matrix label with "data." causes OpenMx to evaluate the matrix fit on individual subject-level data. Using data columns as a definition variable causes OpenMx to automatically remove the variable from the set being analyzed, and reserve it as a definition variable.

PS: this explains why "." style names (though legal in R) are illegal in OpenMx.

Mx used groups to structure its analyses. The comparable structure in OpenMx is the model. Because R provides a lot of functionality, the mapping is not complete. This is clearest in mx groups used for standardising results rather than defining a SEM model. These will often be replaced entirely with manipulation of the data in regular R code. In multi-group models, mx groups will often be mapped directly into OpenMx (sub-)models. Thus a two-group twin design may well be implemented with two models in OpenMx, contained in a parent model. mx scripts often begin with a "Define" group specifying a set of matrices, and this can usually be translated directly to an OpenMx model.

```
<h4>Operators</h4>
```

OpenMx uses R-style operators, which entails some very straightforward find-and-replace type changes. For instance, tow very common functions: matrix multiplication and transposition, signified by "*" and "~" in mx, need to be changed to R functionss, namely %*% for matrix multiplication and t(x) for transposition of matrix x. A full list of function mappings is provided here operators-and-functions.

The other major change in OpenMx algebra is the addressing of symbols. For instance, in mx 1.x, to include a matrix from another group in an algebra, you would import the matrix from that group, then refer to it by its name. In OpenMx, you would refer to an object in another model.

So if in mx you said

**Begin Matrices** = **Group** 1

**Means** M ;

In OpenMx, you would say

"**mxFIMLObjective**("expMean", "name.M"),

where "name" is the name of what was group 1.

**save** and **get**

The result of an MxRun is itself a model, populated with the final estimated values of the matrices and algebras you proposed.

Not available yet, but numerical estimates of Standard Errors are part of the Summary

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

## Comments

## Great insight

Thanks, great insight.

legally binding agreement

Graphic design portfolio