Merge pull request #2701 from RosettaCommons/vmullig/fix_spinny_methyls
Fixing N-methyl-D-valine issue, and adding spinny methyls for sarcosine.
The D-amino acid issue was identified by @gbhardwaj, and I think it's due to a mistake in the patch for D-valine (wrong chi index). I also forgot to add spinny methyls for sarcosine, which is important.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2291 from RosettaCommons/vmullig/hbnet_score
Add a nonpairwise, packer-compatible score term giving a nonlinear bonus based on hydrogen bond network size
**Description**
This pull request adds a new score term, `hbnet`, that gives a bonus to each hydrogen bond network in a pose, which ramps nonlinearly with the size of the network. This is a non-pairwise-decomposible but still fast-to-compute score, which, thanks to Alex Ford's multiplex annealer framework, can be made packer-compatible. This allows the packer to do what Scott Boyken's HBNet algorithm currently does: find buried hydrogen bond networks, but with the advantage that it can do this while _simultaneously_ optimizing for all the pairwise-decomposible score terms (so that we can design hydrogen bond networks and hydrophobic cores at the same time). This can also be done in the context of anything that calls the packer (_e.g._ FastDesign), allowing flexible backbone design, off-rotamer packing, _etc._.
**How it works:**
At each step in the packer's simulated annealing run, the energy:
- Constructs a graph in which nodes correspond to residues and edges indicate at least one hydrogen bond between residues. (See note below.)
- Calculates the size of all connected components in the graph.
- Sums the squares of the sizes of the connected components, and returns the negative of this as the energy.
Note that the first step is currently done by a crude distance check between all polar hydrogen atoms and hbond acceptors in all pairs of neighbouring residues. This can be improved by:
- Only updating the edges to the node of the currently-considered substitution (for speed).
- Using the true hbond calculator (for accuracy, at the expense of some speed; currently, some hydrogen bond geometry is bad).
- Using it in conjunction with Scott's nonpairwise buried unsat energy (currently in development) to ensure that buried networks don't have unsaturated donors/acceptors.
Even in crude form, the energy is working to give me hydrogen bond networks, straight out of the packer. This works particularly well when used in conjunction with `aa_composition`, allowing one to set up problems that might be stated in English as, for example, "Design the core with as many core hydrogen bond networks as possible, subject to the constraint that half the core be hydrophobic and that no more than 5% of residues be serine or threonine".
**Tasks:**
- [x] Add the energy.
- [x] Improve speed by only updating hydrogen bonds to a residue for which a substitution is being considered.
- [x] Update the `ResidueArrayAnnealableEnergy` base class appropriately, and the other derived classes (`AACompositionEnergy` and `AARepeatEnergy`).
- [x] Make sure that symmetry is supported.
- [x] Unit tests.
- [x] Asymmetric.
- [x] Symmetric.
- [x] Integration tests.
- [x] Asymmetric.
- [x] Symmetric.
- [x] Beauty.
- [x] Documentation.
- [x] Mention in HBNet mover documentation, too.
**For the future:**
- Switch this so that it can use the true hbonds calculator instead of the crude approximation that it uses now.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2585 from RosettaCommons/roccomoretti/scons_cxx_fix
Autodetect compiler type and version from in-settings compilers.
If you specify alternate compilers using the user.settings file, Scons sets up the compiler flags and path based on the system compiler. This PR puts in a facility to pull out the compiler type and version from the settings files (if any are present).
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2564 from RosettaCommons/aleaverfay/relax_jd3
relax JD3 / fiasco! cleanup
Writing the beginning of a relax_jd3 application.
There are some outstanding issues that mean not all of the functionality in (JD2) relax is available in relax_jd3 -- at least, not to the Multithreaded job distributor in JD3. There is only one reason, but the reason has metastasized throughout the code: global data. Symmetry relies heavily on global data (namely whether symmetry is on or off; you can have different symmetries simultaneously), and electron-density refinement relies heavily on global data. You cannot relax protein A into density map A and protein B into density map B because of this. I think there are several other pieces of global data that need rooting out.
This PR also fixes a static-initialization-order fiasco problem identified by AddressSanitizer. The big change is that BOGUS_ATOM_ID and the other BOGUS globals are no longer a globals, but instead a static methods of their respective classes (e.g. core::id::AtomID::BOGUS_ATOM_ID()).
This also ensures the proper initialization of the global constants in numeric/constants.hh by putting them into the .hh file -- this was only possible with C++11, so, another win for C++11.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2589 from RosettaCommons/roccomoretti/older_gcc_fix
Fix OLDER_GCC define for e.g. Clang on Linux
The issue is not so much the older GCC, but the older libstdc++ which comes with older GCC versions. Testing for GCC version (like we were doing) doesn't help platforms/situations where another compiler (e.g. Clang on Linux) is using the older GCC's stdlib. This PR attempts to test the STDLIB version directly.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2674 from RosettaCommons/vmullig/spinny_methyls
Allow methyl groups in N-methylated amino acids to spin.
It turns out that this is necessary to relieve clashes.
Tasks:
- [x] Modify N-methylation patch for each case.
- [x] Check whether any code changes are needed.
- [x] Yes -- new chis are not being initialized properly. Fix this.
- [x] Check integration test changes.
- All changes are expected. The `genkic_ramaprepro_sampling` and `simple_cycpep_predict_nmethyl` integration tests both test N-methyl tryptophan, and the trajectory changes result from the N-methyl group being able to pack and minimize, which is exactly what I hoped to see.
- [x] Debug unit test failures.
- Done. These were caused by a very tiny floating-point out-of-range issue, where an arccos was being taken on a value that was -1.0000000000002 (resulting in a NaN). Added a bounds check to correct this.
- [x] Debug additional unit test failure.
- Done. The patch was being applied incorrectly to CYZ. Fixed.
@gbhardwaj
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2684 from RosettaCommons/aleaverfay/fix_spades_performance2
Spades performance bugfix part two
Actually comment out the code that I meant to comment out the first time. What happened was, I commented it out, and then while trying to understand the nature of the trajectory changes, commented it back in and promptly forgot I had done so.
Also fixing a 3 year old bug that declared some functions that should not have been virtual functions as virtual. This slowed down atom-pair-energy evaluation a bit. (By having non-virtual functions, the functions can be inlined, and called at 0 overhead -- these functions are needed by the functions that live in atom_pair_energy_inline.hh).
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2685 from RosettaCommons/fordas/add_chainbreak_update
Add support for chain_ending insertion in AddChainBreak and make mover reentrant.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2690 from RosettaCommons/bfrenz/fix_ideal_coord_generation
Made it so that only glycan residues are fixed by the rebuilding of ideal coords after the connections are determined.
Vikram K. Mulligan 7 years Woah -- we've got green lights across the board after this point. Nice! Let's keep it that way.[list]
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2683 from RosettaCommons/roccomoretti/pyrosetta_pose_checks
Add check for zero seqpos in Pose PyAsserts
Sequence positions in Rosetta can't be zero. If you're using PyRosetta and accidentally pass a zero to one of the Pose functions, you'll get a segfault. This is bad - raise a PyAssert instead.
notify author
notify list [rosetta-logs@googlegroups.com]