Merging remote into local before pushing to master to correct Real -> core::Real in a pilot app (to fix compilation with some versions of gcc).

• Summary

Merge pull request #1085 from RosettaCommons/aleaverfay/fix_matcher_chi_building_bug Fixing a problem in the matcher that assumes that the chi dihedrals are right next to each other along the sidechain. It could not handle sidechains where there were rigid segments (e.g. a benzene ring) between two chi dihedrals. The matcher would incorrectly try to build the chitip atom for chi i directly off of chi i-1, instead of off the rigid segment separating them. The fix is to simply add another HT between chitip atom i and chitip atom i+1 (where these HTs are the identify matrix if there are no rigid segments betwen chi dihedrals), and these HTs can be easily extraced from the ideal RT geometry at the construction of the UpstreamRestypeGeometry class. New unit test to ensure that the construction of an example "PBF" molecule is correct. Thanks, Sophia, for finding this bug. The other thing this pull request does it enforce the idea that the user has given a proper bin width for the euler angles -- and that is, that the bin width must evenly divide 180 degrees. So, for example, 10 degrees, and 9 degrees are fine bin widths, but 8 degrees is not. The math for finding neighbors in rotation space near the poles (theta near 180, or 0) requires an even binning. Perhaps this could be made to accommodate other bin sizes, but it seems hardly worth the effort. By "enforce", I mean that the matcher will throw an exception if the euler angle bin width does not evenly divide 180. So, perhaps, previously acceptable command lines will no longer work. At least the error message instructs the user how to modify their inputs.

• Summary

Again increasing the RMS cutoff for a splice test following PR #1079... this time, because the (non-debug) integration tests are consistently failing with an RMS of the spliced in segment of 0.54A. It is surprising that the splice tests are so sensitive, as PR #1079 only applies the slightest bit more repulsion for hydrogens right as their interaction energy is about to go to zero. I have emailed with Gideon, and he is looking into whether something more worrisome is going on.

• Summary

Merge pull request #1091 from RosettaCommons/sboyken/fixing_xcode_postXRW 160211 fixing Xcode issues post-XRW

• Summary

Merge pull request #1089 from RosettaCommons/dimaio/lkball_trie_bugfix Dimaio/lkball trie bugfixes

• Summary

Merge pull request #1041 from RosettaCommons/tlinsky/rosettascripts_movemap_global_bb_chi_jump Add global bb, chi, jump options to RosettaScripts movemap parser

• Summary

Merge pull request #1083 from RosettaCommons/dougrenfrew/mm_lj_memory_issues This PR fixes an issue with the MM LJ term where is was creating a full neighbor list rather than residue neighbor lists during minimization requiring more than 20GB of memory to minimize a protein. Also includes a non-compiled pilot app, some updates to the MM torsion params for small solvent molecules, and the conversion of some std::cout statements to tracers. The cyclization, doug_dock_design_min_mod2_cal_cal, oop_dock_design, and make_rot_lib tests show show expected differences in output since they all minimize with mm_std

• Summary

Changing the rms_cutoff in the splice_out_L3_longer integration test so that it is less sensitive to small changes in the energy function. The test now follows a different trajectory, but at least it passes.

• Summary

Merge pull request #1079 from RosettaCommons/aleaverfay/fix_some_etable_bugs Fixing two bugs in the Etable energy calculation: Near Etable.cc's line 930: Making sure that the spline that ramps the attractive component of the energy to zero does not start before the analytic minimum (lj_sigma_) by taking one-past the bin index with the smallest value. This issue was uncovered w/ Rocco's recent addition of new atom types with radii > 4.5A (the traditional distance at which the splines start). Near Etable.cc's line 1710: Setting the maxd2 for hydrogen atoms to be the actual square distance at which the repulsive energy goes to zero. Before, it got clipped to just before this value for some atom type pairs. Many non-cosmetic integration test changes expected. When all of Rocco's new atom types are enabled, the new atom types work fine, whereas, before several of his atom types "broke" the TableVsAnalyticEtable unit tests. The current set of atom types, however, work fine.

• Summary

Merge pull request #1084 from RosettaCommons/revert-1082-revert-1066-vmullig/ter_records_at_chain_ends Revert #1082 (reinstating TER records between chain ends) My initial merge broke the PyRosetta unit tests. This attempts to address that. This WILL cause all sorts of integration test failures, all associated with adding TER records to PDB output between chains. There shouldn't be trajectory changes or unit test failures, though.

• Summary

I was dumb and compared atom names without whitespace.

• Summary

Merge pull request #1081 from RosettaCommons/dimaio/lkball_trie Adding trie v trie scoring to LKball.

• Summary

Merge pull request #1082 from RosettaCommons/revert-1066-vmullig/ter_records_at_chain_ends Revert "Post-XRW cleanup: add TER records between chains in PDB output." PR #1066 broke PyRosetta. Reverting until the issues with dump_pdb can be fixed.

• Summary

Merge pull request #1066 from RosettaCommons/vmullig/ter_records_at_chain_ends Post-XRW cleanup: add TER records between chains in PDB output. This adds TER records between chains (as is the PDB standard) in PDB output. This is something that Rosetta has never done properly, but now it will. Of course, this means that every integration test that writes PDB files will fail. This is a separate pull request for that reason: it will cause many, many integration test failures. Also, I'm removing some unneeded (and, in some cases, now-dangerous) code. I'm also moving some functions that were implemented as stand-alone utility functions into the PoseToStructFileRepConverter class, as private member functions (since they're never called from anywhere else). The legacy behaviour can be restored with the -out:file:no_chainend_ter flag.

• Summary

Merge pull request #1076 from RosettaCommons/everyday847/read_more_stuff XRW follow-up: read more stuff in If I make yet more modifications I will almost certainly do so in a separate pull request--I think this resolves every issue I was able to short-term identify.

• Summary

Merge pull request #1070 from RosettaCommons/JWLabonte/XRW/Field_refactor Post-XRW: Further refactoring of Field/Record types `Record`s composed of `Field`s are used as temporary data containers for `.pdb` file input before storage in the SFR. As part of the XRW, I refactored this system, but on the second day, I realized that I was overambitious and had added information to the `Field` `struct` that is pointless to store. This merge makes the following changes * Removes "Data Type" columns from `pdb_record_defs` file in the database. * Removes the `enum` for `.pdb` field data types. * Adds an `enum` for `.pdb` record types. * Fixes a bug in ignoring `END` records ThreadingInputter and fold_and_dock show output changes, because they have tracer volume up very high. splice_out_ integration tests show output changes reflecting the bug fix involving `END` records. cyclization integration test is broken. All other tests pass.

• Summary

Legend: