Hi modellers,
already a while ago I have noticed that modeller tends to produce what I would call spaghetti proteins (containing knots and other fancy structures) when it is supplied with multiple templates that are far from the target (35 % or less) and also quite diverse among each other.
However, Modeller 9 seems to suffer more from this effect than the previous versions: One of our test cases uses 10 templates with between 86% and 31% sequence similarity to the target. I know that this is not the optimal strategy (especially after reading this paper: http://bioinformatics.oxfordjournals.org/cgi/content/abstract/btm262v1 ) but modeller 8.2 still performed quite well and all 10 models had good topology (close to the 86% template) and secondary structure. However, I now re-run our test with modeller 9.1, using the identical alignment (T-Coffee) and the same input file (below) and the result looks much worse. Most among the 10 generated models show a messed up (swaped) topology, many have knots and the different models are generally more diverse.
So to what extend differs the multiple-template treatment of Modeller 9 from previous versions? Do I need to use different parameters for multi-template modeling in the new version? Or is the general default modeling protocol different now?
So here is our (old-style) input file:
INCLUDE SET OUTPUT_CONTROL = 1 1 1 1 1 SET ALNFILE = 'final.pir_aln' SET KNOWNS = '1K2H_A' '1M31_A' '1J55_A' '1KSO_A' '1MQ1_A' '1MWN_A' '1MHO_' '1NSH_A' '1K8U_A' '1DT7_A' SET SEQUENCE = 'target' # code of the target SET ATOM_FILES_DIRECTORY = '../templates/modeller/' SET STARTING_MODEL= 1 # index of the first model SET ENDING_MODEL = 10 # index of the last model CALL ROUTINE = 'model'
I am attaching a typical result of modeller 8 and one of modeller 9 for comparison.
Thanks in advance for any comments! Best regards, Raik
Raik Gruenberg wrote: > So to what extend differs the multiple-template treatment of Modeller 9 > from previous versions? Do I need to use different parameters for > multi-template modeling in the new version? Or is the general default > modeling protocol different now?
The multiple-template treatment did not change at all between Modeller 8 and Modeller 9, so I'm surprised that you're seeing such different models.
I can't deduce anything more from your output PDB files. If you can make a zip file of your inputs (see http://salilab.org/modeller/manual/node10.html) then I can take a look to see whether you're running into a bug.
One obvious thing to check is the generated .rsr file for both 8 and 9. If you're getting different models, then either the multiple-template treatment (or some other part of the restraints generation) is making a different set of restraints, or you have the same restraints in both cases but they are being optimized differently.
> So here is our (old-style) input file: > > INCLUDE > SET OUTPUT_CONTROL = 1 1 1 1 1 > SET ALNFILE = 'final.pir_aln' > SET KNOWNS = '1K2H_A' '1M31_A' '1J55_A' '1KSO_A' '1MQ1_A' '1MWN_A' > '1MHO_' '1NSH_A' '1K8U_A' '1DT7_A' > SET SEQUENCE = 'target' # code of the target > SET ATOM_FILES_DIRECTORY = '../templates/modeller/' > SET STARTING_MODEL= 1 # index of the first model > SET ENDING_MODEL = 10 # index of the last model > CALL ROUTINE = 'model'
Is this being generated by the Biskit framework? If so, why does it generate deprecated TOP files when Python scripts give you more flexibility?
Ben Webb, Modeller Caretaker
Dear Ben,
thanks for your prompt reply!
Modeller Caretaker wrote: > Raik Gruenberg wrote: >> So to what extend differs the multiple-template treatment of Modeller >> 9 from previous versions? Do I need to use different parameters for >> multi-template modeling in the new version? Or is the general default >> modeling protocol different now? > > The multiple-template treatment did not change at all between Modeller 8 > and Modeller 9, so I'm surprised that you're seeing such different models. > > I can't deduce anything more from your output PDB files. If you can make > a zip file of your inputs (see > http://salilab.org/modeller/manual/node10.html) then I can take a look > to see whether you're running into a bug.
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.
The large number of templates isn't perhaps the main issue. I just repeated the test with only the three best templates (42 - 86% ID). And again modeller 8 fares well but modeller 9 produces knots and wrong topologies in many of the 10 output models. Of course this is still using the same automatic input alignment which may be less than perfect (T-Coffee consensus of a structure alignment of *all* 10 templates combined with 2 more alignments from a global sequence search).
> > One obvious thing to check is the generated .rsr file for both 8 and 9. > If you're getting different models, then either the multiple-template > treatment (or some other part of the restraints generation) is making a > different set of restraints, or you have the same restraints in both > cases but they are being optimized differently.
The first page or so of this file is identical between the two versions but then things seem to diverge. Please have a look yourself.
> >> So here is our (old-style) input file: >> > > 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. But you have a point there. We should switch the default template to the current standard also to allow better customization. Besides, and this really leads off-topic now, we also are not actually mixing "your python" with "our python". Seeing how you are transforming Modeller into a full-fledged python library, that would probably give interesting possibilities, though perhaps at the cost of simplicity, modularity, "installability", ... Anyway, that would make a different discussion.
Thanks a lot for your help! Greetings, Raik
> > Ben Webb, Modeller Caretaker
Raik Gruenberg wrote: > 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).
Ben Webb, Modeller Caretaker
Raik Gruenberg wrote: > already a while ago I have noticed that modeller tends to produce what I > would call spaghetti proteins (containing knots and other fancy > structures) when it is supplied with multiple templates that are far > from the target (35 % or less) and also quite diverse among each other. > > However, Modeller 9 seems to suffer more from this effect than the > previous versions
Just to resolve this for the benefit of the modeller_usage list: a bug in Modeller 9v1 caused the original template structures to be used in the generation of its initial model. This is different from the Modeller 8 behavior, in which the templates were first modified by alignment.check() (which does all pairwise superpositions). The Modeller 8 behavior has been restored in the new Modeller release, 9v2.
Ben Webb, Modeller Caretaker
-
Modeller Caretaker -
Raik Gruenberg