Member Site › Forums › PyRosetta › PyRosetta – General › Output different favored solutions with PackRotamersMover design
- This topic has 5 replies, 2 voices, and was last updated 12 years, 1 month ago by
Anonymous.
-
AuthorPosts
-
-
July 13, 2012 at 1:23 pm #1344
Anonymous
Hi,
I’m trying to use PackRotamersMover to mutate a serials of mutatable residues into the predefined residues. Here is part of the core codes:
task = TaskFactory.create_packer_task(mutant_pose)
for i in range(1, mutant_pose.total_residue() + 1):
# only perform design for the mutatable residues
if i in mutation_positions:
# only mutate to specific amino acids types, like [“A”, “K”, “F”, “S”, “T”, “K”, “I”]
aa_allow = [False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False,False]
for aa in [“A”, “K”, “F”, “S”, “T”, “K”, “I”]:
aa = aa_from_oneletter_code(name)
aa_allow[aa] = True
aa_bool = rosetta.utility.vector1_bool()
for j in range(1, 21):
aa_bool.append(aa_allow[j])
# set packing options
task.nonconst_residue_task(i).or_ex1(True)
task.nonconst_residue_task(i).or_ex1_sample_level(ExtraRotSample.EX_FOUR_HALF_STEP_STDDEVS)
task.nonconst_residue_task(i).or_ex2(True)
task.nonconst_residue_task(i).or_ex2_sample_level(ExtraRotSample.EX_TWO_HALF_STEP_STDDEVS)
task.nonconst_residue_task(i).or_ex3(True)
task.nonconst_residue_task(i).or_ex3_sample_level(ExtraRotSample.EX_TWO_FULL_STEP_STDDEVS)
task.nonconst_residue_task(i).or_ex4(True)
task.nonconst_residue_task(i).or_ex4_sample_level(ExtraRotSample.EX_TWO_FULL_STEP_STDDEVS)
task.nonconst_residue_task(i).or_include_current(True)
task.nonconst_residue_task(i).restrict_absent_canonical_aas(aa_bool)
# freeze the other residues
else:
task.nonconst_residue_task(i).prevent_repacking()
# start to design
pack_mover = PackRotamersMover(scorefxn, task, 10)
pack_mover.apply(mutant_pose)My problems are:
1. I have run the design for several times with the same input mutatable amino acids types like [“A”, “K”, “F”, “S”, “T”, “K”, “I”], presumably there should be multiple structures with different mutated sequences coming out. But I have run it for ten times, every time the output is the same sequence composition. I don’t think it is reasonable because all of the mutatable reisudes are selected from the experimental single mutation results, there must be more than one combination which are favored in energy. Since PackRotamersMover is a stochastic method on the basis of SA, why it always gives the same result with the given input?
2. Comparing with other rotamer assembling method like dead end elimination which claimed to be able to find the global energy minimum, how is the accuracy of rosetta? Can it find the global energy minimum as well?
3. What should I do if I want to output more design solutions which are energy-favored with PackRotamersMover?
Maybe they are quite basic questions, but I appreciate any suggestion.
xfliu
-
July 13, 2012 at 1:25 pm #7401
Anonymous
Sorry the indentation of the Python codes were eaten by the forum…
-
July 13, 2012 at 1:41 pm #7403
Anonymous
Your PackerTask appears to be set up correctly. It should not repack most positions, and will design the mutable positions to any of 7 residues. That gives it 7^(# residues) diversity. Look for a PackerTask output function (there’s << in C++, I don't know the python equivalent; you may be able to do "print task") and look at the results for debugging help (or paste for me here). It is not surprising to me that it converges. 7^(#res) may not be very many sequences, so it is exhaustively searchable. Monte Carlo is not guaranteed to exhaustively search, and it is not guaranteed to find a true global minimum like DEE, but in general it does a very good job. For this scale of problem I think Rosetta is finding the true minimum. This is especially true if your mutable positions are not neighbors. You _prevent repacking_ at all non-design positions, freezing their sidechains. This means that isolated designable positions will have fixed best residues, regardless of the other mutations that might get made; this hugely reduces the complexity of the problem and leads to faster convergence. So, the first thing to do is replace “prevent repacking” with “restrict to repacking” – which allows sidechain movement but not design. To get more variety out of the packer, there are a few choices. If your number of mutable positions is small, I would just enumerate the sequences and pack all of them to get all their energies. It will be seconds per sequence, so you can afford thousands of sequences easily. Your second option is to increase the Monte Carlo temperature used in packing. See if you can find a ModifyAnnealer TaskOperation, which lets you modify the simulated annealer temperature scheduler.
-
July 13, 2012 at 1:32 pm #7402
Anonymous
You can attach it as a text file to preserve whitespace.
-
July 13, 2012 at 1:42 pm #7404
Anonymous
Thank you Lewis. I know you are quite familiar with the Rosetta sidechain rotamer packing mechanism. Any suggestions? Is there any similar problem with the C++ codes? I have not used fixbb, but the manual says you can specify more than one solutions to be output. I peeked through the fixbb design codes, but not found anything novel, except a outer loop outside the PackRotamersMover… I did the similar thing, but only the same solution came out…
-
July 13, 2012 at 1:45 pm #7405
Anonymous
“Is there any similar problem with the C++ codes?”
Yes – we usually fix it by redefining the problem in some way, enumerating (as in my post below), or changing the temperature scheduler (again as in the post below)
“I have not used fixbb, but the manual says you can specify more than one solutions to be output.”
Can you point me to the specific section of manual you are referring to? This almost certainly refers to -nstruct, which causes multiple outputs, but has no influence on whether those outputs are distinct.
-
-
AuthorPosts
- You must be logged in to reply to this topic.