Merge pull request #3437 from RosettaCommons/sergey/binder
PyRosetta update. Updating Binder submodule: Disabling trampoline generation for pure-vrtual, const-overloaded member functions. Disabling binding for abstract classes with pure virtual const overloaded functions.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3426 from RosettaCommons/dougrenfrew/seqres_in_pdbinfo
This PR adds the ability to store the SEQRES records from PDB files and have them stored in the PDBInfo object of a pose (the parsing of the SEQRES records was written previously by someone else, thanks +1). The SEQRES records contain the sequence of the full sequence of the protein under study, not just the resolved residues. They are also generally the values that are listed in databases.
This PR simply exposes the chain_sequences strings in the SFR to the PDBInfo object. It requires the --run::preserve_header true flag.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3428 from RosettaCommons/vmullig/fix_parametric_ubsan_issue
Trying to fix an ubsan issue that I introduced when refactoring the parametric code
I had a base class with a method in it that could be used to determine the derived class, and a switch statement of the following pattern:
```c++
// Using static_cast instead of dynamic_cast to avoid the overhead of a dynamic_cast, since I
// don't need dynamic_cast to tell me the derived class type because I have the class function
// instead:
DerivedClass1OP class1pointer( static_pointer_cast< DerivedClass1 >( baseclass_pointer );
DerivedClass2OP class2pointer( static_pointer_cast< DerivedClass2 >( baseclass_pointer );
switch( baseclass->tell_me_derived_class() ) {
case class1:
// Do stuff with the class1pointer
break;
case class2:
// Do stuff with the class2pointer
break;
}
```
This meant that I was guaranteed to be setting up at least one pointer that had been invalidly static-casted to the wrong type, but I was never using it, so it didn't matter. The code was working as written, but was probably a bit fragile and non-ideal, and was tripping up the Ubsan tests. (If ever someone modified it and _did_ try to do something with the wrong pointer, it would cause nasty things to happen.) I've refactored it to follow this safer pattern instead:
```c++
switch( baseclass->tell_me_derived_class() ) {
case class1:
{ //Scope for declaration
DerivedClass1OP class1pointer( static_pointer_cast< DerivedClass1 >( baseclass_pointer );
// Do stuff with the class1pointer
break;
}
case class2:
{ //Scope for declaration
DerivedClass2OP class2pointer( static_pointer_cast< DerivedClass2 >( baseclass_pointer );
// Do stuff with the class2pointer
break;
}
}
```
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3409 from RosettaCommons/roccomoretti/ResidueIndexDescription_update
Rework how ResidueIndexDescription works.
This attempts to make ResidueIndexDescription work a bit more like ResidueSelectors. In particular, instead of having a single, monolithic ResidueIndexDescription class, ResidueIndexDescription becomes an abstract base class which can have different subclass implementation. This allows us to potentially have RIDs like "the last residue in the pose", "the first residue of chain X", "the residue closest to the Pose's center of mass", "reference pose enabled selection designation". This should allow us to better defer things from parse time to apply time.
Note that this splits the current ResidueIndexDescription functionality into two classes ResidueIndexDescriptionPDB (which handles PDB-numbered selections) and ResidueIndexDescriptionPoseNum (which handles Pose-numbered selections). This does not seem to be an issue with the current (limited) use cases in the C++ code.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3419 from RosettaCommons/jadolfbr/simple_metric_cache
Ok, as per request, this PR addresses #3378 - caching SimpleMetrics.
Major
====
SimpleMetrics are now stored in a new `CacheableData` object: the `SimpleMetricData` object. Thanks to @lyskov 's help, the only classes that can store the data are the SimpleMetrics themselves. Anything is able to 'get' the data.
Data is stored during the `apply()` method that all SimpleMetric bases have defined. In addition, the PerResidueReal/String Metrics also create one of @vmullig 's wonderful reference poses during the apply. By default, when we grab the data, we use the reference pose to make sure the residue numbers we are dealing with match the data.
New functions are given during ScoreFile output to output all this data. This also sets up for a future data file for only Per-Residue metrics, which will be easier to make sense of as it stands now.
A new function has been added into each of the base classes where we can use the cache or calculate the data. This is used by `SimpleMetricFilter` and `SimpleMetricFeatures`. The `RunSimpleMetrics` mover will cache this data.
The function is as follows:
```
core::Real
cached_calculate(
pose::Pose const & pose,
bool use_cache,
std::string prefix="",
std::string suffix="",
bool fail_on_missing_cache=true) const;
```
Minor
====
All SimpleMetrics now have serialization methods associated with them. We can now consider using them in GUIs! Code templates have been updated to reflect this.
`DensityFitResidueSelector` now takes an optional pre-configured `PerResidueDensityFitMetric` and the ability to grab the cached version. This speeds up glycan-benchmarking runtimes by about 4 fold as this is a very expensive calculation.
Tests
====
Unit tests have been updated to reflect the major change to the way `SimpleMetrics` are stored. A suite of unit tests have been added to test fetching from this cache, in addition to tests for EVERY base type of Simple Metrics and their cached-use in the Filter system.
A new integration test for caching Simple Metrics has been added.
The Per Residue integration test has been updated to test and confirm caching of Density fit stuff.
Integration test changes are expected for SimpleMetrics as the final output for composite metrics and per-residue metrics is now different with the new cache system. I think this is better organized anyway, with the composite name being added to the end of the 'score' type.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3422 from RosettaCommons/longxing/pack_interface
bias the sampling of interface interactions by upweighting the interface interaction edges
Vikram K. Mulligan 6 years Note: the ubsan test failures for all the parametric stuff was not a problem introduced by Longxing's pull request. Ubsan tests are "best-effort" tests that are not run on every revision. This is the first time that they were run after a mistake that I introduced. As such, I'll fix 'em.[list]
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3421 from RosettaCommons/danpf/cyclic_peptide-patch-1
Fix AchiralResidueTypeTestHeaders.hh typo
VKM had a typo in his unit test that resulted in the score of a pose being compared to the score of that same pose (a comparison guaranteed to yield identical results and pass), rather than the intended comparison between the score of the pose and the score of its mirror-image. This corrects that.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #3402 from RosettaCommons/jadolfbr/ProtocolSettingsMetric
Add ProtocolSettingsMetric to monitor experimental conditions
This PR adds a new composite string metric, `ProtocolSettingsMetric`. It is analogous to the ProtocolFeatures reporter and basically reports both `.user()` options and splits ` any script_vars` options.
The class is configurable to get specific options, or only get `.user()` or set `script_vars`. The primary purpose of this class is for benchmarking, but it is generally useful for record-keeping a specific decoy with set options - IE - the experimental conditions - in which it was run. Typically this is done using file names or directories or other scripts, but using this `SimpleMetric` should streamline benchmarking efforts - especially for those using python, where you can easily plot groups with specific experimental conditions.
This class also works through a Local `OptionsCollection` object (if present) - A COP is placed into the `DataMap` as a resource and available to ALL RosettaScript objects for configurable local options accessing. There may be a better way when we decide to try to remove all global option accessing, but for RosettaScripts, I believe this will work fine.
An integration test and a suite of unit tests have been added.
notify author
notify list [rosetta-logs@googlegroups.com]