Merge pull request #2122 from RosettaCommons/lqtza/snugdock_foldtree_update A frequent complaint of SnugDock users is the requirement for PDB chain order to be LH_A. I'm not sure why this was hard-coded at a point, but it shouldn't be the case. This pull request will update the SnugDock code to use a single FoldTree for docking and loop remodeling. This "universal" FoldTree is shown below.  It will be set once by setup_ab_ag_foldtree in the apply() function of SnugDockProtocol. This new function will also set up the FoldTree with the appropriate Loops for the CDRs. The universal FoldTree will also set the MoveMap and PackerTask for docking. All these objects will be passed along to the various movers involved in SnugDock, so no additional modification is made, whereas previously the FoldTree would be altered at each step depending. Future work will involve generalizing the new functions and moving them to AntibodyInfo as there might be some other code that will benefit from this FoldTree.

• Summary

Merge pull request #3238 from RosettaCommons/JWLabonte/sugars/sampling2 ShearMover: Refactoring BackboneMover code to allow for shearing of non-peptide linkages This merge refactors and simplifies the archaic code of `BackboneMover` to remove most of the hard-coded assumptions and setup a much simpler framework for moves of NCAAs and non-peptides. I am doing this primarily to introduce shear moving of sugars, which was impossible with the previous framework, but it should be much easier to code up shearing for other systems now. FWIW, historical shear moving of a standard peptide linkage only works because a trans peptide bond (omega) forces the two bonds on either side [psi(n-1) and phi(n)] to be nearly parallel. To make a shearing motion, minimizing downstream effects, the two twisting bonds must be near-parallel, and the bond twists must occur in opposite directions with equal magnitude. If the bonds are not near parallel, the chain will spiral. In non-peptide cases, there is no guarantee of any particular bonds being near-parallel to each other, so functions had to be written to search for nearby bonds with similar directional/3D orientations. In the setup phase of the `BackboneMover`s, a list of moving `TorsionID`s is now stored for every "position", removing any hardcoding of which torsions are moving and allowing for shearing of any system. This major change to shearing code means that Rosetta no longer will be guaranteed to pick the previous residue as the counter-moving residue for peptides; it may now also choose the next residue for the counter move. However, it also means that shearing should work for NCAAs with only very minor modifications. Some pedantic notes: in this new implementation, the selected counter move is the nearest to parallel, but no cut-off is used, so it is hypothetically possible that a near-orthogonal counter-move is chosen if there are no better options. However, I think that this case should be exceptionally rare, since most systems are going to be extended, and I require that a counter move be at least a bond away. Even if not so, such a "defective" shear move would effectively be like a small move. It could also be noted that a "less-parallel" bond that is a bond away may be less disruptive than a "more-parallel" bond that is three bonds away. I don't think the difference is worth the extra complexity involved to check for this, again, since a shear move is a small move to begin with. That is, if a move has two shearing counter-move options, the system doesn't test for the least disruptive; it tests for the closest to parallel bond, but both options would at least be shearing and therefore not as disruptive as other options. A large number of integration test changes are expected, from any tests that use glycans, `SmallMover`, `ShearMover` or any torsion-moving across branches, such as ubiquitin tests. All unit tests pass, and old tests were expanded and new ones written to ensure that shearing is behaving as expected. To the best of my knowledge, things work differently but they still work as they should. If this causes anyone problems, please let me know.

• Summary

Merge pull request #3241 from RosettaCommons/everyday847/accelerate_bfm Build full model now 15-20x faster

• Summary

Merge pull request #3242 from RosettaCommons/revert-3240-smlewis_for_gideonla/add_additional_protocol_data_submodule Revert "Add additional_protocol_data as a submodule, on Gideon's behalf" Reverts RosettaCommons/main#3240 because submodule contain LFS files (see https://github.com/RosettaCommons/additional_protocol_data/blob/master/motif_dock/.gitattributes) so it make impossible for ppl to clone it

• Summary

Merge pull request #3240 from RosettaCommons/smlewis_for_gideonla/add_additional_protocol_data_submodule Add additional_protocol_data as a submodule, on Gideon's behalf

• Summary

Merge pull request #3237 from RosettaCommons/vmullig/add_square_planar_or_square_pyramidal_metals Vmullig/add square planar or square pyramidal metals This pull request will allow the `CrosslinkerMover` to place square pyramidal or square planar metals. - [x] This is branched off of pull request #3222, so that must be merged first. @srgerb Tasks: - [x] Add parameters for nickel. - [x] Add new helpers. - [x] Square planar helper. - [x] Delete std::cout line. - [x] Square pyramidal helper. - [x] Delete std::cout line. - [x] Update them to do something. - [x] Square planar helper. - [x] Square pyramidal helper (have it call the square planar helper functions, and inherit from the square planar helper class). - [x] Link to `CrosslinkerMover`. - [x] Link to `simple_cycpep_predict`. - [x] Integration tests: - [x] Square planar case, asymmetric. - [x] Square planar case, d2 symmetric. - [x] Square pyramidal case, asymmetric. - [x] Shorten this test. - [x] Square planar case with `simple_cycpep_predict`, with s6 quasi-symmetry. (The two unoccupied positions break symmetry.) - [x] Check this and add expected results. - [x] Square pyramidal case with `simple_cycpep_predict`, with s6 quasi-symmetry. (Note that 5th position breaks symmetry.) - [x] Check this and add expected results. - [x] Documentation for `CrosslinkerMover`(see https://github.com/RosettaCommons/documentation/pull/22 in the documentation repository). - [x] Documentation for `simple_cycpep_predict`(see https://github.com/RosettaCommons/documentation/pull/22 in the documentation repository). - [x] Beauty.

• Summary

