- This topic has 1 reply, 2 voices, and was last updated 9 years, 9 months ago by Anonymous.
March 12, 2014 at 4:28 pm #1850Anonymous
I’m running RosettaScripts with an Enzdes xml file taken from Fleishman et al PlosOne 2011 (file attached). I’m using Rosetta 3.5 wk52 release. It is working; however, because the enzyme design documentation is not written for rosettascripts, I’m confused as to which options I should include. In particular, my score file does not include many of the parameters (such as interface energies) mentioned in the documentation, and I wonder if this has something to do with the options I provide. I also wonder if this has to do with the talaria changes, but passing -restore_pre_talaris_2013_behavior is incompatible with my xml file.
Any suggestions? Should I stop using RosettaScripts or is there something I need to add to get a more complete score output?
Thank you in advance.
March 13, 2014 at 3:04 pm #9895Anonymous
If you want the extra scoring information like the enzdes application gives you, add the “-jd2::enzdes_out” flag to your options file
Other useful options when doing enzdes with RosettaScripts is “-run:preserve_header” to make sure that the enzdes-style constraint REMARK lines are properly loaded, and “-enzdes:parser_read_cloud_pdb”, which causes rosetta_scripts to properly load the extra ligand position information from the CloudPDB-style matcher output.
All this is entirely due to the enzyme_design/rosetta_scripts differences, and isn’t related to the talaris2013. It should be pointed out, though, that the enzdes.wts file is a score12-based weights file, so is not particularly optimized for a post-talaris context. That’s okay, as from the benchmarks it looks like talaris2013 does as good or better in a post-talaris context as enzdes does in a pre-talaris context. (Although I’d recommend using the talaris2013_cst.wts weights file, which has the various constraint weights turned on.) — I’m slightly confused why your xml file is incompatible with -restore_pre_talaris_2013_behavior: as I read it, it should work with both.
Also, the database already has params files for magnesium and water, so you don’t necessarily have to use -extra_res_fa to load them. Having them be “_MG” (where the “_” is a space) and “WAT” in the input PDB should be sufficient. Of course, if you want to provide your own, slightly altered versions, that’s perfectly alright too. I’d just suggest using a different three letter code in your input PDB to make sure your definitions are used rather than the database ones, or to turn off the loading of the default versions of the parameter files by commenting out the appropriate lines in main/database/chemical/residue_type_sets/fa_standard/residue_types.txt
- You must be logged in to reply to this topic.