At the Developers Meeting on 6/15/12 we discussed the following:
- Michael Neale and Hermine has identified several performance issues. One performance issue is related to more threads that results in slower the optimization. Mike Neale emailed this out to developers list earlier in the week. The other issue is related to a script written by Hermine. The script contains a large number of algebras which build up large matrices (18 X 18) from smaller matrices using cbinds and rbinds. Steve is going to work with Hermine next week in Edinborough to attempt to find a way to rewrite the script so that it allocates the memory for the large matrix immediately and fills it in without cbinds and rbinds.
- Mike Neal advocated for a "arrows = 0" feature to be added to mxPath. He will be providing examples and explanation of the utility of this feature in the future.
- The group discussed the confidence limit issue  recently identified on the forums. In the future an "x" will be placed next to confidence limits where this  is a problem.
- The group discussed the progress of Mike Hunter and Joshua Pritikin on working with IRP models. Joshua has added some functionality to code Mike originally wrote for IRT models. Currently, these models are quite slow. The group discussed creating our own EM optimizer as a possible avenue to create speedup for these models as well as adding functionality to OpenMx in general. Mike Hunter pointed out that the actual functionality in an EM optimizer is not overly complex, however giving users prefined choices for optimization is necessary due to the general lack of familiarity of most users with converge constraints for EM optimizers.
- The group discussed in the abstract a decision tree optimizer which would spawn different optimizations for different submodels in a larger model. Each branch of the decision tree would be required to have a leaf optimizer where to guarantee optimization for each submodel. This general idea seemed to resonate with the group but no actual implementation was discussed.
- The group discussed how and where packages that use OpenMx should be featured on the OpenMx wiki. Most agreed that these packages should be featured along with an explicit warning that featuring these packages on the wiki does not mean the OpenMx team supports or guarantees support for them in any way. The current idea is to include a list and links to these packages in the a section on the Resources  page of the wiki.