Merge pull request #1678 from RosettaCommons/aleaverfay/sfxn_from_option_collection
Initialize ScoreFunction and its derivatives from a local OptionCollection
In particular, the EnergyMethodOptions class previously read from the global option system in its constructor. Now, when you call get_score_function with a local OptionCollection object (as people will do in JD3), the OptionCollection is passed along through the ScoreFunction to the EnergyMethodOptions object, and the EnergyMethodOptions object reads from this OptionCollection.
This PR brings in two unit tests that ensure that no options read during ScoreFunction initialization from the local option collection are undocumented. The main documentation function is the static method EnergyMethodOptions::list_read_options.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #1690 from RosettaCommons/everyday847/dont_make_bad_promises
You will see all those EnergyMethod integration test changes, just in the other direction. Do not be alarmed.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #1686 from RosettaCommons/roccomoretti/transform_randomizations
Transform mover randomization tweaks
The Transform mover in ligand docking has a pre-randomization step, but previously you were able to adjust the translational distance in this randomization, but not the magnitude of the rotational randomization. This adds an option which allows you to specify a maximal rotational magnitude (0-360 degrees, defaults to a full 360 randomization.).
Also, the translational randomization was slightly skewed, sampling only one octant from the original position. I've changed the sampling method such that the random translation is uniformly in a sphere of the given maximal radius around the starting position.
Integration test changes expected from XML-based ligand docking protocols, as this changes the random number pulls involved in setting up the ligand randomization.
@darwinyfu Feel free to resolve the merge conflicts with your branch how you like.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #1685 from RosettaCommons/rhiju/thermal_minimizer_tests
Rhiju/thermal minimizer tests
All tests pass (except floating-point sensitive ones & erraser_minimizer which I think will no longer trigger diffs).
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #1696 from RosettaCommons/vmullig/refix_peptidecyclizemover
Reinstating Parisa's fix to the PeptideCyclizeMover. One integration test change expected.
notify author
notify list [rosetta-logs@googlegroups.com]
Commented out the ifdefs that prevented devel from being used in the
Rosetta@home application. Many design filters are in devel that should
be useful on Rosetta@home.
notify author
notify list [rosetta-logs@googlegroups.com]
Resetting master to 7693ff1 and adding .beaut to the .gitignore file
Do not merge your branch into master if it contains the poison commit
99b81fc02, which appeared last night (10/4/2016) at 7pm EDT.
How can you know if your branch contains this commit?
Run this command in your branch:
> git merge-base 99b81fc02 HEAD
If it returns 99b81fc02, then it does. How will you fix your branch if you've
already merged this commit into it?
*sigh* You'll need to create a new branch from the version before you merged
master into your branch, and then you'll need to re-merge master and then
cherry-pick all subsequent commits you've made to your branch since.
BUT you can't do that until after you've cleaned up your version of master.
How will you clean up your version of master. One of two ways.
> git checkout master; git reset --hard 7693ff1; git pull
or
> git fetch; git reset origin/master —hard; git branch -d master; git checkout master
Hopefully, you did not pull master between last night and this morning, and hopefully
you did not merge master into your branch between last night and this morning. But
many of you, of course, did. Contact me if you have trouble. aleaverfay@gmail.com.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #1683 from RosettaCommons/vmullig/support_nmethyl_merge1
Initial merge of code to support N-methylated peptides
I want to split this pull request into a few merges. This one brings in considerably refactored Patch, RamaPrePro, and rotamer code. Lazy loading of any number of mainchain torsion potentials is now supported, and the RamaPrePro score term has been switched over to use the new lazy loading machinery. All integration test changes are expected.
#Background and Rationale:
N-methyl amino acids can be used during peptide synthesis to confer various desirable properties on a synthetic peptide. N-methylation removes a hydrogen bond donor, in many cases promoting solubility in hydrophobic environments and helping with membrane permeability. It also greatly alters the conformational preferences of an amino acid residue.
We want to be able to design with N-methyl amino acids, and this pull request is intended to add support for:
- Modelling N-methyl amino acid geometry (adding a patch for N-methylation).
- Properly scoring N-methyl amino acid-containing peptides (permitting the loading of custom Ramachandran and p_aa_pp tables for N-methyl amino acids).
Following the implementation of PackerPalettes (pull request #1047), a future pull request will add:
- Support for designing with N-methyl amino acids (i.e. getting the packer decide whether to N-methylate a position or not).
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #1660 from RosettaCommons/everyday847/ncnts_in_stepwise
NCNTs in stepwise: Integration test changes are all spurious (new EnergyMethodOption, in particular, causes ~50).
notify author
notify list [rosetta-logs@googlegroups.com]