You are here

Version 2.7 of OpenMx now in beta release

The beta release of version of OpenMx v2.7.4 is now available through CRAN and through our own package repository. OpenMx version v2.7 has been available through CRAN and our package repository since January 10th, 2017, and v2.7.4 (its most recent patch) has been available through CRAN since January 17th, and through our package repository since January 23rd. However, we repeatedly hesitated to formally announce the release of v2.7 because of sufficiently serious issues with it, brought to our attention by CRAN, by maintainers of packages that depend upon OpenMx, and by early adopters of v2.7. Most of these issues are now resolved in (the master branch of) our source repository. However, we are currently delaying release of a stable patch of v2.7 for two reasons. First, we presently lack dedicated hardware to thoroughly test the code in our repository, and we do not want to release a package that has not been tested according to our standards. Second, there is a bug in version 6.0 of R package 'roxygen2' that severely interferes with our automated generation of R documentation pages when building the package. We will release and announce a stable patch of OpenMx v2.7 when these two delays are resolved in the near future.

We understand some users may not wish to run a beta release of OpenMx. If this applies to you, you can downgrade to OpenMx v2.6.9 (the most recent stable binary release), from either CRAN or our own repository. The source tarball for the CRAN build of v2.6.9 is available here. To download the OpenMx Development Team's build of v2.6.9, look in the directory for your version of R in here for Windows and in here for most MacOS systems; click here to download v2.6.9 for Linux/GNU and other non-Mac Unix-likes. Once you download the file, you will need to install it, either through R's install.packages() command or an equivalent package-installation menu if you are using a GUI frontend to R. Note that you will be installing a package from a local file on your system, and not from a remote package repository.

The most significant change between OpenMx v2.6 and v2.7 is that CSOLNP is now the on-load default optimizer. Use mxOption() to switch optimizers, e.g. mxOption(NULL,"Default optimizer","SLSQP") to switch to SLSQP (the default since OpenMx v2.2) or mxOption(NULL,"Default optimizer","NPSOL") to switch to NPSOL (the only optimizer prior to v2.2 of OpenMx, and in classic Mx before it).

New features, performance improvements, and bug-fixes in OpenMx v2.7.4 include:

  • mxFitFunctionWLS() now includes an internal standardization that allows the scale parameters for ordinal variables to be estimated. This allows any ML ordinal model to be estimated as a WLS model by merely switching (1) the mxFitFunctionML() with mxFitFunctionWLS(), and (2) the mxData(..., type='raw') with mxDataWLS(...)..
  • Analyzing joint ordinal-and-continuous data with full-weighted WLS no longer triggers a warning message about bias. For details, see the documentation for mxDataWLS().
  • If there are missing observations (NAs) in the dataset, mxFactorScores() now requires the user to provide a value for its new argument, minManifests, which sets a minimum count of non-NA scores to be present for each data row, below which the function will not calculate factor-score estimates for that row. Note that is is a backwards-incompatible change in behavior.
  • There is a new function, mxSE(), which calculates delta-method standard errors for arbitrary expressions, named entities, and algebras. Note that it requires that standard errors (really, a valid Hessian matrix) be available for the MxModel's free parameters.
  • mxRun() now prints non-persistent feedback messages about optimization progress.
  • Advanced users are now able to provide analytic constraint Jacobians to mxConstraint() (but see the related "known issue" below). This feature is presently supported only for NPSOL, though support for SLSQP will be included in a future release. Providing analytic Jacobians can significantly reduce the number of fitfunction evaluations that the optimizer needs to reach a solution.
  • Additional information about MxConstraints is now exported from the optimizer in the backed to the MxModel's 'output' slot. This feature is presently implemented for NPSOL and SLSQP. The additional diagnostics include the constraint function values and the corresponding Lagrange multipliers, the full constraint Jacobian, and the Hessian of the augmented Lagrangian at the solution.
  • A new function, omxDefaultComputePlan(), which creates a "default" MxComputeSequence, has been implemented. This new function is intended for cases where the user wants to run an MxModel with the same compute plan that would ordinarily be generated automatically at runtime, except for a few changes.
  • New performance improvements have enabled RAM and LISREL MxModels to analyze continuous raw data almost as quickly as covariance-input data in many cases. The means matrix is also optimized more efficiently.
  • Evaluation of the GREML fitfunction's analytic derivatives is now much faster. Specifically, the computational effort involved is now load-balanced among multiple threads, and refactoring the code has eliminated unnecessary computational bottlenecks and has reduced memory demand.
  • Error reporting is much improved throughout OpenMx.
  • Function mxGenerateData() can now accept a dataframe as input instead of an MxModel, in which case it will return data based on a saturated multivariate-normal model.
  • Function mxGenerateData() is now compatible with joint ordinal-and-continuous datasets.
  • By default, mxGenerateData() now approximates the missingness pattern of the original data. Note that this is a backwards-incompatible change in default behavior. The previous default behavior can be restored with argument use.miss=FALSE.
  • Diagnostics for confidence intervals are now displayed in the output of summary() with argument verbose=TRUE.
  • When evaluating raw-data row loglikelihoods in a row-wise parallel manner, OpenMx now dynamically balances the computational workload among multiple threads using empirical times elapsed.
  • Continuous-time state-space models now allow non-invertible ("drift" or "dynamics") A matrices.
  • SLSQP now ignores inactive inequality constraints and extraneous equality constraints, and correctly reports when inequality constraints cannot be satisfied.
  • The Wu & Neale (2012) adjustment for parameters with upper or lower bounds has been implemented for confidence intervals, and is applied by default. Note that this is a backward-incompatible change in default behavior. To disable the adjustment, provide argument boundAdj=FALSE to mxCI().
  • Function mxRefModels() now correctly handles MxModels with a single-variable dataset.
  • Function mxTryHard() and its ilk now no longer compute the numerical Hessian and standard errors when there are MxConstraints in the model. This makes its behavior both consistent with mxRun(), and correct in the general case, as OpenMx's numerical standard errors will not in general be valid in the presence of MxConstraints.
  • The following functions are now usable as part of MxAlgebras: dchisq(), pchisq(), dbinom(), pbinom(), dcauchy(), pcauchy().
  • The documentation for mxOption() and mxComputeGradientDescent() has been expanded and clarified.
  • The documentation for mxFitFunctionR() now warns against defining the fitfunction with functions that call OpenMx's backend (most notably omxMnor()), because doing so can crash R.
  • Functions mxRun() and mxTryHard() et al. previously ignored the values of certain mxOptions if those options were set specifically to the MxModel being run, and instead used those options' globally set values. This bug has been repaired.
  • A bug involving omxSetParameters() and global R option mxCondenseMatrixSlots set to TRUE has been repaired. This bug would have most likely manifested itself as mysterious errors at runtime involving the internal function 'setParametersMatrix'.

    There are also several known issues with OpenMx version 2.7.4 (note that any bugs repaired in the source repository will ipso facto be repaired in a future release of OpenMx):

  • The most serious issue with v2.7.4 is its over-sensitivity to start values. This will cause a nontrivial proportion of MxModels which ran with previous OpenMx versions to fail with v2.7.4. This issue is resolved in the source repository. mxTryHard() and its wrappers may be useful as a workaround in v2.7.4.
  • The conditions under which NPSOL expects the sign of an analytic constraint Jacobian to be positive versus negative are not simple. We expect that a future release of OpenMx will address this issue with clearer documentation and/or a streamlined backend interface with NPSOL.
  • When using SLSQP with an MxModel containing MxConstraints, OpenMx has no way of checking the optimality conditions of SLSQP's solution. Therefore, under such conditions, OpenMx will not return status code 5 or 6 when it actually should. This bug is expected to be repaired in a future release.
  • If an MxModel is using the default compute plan, then mxRun() silently overrides the values of mxOptions "Gradient step size", "Gradient iterations", and 'Function precision". In the source repository, this behavior is retained by default, but it is also possible to force OpenMx to respect user-supplied values for those options.
  • When used in MxAlgebras, functions dnbinom() and pnbinom() will cause collisions with their base-R counterparts (from package 'stats') when passed to mxEval(), because the two pairs of functions accept a different number of arguments. This bug has been repaired in the source repository.
  • Scores calculated by mxKalmanScores() may be incorrect. This bug is repaired in the source repository.
  • There are several bugs in the sufficient-statistic optimization of Rampart (OpenMx's multilevel SEM algorithm). These bugs have been repaired in the source repository. As a workaround with v2.7.4, set the value of the '.useSufficientSets' slot of your MxExpectationRAM object to FALSE.
  • Running an MxModel containing an MxAlgebra that uses omxAllInt() will end with an error if omxAllInt() returns a probability of zero. This bug has been repaired in the source repository. mxTryHardOrdinal() may be useful as a workaround in v2.7.4.
  • Running a FIML analysis with a dataset containing a large (>1000) number of endogenous variables will end in an error. This bug has been repaired in the source repository.
  • Using NPSOL or SLSQP to run an MxModel containing an MxConstraint that involves fixed parameters may end with an error. This bug has been repaired in the source repository. As a workaround with v2.7.4, either use CSOLNP, or eliminate the offending MxConstraint by modifying the MxModel's 'constraints' slot.
  • Using mxGetExpected() on an MxModel containing submodels that refer to the container will result in an error. This bug has been repaired in the source repository.
  • If an object of class 'MxRAMModel' is loaded from an .RData file before the OpenMx package is loaded into R's workspace, then the methods (e.g., summary()) defined for that class will not work.
  • When the optimizer invokes the GREML fitfunction to obtain only the fitfunction value, and not any analytic derivatives, there is an unneeded step involving matrix-by-matrix multiplication which exacts an unnecessary performance cost. This issue has been resolved in the source repository.

    Users interested in building and installing OpenMx from the source repository are referred to our instructions for same. Be advised that the instructions for Windows users have not been recently updated.