Developers Meeting 7/22/11

3 replies [Last post]
rgore's picture
Offline
Joined: 01/27/2011

At developers meeting on 7/22 we discussed the following:

  • There continues to be a known bug in the OpenMx 1.1 Beta release. When running FIML with an ordinal non-positive definite covariance matrix OpenMx goes into an infinite loop instead of reporting an error to the user. This issue has been moved very high on the OpenMx 1.1 priorities list.
  • We discussed several possible interface changes to the useOptimizer flag in mxRun. The modifications would address the issues of the calculation of the gradient and hessians discussed here. Ultimately the group decided that a forum post would be created to get feedback from the OpenMx user community.
  • The implementation of the connect slot for mxPath was discussed. Recall the connect slot will replace ALL=TRUE in mxPath. Further information about this change can be found here. It was decided that all mxPath errors should be reported to the user as quickly as possible. This requires performing error checking pertaining to any type of model (RAM, LISREL, etc) in MxPath.R and performing the remaining error checking specific to the model type when the model is created (MxRAMModel.R, etc). The implementation appears nearing a state where it can be thoroughly tested.
  • The coding style of the models within the demos and the examples used in the OpenMx documentation was discussed. Three coding styles were identified. The names given to these styles were used within the meeting but are by no means set in stone:
    • A monolithic coding style where everything is embedded within one call to the mxModel constructor. This style is featured on the homepage.
    • A recursive coding style which makes lots of calls to the mxModel constructor.
    • A piecemeal coding style which stores each piece of the model in a separate R variable and the constructs the mxModel using each piece/variable with a single concise call. This style tends to be favored for expert users and more complex models as it makes debugging the more straightforward than the other two styles.
  • The group agreed that OpenMx should supply users with:
    • A brieft introduction to each coding style in the documentation.
    • An indication in each demo and documentation example of what coding style is being used.
  • The group discussed choosing one style (piecemeal) to use consistently throughout the demos. The goal would be to encourage users to create scripts using the style that facilitates the most straightforward debugging. Concern was raised that this decision may turn off novice users who are most comfortable with the monolithic coding style used in MPlus and Mx. Next week we will discuss the trunk/demos/LatentGrowthCurveModel_PathRaw.R model written in each of the three styles. Mike Hunter has volunteered to supply everyone with a copy of this demo written in the recursive and piecemeal coding style. It is currently written in the monolithic coding style in the source code repository.
  • A bug was identified in the summary method of MxModel when an R objective function is used. The demo in trunk/demo/RObjectiveLISRELFactorRegression.R triggers the bug when line #334: summary(ex1Run) is uncommented. This bug is being looked into.
  • Progress continues to be made on the implementation of a LISREL model type.
mhunter's picture
Offline
Joined: 07/31/2009
"Mike Hunter has volunteered

"Mike Hunter has volunteered to supply everyone with a copy of this demo written in the recursive and piecemeal coding style."

I've added these demos to the repository as trunk/demos/LatentGrowthCurveModel_PathRaw_ModelRec.R and trunk/demos/LatentGrowthCurveModel_PathRaw_ObjectAdd.R.

The ModelRec file is in the recursive style. The ObjectAdd file is in the piecemeal style. The original file is in the monolithic style.

mspiegel's picture
Offline
Joined: 07/31/2009
I changed the ModelRec style

I changed the ModelRec style from:

a <- mxModel(...)
b <- mxModel(a, ...)
c <- mxModel(b, ...)

into:
a <- mxModel(...)
a <- mxModel(a, ...)
a <- mxModel(a, ...)

Those temporary variables did not serve a pedagogical purpose, unless we were saving them around to execute them, which we did not in this script.

mspiegel's picture
Offline
Joined: 07/31/2009
"A bug was identified in the

"A bug was identified in the summary method of MxModel when an R objective function is used." This has been fixed in the trunk and the next OpenMx 1.1 release.