How tu use Delta filter’s relax_mover

[Anonymous]

Hi,

I want to use https://www.rosettacommons.org/docs/latest/scripting_documentation/RosettaScripts/Filters/filter_pages/DeltaFilter to calculate the difference in energy between wt and design. I think I have to use parameter relax_mover, but from the docs It is not clear what value to use. Does anyone have any experience with it?

Edit:

I dug into the source code and it appears that this should work:

<dock_design>

<SCOREFXNS>

<myscore weights="talaris2014.wts"/>

</SCOREFXNS>

<TASKOPERATIONS>

<LimitAromaChi2 name="limchi2"/>

<ReadResfile name="read_rf" filename="enzyme.resfile" />

<InitializeFromCommandline name="ifc" />

<IncludeCurrent name="in_curr" />

</TASKOPERATIONS>

<FILTERS>

<EnzScore name="totalscore" score_type="total_score" scorefxn="myscore" whole_pose="1" energy_cutoff="20"/>

<Delta name="d_totalscore" upper="1" lower="0" range="200" filter="totalscore" unbound="0" relax_mover="whole_min"/> <!-- here -->

</FILTERS>



<MOVERS>

<EnzRepackMinimize name="desmin" design="1" repack_only="0" scorefxn_minimize="myscore" scorefxn_repack="soft_rep" minimize_rb="0" minimize_sc="1" minimize_bb="0" cycles="2" minimize_lig="0" min_in_stages="0" backrub="0" task_operations="limchi2,read_rf,ifc,in_curr"/>

<FavorNativeResidue name="fav_nat_res" bonus="1.5"/>

<MinMover name="whole_min" scorefxn="myscore" chi="1" bb="1" type="dfpmin_armijo_nonmonotone" tolerance="0.01"/> <!-- use this mover for the deltafilter -->

</MOVERS>

<APPLY_TO_POSE>

</APPLY_TO_POSE>

<PROTOCOLS>

<Add mover_name="fav_nat_res"/>

<Add mover_name="desmin"/>

<Add mover_name="whole_min"/>

<Add filter_name="d_totalscore"/>

<!-- report the delta in energy between minimized input structure and designed pose -->

</PROTOCOLS>

</dock_design>

However in the log, I am getting

protocols.simple_filters.DeltaFilter: DeltaFilter

Error: ERROR: Exception caught by rosetta_scripts application:Mover whole_min not found

Error:  

 

[Anonymous]

The relax_mover setting is there such that you can relax your reference pose to the same extent that  you’ve relaxed your “experimental” pose. For example, in design runs you’re typically not just designing, you’re also repacking and minimizing. To get a reasonable reading on the energy difference between the mutated and unmutated forms, you probably want to repack and minimize the reference structure to the same extent (just without the design) to get a fair comparison. The relax_mover setting gives you an opportunity to do that. It will be applied only to the reference structure, and it’s up to you to make a mover that is “comparable”.

 

The reason your XML is not working is that you need to define the mover you’re using prior to the definition of the filter which uses it.

While at apply-time (when the protocol actually run), the order of movers is controlled by the PROTOCOLS block and is independent of the order in which the mover definitions appear in the XML, at parse-time (when the definitions are being read) the definitions are being parsed from the start of the XML to the end, so any definitions which use a particular mover/filter/etc. need to come *after* the definition of that mover/filter/etc.

This isn’t typically an issue because you can have multiple MOVERS/FILTERS/etc. blocks in the XML. In your case, you move the definition of whole_min to a new (additional) MOVERS block that comes between the end of the TASKOPERATIONS block and  the start of the FILTERS block. The rest of the movers can stay in the existing MOVERS block.

[Anonymous]

The relax_mover setting is there such that you can relax your reference pose to the same extent that  you’ve relaxed your “experimental” pose. For example, in design runs you’re typically not just designing, you’re also repacking and minimizing. To get a reasonable reading on the energy difference between the mutated and unmutated forms, you probably want to repack and minimize the reference structure to the same extent (just without the design) to get a fair comparison. The relax_mover setting gives you an opportunity to do that. It will be applied only to the reference structure, and it’s up to you to make a mover that is “comparable”.

 

The reason your XML is not working is that you need to define the mover you’re using prior to the definition of the filter which uses it.

While at apply-time (when the protocol actually run), the order of movers is controlled by the PROTOCOLS block and is independent of the order in which the mover definitions appear in the XML, at parse-time (when the definitions are being read) the definitions are being parsed from the start of the XML to the end, so any definitions which use a particular mover/filter/etc. need to come *after* the definition of that mover/filter/etc.

This isn’t typically an issue because you can have multiple MOVERS/FILTERS/etc. blocks in the XML. In your case, you move the definition of whole_min to a new (additional) MOVERS block that comes between the end of the TASKOPERATIONS block and  the start of the FILTERS block. The rest of the movers can stay in the existing MOVERS block.

[Anonymous]

The relax_mover setting is there such that you can relax your reference pose to the same extent that  you’ve relaxed your “experimental” pose. For example, in design runs you’re typically not just designing, you’re also repacking and minimizing. To get a reasonable reading on the energy difference between the mutated and unmutated forms, you probably want to repack and minimize the reference structure to the same extent (just without the design) to get a fair comparison. The relax_mover setting gives you an opportunity to do that. It will be applied only to the reference structure, and it’s up to you to make a mover that is “comparable”.

 

The reason your XML is not working is that you need to define the mover you’re using prior to the definition of the filter which uses it.

While at apply-time (when the protocol actually run), the order of movers is controlled by the PROTOCOLS block and is independent of the order in which the mover definitions appear in the XML, at parse-time (when the definitions are being read) the definitions are being parsed from the start of the XML to the end, so any definitions which use a particular mover/filter/etc. need to come *after* the definition of that mover/filter/etc.

This isn’t typically an issue because you can have multiple MOVERS/FILTERS/etc. blocks in the XML. In your case, you move the definition of whole_min to a new (additional) MOVERS block that comes between the end of the TASKOPERATIONS block and  the start of the FILTERS block. The rest of the movers can stay in the existing MOVERS block.

[Anonymous]

Simply briliant. Thank you!

One small additional question: is it possible to show the calculated value as a column in the scorefile? It appears in the log, but I was wondering if I could squeeze it right into the scorefile.

 

[Anonymous]

Simply briliant. Thank you!

One small additional question: is it possible to show the calculated value as a column in the scorefile? It appears in the log, but I was wondering if I could squeeze it right into the scorefile.

 

[Anonymous]

Simply briliant. Thank you!

One small additional question: is it possible to show the calculated value as a column in the scorefile? It appears in the log, but I was wondering if I could squeeze it right into the scorefile.

 

[Anonymous]

Yes – by default any filters put in the PROTOCOLS section will also be placed in the scorefile, under the name of the filter (so here it would be “d_totalscore”) — There’s a BIG caveat here that the score in the scorefile will be the score of the *final* structure, rather than the score of the pose at the point in time which the filter is applied. (Here the filter is the last thing in the PROTOCOLS block, so the distinction is academic, but it matters if you add any movers after the filter application.)

If you want to capture the value of a filter at a certain point in time in the middle of the protocol, then you’ll want to use FilterReportAsPoseExtraScoresMover (https://www.rosettacommons.org/docs/latest/scripting_documentation/RosettaScripts/Movers/FilterReportAsPoseExtraScoresMover ).

[Anonymous]

Yes – by default any filters put in the PROTOCOLS section will also be placed in the scorefile, under the name of the filter (so here it would be “d_totalscore”) — There’s a BIG caveat here that the score in the scorefile will be the score of the *final* structure, rather than the score of the pose at the point in time which the filter is applied. (Here the filter is the last thing in the PROTOCOLS block, so the distinction is academic, but it matters if you add any movers after the filter application.)

If you want to capture the value of a filter at a certain point in time in the middle of the protocol, then you’ll want to use FilterReportAsPoseExtraScoresMover (https://www.rosettacommons.org/docs/latest/scripting_documentation/RosettaScripts/Movers/FilterReportAsPoseExtraScoresMover ).

[Anonymous]

Yes – by default any filters put in the PROTOCOLS section will also be placed in the scorefile, under the name of the filter (so here it would be “d_totalscore”) — There’s a BIG caveat here that the score in the scorefile will be the score of the *final* structure, rather than the score of the pose at the point in time which the filter is applied. (Here the filter is the last thing in the PROTOCOLS block, so the distinction is academic, but it matters if you add any movers after the filter application.)

If you want to capture the value of a filter at a certain point in time in the middle of the protocol, then you’ll want to use FilterReportAsPoseExtraScoresMover (https://www.rosettacommons.org/docs/latest/scripting_documentation/RosettaScripts/Movers/FilterReportAsPoseExtraScoresMover ).

[Author]

Posts