Merge pull request #4175 from RosettaCommons/JWLabonte/sugars/database
Carbohydrates: Adding patch for O6-acetylation modification for Pooja
This merge will add a single patch file for acetylation of saccharide residues at the oxygen at position 6.
All unit tests pass. carbohydrates integration test changes as expected. There is a known bug in regards to nomenclature that will be fixed in a later PR. It has no effect on results.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #4181 from RosettaCommons/roccomoretti/fix_ncbb
Better error messages for non-canonical backbone types.
With certain patches, it's assumed that residues come in pairs. If that isn't the case, one can get obtuse crashes (see, for example, https://www.rosettacommons.org/node/10602). Add better checking and error messages for these cases.
notify author
notify list [rosetta-logs@googlegroups.com]
Better error messages for non-canonical backbone types.
With certain patches, it's assumed that residues come in pairs. If that isn't the case, one can get obtuse crashes. Add better checking and error messages for these cases.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #4177 from RosettaCommons/rdkibler/graft_switch_mover_fix
Fixed small bug in graftswitchmover involving the wrong type for the burial_cutoff option (change Size to Real)
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #4066 from RosettaCommons/jadolfbr/mmTF
With Dan Farrell's gracious help, this PR allows extra data to be output and read back in for mmTF. For SimpleMetrics, this allows basic multi-run protocols to keep important data around (that could also be used for a subsequent jobs like filtering), and leads the way for a multistage implementation using mmTF.
This PR includes a full round-trip unit test suite for the extra data.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #4170 from RosettaCommons/roccomoretti/fix_broker_test
Fix issue with silent file endianess flipping on Mac.
The broker integration test was broken related to the fact that the input silent file was created on a big-endian system. Normally that should be fine, as the binary silent file reading code has checks to flip the endianness of the input when read on an alternate-endian system. However, it looks like those checks weren't working properly on the Mac/Clang test server system.
Best I can tell, the Mac/Clang compiler isn't realizing that the bit twiddling we do to flip endianness will change the memory layout, and is effectively optimizing out the check. I'm not exactly sure why that is, but moving the code body from an inlined function to a cc function seems to fix the issue.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #4178 from RosettaCommons/vmullig/fix_minor_helical_bundle_predict_issues
Fix minor issues with helical_bundle_predict application that were flagged by clang analysis
Clang analysis complains if a variable is assigned a value on initialization if that value is never read. Personally, I think that this should be left to developer discretion. In performance-limiting contexts, this is a waste of a few clock cycles, it's true. In contexts that are _not_ performance-limiting, though, the slight inefficiency can be less important than the avoidance of uninitialized variable errors in the future, if someone adds a read of the variable in question between its declaration and the first assignment.
Nevertheless, I'm taking out a couple of initializations that are never read, to keep the clang analysis test happy.
(I'm also taking the opportunity to convert a few instances of `vect.push_back( MyClassOP( make_shared< MyClass >( ... ) ) )` into `vect.push_back( make_shared< MyClass >( ... ) )`. There's no need for the extra temporary `MyClassOP`, given that `make_shared` already returns a `MyClassOP`.)
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3593 from RosettaCommons/vmullig/bundle_struct_prediction
Fragment-free structure prediction
When designing proteins, we use _ab initio_ structure prediction as a final validation step. This is useful because it's a test with more false negatives than false positives: if we have 1000 designs, we might throw some away wrongly because Rosetta incorrectly predicts that they don't fold (or doesn't sample close to the designed state), but we tend not to accept a bad design wrongly. Rosetta's _ab initio_ algorithm is, however, dependent on fragments or proteins of known structure.
We need an equivalent for heteropolymer design with noncanonical building blocks. When designing with noncanonicals, we can't use fragments: we don't have databases of folded noncanonical heteropolymers of known structure. We already have a solution for cyclic peptides (GeneralizedKIC / simple_cycpep_predict), but I want to be able to validate linear peptides, peptoids, _etc._ So I'm going to try to write a fragment-free structure predictor for linear structures.
This is a first attempt at a helix-coil transition-based predictor. The idea is:
- Sample random coil regions with a combination of the SmallMover and randomization biased by Ramachandran propensities.
- Sample helical regions using parametric generators to alter helix curvature and curvature direction.
- Allow nucleation, elongation (with possible merging of helices), and retraction/fraying moves with various probabilities to allow transitions from helix to coil and coil to helix.
Allowed moves are shown here:
This doesn't have to be as good as fragment-based _ab initio_ (since some false negatives are okay, but false positives are not). Nevertheless, I'll try to optimize it first by getting it to predict proteins of known structure, then go on to try to validate my peptoid designs.
Tasks:
- [x] Add the app.
- [x] Add the protocols-level implementation of the app.
- [x] Have it do something.
- [x] Integration test.
- [x] Allow `in:file:fasta` or `sequence_file` for constructing the pose.
- [x] Add a RandomizeBBByRamaPrePro mover -- we don't currently have this functionality.
- [x] Unit test.
- [x] Documentation.
- [x] Add a simulated annealing temperature generator.
- [x] Add a Monte Carlo move generator.
- [x] Tie in to the parametric code to allow sampling helix curvature.
- ~~Sensible FoldTree setup: if one or more fixed, folded protein domains are supplied on the command line, at least one should contain the root. (This should be applicable to the case of "enormous loop modeling problems", too: if you have a fixed hairpin with residues A:1-20 and A:481-500, you should be able to model the "middle bit" without either part of the "outside bit" moving.~~ --> For a future pull request.
- ~~Generalize the bits that throw red warnings right now because they're hard-coded for proteins right now.~~ --> For a future pull request
- [x] Add MPI support.
- [x] Move most of the generic code from `SimpleCycpepPredictApplication_MPI` to a base class, and create subclass `HelicalBundlePredictApplication_MPI`.
- [x] Check that I didn't break simple_cycpep_predict: **CREATE A SCIENTIFIC TEST FOR THIS BEFORE MERGING THIS PULL REQUEST**.
- [x] Add multi-threading support.
- [x] Benchmark on Blue Gene/Q.
- [x] Tune the parameters for the temperature scheme and the rules for the Monte Carlo moves.
- [x] Document the helix definitions file format.
- [x] Documentation. --> Documentation is here: https://www.rosettacommons.org/docs/wiki/structure_prediction/helical-bundle-predict (or https://www.rosettacommons.org/docs/latest/structure_prediction/helical-bundle-predict).
- [x] Beauty.
- [x] Remove added line from VSCode configuration (defining `USEMPI` temporarily).
@dougrenfrew @everyday847 @jameseastwood
(Here's an early attempt at predicting the structure of one of @cdbahl's helical bundle mini-proteins:)
notify author
notify list [rosetta-logs@googlegroups.com]
Fix performance bug in the SmallMover (#4141)
A large fraction of the SmallMover's running time was spent on
creating a movemap so that it could look at one thing inside
that move map, and then destroying the newly created movemap.
Same thing in the ShearMover.
Now, create the movemap once at the beginning of `setup_list`
and use that movemap throughout its execution.
Also, there's no need to call pose.energies().clear(); an @details
has been adde to the Energies class to explain why the `clear`
method would ever be necessary.
Running time in a small-mover-only protocol drops 90%!
notify author
notify list [rosetta-logs@googlegroups.com]
Fix bug: InterfaceGroupByVector order dependency (#4142)
The InterfaceGroupByVector selector was sensitive to the order
in which residues were presented it, failing to detect interactions
between residue i in group 1 and residue j in group 2 if j < i.
Why? The UpperEdgeGraph stores only the edges to higher-
indexed nodes and is used for neighbor detection because it
is fast to add edges to this kind of graph. It's not the right
choice, however, if you're trying to iterate across all neighbors
of a particular set of residues.
Because the InterfaceGroupByVector class used this graph,
it would miss residues at the interface between two sets
if the lower-indexed residues were listed second; e.g.
if you have a pose w/ chains A and B (and A comes first)
and you created an IGBV where you said the two groups
were chain B and chain A (in that order), then the IGBV
would find no residues at the interface.
notify author
notify list [rosetta-logs@googlegroups.com]