Developers Meeting 11/4/11

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

At developers meeting on 11/4 we discussed the following:

  • The source of the standard error issue identified by Timo has been discovered. The source of the error is a precision issue. OpenMx's numerical solution to calculating the hessian was (0.02) while the analytical solution was (-.04). Because the numerical solution crossed the zero boundary the numerical solution was significantly off. The group discussed implementing an analytical hessian calculation to address this.
  • The group examined the recent R implementation of npsol, Rsolnp. The implementation is written entirely in R. The group discussed porting the implementation to C to use with OpenMx. Because Rsolnp is under GNU license we could add OpenMx to CRAN if we ported it to a sufficiently efficient version of npsol (ANSI C).
  • A working implementation of the parallel hessian calculation is checked into the trunk of OpenMx. The implementation has been checked with several tests and for all versions of R from 2.11 to 2.14.
  • The group discussed the design of the implementation to the parallel FIML calculation. The group is currently debugging an error in the calculation. The group is fairly certain that the error is in the sequential portion of the code, not the parallelized portion.
  • The group discussed several funding opportunities including: The Census Bureau, The NSF and Google. Each proposal must be tailored to each source.
  • The group discussed the possibility of using GPUs to offboard the optimization in OpenMx to improve efficiency. The group agreed that the FIML computation has several properties that would make employing GPUs an attractive option. The group also discussed the ramifications of adding a feature so closely tied to a specific hardware.
  • The group discussed a bug identified this week dealing the joint/ordinal computation. If either an entire joint side or an entire ordinal side is missing there error appears. In these cases the appropriate likelihood should be 1.
  • The group discussed the fact that the sadmvn implementation is not thread safe. Spiegel has tried to poke around the implementation and look for static local variables and global variables that can be eliminated but this is very difficult due to a lack of familiarity with FORTRAN, bad compiler messages and complex code paths.