Dear developers
I am trying to use pmut_scan for a symmetric dimer. I don't know if this is possible but when I run it with a symmetry definition file the program crashes with the following message:
protocols.pmut_scan.PointMutScanDriver: mutation mutation_PDB_numbering average_ddG average_total_energy
terminate called after throwing an instance of 'std::bad_cast'
what(): std::bad_cast
Pmut_sym.sh: line 29: 678 Aborted (core dumped) pmut_scan_parallel.default.linuxgccrelease
the script used is the following:
pmut_scan_parallel.default.linuxgccrelease \
-database /home/Xtal/Rosetta/main/rosetta_database/ \
-in:file:s ../$file.pdb \
-in::file:native ../$file.pdb \
-ignore_unrecognized_res \
-ex1 \
-ex2 \
-extrachi_cutoff 1 \
-use_input_sc \
-no_his_his_pairE \
-multi_cool_annealer 10 \
-mute basic core \
-output_mutant_structures \
-out:file:fullatom \
-symmetry::symmetry_definition ../$symfile.symm \
-symmetry:symmetric_rmsd
thanks in advance
felipet
Unfortunately, protocols in Rosetta need to explicitly set up symmetry in order to take advantage of it. Many protocols are set up to automatically set up symmetry, but some are not. Pmut scan is one that is not.
As a stop-gap, I'd recommend doing the scan in an asymmetric context (either as a one-sided mutation, or as a non-symmetric forced double point mutant) as a first pass, and then refining the scoring based on a symmetric relax as a post-processing.
Alternatively, you could try to put together a protocol within RosettaScripts to do the equivalent mutation scan. The GreedyOptMutationMover can do similar point mutation scanning (https://www.rosettacommons.org/docs/latest/protein-interface-design-move...), although the details differ.
Dear rmoretti
thank you very much for the response
I am trying to put together a xml protocol using GreedyOptMutationMover, for some reason the running ends with a segmentation fault ("2432 Segmentation fault (core dumped)")
do you think this script perform a similar procedure as pmutscan?
thanks again
felipet
script.xml:
<ROSETTASCRIPTS>
<SCOREFXNS>
<score12_symm weights=score12_full symmetric=1/>
</SCOREFXNS>
<TASKOPERATIONS>
<OperateOnCertainResidues name=prot>
<ResidueHasProperty property=PROTEIN/>
</OperateOnCertainResidues>
</TASKOPERATIONS>
<FILTERS>
<ScoreType name=filter scorefxn=score12_symm score_type=total_score threshold=0/>
<RelativePose name=filter1 pdb_name=file.pdb filter=filter scorefxn=score12_symm packing_shell=8.0 thread=1/>
</FILTERS>
<MOVERS>
<SetupForSymmetry name=setup_symm definition=file.symm/>
<PackRotamersMover name=packing scorefxn=score12_symm task_operations=prot/>
<GreedyOptMutationMover name=pmut task_operations=prot filter=filter1 scorefxn=score12_symm relax_mover=packing sample_type=low dump_pdb=1 dump_table=1 rtmin=0 stop_before_condition=0 skip_best_check=0 design_shell=-1 repack_shell=8.0/>
</MOVERS>
<PROTOCOLS>
<Add mover_name=setup_symm/>
<Add mover = pmut/>
</PROTOCOLS>
</ROSETTASCRIPTS>
Your OperateOnCertainResidues operation needs a ResidueLevelTask specification in order to work (https://www.rosettacommons.org/docs/latest/TaskOperations-RosettaScripts...). If you want to allow scanning for mutations at all protein positions, I'd recommend inverting the logic - set all positions that *aren't* protein to repack only. -- Task operations are restrictive: you start with being able to repack and resdesign all positions, and then you turn off the ability to pack or design selectively.
It also looks like you're optimizing over your RelativePose filter. I'm not sure what exactly your use case is, but the GreedyOptutationMover will do the mutation and packing in the context of the starting pose itself. The RelativePose filter is used in contexts where you want to compare the score of a mutation on a second structure. It computes the before and after value of the given filter on the provided PDB backbone. If you just have the one structure, I would skip the RelativePose filter, and use the GreedyOptMutationMover directly.
Also, in your relax mover you are actually permitting mutations. Remember task operations are restrictive, starting from full design. If you don't turn off design in a PackRotamersMover, you'll get design. I'd add a RestrictToRepacking task operation to your PackRotamers task_operations in order to limit things to the point mutations that the GreedyOptMutationMover produces.
Dear rmoretti
I have some problems running the GreedyOptMutationMover with symmetry. This protocol always ends with a segmentation fault...I am attaching the rosetta script just to know why is not working
In the meantime, I realized that I could run the pmut with the flag -out:output of the monomer as a mean to recover all the possible single mutants and then run a fastrelax protocol with symmetry conditions to obtain the score of each mutation. Do you think this procedure is correct?
thanks in advance
felipet
mmm