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(...).
.
mxDataWLS()
.
NA
s) 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 this is a backwards-incompatible change in behavior.
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.
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.
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.
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.
mxGenerateData()
is now compatible with joint ordinal-and-continuous datasets.
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
.
summary()
with argument verbose=TRUE
.
A
matrices.
boundAdj=FALSE
to mxCI()
.
mxRefModels()
now correctly handles MxModels with a single-variable dataset.
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.
dchisq()
, pchisq()
, dbinom()
, pbinom()
, dcauchy()
, pcauchy()
.
mxOption()
and mxComputeGradientDescent()
has been expanded and clarified.
mxFitFunctionR()
now warns against defining the fitfunction with functions that call OpenMx's backend (most notably omxMnor()
), because doing so can crash R.
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.
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):
mxTryHard()
and its wrappers may be useful as a workaround in v2.7.4.
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.
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.
mxKalmanScores()
may be incorrect. This bug is repaired in the source repository.
FALSE
.
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.
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.
summary()
) defined for that class will not work.
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.