Merge pull request #4341 from RosettaCommons/benchmark
Adding `--disable-new-dtags` linker option to default GCC settings, this should allow proper linking to Rosetta sqlite on Ubuntu.
Merge pull request #4327 from RosettaCommons/rfalford12/find-optimal-hydrophobic-thk
Adding application for finding the lowest energy hydrophobic thickness
Merge pull request #4291 from RosettaCommons/vmullig/bind_fragmentstore_vartypes_to_python
Bind FragmentStore variables to allow access to Python. This incorporates changes from Brian Weitzner and Bobby Langan, and suggestions from Sergey Lyskov.
Merge pull request #4242 from RosettaCommons/JackMaguire/floats_core
Revive extras=rosetta_float, part 2
Sequel to #4241 , partial replacement of #4240
Just modifying src/core in this PR
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.
Merge pull request #4072 from RosettaCommons/roccomoretti/component_loading_both
Fix CCD component loading such that it is more complete.
We're now providing the CCD for reading of arbitrary wwPDB recognized ligands, but we're doing it incompletely.
Right now we have an odd system where we'll load a CCD version, but only if there isn't a Rosetta residue type which has the same three letter code. This is a bit silly, as there's a large number of Rosetta residue types with three letter codes which are not equivalent to the wwPDB residue with that three letter code, and these will obscure the CCD version.
We already have a mechanism for removing CCD types that are equivalent to Rosetta types. This is the exclude_pdb_component_list.txt in the Rosetta database. (And associated facilities for -extra_res_fa etc.) If a three letter code is listed there, we don't load the CCD version.
If the CCD version isn't excluded, and has the same three letter code as the (chemically non-equivalent) Rosetta version, we can load both and then let the atom name heuristic (or other such facility) pick the best residue type match. (The CCD types should come after the Rosetta types, so all else being equal, Rosetta should prefer the database version.)
If, for some reason, this behavior doesn't work for you, you can always add -check_all_PDB_components false (now defaults true) to the command line, or call rtf.set_no_CCD_on_name3_match(true) in-code for your ResidueTypeFinder, and this should re-enable the old behavior.
With this, I've dug through the centroid and fa_standard residue type sets, and updated their exclude_pdb_component_list.txt to be more complete.
Merge pull request #4104 from RosettaCommons/vmullig/rename_scorefunction_tracer
Renaming ScoreFunction tracer to actually reflect the class name and not just the namespace.
This will unfortunately change a bunch of integration tests. It brings the tracer in line with Rosetta conventions, though.
Merge pull request #4068 from RosettaCommons/JWLabonte/quick_fix
Bug Fix: ligand_motif_design integration test
This merge will hopefully correct the `ligand_motif_design` integration test, which I accidentally broke when adding ATP to the database. (:rat: is sorry.) The test formerly used its own ATP `.params` file, and Rosetta will not allow there to be two ATPs in a `ResidueTypeSet`.
I am simply making the test use the database version, which also involves renaming the atoms in the input `.pdb` file to their correct PDB names.
All tests pass, but there are naturally differences in the `ligand_motif_design` test.
Merge pull request #4025 from RosettaCommons/JackMaguire/ClangCxx14
Correcting extras=cxx... flags for clang
#3992 added options to compile with std=c++1y and later versions of c++. To do this, I needed to remove std=c++1x from those builds but failed to notice that clang uses std=c++11 instead. This PR simply corrects the flag being removed.
Thanks for the review Sergey!
Merge pull request #4001 from RosettaCommons/jaumebonet/coupledmovesRS
CoupledMovesProtocol: fixed attribute definitions between parse_my_tag and provide_xml_schema
Fix EnergyMap::operator += (#3977)
The convention for increment-and-assign type operators is to return a
reference to the object that has just been incremented, thereby facilitating
multiple increments in a single statement
```
a += ( b+= c );
```
The original author* of the EMapVector class (aka EnergyMap) did not realize
this and so this class does not return a reference, and instead returns void.
This has never been a problem for C++ code as no one has seemingly wanted
to chain increment-and-assign operations. PyBind11, however, will take the
returned type and assign it to the original object:
```
emap1 += emap2
```
is interpretted as:
```
emap1 = (emap1 += emap2)
```
so that this code:
```
emap1 += emap2
print("Surpise!", emap1)
```
will print
```
Surprise! None
```
This PR changes the signature of just the EMapVector's operator+= and similar methods,
but surely there are other places in the code where operators are not conforming to
the C++ conventions.
*I am the original author of this code.