At developers meeting on 9/16 we discussed the following:
- The group updated the status of the effort to parallelize the FIML Objective function. Several issues exist:
- RMPI uses point-to-point communication when it should not. As a result it is not as efficient as it should be.
- MPI is a library not an extension, thus we need to link against it. In order to do so a 300 line script to determine the implementation of MPI running on the host machine is required. Each implementation of MPI provides a wrapper which would allow us to link against the library with two lines of code if we were allowed to change the c compiler used in R. The group has asked the R-Developers to change this but they are resistant.
- The group discussed the status of Swift . Currently Tim Armstrong is setting up several OpenMx benchmarks to run with Swift on a 500-1,000+ core Cray environment. The benchmarks will be scaled upwards via (1) # of models, (2) size of the data set and (3) the number of free parameters. It has been observed so far that a lot of the overhead in the benchmarks is due to marshaling and unmarshaling arguments. The group agreed that there is room to reduce this overhead.
- Mike Hunter is debugging the LISREL front end and making progress.
- The group discussed adding a weighted least squares objective function to the back end. It is believed that this would doable and made easier with several R examples that make the mathematics involved very clear. Such examples would serve as a reference and provide the group with timing numbers to compare the two approaches.
- Changes are being made to the OpenMx Documentation to improve readability of examples. The group also decided to add a place on the website for a beta-version of the user guide that would describe the functionality of the current beta release of OpenMx.
- Additional information is being added to the warning and error messages for mxMatrices. The new information will specify the exact call to mxMatrix that caused the warning or error. This is particularly useful for OpenMx users who write matrix models in the monolithic style where many different calls are evaluated at once. The new functionality will allow users to see exactly which calls are causing errors or warnings.
- The function omxCheckWarning is being developed and soon will be added to the trunk. It allow developers to check if the appropriate warning is being produced for in OpenMx test cases. It will mimic the behavior of omxCheckError for warnings.