Merge pull request #4216 from RosettaCommons/vmullig/add_options_to_simple_cycpep_predict_incremental_merge1
Incremental merge #1 of improvements to simple_cycpep_predict.
This adds support for automatically computing RMSD and PNear from the lowest-energy structure sampled rather than from a user-supplied native. This pull request should be merged before pull request #4197.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #4214 from RosettaCommons/jadolfbr/fix_rabd
This PR fixes a major bug that caused the xml interface for RAbD to fail.
This also adds a short integration test and an extra setter in the mover.
Rocco Moretti 5 years Bisection isn't complete yet, but this commit likely broke the integration.ubsan test. (https://b3.graylab.jhu.edu/test/553770). Generally this particular failure is related to an uninitialized bool variable.
notify author
notify list [rosetta-logs@googlegroups.com]
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
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #4247 from RosettaCommons/vmullig/fix_bind2nd_error
Fix MacOS/clang compilation error due to deprecated std::bind2nd().
Dropping in the following as a replacement:
```c++
//std::bind2nd( &myfxn, old_parameter );
std::bind( &myfxn, std::placeholder::_1, old_parameter );
```
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3770 from RosettaCommons/roccomoretti/const_restype_split
Split ResidueType into separate modifiable and "finalized" classes.
Our current ResidueType layout leaves something to be desired. Right now we have an odd prefinalized/finalized state distinction in a single class, with a whole host of duplicated data which may-or-may not be valid based on the (semantic and non-queriable) state of ResidueType.
To fix this, I'm splitting the ResidueType into two (three if you count the common base class). The vast majority of usage with be of the (always-finalized) plain ResidueType class, which has the conventional name-and-index implementation, with an internal struct-of-arrays layout. For most people, the interaction with ResidueTypes will be the same.
What does change is the interface for people who are modifying ResidueTypes. These people don't work with the plain ResidueType class, but with a new ModResidueType class, which uses VD's (and names) as the primary accessor, with atomic information represented in a graph. (While there is an implicit atom order, accessing by index is highly discouraged in favor of the VD interface, as atoms could be added/deleted at any time, and there isn't necessarily the same bb/sc/hydro order that the plain ResidueType has.)
The only way to make a (non-modifiable) ResidueType is through building and converting a ModResidueType. (You can also convert a plain ResidueType back to a ModResidueType for further alteration.) The ResidueType factory function/constructor takes over the function of the (now-removed) finalize() function. (A common base class which stores non-atom-dependent data simplifies things.)
This should make working with (Mod)ResidueTypes in their modifiable form easier, as there's less redundant information, and all information there is should all be valid and up-to-date throughout the lifetime. (Versus some data/functions being contingent on being finalized.)
A side effect should be that ResidueTypes become slightly smaller (as they no longer have redundant atom information), and that compilation times become shorter because ResidueType no longer has to include the highly-templated boost::graph headers. (These are limited to the ModResidueType class, which is included in many fewer compilation units.)
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #4246 from RosettaCommons/roccomoretti/silent_warning_update
Update number-of-atoms-differ silent file message.
Give better/additional information about potential causes.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #4238 from RosettaCommons/aleaverfay/sjq_ilj_construction_bug
Fixing bug w/ MSRS following JD3 refactor (Issue #4234).
The MRSJobQueen had operated with the knowledge/assumption that the
job_node index stored in the StandardInnerLarvalJob referred to the
preliminary job node from which the later job node descended. The
When the JD3 refactor went through back in January, the JobExtractor
began using the job-node index stored in the InnerLarvalJob to record
the node of origin for a job. The logic for when you declare one job node
complete and move on to the next job node depended on the proper labeling
of InnerLarvalJobs with their node of origin. However, multistage rosetta
scripts was not labeling ILJ's with the job node but instead with the
preliminary job node. This meant that multistage rosetta script jobs
stopped working; it seems likely that everyone who has tried to use MSRS
since January would have been unable to get it to run properly.
(Thanks @odaunc for bringing this bug to Jack's and my attention!)
It turns out that the integration tests for multistage_rosetta_scripts
were not failing before because they were run using the
VanillaJobDistributor, and the VanillaJobDistributor is so simple
that it does not use the JobExtractor at all.
In order to test JD3 applications in single threaded code,
I'm making the VJD as similar as possible to the other JDs
(Thanks for this suggestion, @JackMaguire ).
It was a good thing I did this! It turns out that MRSJQ has/had
a different idea of what the JobDAG would look like from the SJQ.
The MRSJQ thinks that an n-stage protocol should have n nodes in
the JobDAG. The SJQ thinks that if there are m input Poses, that
the first m nodes in the JobDAG will represent one input Pose
apiece. The VJD-version of the MRS integration test was exiting
with an assertion failure.
There's actually a one-line solution to this inconsistency/discrepancy,
in job-dag philosophy, which is that when the MRSJQ calls the
SJQ::create_and_init_inner_larval_job_from_prelim
for the very first stage, the MRSJQ should pass "1" for the
job-node index. (This "fix" is relative to earlier in this PR,
because I am the one to have put the wrong value for this parameter.)
This means that the InnerLarvalJobs that the SJQ constructs for the
preliminary-job-node will have a different job-node index than the
InnerLavalJobs that the MRSJQ constructs and that will actually be used
to construct LarvalJobs. This discrepancy likely has no consequences,
but should be noted.
This PR causes several cosmetic integration test changes as all JD3
applications now will use the JobExtractor and the JobExtractor is
more verbose in its interactions with the JobQueen.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #4241 from RosettaCommons/JackMaguire/floats_protocols
#4240 is a monster, so @lyskov had the great idea to divide it up into multiple merges. This PR only merges the code in src/protocols and a handful of upstream files in src/numeric.
Here, we are replacing doubles with core::Reals and hoping no tests fail.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #4225 from RosettaCommons/vmullig/no_nbr_atom_error
Adding check for NBR_ATOM and NBR_RADIUS lines in params files.
Currently, a params file without a NBR_ATOM line results in a very cryptic error when you try to score a pose containing that residue. Since a params file is really a Rosetta input, and users might provide their own, this isn't ideal: we should have proper error-handling with an informative error message if badly-formatted or incomplete inputs are provided. This pull request adds an explicit check for NBR_ATOM and NBR_RADIUS lines on params file read.
notify author
notify list [rosetta-logs@googlegroups.com]