Developers Meeting 10/21/11

1 reply [Last post]
rgore's picture
Offline
Joined: 01/27/2011

At developers meeting on 10/21 we discussed the following:

  • The group reviewed the state of the multi-level modeling effort.
  • The group discussed the current segmentation fault that exists for some of the test cases when the mxOption for hessian parallelization is enabled. The group reviewed different techniques to debug multi-threaded programs in gdb to localize the cause of the segmentation fault. Tim believes the bug is related to another issue in the parallelization he is planning to address. This bug was first discussed in last week's meeting.
  • The group discussed the standard error bug identified by Timo and Dan Hackett. As referenced in Timo's email earlier this week the bug occurs for ACE Models with definition variables and a covariance between A and C. The standard errors are computed correctly if the covariance between A and C is removed. An example model featuring the bug can be found here. In previous versions of OpenMx some of the standard errors were returned as Nan, in the current version of OpenMx (built from source) the standard errors are off by ~20%. This bug was first discussed in last week's meeting.
  • The group discussed the state of the documentation and in particular the issue with properly rendering multiple (at least two) different colored code/pre-formatted blocks. Michael Spiegel identified possible help via a google code forum. When possible I will link to the forum here.
  • The group discussed possible ways to improve the memory capacity for systems attempting to solve large OpenMx models. One suggested solution involved pre-processing the model with PPML to reduce overhead. Another solution involved employing an R package that offered a virtual memory type solution to RAM similar to current high-level programming languages like Java.
  • Mike Hunter presented several interesting results from a close examination of npsol.
    1. (1)What the group refers to as minor iterations in npsol and what actually constitute minor iterations in npsol may be slightly different. In particular, in actual npsol minor iterations neither the hessian nor gradient is referenced.
    2. (2)npsol does not calculate a hessian at all. Thus computing an analytical hessian will not improve efficiency.
    3. (3)Computing an analytical gradient can offer efficiency improvements. Currently the gradient is computed via three separate function calls per parameter.
carey's picture
Offline
Joined: 10/19/2009
on the standard error

looked over the code on the standard error problem and it may not be a standard error problem. is the model identified in the first place? an unidentified model MAY (but not always) give NaN for standard errors when the hessian is not positive definite. suggest taking eigenvalues of the calculated hessian to make certain this is not the case.
the only genetic models that can identify covGC with these data are those that predict a different phenotypic variance for adoptees/foster children than for children raised by their biological parents. to identify this model, you can use two groups (bio sibs and adoptive sibs), let covGC be free for the bio sibs but constrain it to = 0 for the adoptive sibs.
best,
greg