Merge pull request #5603 from RosettaCommons/jadolfbr/mrs_fixes
Fix some issues with MultistageRosettaScripts
This PR fixes the following.
- Enable MRS to actually work well with ParsedProtocol and control-flow.
- Enable MRS to not have a filter for every stage. If there is no filter, we add a TrueFilter.
- Disable all_results_are_not_in. This causes a lot of problems where the job just hangs.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #5622 from RosettaCommons/vmullig/fix_generate_mainchain_potential_copy_constructor
Mistake in GenerateMainchainPotential copy constructor.
This wasn't properly copying, and was creating a compilation error on Mac/clang. Now it should work properly.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #5607 from CyrusBiotechnology/forcommons/hybridize_fix_disulf
HybridizeProtocol: expose disulf_file_ internal
HybridizeProtocol has two constructors. The default constructor assumes data will come in via XML, and DOES check the value of the fix_disulf flag, storing it into an internal string disulf_file_ for later use. The argumented constructor sets class internals via either the arguments or hardcoded defaults and does NOT check the options system - in fact the code is there, commented out.
Cyrus was bitten by this difference. In our fork I am unifying their behavior, but I am uninterested in taking responsibility for making that type of default change globally. (If it were to be properly fixed, HybridizeProtocol should just use a different flag entirely for the purpose; as it is the C++ code in HybridizeProtocol does writing TO the option system to disable this flag during template read-in, because the flag is active at PDB read in time and causes templates to be misread when present...it's, uh, highly nonstandard).
Here I expose disulf_file_ via a standard getter/setter and offer a unit tests that checks A) getting and setting work, and B) that the current constructor behaviors are maintained. I'm fine if RosettaCommons chooses to change the constructor behaviors to match each other in a subsequent PR (I will be doing so in our fork).
I fixed the const & ness of the argumented ctor as a side effect; it made writing the unit test simpler because you can't pass a const string to a nonconst ref argument.
TY sergey for kicking windows tests and Rocco for prompt review
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #5184 from RosettaCommons/aleaverfay/rs_schema_validator_singleton2
This commit adds a new singleton to construct the schema for RosettaScripts and to
then hold the (expensive to construct) XMLSchemaValidator. This validator can
then be requested repeatedly without requiring the costly construction of the schema
or the costly construction of the validator. This should make repeated calls
to the XMLObjects' methods much faster.
Thanks @weitzner for hashing out this idea with me. Thanks @bkuhlman for bringing
the problem to our attention.
This is the alternative fix to the issue that PR #5179 was meant to address
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #5592 from RosettaCommons/jameseastwood/generalize_SequenceSymmetricAnnealer
Generalize the SequenceSymmetricAnnealer to work with noncanonical residues
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #5596 from RosettaCommons/vmullig/fix_single_residue_helix_error
Fix spurious error in helical_bundle_predict when PsiPred predicts a single isolated residue of helix.
The `helical_bundle_predict` application was being a bit too strict in its checks when new helices were defined. One check was producing an error if the last residue index of the helix was not strictly greater than the first residue index. This is unnecessarily strict since the rest of the code tolerates one-residue helices just fine: if extension beyond the defined helices is allowed, then nucleation at a single residue of helix produces one turn of helix (four helical residues), and if extension is _not_ allowed, then nucleation fails but the program continues on happily. Since PsiPred sometimes predicts a single residue to be helical, this check was creating spurious errors in a lot of structure prediction attempts.
This pull request relaxes the check, so that now it checks that the end residue index is greater than _or equal to_ the start residue index in a helix.
This also updates the documentation submodule to point to the latest master of the documentation repo.
notify author
notify list [rosetta-logs@googlegroups.com]