Developers Meeting 9/9/11

No replies
rgore's picture
Joined: 01/27/2011

At developers meeting on 9/9 we discussed the following:

  • Timo implemented a change to the determinant calculation in omxFIMLObjective.c and omxMLObjective.c. Now we take logs of each element rather than doing multiplies and taking log of the result. This process is significantly more stable.
  • Several bugs related to the joint continuous/ordinal FIML optimization. We will be updating the test suite to include test cases to ensure that an error is not thrown for the patched issues.
  • Some precision differences are being noted with the advent of new operating systems (Mac OS X Lion). We are handling this by reducing the level of precision in the test suite on a case by case basis.
  • The new threading plan for FIML optimization was discussed. The strategy is to store all state information in one data centralized data structure to facilitate copying. Data will be "chunked" hierarchically. Each chunk will have a number of children which indicates the maximum degree of parallelism and each child will be a copy of the state. The parallelization will only use the children not the parent data chunks. This make the hessian calculation and FIML calculation straight forward because data can be easily accessed between parent-child.
  • Mike Hunter and Tim discussed planning to meet to get the LISREL ojbective function up and running in the trunk directory of OpenMx.
  • The integration of the analytical solutions for the analytical solutions for the gradient and hessian into the back end was was discussed. More details on the analytical solutions can be found here.
  • The group brainstormed about a potential hybrid method between EM methods and SWARM methods where the expectation is performed in one thread and maximization is performed simultaneous and information is shared between the two whenever is "convenient". It appeared such an approach could yield more accurate solutions efficiently.
  • Moving PPML to the back end was discussed. There are two aspects of the move that will be novel in OpenMx. The first is that free parameters will need to be put into new locations in the back end. This seems straightforward but has not been previously done in OpenMx. The second novel aspect of the move is that new objective functions will need to be created. Again, this appears straight forward but has not been previously done.