「view this page in B3 βῆτα server」

Revisions №60013

branch: master 「№60013」
Commited by: Vikram K. Mulligan
GitHub commit link: 「7a9e84ccd7d0f2ee」 「№2855」
Difference from previous tested commit:  code diff
Commit date: 2018-01-30 13:39:32

Merge pull request #2855 from RosettaCommons/vmullig/fix_adams_rotamer_order_issue Fix issue with rotamer libraries that put rotamers in a wonky order. The rotamer code assumes that rotamers are listed in rotlib files in order from lowest chi to highest (with chis defined on `[0,360)`). Unfortunately, not all NCAA rotamer libraries do this, which creates big problems with interpretation of the libraries. This pull request aims to eliminate this requirement for the rotamer order. Kudos to @atom-moyer for identifying the cause of the problem. <b>EDIT:</b> This ended up requiring implementation of a new Voronoi-inspired method for determining the nearest rotamer well centre for noncanonicals. I _think_ that ```fa_dun``` scoring now works correctly for all noncanonicals. Pull request #2887 should be merged before this one --> DONE. Tasks: - [x] Add unit test for equivalence of scoring of DAB with rotamers in the original order or in the corrected order. - [x] Confirm that this _fails_ prior to making any code changes. - [x] I'm going to rewrite rotamer library parsing, since that function's a mess. - [x] Add a rotamer library parsing class. - [x] Reproduce existing functionality, but in separate read, analysis, and configuration steps. - [x] Use an instance of this class for parsing. - [x] Fix unit tests broken by this refactoring. - [x] Add a correction step between initial read and subsequent configuration of the rotamer library object in memory: - [x] Check the rotwell assignments that were in the rotamer library file, and ask whether they are acceptable. - [x] If not, figure out a remapping that makes them acceptable. - [x] Apply the remapping globally (so if bin 1, chi 2, rotwell 3 used to correspond to bin 2, chi2, rotwell 3, and now rotwell 3 is rotwell 2, it remains true that bin 1, chi 2, rotwell 2 corresponds to bin 2, chi 2, rotwell 2). - [x] Throw an error if no consistent remapping is possible (_i.e._ the numbering in the rotamer library wasn't just jumbled, but was actually inconsistent). - [x] Revisit this and fix the sort logic. - [x] Confirm unit test now _passes_. - [x] Confirm that I haven't broken anything else. - All other noncanonicals (TRP:N_methylation, peptoid 601, _etc._) seem to load properly. - [x] The Dun02 rotamer libraries now fail to load, due to inconsistent rotamer well ordering. --> fixed by hard-coding an exception for the canonical Dun02 libraries. - [x] Check the integration test changes. Are the NCAA rotamers as good or better? - [x] Beauty. - [x] Add an override that allows skipping the high-stringency check. It's probably too conservative in some cases. - [x] Fix N-methyl tryptophan problem. - [x] Fix beta-amino acid problem. - [x] Add test for peptoids. - [x] Add test for oligoureas. - [x] Add a D-oligourea test. - [x] Fix issue with D-residues. @atom-moyer @twcraven @dougrenfrew @everyday847

Rocco Moretti 2 years
Are the error/warning messages on the validate_database integration test overzealous? You have warning for beta/talaris which are probably not warranted. (I'd also argue the "canonical rotamer file for the old Dunbrack2002 libraries" warning should be suppressed if the person is explicitly asking for -restore_pre_talaris_2013_behavior
Vikram K. Mulligan 2 years
I'd be inclined to keep the warning with the "-restore_pre_talaris_2013_behavior" flag, since it's good to know what all is affected when using a non-recommended flag. I had missed the warnings that occur with beta_nov16, though -- I hadn't realized that that scorefunction uses Dun02-formatted rotamer libraries. I'll open a pull request to remove the warning in that case.