We are pleased to announce the official release of OpenMx version 2.22. Click here for instructions on how to install OpenMx version 2.22, bundled with the proprietary optimizer NPSOL, from our repository.  As of this writing, our repository only contains a source tarball for x86_64 Linux/GNU; our package binaries for macOS and Windows are not yet available, but we expect the latter to be ready in about a week.  Of course, users may alternately install the fully open-source build of the new OpenMx version from CRAN. Please note that OpenMx version 2.22 is only compatible with R version 4.5.0 or newer. If you are running an older version of R than that, you may get the error message "Error: package 'OpenMx' is not available" when you try to install OpenMx from CRAN or from our repository.

OpenMx's GREML feature has been the focus of most of our development effort since our prior stable release last year. See below for details.

New Features and Performance Improvements:

• Using a GREML expectation and a GREML fitfunction, it is now possible to fit a model using ordinary (rather than restricted) maximum-likelihood. See below for details.
• Using a GREML expectation, it is now possible to explicitly model the phenotypic mean vector as an arbitrary MxMatrix or MxAlgebra, rather than implicitly model it in terms of covariates. See below for details.
• OpenMx can now analytically and automatically compute first and second fitfunction derivatives for a class of MxModels that use a RAM expectation (including those of type="RAM"). To belong to this class, a RAM model must (1) use data of type="cov", or data of type="raw" that are not binary, ordinal, or discrete; (2) use a non-Fellner MxFitFunctionML; (3) not be multilevel; and (4) not contain any definition variables, Pearson-Aitken selection, product nodes, algebras on paths, or penalty functions. To use these analytic derivatives, both mxOption "Analytic Gradients" (on-load default: "Yes") and a new mxOption, "Analytic RAM derivatives" (on-load default: "No"), must be set to "Yes". Note that mxOption "Analytic RAM derivatives" has an on-load default value of "No", because our testing has surprisingly shown that use of the new analytic derivatives does not improve computational speed or optimizer effectiveness for most eligible RAM models in our test suite. We therefore only recommend switching "Analytic RAM derivatives" to "Yes" for eligible RAM models for which the number of manifest variables and the number of free parameters are both large.

Bug-fixes and Tweaks:

• Three GREML-related bugs have been repaired. See below for details.
• Previously, OpenMx incorrectly counted the number of observed statistics in mixture models, which prevented mxCompare(), the interface to the bootstrap likelihood-ratio test, from functioning correctly. This bug has been repaired.
• omxGetNPSOL() no longer fails with an error due to an incorrect URL.
• Using casewise sampling weights with a state-space expectation no longer crashes R.
• Running mixture models that contain invalid MxAlgebras no longer crashes R.
• OpenMx no longer gives spurious status code 5s when one or more free parameters are at their lbound or ubound.
• Formerly, when OpenMx did not have enough information to compute a model's RMSEA and TLI, it confusingly reported them in summary() output as 0 and 1, respectively. Now, it reports them as NA instead.
• Using mxFactorScores() on a matrix-specified RAM model no longer fails with an error.
• Formerly, adding a latent variable to a RAM model that only had manifest variables would fail due to a bug. That bug has been repaired.
• Renaming mixture models via argument name to omxSetParameters() no longer fails with the spurious error message "Not implemented yet".
• OpenMx now warns when, in a RAM model, a one-headed path between two variables automatically overwrites a two-headed path between those variables, or vice versa. The help page for mxPath() now describes workarounds for this overwriting behavior.
• mxStandardizeRAMpaths() no longer reports standard errors of 0 for raw means when the 'M' matrix is an MxAlgebra.
• The bootstrap likelihood-ratio test no longer excludes replications in which the alternative model has very slightly worse fit than the null model.
• MxModels can be run according to a compute plan that lacks an MxComputeNumericDeriv step (or in some cases, an MxComputeOnce step) for the "final" gradient at the optimizer's solution. In such cases, the gradient in the MxModel's output slot is supposed to be the optimizer's gradient at the solution. At some point, OpenMx's interface to NPSOL changed in such a way that NPSOL's gradient would never be exported to the frontend, and the 'gradient' element of the output slot would instead contain a vector of NaNs. The intended behavior is now restored.
• The help pages for mxCI() and mxConstraint() no longer incorrectly state that OpenMx does not calculate standard errors or the final Hessian matrix when MxConstraints are present in the model.

Known Issues:

• Optimizing a GREML model with the Newton-Raphson optimizer, using semi-analytic derivatives and more than 1 CPU thread, will crash R. However, that is a result of a bug in the Newton-Raphson code, rather than in the GREML code. The bug, which may have caused crashes in other applications of the Newton-Raphson optimizer as well, has been repaired in the OpenMx source repository, and will be repaired in the next OpenMx release.
• mxCheckIdentification() has incomplete support for GREML models. Specifically, there is a form of unidentification, specific to GREML models that use an implicit means model, that the function seems unable to detect. However, this fact is undocumented.
• mxAutoStart() has incomplete support for GREML models. Specifically, its use on GREML models that use an explicit means model is often counterproductive. However, this fact is undocumented.
• OpenMx does not behave as expected when bootstrapping a state-space model while using more than one CPU thread.

See here for the OpenMx Project's issue tracker.

GREML-Related Details:

Before this release, one of the biggest limitations of OpenMx's GREML feature was its inability to model "one-headed paths" from one endogenous variable to another. This limitation precluded the possibility of regressing one phenotype of interest onto another while simultaneously subjecting both traits to variance-components analysis, or the possibility of modeling a feedback loop (i.e., nonrecursive paths) between two phenotypes. This limitation existed due to two design considerations of the GREML feature. First, as its initialism implies, full GREML in OpenMx only fitted models by restricted maximum-likelihood (REML). Although it was (and remains) possible to combine a GREML expectation with a maximum-likelihood fitfunction (instead of a GREML fitfunction), the implementation of that combination was never performance-optimized. Second, the GREML expectation previously allowed the user to specify only an "implicit" model for the phenotypic means, by identifying which variables in the dataset are to be covariates for which phenotypes. Then, at runtime, the GREML backend would implicitly partial out those covariates via feasible generalized-least-squares regression.

Now, both of those limitations of the GREML feature have been relaxed. Users can now fit a model via ordinary (i.e., not restricted) maximum-likelihood when using a GREML expectation with a GREML fitfunction, with all of the performance optimization of the GREML backend (e.g., [semi-]analytic fitfunction derivatives); this is now the recommended way to fit a GREML model via ordinary maximum-likelihood. Moreover, when fitting a GREML model via ordinary maximum-likelihood, users now have the option of specifying an "explicit" model for the phenotypic means. Specifically, and similarly to the case of MxExpectationNormal, users of the GREML expectation can define an arbitrary vector-valued MxMatrix or MxAlgebra, and tell the expectation to treat it as the mean vector of the phenotypes. This new functionality does allow the user to, say, regress one phenotype of interest onto another while simultaneously subjecting both traits to variance-components analysis, or model a feedback loop (i.e., nonrecursive paths) between two phenotypes.

The use of these new features has certain implications worth discussing. First, the math underlying restricted maximum-likelihood assumes that the mean and covariance parameters of the model are information-orthogonal. In contrast, ordinary maximum-likelihood allows parameters to appear in the models for the mean as well as in the model for the covariance. Second, the regression parameters in the implicit-means model are computed analytically, given the phenotypes, the covariates, and the current values of the covariance parameters. In contrast, the parameters of the explicit-means model are explicit free parameters of the MxModel, for which the optimizer must find values, just like the covariance parameters. This has the disadvantage of increasing the dimension of the optimization problem by increasing the number of parameters to optimize. However, this does allow the user to treat the regression parameters as ordinary OpenMx parameters: by assigning them labels, by subjecting them to lbounds/ubounds/MxConstraints, by requesting profile-likelihood confidence intervals for them, and so on.

In addition to the exciting new capabilities of OpenMx's GREML feature, 3 GREML-related bugs have been repaired in this release:

• Formerly, there was long-standing memory-management bug in part of the GREML backend code for analytic and semi-analytic fitfunction derivatives. This bug caused (semi-)analytic derivatives of the GREML fitfunction to be inaccurate by a random amount each time they were computed, but would only be triggered if (1) the user was letting the backend automatically filter the model-expected covariance matrix (and its matrix derivatives) for missing data, and (2) if the number of available CPU threads was large relative to the number of explicit free parameters.
• A long-known memory leak in the GREML backend has finally been patched. This leak caused an array of data equal in size to the phenotype vector 'y' to remain unfreed after each call to mxRun(). We believe it to have been the last remaining memory leak in the GREML backend.
• The help page now clearly explains that mxGREMLDataHandler() and mxExpectationGREML() can accept an empty list (the default value) for argument Xvars, in which case the 'X' matrix will be constructed for an intercept-only regression model. Also, there was previously a bug such that, if Xvars was provided its default value (an empty list), certain OpenMx frontend functions assumed that arguments blockByPheno and staggerZeroes were also at their defaults. Doing GREML with no covariates at all is uncommon, so this bug lasted a long time, but it is now repaired.