Suggestion Box

I just thought I'd suggest again the usefulness of a simple user option to obtain c.i.'s using multiple cores (like through snowfall). Could be bootstrapped, could be ML.

I'm routinely it seems running into problems with many parameters. Ideally I'd want c.i.'s on all of them, but computation proceeds too slowly for this to be feasible.

I'm sure you get this often, but OpenMx is fabulous. Longtime R and S users are most grateful.

-Scott

It might be nice if OpenMx came with an optional open source optimizer. There are a couple that can deal with nonlinear constraints: solnp (R package Rsolnp), and DONLP2 (R package Rdonlp2).

This is not a high priority and they would probably slow down performance, but maybe some users would prefer to use an open source optimizer.

Dear All,

thanks for all the time and effort put into this project! Just starting and I am already thrilled.

I would like to suggest to start a list of published works that used OpenMx. This might help to establish more confidence in the package over time.

cheers
Gerrit

As a novice in the field of OpenMx and R, I am deeply grateful to the OpenMx team for their competent and patient answers to my questions posted in the different forums on the OpenMx web site. However, I must admit, getting answers from the main developers to very newcomers' questions seems a bit like corresponding with Bill Gates when you cannot find the CapsLock key.

congrats on getting the correct gradient and calculated hessian implemented!

suggest a warning to the user when the calculated hessian is not positive definite, something that should be easy to implement because the you invert the hessian to get the standard errors. see attached code which shows that openmx can appear to have converged when the model is unidentified.

also a warning when a gradient element is exactly 0 can help a user diagnose a problem.

greg

Hi
anychance of a mirror in SE Asia somewhere or a text only option of the site for areas with poor internet connection?
thanks
Sarah

Suggestion: Add an option to mxPath to accept an MxMatrix object.
E.g.,
VApsn <- mxMatrix(name="VApsn", type="Symm", nrow=5, ncol=5, free=TRUE)
hVApsn <- mxAlgebra(.5 %x% VApsn, name="hVApsn")
mxPath(from=AMZ1, to=AMZ2, arrows=2, matrix=VApsn)
mxPath(from=ADZ1, to=ADZ2, arrows=2, matrix=hVApsn)

Hi

I just saw a small inconsistency... don't know if this forum categroy is the right one to report that? If one which one would be more appropriate?

It is just that when using mxPath() if length(labels ) is smaller than number of variables, not all variables will be estimated, while in the graph all will be shown, for example using the seminal example from start page:

mxPath(from=manifests, arrows=2, labels="a"),

Estimation will lead only one manifests (with arrow=2), while graph will show all. Maybe should a check be added to ensure consistency? Thanks!

For complete example: