I double-checked things this morning and I am indeed getting very
different results from the two modeller versions running on the same
machine, using the same alignment, structures etc. I am going to send
you the complete input and the different results in a separate e-mail.
As far as I can see from your files, your initial model (.ini file) is
very different between Modeller 8 and 9. The restraints file (.rsr) is,
however, almost identical (small differences in the last few restraints
are probably due to rounding during the conversion of these restraints
to cubic splines). So I'm fairly confident that your odd Modeller 9
results are simply due to the different initial model.
The difference is simple: Modeller 8v2 uses the superposed templates to
construct the initial model, while Modeller 9v1 uses the original
template orientations. In your case, since your templates are very
different, Modeller 9 is giving you a bad initial model and the
optimizer simply isn't able to recover.
The 8v2 behavior is clearly superior in most cases, and thus this will
be restored for the 9v2 release. There is a workaround for 9v1 TOP
scripts at http://salilab.org/modeller/wiki/Patches(superpose-templates.patch) which you can use in the meantime. (In this
particular case the Python interface is not affected by the bug, so no
workaround is necessary.)
Is this being generated by the Biskit framework? If so, why does it
generate deprecated TOP files when Python scripts give you more
flexibility?
:-) Well, we implemented the homology modeling module of Biskit already
back in 2004 starting with Modeller 6 (!) if I remember right. We just
never really advertised it. I would say, it testifies to your good
software development that the same wrapper is still working 3 versions
later.
We do have testcases for the TOP wrappers, but they are deprecated, and
don't get quite as much attention as the Python wrappers. New features
are also only supported by the Python wrappers.
But you have a point there. We should switch the default template
to the current standard also to allow better customization.
I suggest that if you do that you query modeller.info.version_info so
that your script requires Modeller 9. (Parts of the Python interface,
particularly for atom selections, changed between Modeller 8 and 9;
alternatively, you could implement different Python code for the two
versions and use version_info to switch between them at runtime.)
Besides, and this really leads off-topic now, we also are not actually
mixing "your python" with "our python".
Looks like you are writing out a script file and then spawning a
Modeller process, rather than loading in the Modeller Python module
directly. Either approach should work fine - the latter just gives you a
bit more fine-grained control if you need it (e.g. proper catching and
processing of exceptions).