Distinctions between InterfaceAnalyzer and RosettaScript

Member Site Forums Rosetta++ Rosetta++ – Applications Distinctions between InterfaceAnalyzer and RosettaScript

Viewing 0 reply threads
  • Author
    Posts
    • #2227
      Anonymous

        Hi,

        I am currently working to develop a protocol to compute the destabilization of the interface between two proteins upon mutation. The characteristics that I am looking for are a methodology that will distinguish between the perturbation induced by a mutation at the surface and one that is buried, and a perturbation that leads to destabilization of the interface versus one that does not. Thus my general strategy is to compute the energy of binding for the wild type and for the mutant and then take the difference. Because the initial structures are taken from crystal structures, I allow for repacking of the sidechains for both wildtype and mutant before computing the binding energy. From perusing the forums and sundry papers recommended there I either modified or created three different protocols. As far as I understand, the primary distinction lies in either scoring or the packing used however I am not clear how so. From my perspective they should in principle produce the same trends though perhaps not the same numbers, they do not and I am left a bit perplexed. I found that protocol 3 produces the qualitative behaviors I expected however I am somewhat unsure at this point how it differs from protocols 1 and 2. I know that in one fashion or another this question has been hashed and rehashed however having spent alot of time trying to figure out why these different methods produce wildly different results, I figured it might be nice to clarify this in a single spot. Your thoughts and insight regarding how the protocols differ would be very welcome.

        Protocol 1:
        Commandline:
        InterfaceAnalyzer.default.linuxgccrelease @options -s

        options file:
        -overwrite
        -interface A_B
        -pack_input true
        -pack_separated true
        -out:file:score_only score.sc

        The initial sidechains are built externally and a prebuilt PDB was fed in. This was done because as I understood it the InterfaceAnalyzer when called alone did not handle resfiles. As I understand, it uses the default score12 weights. While the mutation is done in an external program I thought that since the sidechain is repacked, this would not introduce a significant issue.

        Protocol 2:
        Commandline:
        rosetta_scripts.linuxgccrelease @options -s

        options file:
        -parser:protocol interface_analysis.xml
        -score12prime true
        -ignore_unrecognized_res
        -no_his_his_pairE
        -out:file:score_only score.sc
        -no_optH false
        -ex1
        -ex2
        -use_input_sc
        -extrachi_cutoff 1
        -linmem_ig 10
        -ignore_unrecognized_res
        -atomic_burial_cutoff 0.01
        -sasa_calculator_probe_radius 1.2
        -overwrite

        interface_analysis.xml:








        As I understand this protocol primarily differs from the 1st in terms of possibly allowing for extra chi angles in the rotamer sampling.

        Protocol 3:
        Commandline:
        rosetta_scripts.linuxgccrelease @resfile.flags

        resfile.flags file:
        -parser:protocol mutation_script.xml
        -s 2O8B.pdb
        -ignore_unrecognized_res
        -out:file:score_only score.sc
        -nstruct 1
        -overwrite

        mutation_script.xml:




        Here we add two delta G filters to calculate the delta G of binding before and after mutations are made.
        We specify a jump number of 3 because want to calculate the delta G of binding the ligand, which is chain D
        in the given PDB file.


        Here we add a task operation used to specify that we want only to repack residues without design

        Here we specify the location of the resfile to use for design.



        Here is a mover to relax the crystal structure
        FastRelax name=relax/>
        Here we pack the rotamers without any design Here we pack the rotamers with design. We specify to read the resfile containing the mutation we want to design
        Here we include the movers and filters in the order we want them to run
        Add mover_name=relax/>



        mut.resfile:
        NATAA
        EX 1 EX 2
        USE_INPUT_SC
        AUTO
        start
        A PIKAA

        The last protocol differ from the first two in the fact that mutations are handled using a resfile rather than reading in a pre-mutated pdb, it also allows for the specification of several more repeats of the initial sampling (50 repeats in this case), rather than requiring repeated runs from the external commandline (not shown) to obtain statistical sampling. However other than these distinctions I am not clear how exactly it differs from the preceding protocol. As I said before thoughts and suggestions would be most welcome. Thank you for your consideration in advance.

    Viewing 0 reply threads
    • You must be logged in to reply to this topic.