I am trying to validate a .xml script to be used by rosetta_script application. I copied the .xml file from the paper: Force Field Optimization Guided by Small Molecule Crystal Lattice Data Enables Consistent Sub-Angstrom Protein−Ligand Docking. But the valdation fails...
When I run,
validate_rosetta_script.default.linuxgccrelease -parser:protocol crystdock.xml -parser:script_vars sg=input random=0
Here is my XML:
<ROSETTASCRIPTS>
<SCOREFXNS>
<ScoreFunction name="fullatom" weights="genpot_condensed" symmetric="1">
<Reweight scoretype="coordinate_constraint" weight="1.0"/>
</ScoreFunction>
</SCOREFXNS>
<MOVERS>
<DockLatticeMover name="crystdock" scorefxn="fullatom" trans_step="0.5" rot_step="2.5" chi_step="2.0" ncycles="50" purturb_init_unit_cell="0" slide_lattice="1" spacegroup="%%sg%%" randomize="%%random%%" rand_init_pos="%%random%%" rand_init_chis="%%random%%" rand_init_cell="1" min_init_chis="1" perturb_chi="1" perturb_lattice_scale="1" verbose="1" min="1" final_min="1" pert_ucelldim_step="0.2" pert_ucellangle_step="5" contact_dist="16" init_min_ncycles="5" init_score_cut="0" kT="2" recover_low="1" occ_min_cutoff="0.3" occ_max_cutoff="2.0" occ_min_cutoff_init="0.4" occ_max_cutoff_init="2.0" constraint_jump="1"/>
</MOVERS>
<PROTOCOLS>
<Add mover="crystdock"/>
</PROTOCOLS>
<OUTPUT scorefxn="fullatom"/>
</ROSETTASCRIPTS>
What I notice from the ROSETTA_CRASH.log file is:
Error: Element 'DockLatticeMover', attribute 'purturb_init_unit_cell': The attribute 'purturb_init_unit_cell' is not allowed.
Error: Element 'DockLatticeMover', attribute 'slide_lattice': The attribute 'slide_lattice' is not allowed.
Error: Element 'DockLatticeMover', attribute 'rand_init_pos': The attribute 'rand_init_pos' is not allowed.
[...] Attached is the full ROSETTA_CRASH.log
My question is: Will this affect the rosetta_scripts running? If so, what is wrong with my XML?
| Attachment | Size |
|---|---|
 ROSETTA_CRASH.log | 19.1 KB |
I tried running the application rosetta_scripts. As exepcted, it also gave an erro similar to the one of the validation. What can be the problem here? I dont think is anything with the XML file. Is thhe mover DockLatticeMover already available for public use ? Or is it a new version not released yet?
The DockLatticeMover is availible for public use, but it looks like that XML is using features which are not availible in the publically released version. (If those settings exist, they're in a custom version of the code. I don't see them in any of the most recent developer versions.)
I think you should be able to remove the parameters being flagged (the purturb_init_unit_cell, slide_lattice and rand_init_pos) and get something which works. It might not be _exactly_ what the paper ran, but it's probably going to be the closest you can get with the publically released version.
If you're concerned about the differences, I would recommend emailing the authors of the paper from which you got the XML, and asking them about those settings. (Though on internal channels I just got info that the code which made it to release actually removed those settings because they aren't really needed -- the current defaults [what you get by just removing them] should be fine.)
Hello,
I contacted one of the authors to check on this since the latest documentation also differs from the publication. It appears that, in the current code, most of these values are automatically set from the pose. The primary difference is the constraint_jump option. It's part of the last five options reported that keep occupancy in a specific range. constraint_jump added a constraint during minimization to help with that. Without the constraint, about half of the samples had very low occupancy (and high energy). constraint_jump didn't make it into the main trunk of Rosetta, so, currently, the code will output anything generated. You'll need to increase sampling and post-filter the models to get the ones with the best energy.
As an immediate next step for you, strip out the tags that are not in the current documentation.
You can also use the rosetta_scripts application to give you the accepted tags. For example, run `rosetta_scripts -parser:info DockLatticeMover` and it will provide you this information.
Thank you so much for the reply and the help. Ipartially solved those issues. The validation indeed worked. Now the problem is that, when i run 'rosetta_scripts' it gives me the following error:
ERROR: 'fullatom' is not a valid option for DockLatticeMover
When I check the valid options for the mover with 'rosetta_scripts -parser:info DockLatticeMover', this option is included.
When I strip this option out of the mover the following error occurs:
ERROR: Assertion `ci.A()*ci.B()*ci.C() != 0` failed.
Is there a line number provided for the Assertion error?
I'm out of my depth here, but it looks like this is a check that the spacegroup is defined somewhere, either in a symmdef file or a CRYST1 line. Does your input pdb have a CRYST1 line?
Look at tests/integration/tests/small_molecule_lattice_dock. This should provide some clues as to get the process running. Once running, you can modify it.
Hopefully the experts in this code (or greater experts in the C++ code in general) will chime in, too.
In addition to making sure your input PDB has a CRYST1 line, you may also need to provide the option `-in::preserve_crystinfo` on the command line to enable reading the crystallographic information.
Thank you so much for your help. I was able to run the crystal structure prediction. Since, the mover itself uses the crystallographic information (CRYST1) from the pdb. Do you think that depending on those parameters the final poses might be different - e.g. if I take those parameters from different source, or use the parameters from a co-crystalized structure (Receptor + ligand) ?
The DockLatticeMover is explicitly about docking within a symmetric crystallographic lattice. If you have a different crystallographic symmetry, you have a different docking problem. Which lattice you have is intrinsic to the sort of docking you're doing.
I'm wondering if you've been mislead here a bit. The XML script you're looking at is primarily used for the parameter optimization phase of the specified paper. That is, its primary use is to help (re)fit the weights of the scoring function. If you're just interested in _using_ the fit scorefunction, then you wouldn't use the DockLatticeMover at all -- you'd use the GALigandDock protocol instead.
Thank you so much for your help. I notice that too, but I'm using this docking protocol as a starting point for a virtual screening (comparison purpose).