Merge pull request #3753 from RosettaCommons/JackMaguire/ExFlagProfileTest2
This corrects behavior from #3745
I added a very short profile test that was intended to track memory usage and not focus on speed. Turns out that it is too short for the benchmark server and now it always fails with the warning "Execution time is below 128s, marking test as failed!". This PR increases the nstruct of that test so that it takes longer (still only a few minutes).
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3736 from RosettaCommons/dougrenfrew/conf_residue_full_to_fwd_header
Convert some full headers to forward headers. May improve compile times slightly.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge aleaverfay/slim_lkball2 (PR #3729)
@JackMaguire noticed that the per-residue memory use has increased substantially and tracked it down to the arrays used to store the water coordinates and water-derivative matrices in the Residue data cache for the LK_BallEnergy. Previously the coordinates were held in natoms x max_waters_per_atom x 3 arrays, and the derivative matrices in three natoms x max_waters_per_atom x 3 x 3 arrays. In the case of TRP, this was nearly 15KB per Residue.
This memory allocation is 100% my fault from a few years back when trying to make LK_Ball faster, which it did, but not in the most space efficient format.
The new code allocates the coordinates in nwaters_actual x 3 arrays, and the derivative matrices in nwaters_actual x 3 x 3 arrays and only when derivatives are actually being calculated.
The memory use is now ~200 bytes per Residue in the context of the packer and ~2KB per Residue in the context of the minimizer.
Integration tests are clean except for one cosmetic test change.
Vikram K. Mulligan 6 years Note: this merge resulted in a release-mode unit test failure.[list]
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3745 from RosettaCommons/JackMaguire/ExFlagProfileTest
Andrew's PR #3729 fixes an issue that increases Rosetta's memory usage by a factor of 4*. This issue doesn't stand out on the testing server because our test cases tend to be small enough to run quickly (this issue only presents itself when memory usage is dominated by Residue objects). This PR adds a profile test that sets up to perform a large packing run but stops after the setup. All of the Residue objects get made but no sampling takes place. Only takes a few seconds.
*when packing with linmem_ig
Thanks Steven and Sergey for reviewing!
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3725 from RosettaCommons/JackMaguire/Inlining2
Continuation of #3670
@dougrenfrew measured a 5% speed increase by compiling with link-time-optimization. The main benefit of LTO is inlining simple functions defined in .cc files. I profiled Rosetta and found a handful of getter-functions that accounted for roughly 0.5% of Rosetta's runtime each. This PR moves those functions to the corresponding .hh file with the hopes of seeing a speed increase. I also moved neighboring functions if it looked like the bundle should be kept together.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3742 from RosettaCommons/sergey/f2
Refactoring main unit test script, adding time measurements for TestSuites, removing mentioning of `YAML` to reduce confusion
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2513 from RosettaCommons/vmullig/peptoid_struct_predition
Add support for peptoid macrocycle structure prediction
This pull request fixes a number of bugs and issues related to general noncanonical design, and peptoid design in particular. It also enables peptide macrocycle structure prediction with the simple_cycpep_predict application, and restores support for N-methylation.
- [x] This pull request is branched off of pull request #2309, and must be merged after that one. (OK, done -- that one is merged.)
- [x] This pull request also requires that pull request #2308 be merged first. (The `xrw_dunbrack_unification` branch was merged into this one.)
- [x] This pull request also requires that pull request #2975 be merged first.
- [x] This pull request will ultimately require that pull request #3477 be merged first.
Tasks:
- [x] Update chiral (600-series) peptoid params files as described in the comments below.
- [x] Update simple_cycpep_predict to allow peptoid residues.
- [x] Update cutpoint handling to use the refactored cutpoint energy instead of the current kludge (constraints).
Tasks:
- [x] Remove redundant sarcosine params files.
- [x] Add sarcosine rama table to params files for remaining peptoids.
- [x] Add properties for `ACHIRAL_SIDECHAIN`, `L_PEPTOID` (for peptoids with chiral side-chains that are in the database), and `D_PEPTOID` (for peptoids with chiral side-chains that are the mirror image of what's in the database).
- [x] Ensure that terms like `omega` and `ramaprepro` are updated to correctly mirror their potentials for `D_PEPTOID` residues.
- [x] Add check that Dunbrack file read was successful. (Currently, it segfaults without an error message if the peptoid rotamer libraries are missing.)
- [x] Unit test for scoring (current default energy function -- currently `ref2015`).
- [x] Unit test for scoring (current `beta` energy function -- currently `beta_nov16`).
- [x] Unit test for minimizing (current default energy function -- currently `ref2015`).
- [x] Unit test for minimizing (current `beta` energy function -- currently `beta_nov16`).
- [x] Unit test for minimizing with N-methylation (current default energy function -- currently `ref2015`).
- [x] Unit test for minimizing with N-methylation (current `beta` energy function -- currently `beta_nov16`).
- [x] Unit test for cyclic geometry.
- [x] Unit test for mirror symmetry.
- [x] Test peptoid with chiral side-chain (e.g. 601 -- like phenylalanine, but with extra methyl on beta-carbon creating a chiral centre).
- [x] Test peptoid with achiral side-chain (e.g. 001 -- phenyl ring side-chain).
- [x] Solve asymmetry issue with achiral side-chain peptoids. I think this a problem with the interpolation, which might be addressed by Andy's pull request #2851. **Edit:** Confirmed. Pull request #2851 addresses this. The `core:SymmDL_peptoid_Tests:test_symm_DL_fa_dun` unit test passes after merging pull request #2851 into this branch. **Edit2:** But my simpler polylinear interpolation scheme (#3477) does _not_ seem to fix this. Hmm...
- [x] Integration test -- simple_cycpep_predict
- [x] The majority of the current unit test failures in this branch are due to a problem with the cutpoint variant and peptoids. Debug this.
- [x] Problem remains with Dunbrack scoring. This is caused by small asymmetries in rotamer libraries for achiral peptoids. Adding automatic symmetry correction on peptoid rotamer library load.
- [x] GAH! Dunbrack unit test failures remain mysterious. Debug this.
- Found it. Corrected by pull request #2975.
- But it does _not_ seem to be resolved by pull request #3477. Hmm. I need to debug this still.
- OK, we're good, now. The problem was inconsistently-numbered rotamer wells from one backbone bin to another. The wrong rotamer centres were often interpolated. This is fixed, now.
- [x] Resolve `core:CyclicGeometry_beta_peptoid_TwoChainTests:test_cyclic_permutation_fa_dun_rot` unit test failure.
- [x] Resolve `SingleNCAARotamerLibraryTests:test_peptoid_001_rotamer_well_scoring` unit test failure.
- [x] The `polycubic_interpolation()` function was also apparently introducing asymmetry. This was actually due to spikes in the landscape caused by improper identification of the rotamers over which to interpolate, due to inconsistent rotamer numbering in the Dunbrack library. I think I've fixed this, now.
- [x] Remove temporary `std::cout` lines in `RotamericSingleResidueDunbrackLibrary.tmpl.hh`.
- [x] Decide whether to uncomment the special-case rotamer spline setup code for N=3.
- [x] Fix Dun02 unit test failures that my fix to the asymmetry issue introduced.
- [x] Fix bug in peptoid clustering. (This was actually due to the virtual atoms introduced by the cutpoint variant.)
- [x] Fix integration test failures that I caused.
- [x] Address further issues: 601/602 design not working.
- ~~Ensure that peptoid design from sarcosine works. (This will probably fail without special-casing due to variant type matching.) This is likely something in `ResidueLevelTask_.cc`.~~ --> Will be fixed in PackerPalette branch (pull request #1047).
- [x] Ensure that peptoid/amino acid design works. (_e.g._ I should be able to say, "Allowed residues at this position are 601, 602, proline, sarcosine, glycine, or alanine."). This is also likely something in `ResidueLevelTask_.cc`.
- [x] Address further issues: design not working with peptoids due to "interchangability group" error (at least, with peptoid 303).
- [ ] Add rotamer libraries for peptoids 631, 633, 332, 333.
- [x] Address issues with design not working with N-methyl amino acids.
- [x] Fix peptoid params files that don't depend properly on LOWER connection.
- [x] Documentation.
- [x] Add note about "GLY:N_Methylation" being considered "SAR" for purposes of design.
- [x] Beauty.
Also:
- [x] This pull request restores N-methylation support, and should address the N-methylation bug.
- Update: this fixes several N-methylation bugs. The N-methyl libraries likely suffered the same spikiness in Dunbrack maps from inconsistently-assigned rotamer wells and from Voronoi boundaries crossing backbone bins.
Addresses issue #2133.
Note:
- [x] I should cherry-pick whatever I can salvage from pull request #2134 and close that pull request.
Put off to a future pull request:
- Add params file for @twcraven's new peptoid.
- Add mainchain potential.
- Add rotamer libary to LFS repository.
Vikram K. Mulligan 6 years The release_debug failure of the octahedral metals simple_cycpep_predict integration test will be fixed in the PackerPalette branch. It's just a timeout in an inherently long integration test.[list]
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3732 from RosettaCommons/jadolfbr/gtm_updates
GlycanTreeModeler Updates
This PR adds a few new options that improve model energies and will be benchmarked in the coming weeks
1) Add an option to GTM for `hybrid_protocol` that is a hybrid between layer building and random sampling. This protocol of the GTM builds out the layers like a tree growing, but instead of only sampling the newly built layer, it spends half its time sampling the layer, and the other half using the `GlycanTreeSampler` to sample any residue up to where we have built out onto. This seems to result in much better energies, while still having the benefits of the iterative layer-build of the core protocol.
2) Refinement now turns off virtualization in order to better maintain and improve the input structure. This can be overridden using an option, and is useful for multiple calls to the modeling protocol.
3) Implement optional sampling of individual conformer torsions using a gaussian. Currently, the angles are set using the mean and a uniform distribution on the up to a single SD. Add functions to enable this in `GlycanTreeModeler` and `GlycanTreeSampler`.
4) Add options to the GTM to use conformer probabilities instead of uniform sampling of the conformer populations.
Update integration tests to test these.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3646 from RosettaCommons/everyday847/more_aramids
More aramids, and Rama maps for ala-aramids that we'll try to use for the whole thing.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3602 from RosettaCommons/roccomoretti/convert_to_make_shared
Convert `new` usage to `make_shared`.
This PR makes utility::pointer::make_shared() available upon the inclusion of utility/pointer.owning_ptr.hh. It also start the conversion of usage of things like `core::pose::PoseOP( new core::pose::Pose )` to use make_shared.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3712 from RosettaCommons/roccomoretti/deep_copy_util
Add a deep copy utility class.
Having a member variable with deep-copy semantics makes things more complicated than it should.
Having just one member variable that needs special treatment means that you can't use the implicit copy/assignment operators, necessitating manual copying of the 100 other member variables in the class, and all the attendant issues with forgetting one, or having someone add one and forget to copy it over, etc.
Instead, it would be nice to have a wrapper class which just "does the right thing". That's what the new utility::pointer::DeepCopyOP class in this PR intends to do. By using a DeepCopyOP class (instead of a straight OP) as a member variable in your class, you should get automatic deep-copy semantics from the implicit copy/assignment operators, but the member variable should work identically to an OP.
The only little "wart" on the implementation is that permit use of forward headers, you need to declare (in the forward header) a (non-class) deep_copy() function in the header, and then define it with the appropriate semantics (usually just calling clone() on the object).
I've done some test conversions on MainchainScoreTable and AnchoredGraftMover, and things seem to be working. There may be edge cases where the DeepCopyOP is not 100% convertible with a regular OP, but I think it will be possible to extend the DeepCopyOP class for those cases.
notify author
notify list [rosetta-logs@googlegroups.com]