Merge pull request #2412 from RosettaCommons/JWLabonte/sugars/database
Carbohydrates: H-Placement and Other Topology File Corrections
This merge will correct problems with H-placement that occur when a sugar is not in an ideal chair when loaded in and other blatant topology file errors that have slipped through the cracks.
All sugar `.params` files have been edited/standardized for H-placement, with the following exceptions:
- `to3-alpha-Neup.params` and `to3-beta-Neup.params` — These are chemically impossible sugars and should _not_ be in the database to begin with; however, I am leaving their removal to a future pull request.
- `to8-alpha-Neup.params` and `to4-alpha-Daup.params` — I discovered a `pose_from_saccharide_sequence()` error in loading these two sugars, yet they work fine when loaded from a `.pdb`. The latter is definitely not commonly used; it is only there for a proof-of-concept integration test set up by @everyday847. The former is very common. Please let me know if anyone finds H-placement issues still in the Neup files.
This branch causes integration changes in every sugar test, because I have tweaked all coordinates. I've manually looked at every single one of the ideal structures to make sure that they are correct.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2437 from RosettaCommons/jcminerlanl/git-workflow-demo
Trivial pull request for teaching purposes.
A trivial change was made to a comment line in order to demonstrate the process of a pull request.
-[] Documentation.
-[] Beautification.
notify author
notify list [rosetta-logs@googlegroups.com]
Fixed broken integration tests caused by PR #2418
Reverted a new flag (for hydrate protocol) to prevent breaking integration
tests due to pull request #2418. The option needs to be revisited later for the
hydrate protocol, but for now it will at least stop breaking things by default.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2406 from RosettaCommons/ch.norn@gmail.com/alignmentCleaner
AlignmentCleaner filters -- useful for removing epistasis from MSAs. Typically, to learn the amino acid background frequencies for a protein one would assume that all the sequences in a MSA are samples from some average amino acid frequency profile. However, knowing a structure of your target sequence, this is assumption is unnecessary. Instead you could make sure, that each amino acid in the MSA is a sample from the same chemical environment as your target sequence.
This is useful for optimizing the force field and possibly also for design.
Rocco Moretti 7 years The new `cleanAlignment` integration test added with this commit is currently in permanent (magenta) failure, with the utility_exit_with_message of "The avail aas file must have the same length as the pose"
Christoffer Norn 7 years Thanks for noticing. I've fixed the problem now and pushed to master (hope it was alright, that such a tiny change didn't go through a pull-request?)
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2418 from RosettaCommons/jklai/hydrate
Hydrate/SPaDES protocol with hybrid implicit-explicit solvation
Rocco Moretti 7 years Hi Jason, this commit broke (permanent/magenta failure) some of the integration tests, which weren't corrected by your subsequent fix. Specifically the header_using_check (`using namespace` in a header is forbidden), which Andy fixed for you, but also `thread_local_tracers_check` (declare all tracers as `static THREAD_LOCAL basic::Tracer`) and `app_exception_handling` (the new `hydrate` application needs a try/catch block like the other applications), which are currently still broken in master.
Jason K Lai 7 years Apologies. Andrew Leaver-Fay suggested I revert my merge. Unfortunately, he is travelling right now, so I'm wondering if there is an automatically way of doing this without affecting too many of the subsequent commits
Jason K Lai 7 years Github is not allowing me to revert the pull request. I am currently working on a new pull request to fix the thread_local_tracers_check and app_exception_handling tests.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2420 from RosettaCommons/vmullig/threadsafe_tracers
Grab-bag of thread safety fixes
See issue #2419 -- this started as an attempt to fix the tracer thread-safety issue. Note that this pull request was branched off of pull request #2416, and must be merged after that one.
Also:
- [x] Ensuring that all tracers are `THREAD_LOCAL`.
- [x] The CarbohydrateInfoManager is not threadsafe -- it lazily loads data in a non-threadsafe manner. This pull request will fix that.
- [x] The same is true for the initialization of some global data related to VariantType names, also fixed here.
- [x] Some instances of `std::recursive_mutex` have been switched to `std::mutex`. From what I've read, `std::recursive_mutex` should be avoided, because it encourages sloppiness. (A developer can get away with not knowing the scope over which a mutex is locked, which, at best, can lead to inefficient code with objects locked for way too long, and, at worst, can lead to very difficult-to-diagnose bugs. Misusing a `std::mutex` by trying to lock it repeatedly, on the other hand, leads to unambiguous deadlock, which is easier to diagnose.)
- [x] Making the `been_accessed_` `bool` in `utility::options::Option` into a `std::atomic_bool` in compilations with `MULTI_THREADED` defined. (Issue identified by Helgrind).
TODO:
- [x] Run unit tests for cxx11thread build.
- [x] Check integration tests for cxx11thread build.
- [x] Check scoring tests for cxx11thread build.
- FACTS test fails, as expected. (The FACTS global data cache pose-specific information, and are not threadsafe). All other tests pass.
- [x] Beauty
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2416 from RosettaCommons/vmullig/threadsafe_scoringmanager
Caught a problem in the FoldTree class that was impeding thread-safety
The FoldTree class creates some global data (grr). When multiple threads were working with different instances of FoldTrees, these global data were getting messed up. Adding `thread_local` resolves this -- though I think it might be better not to make these data global at all. As far as I can tell, there's no reason to be using the `static` keyword here, except to avoid a tiny bit of deallocating and allocating (which this probably doesn't avoid all that well, when working with multiple FoldTrees simultaneously). It would be better to make this a private member variable of the FoldTree class (one per instance).
DONE:
- [x] Fix general integration test failures.
- [x] Check unit tests in cxx11thread/serialization build.
- [x] Check integration tests in cxx11thread/serialization build.
- [x] Check scoring tests in cxx11thread/serialization build.
- FACTS test fails, as expected. (The FACTS global data cache pose-specific information, and are not threadsafe). All other tests pass.
- [x] Beauty.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2408 from RosettaCommons/guffysl/set_up_metals_manually
Adds additional tools for handling metals and metal-containing ligands in Rosetta. MetalContactsConstraintGenerator adds distance, angle, and dihedral constraints between (optionally specified) contacts and a user-specified metal atom, either as a single ion or as part of a ligand. LigandMetalContactSelector identifies and selects residues that form contacts with selected metal-containing residues.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2428 from RosettaCommons/vmullig/ui/bundle_gui
Adding support for presets to bundle_gui in anticipation of PreRosettaCon demo
This pull request adds:
- antiparallel beta-barrel preset
- three-helix bundle preset
- support for non-canonical helices (e.g. beta-amino acid 14-helices)
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2417 from RosettaCommons/everyday847/grab_bag
Four grab-bag changes that I needed to get into master. This is a request from Andy via phone.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2372 from RosettaCommons/vmullig/threadsafe_scoringmanager
Make the lazily-loaded data in the ScoringManager threadsafe
This pull request aims to add mutexes to all of the lazily-loaded data in the ScoringManager, allowing the relevant objects to be locked temporarily by one thread as it loads the data for the first time (preventing concurrent reads and writes to these objects, or multiple threads all trying to write to these objects).
Tasks:
- [x] Implement proper double-checked locking scheme (using `std::atomic_thread_fence()` -- see http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/) for each relevant ScoringManager function that loads data.
- [x] Encase relevant stuff in `#ifdef` statements so that it only affects multi-threaded compilations of Rosetta.
- [x] Think about organizing code to minimize the number of scattered `#ifdef` statements. Maybe this is an appropriate place to violate the community rule against macros? --> Yes, added some suitable macros.
- [x] Check whether any of the objects stored in ScoringManager has mutable data likely to be altered when multiple threads are doing supposedly const access.
- [x] Implement for all scoring functions in the ScoringManager.
- [x] Add function that can do a threadsafe check of whether a key is in a map of (string->OP), and, if it is not, can add an object with the given key to the map.
- [x] Implement for all maps in the ScoringManager.
- [x] Implement for other functions in the ScoringManager.
- [x] Test that scoring is unchanged in cxx11thread/serialization build.
- [x] Check integration tests in cxx11thread/serialization build.
- Confirmed: all changes are due either to expected failures of fundamentally non-threadsafe scoring objects which now throw if you try to use them in a multi-threaded context, or are extra output due to loading of all extra rama CDFs in a multi-threaded context.
- [x] Beauty.
Vikram K. Mulligan 7 years Note: this breaks the Mac/clang cxx11thread build test on the testing server due to an older version of the compiler which doesn't support the thread_local c++11 keyword. This is a known issue which will be addressed at some point.[list]
notify author
notify list [rosetta-logs@googlegroups.com]