Merge pull request #2111 from RosettaCommons/aleaverfay/interleave_new_rotamers_in_rotset
Aleaverfay/interleave new rotamers in rotset
Adding a new way to append rotamers to a RotamerSet to reduce memory usage and running time when a large number of new rotamers need to be appended. The new functionality comes through the function RotamerSet::add_rotamer_into_existing_group and will figure out what existing residue-type group to add your rotamer to. If you already have a bunch of ARG rotamers and you add another, then the new rotamer will get slotted in at the end of the list of ARG rotamers, but in front of the set of SER rotamers (assuming you have SER rotamers).
There are a number of places in the packer where the memory use scales quadratically with the number of different amino acid types, even if it scales linearly with the number of rotamers. Try avoiding calls to RotamerSet::add_rotamer.
Expected integration test changes in the following integration tests which now have different rotamer orderings, and thus produce different outputs from the packer (and further downstream trajectory changes):
- enzdes
- inverse_rotamer_remodel
- ligand_motif_design
- motif_dna_packer_design
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2730 from RosettaCommons/vmullig/rescountfilter_fix
A few fixes to recent changes to the ResidueCountFilter
Tasks:
- [x] Add logic to avoid double-counting if multiple, overlapping properties are defined.
- [x] Add logic to avoid double-counting if residue types AND residue properties are defined.
- [x] Remove unnecessary `static` keyword and correct variable naming convention.
- [x] Updating some Doxygen tags.
- [x] Add unit test for ResidueCountFilter.
- [x] Beauty.
- [ ] Documentation.
@hssnzdh2 @tjbrunette
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2668 from RosettaCommons/roccomoretti/first_use_tracer_2
Change how we do `thread_local` tracers
Having a large number of static thread_local Tracer objects causes issues with stack usage with multithreading. This PR separates the static portion of Tracers from the main, thread_local, part (now called TracerImpl), and adds a behind-the-scenes construct-on-first-use linkage between the two.
**What does this mean for the average Rosetta Developer?** Not much. I attempted to make this invisible to normal Tracer use. The only change for most people is now you need to omit the THREAD_LOCAL from the Tracer definition. (You'll likely you'll get a compiler error if you forget, and there's also an integration test to check.)
notify author
notify list [rosetta-logs@googlegroups.com]