CSOLNP CIs far too small and out of order?

Here's a test .rda file containing a model, along with an accompanying script to add a CI to this model, and estimate it with NPSOL and with CSOLNP

The behaviors are very different: NPSOL code reds on the model, but computes the CIs where they should be.

CSOLNP says everything is fine, but returns miniscule CIs - sometimes it's even out of order.

The direct link to the attached model is

http://openmx.psyc.virginia.edu/sites/default/files/issues/m1.txt


mxVersion()
OpenMx version: 2.0.0.3952
R version: R version 3.1.2 (2014-10-31)
Platform: x86_64-apple-darwin13.4.0

Side effect of lbounding? F matrix associated with RAM expectation function contains dimnames and expectation has dimnames

The following code runs a RAM model, then lbounds a path at zero.

Running that model dies with an error about the F matrix contains dimnames and the expectation function has dimnames.

Seems a not easy to diagnose what to do, but also wrong to fail in this case? (the bound is legal).


data(myFADataRaw, package="OpenMx")
manifests = names(myFADataRaw)
latents = c("G")
m1 <- mxModel("m1", type="RAM",
manifestVars = manifests, latentVars = latents,
mxPath(from = latents, to = manifests),
mxPath(from = manifests, arrows = 2), # manifest residuals

OpenMx version 2.0 is officially released!

We are very pleased to announce that version 2.0 of OpenMx has been officially released! Users can download and install this new version by copy-pasting source('https://openmx.ssri.psu.edu/getOpenMx.R') into the R command line and pressing 'Return'. Users who still wish to download and install version 1.4, the previous stable version of the package, can instead use source('https://openmx.ssri.psu.edu/getOpenMx1.R').

detect if model has not been run in mxStandardizeRAMpaths() and offer solution

mxStandardizeRAMpaths(unRunModel, TRUE) gives a warning about the hessian instead of a warning that the model has not been run.
i.e.

manifests <- names(demoOneFactor)
latents <- c("G")
factorModel <- mxModel("One Factor", type="RAM",
manifestVars = manifests,
latentVars = latents,
mxPath(from=latents, to=manifests),
mxPath(from=manifests, arrows=2),
mxPath(from=latents, arrows=2, free=FALSE, values=1.0),
mxData(cov(demoOneFactor), type="cov", numObs=500)
)
> mxStandardizeRAMpaths(factorModel,T)
Loading required package: numDeriv

mxData.Rd contents and acov

Just to set a reminder, mxData needs more work documenting the parameters and capturing acov functionality.

We mention four types of data, but only three were listed. `acov` now added as the fourth type, but needs filling out.

`thresholds` and `acov` parameters are listed as not implemented yet, but the function is working with them.

PS: Is sscp format on the todo list or not included by design?

\link{omxDetectCores} = missing in documentation object

In mxOption, \link{omxDetectCores} is flagged as a bad link by check.

The function lives in MxDetectCores.R and is just a memoization of a core function "detectCores"

omxDetectCores <- memoize(detectCores)

the memoize work is borrowed from Hadley Wickham

Anyone see how to get this to link correctly?
Or we could just not link to it.

It works fine as ?omxDetectCores on the cmd line

mxRun() returns without error, model claims to have not been run...

Several core users report models (typically running for many hours) returning as if the run was successful, but the returned model is marked as never run, contains no output.

I think all cases involve ordinal/binary data or joint ordinal.

CSOLNP is known to have this behavior, May affect NPSOL as well: need to check and update this bug report

Happens with 1 core as well as several.

Mike suspects optimiser finds an -Inf log likelihood and quit.