Merge pull request #3239 from RosettaCommons/BYachnin/enzdes_preverse_header_errorhandling The enzdes constraint machinery relies on a set of REMARK headers in the pdb file. If the -run:preserve header option is NOT set, these remarks get discarded when Rosetta reads in the PDB. If the user tries to apply enzdes constraints, the error message that is produced indicates that there are no REMARKs in the PDB file. I have added a quick check to see if -run:preserve_header is set, and if not, add additional tracer output to inform the user that they probably need to turn it on.

• Summary

Merge pull request #3233 from RosettaCommons/jadolfbr/cart_glycan_min Add per-atom Cartesian Minimization Control This PR adds the ability to control specific atoms in cartesian minimization through a new `set_atom( AtomID, bool`) function and associated map in the `MoveMap` Additionally, a boolean option is added to the `MoveMapFactory`, `cartesian`, in order to allow us to set specific behavior for `cartesian` vs `dihedral` movemaps. This option is available in code or through RosettaScripts, and currently is only in use for glycans. It could be expanded in the future for lipids or other polymeric systems. This PR addresses issue #3181, allowing cartesian minimization of glycans to match dihedral minimization and standard IUPAC nomenclature of residues and torsions. This PR will also allow refinement of specific glycan residues in cartesian space, or per-atom refinement for ligands. However, since we do not yet have an `AtomSelector`, this functionality is only currently accessible via code. Unit tests for the `MoveMapFactory` and glycan-specific movemap creation have been added. An integration test for the full functionality has also been added. Finally, this fixes GlycanRelax and GlycanTreeRelax to use the new settings for cartesian.

• Summary

Merge pull request #3222 from RosettaCommons/vmullig/add_trigonal_pyramidal_or_planar_metals Add support for trigonal planar and trigonal pyramidal metal coordination to the CrosslinkerMover This pull request will allow the `CrosslinkerMover` to place trigonal pyramidal or trigonal planar metals. Tasks: - [x] This pull request is branched off of pull request #3216, so that one must be merged first. - [x] Add new helpers (`TrigonalPlanarMetal_Helper` and `TrigonalPyramidalMetal_Helper`). - [x] Update names. - [x] Update `TrigonalPlanarMetal_Helper`'s bond angles, expected symmetries, _etc._ - [x] Add improper dihedrals for planarity. - [x] Update `TrigonalPyramidalMetal_Helper`'s bond angles, expected symmetries, _etc._ - [x] Tie in to `CrosslinkerMover`. - [x] Tie in to `SimpleCycpepPredictApplication`. - [x] Integration tests: - [x] For `TrigonalPlanarMetal_Helper`: - [x] Asymmetric case - [x] Update this. - [x] C3-symmetric case - [x] Fix this. - [x] With `simple_cycpep_predict`, quasi-C3-symmetric case. - [x] For `TrigonalPyramidalMetal_Helper`: - [x] Asymmetric case - [x] C3-symmetric case - [x] With `simple_cycpep_predict`, quasi-C3-symmetric case. - [x] Caught a little bug in the filtering steps performed by the `Metal_HelperBase` class. - [x] Remove temporary `std::cout` line in `TrigonalPlanarMetal_Helper`. - [x] Beauty. - [x] Update `CrosslinkerMover` documentation. - [x] Update `simple_cycpep_predict` application documentation. @csykang @ralphcacho @srgerb

• Summary

Merge pull request #3232 from RosettaCommons/sergey/scientific adding protein_data_bank_diagnostic script and switching Benchmark execute to use PTY

• Summary

Merge pull request #3234 from RosettaCommons/vmullig/shush_noisy_tests Switch some unit tests from std::cout or TS_TRACE to proper tracers Tests can't be muted unless they use tracers.

• Summary

Merge pull request #1636 from RosettaCommons/vmullig/cyclic_cart Making cart_bonded compatible with cyclic geometry, D-amino acids, and symmetric gly tables. Most of this pull request was already merged. This corrects symmetric glycine scoring and minimization with cart_bonded, and should also fix a bug with cyclic geometry and cart_bonded minimization. Tiny cart_bonded scoring changes are expected, and changes to cart_bonded minimization trajectories in several integration tests are likely.

• Summary

Merge pull request #3231 from CyrusBiotechnology/231-forcommons-options-order-test Unit test to ensure that the order in which options are interpreted it as-intended and remains stable. This checks a vector option to make sure it appends and a single-valued option to make sure the "last" one always dominates.

• Summary

Merge pull request #3028 from RosettaCommons/vmullig/exclude_from_rms Add option to exclude user-specified residues from RMSD calculation in simple_cycpep_predict application This is useful, for example, when predicting structures of lariats with "tails", where the ring RMSD matters more than the tail RMSD. Requested by @deiblerk. Tasks: - [x] This branch is branched from pull request #3000. That pull request must be merged first. - [x] Add option. - [x] Have it do something. - [x] Integration test. - [x] Documentation. - [x] Beauty.

• Summary

Merge pull request #3221 from RosettaCommons/bfrenz/anomeric_pseudotorsion Bfrenz/anomeric pseudotorsion

• Summary

Merge pull request #3223 from RosettaCommons/rpavlovicz/water_ddg This commit is a major refactor of PR #2825, removing a lot of code from core into protocols. * all the point-water code, including generation and packing, now lives in WaterBoxMover. This mover is parsable with only 3 options: <WaterBoxMover mode="replace"/> Mode is one of (remove, append, replace), and the mover carries out all steps of the protocol. * water overlap code logic is rewritten to be faster * bunch of options removed (where default values were generally reasonable); option system calls centralized to one function There are many expected integration test failures: * 20 result from changing RestrictToInterface (removing dependency on interaction graph) * 49 result from showing EnergyMethodOptions on stdout (several defaults changed)

• Summary

Legend: