Merge pull request #1809 from RosettaCommons/roccomoretti/fill_missing_atoms_B
Fill missing atoms updates/fixes #2
This is an extension of pull request #1789 That PR added functionality to Residue::fill_missing_atoms() to extend the cases in which it can build residues. This PR converts Conformation::fill_missing_atoms() to use Residue::fill_missing_atoms().
This should (hopefully) fix most/all of the "fill missing atoms" from the all-PDB read-in tests.
Integration test changes expected, due to slight differences in coordinate building and trajectory changes. (Checked locally with debug-mode builds.) Tracer changes due to extra debugging lines. Also, fewer "missing atom" lines, as we no longer double-report.
Non-trivial changes in AnchorFinder, PDB_diagnostic, antibody_numbering_converter and identify_cdr_clusters due to slight differences in how dangling connections are treated. Nucleic acid based integration tests also show non-trivial changes, but in what I think is a positive direction: missing phosphates are no longer built from ideal, but are build "backwards" from the rest of the residue.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #1814 from RosettaCommons/roccomoretti/interpolation_addsan_fix
Fix an integration.addsan error by changing how InterpolatedPotential stores data.
Basically, change a raw pointer to a C-style array into a vector0, to avoid new/delete mismatch issues.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #1801 from RosettaCommons/vmullig/tbmb_predict
Add support for sampling threefold-symmetric crosslinkers during peptide structure prediction
Tasks:
- [x] Add a mover to place 1,3,5-tris(bromomethyl)benzene and other three-way crosslinkers.
- [x] It should take a ResidueSelector to pick three residues.
- [x] It should add and place the linker.
- [x] It should set up constraints.
- [x] Distance.
- [x] Torsion.
- [x] It should have an option to pack and minimize the linker and the side-chains to which it's connected.
- [x] It should have an option to do a final relaxation of the structure.
- [x] It needs a parse_my_tag().
- [x] It needs a way to set different crosslinkers.
- [x] Optional distance filters.
- [x] Optional filters for pre- and post-minimization energy.
- [x] More controls for stringency of filters.
- [x] Integration tests.
- [x] Documentation.
- [x] Add support for symmetry.
- [x] Integration test.
- [x] Documentation.
- [x] Add options and code to call the above in simple_cycpep_predict.
- [x] Debug RMSD steps.
- [x] Debug de-permutation steps.
- [x] More controls for stringency of filters.
- [x] Integration test.
- [x] Re-enable filters in integration test.
- [x] Documentation.
- [x] Aw, crap -- I'll need to write XML schema for the new mover.
- [x] Beauty.
Put off to a future pull request:
- Add options to call the above in classic <i>ab initio</i>.
- Add other threefold-symmetric crosslinkers (<i>e.g.</i> Kathy's case).
- Maybe generalize this for Nfold-symmetric crosslinkers?
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #1786 from RosettaCommons/JWLabonte/sugars/database
Carbohydrates: Improving handling of stereochemical nomenclature
This merge will improve the input methods with sugars regarding default stereochemistries. For example, Glc will be assumed to be D-Glc and Fuc will be assumed to be L-Fuc. Also, sugars like Neu are always D; it's inherent to the name. The change involves expanding the nomenclature data in the database and corresponding code to remove hardcoding.
This merge will also add the common bacterial sugar bacillosamine to the database.
Several integration tests change because of an additional `ResidueType`. All other tests pass.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #1789 from RosettaCommons/roccomoretti/fill_missing_atoms_A
Fill missing atoms updates/fixes
Some code improvements to fill_missing_atoms to allow it to build atoms in situations where it normally wouldn't. Basically, add "fall back" logic such that we can build atoms by going up/across the ICOOR tree, not just down it. (This is code that originally comes from the drug design branch, but extended/improved as a result the ChemicalXRW.)
This involved some changes/fixes in how inter-residue AtomICoor are handled.
This touches widely used code, and a large number of integration test changes due to optimization-based trajectory changes are expected. The fact that these stem from insignificant numeric differences (or dangling inter-residue connections) was tracked/confirmed locally with debug-mode integration tests. Additionally, there's a fair amount of cosmetic changes in tracer output.
This is the first part of a two-part pull request, which is being split in half to isolate integration test changes. Changes to Conformation::fill_missing_atoms() are forthcoming, after this one clears the test server.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #1798 from RosettaCommons/roccomoretti/integration_test_count_fix
Fix job accounting in integration.py.
When skipping tests because of a missing command file (e.g. for MPI-only tests), mark the job as 'done' to get proper number-of-tests-running statistics.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #1813 from RosettaCommons/aleaverfay/xsd_xrw_merge_to_master
This is the big XSD XRW merge.
We have written complexTypes for all of the 800+ classes that are create-able through rosetta_scripts. These complexTypes, sewn together, form a schema describing valid input files for it. It serves two purposes. First, it ensures that your input scripts are on one level correct before any movers are created. Second, it provides a reminder to developers at the time that they add new code that they must document it, and enforces that reminder by preventing them from using their new code without doing so.
From here forward, when you add new options to your movers/filters/task operations/residue-level task operations/res filters//residue selectors/scoring grids/feature reporters/constraint generators/RDF functions/ligand areas/movemap definers/etc., you will have to update the schema.
A first-glance description of XML Schema, at least the way we use it, is that there are three things: there are elements (what we call tags), and there are complex types, which describe how the elements can be structured. Elements are described by complex types. Complex types can hold elements (i.e. sub-elements). The third thing: attributes (what we call options). When you say that "PackRotamers" can have an option named "taskoperations", the schema would say "the complex type 'mover_PackRotamers_type has an attribute 'taskoperations'" and elsewhere it would say "there is a subelement of the rosetta_scripts_MOVERS_type' that contains an element named 'PackRotamers', and its type is 'mover_PackRotamers_type.'"
```
<xs:complexType name="mover_PackRotamers_type">
<xs:attribute name="taskoperations" type="xs:string"/>
</xs:complexType>
</xs:complexType name="rosetta_scripts_MOVERS_type'>
<xs:choice>
<xs:element name="PackRotamers" type="mover_PackRotamers_type"/>
... other movers might go here
</xs:choice>
</xs:complexType>
```
The above example is a little hand wavy, but is intended to illustrate the complexType<-->element inter-relationship. You're responsibility as Mover/Filter developers is to define the complexType for your Mover/Filter. Fortunately, you now have 800 examples to learn from.
The code we developed here makes use of a set of classes in utility/tag/XMLSchemaGeneration.hh. These classes were designed to facilitate in-code creation of XML Schema. They are extensively documented. There is also the beginning of a wiki page describing XML Schema here.
About the pull request itself:
There are ~150 cosmetic and expected integration test changes. The only unexpected change is from the OrbitalsFeaturesReporter in the features integration test, which smells like an inlining difference (Some angles and distances that it measures and reports change ~10 digits past the decimal. None of the other features reporters show integration test changes; this is one of the few that involves a lot of code within the features reporter itself as opposed to it calling functions housed in other compilation units.)
Unit tests pass.
The 727 XML tests that were culled from the demos, integration tests, and the community at large all validate, after we went and threw out dozens of them that we could tell would not have worked in the current version of Rosetta, and after we commented out all but one of the LayerDesign operations, whose format is changing.
There is a really cool, really malleable python script that lives in the tools repository; it's in tools/xsd_xrw. It's named rewrite_rosetta_script.py. You give it your old XML with the --input flag and you give it the name of the file you want it to write to with the --output flag, and it turns your pre-XRW scripts into ones that should work post-XRW. You will definitely want to use this script.
Rocco has already begun extracting documentation from the schema output by rosetta_scripts (with the --output_schema flag) which is super cool.
This pull request also beautifies. If you hit a large number of merge conflicts, merge up until 76eb43e, carefully resolving any merge conflicts on the way, beautify your branch, and then merge the final commit of this PR (82349d7) with the assurance that your version should be taken at any point where you encounter a conflict. This is the same post-beautification merge process I outlined here but with different revisions.
On this Thanksgiving, I have to say I am extremely grateful for the hard work and camaraderie of the XRW team. Thank you Una, Sharon, Sam, Andy, Steven, Melanie, and Sebastian. It was a great week and I appreciate your having volunteered your time and energy.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #1811 from RosettaCommons/everyday847/devel_init_like_your_life_depended_on_it
Use devel::init in apps
If you're in an app, you want to call devel::init to go through the whole cascade of initializations.
If you only call protocols::init or, don't even say it, core::init, weird stuff can happen, especially if you try to use any job distributor.
We need to fix this issue before merging XRW stuff because it affects integration tests in a hardware-dependent manner. It's also the cause of some ubsan/addsan issues.
resolves #1375
notify author
notify list [rosetta-logs@googlegroups.com]