kyleabeauchamp
commented
9 years ago If we can put some input files on gist, I can take a look on my machine and then try to find an issue tracker for this sort of thing.
Closed danielparton closed 9 years ago
kyleabeauchamp
commented
9 years ago If we can put some input files on gist, I can take a look on my machine and then try to find an issue tracker for this sort of thing.
danielparton
commented
9 years ago Thanks - I've added the necessary files to this repo: https://github.com/danielparton/loopmodel-debugging
kyleabeauchamp
commented
9 years ago Hmm. It seemed to work on my first attempt (https://gist.github.com/kyleabeauchamp/2b17d9fa7a0baeb204b8). What version of rosetta? I have rosetta_2014.35.57232_bundle
kyleabeauchamp
commented
9 years ago Actually, my run also failed, but it didn't hang--it said that it failed.
kyleabeauchamp
commented
9 years ago Could it be due to a loop that's geometrically impossible? This warning message seems to suggest that the problem is a loop with two residues:
[WARNING] Failed to build loop with kinematic Mover during initial kinematic perturbation after 100 trials: LOOP start: 154 stop: 156 cut: 155 size: 3I think the problem was that the loop was geometrically impossible given the template constraints--the endpoints were too close together to fit 2 residues between them. If you increase the length of the loop by 1, it works:
LOOP 153 156 - - 1Thanks for checking this. My run did eventually complete (unsuccessfully) too - after 18 hours. Looks like yours took about 10 hours? I'm using the same Rosetta version as you.
It's actually just one residue which is being added. The residue span defined in the .loop file includes the two residues either side, and these are allowed to be flexible during the modeling process. Either way, I agree it looks like this is a case where it is geometrically impossible for the loop to be built.
One option would be to have ensembler iteratively increase the residue span (up to a max of 2 or 3 residues) until the loop is built successfully. Or I could set a timeout limit for the call to loopmodel. I'm currently looking at the statistics from the loopmodel runs to see if there might be an obvious choice of timeout limit.
jchodera
commented
9 years ago I like the timeout idea!
Eventually, we will replace this with a more sophisticated template reconstruction method anyway, so let's not spend a huge amount of time finding the absolute best ROSETTA-based reconstruction scheme right now.
danielparton
commented
9 years ago Here is a plot of the timing for each loopmodel run, against the number of missing residues:
I think I'll go with a timeout of 3 hours. This should mostly cut off unsuccessful runs.
danielparton
commented
9 years ago I used the subprocess32 package to implement a timeout feature, set to 3 hours by default.
The code falls back to the standard subprocess package (without the timeout feature) if subprocess32 is not available.
subprocess32 is available on PyPI, but not binstar, so I built a conda package and uploaded it to my own binstar channel (https://binstar.org/dannyparton/subprocess32), and then added it as a requirement in the ensembler conda recipe.
jchodera
commented
9 years ago Thanks!
Can you make a PR to include the conda recipe in omnia-md/conda-recipes as well?
Rosetta loopmodel seems to get stuck on the template AURKA_HUMAN_D0_3UOK_A, on the first loop build attempt. Output from a command-line run is below - the program has been stuck following that rmsd message for almost an hour now. I'll look into whether Rosetta has some kind of option for working around this. Otherwise I'll probably see if there is a way to implement a timeout for the subprocess call to
loopmodel. Looks like this is possible in the Python 3 version of subprocess, and there is a backport to Python 2.7 here: https://pypi.python.org/pypi/subprocess32