Getting Started

Build Documentation

Rosetta Basics

Application Documentation

Scripting Interfaces

Development Documentation

Internal Documentation

How to Write Documentation

FAQ

Glossary

Options list

Back to Filters page.
Documentation added 17 July 2015 by Vikram K. Mulligan (vmullig@uw.edu), Baker laboratory.

BundleReporter

The BundleReporter writes all of the helical bundle parameters of a parametrically-generated pose (as might be created with the MakeBundle or BundleGridSampler movers) to the logfile. This filter is mainly intended as a reporter, though it can filter based on energy (much like the ScoreType filter) if one so wishes. Its default behaviour is to write bundle parameters and return "true" (always passing).

<BundleReporter name="(&string)" scorefxn="(&string)" score_type="('total_score' &string)" behavior="('ALWAYS_TRUE' &string)" threshold="(0.0 &Real)" report_sequence="(false &bool)" use_three_letter_code="(false &bool)" />
Options for this filter include:
  • scorefxn: The scoring function that will be used to provide the score output. This option must be set by the user, or an error will be thrown.
  • score_type: The score term that will be used. By default the full scoring function ("total_score") is used.
  • behavior: This filter has three possible filtering behaviours. It can be set to pass always ("ALWAYS_TRUE"), fail always ("ALWAYS_FALSE"), or filter based on the score ("FILTER"). Set to "ALWAYS_TRUE" by default.
  • threshold: If behavior is set to "FILTER", energies above this value result in the filter failing (returning false). Ignored if behavior is set to "ALWAYS_FALSE" or "ALWAYS_TRUE". Set to 0.0 by default.
  • report_sequence: If true, the report includes the bundle sequence. False by default.
  • use_three_letter_code: If true, the sequence reported is as a series of three-letter codes. False (one-letter codes) by default.

Suggested usage

This filter can be useful in cases in which one wants to do very large sampling runs with the BundleGridSampler mover to identify designable regions of parametric space, without producing PDB or silent file output. In this case, one's protocol might be something like the following:

  • A BundleGridSampler mover, probably in nstruct mode, to generate initial geometry.
  • One or more filters to discard backbone configurations that are obviously "bad" (e.g. with mainchain clashes). To this point, the protocol is extremely computationally inexpensive.
  • One or more design movers (e.g. FastDesign, with backbone fixed). This is the relatively computationally expensive step.
  • One or more filters to determine whether a design is "good".
  • The BundleReporter filter to report parameters for those designs passing filters, with the "ALWAYS_FALSE" behaviour set so that no structures are written out to disk.

The script outlined above could be run with the -mute all and -unmute protocols.helical_bundle.BundleReporterFilter.REPORT flags. These flags will mute all output except the reports generated by the filter, summarizing the helical bundle parameters for those designs passing filters.

See also: