RosettaDNA error – Rosetta Commons

This topic has 10 replies, 3 voices, and was last updated 12 years ago by Anonymous.

Viewing 4 reply threads

Author

Posts
- December 7, 2012 at 2:09 pm #1482
  Anonymous
  Dear Rosetta Community,
  
  I am trying to test run RosettaDNA by following the PlosOne 2011 paper “RosettaScripts: A Scripting Language Interface to the Rosetta Macromolecular Modeling Suite”. http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0020161. The protein example I used is zif268 from the NAR 2009 paper “Assessment of the optimization of affinity and specificity at protein-DNA interface”. But my calculation didn’t complete with error reported at the 2nd round of DNAInterfaceMultiStateDesign after DesignProteinBackboneAroundDNA. The first round DNAInterfaceMultiStateDesign ran without problem. The error message is the following:
  
  Error in log file
  “protocols.dna.DnaInterfaceMultiStateDesign:
  Building dna target state:
  A.2.GUA/B.11.CYT_p:UpperDNA,
  protocols.dna.DnaInterfaceMultiStateDesign: WARNING: Message(s) above was printed in the end instead of proper place because this Tracer object has some contents left in inner buffer when destructor was called. Explicit call Tracer::flush() or end your IO with std::endl to disable this warning.”
  
  Error in the terminal
  ERROR: pos.paired()
  ERROR:: Exit from: src/protocols/dna/DnaInterfaceMultiStateDesign.cc line: 450
  
  I attached the pdb input, flag, script and log files. Can you please help to diagnose the problem? Thanks a lot.
- December 7, 2012 at 3:32 pm #8189
  Anonymous
  I can tell you that it’s angry that you have an unpaired DNA base. Is one of your DNA bases in the interface unpaired? Can you take it out? I’ve attempted to contact Justin Ashworth (the code’s author) for further input.
- December 7, 2012 at 3:53 pm #8190
  Anonymous
  Justin says:
  
  “It could be that the DNA is coming apart or mispairing. I would suggest trying only the interface packer, the multistate design, or the backbone design independently to see which ones work in isolation.”
- December 7, 2012 at 9:31 pm #8196
  Anonymous
  Justin says:
  “I implemented those flexible TaskOperations to configure what happens to DNA during Packer operations. Adding that ‘DnaNoPack’ to the task_operations of the movers should fix the loss of pairing by preventing the nucleotides from mutating or repacking.
  
  That nullifies certain protocols that cycle through or mutate DNA types though, which may or may not be desired by this user. If the following taskoperation works in the release then it’ll enforce Watson-Crick basepairs if and when the DNA mutates.
  {WatsonCrickRotamerCouplings name=WCRC/}
  I’m [not] sure if it works in the release, or whether the dna_bp weight needs to be set for it to be enforced. It is worth trying if the user is expecting the DNA to change.”
- December 10, 2012 at 5:50 pm #8208
  Anonymous
  Certain DNA Interface protocols (MultistateDesign included) require that the DNA remain ‘mutable’ with respect to the rotamer packing routines. However it seems that perhaps during the DesignProteinBackboneAroundDNA protocol, the DNA goes awry for you… if the WatsonCrickRotamerCouplings operation alone does seem to fix that problem, then I would suggest limiting the use of the DnaNoPack operation to DesignProteinBackboneAroundDNA.
  
  Some additional experimentation with suitable combinations of taskoperations and protocols may be necessary or fruitful; not all combinations of taskoperations and protocols will cooperate, and not all structures will behave similarly, but soon it should be apparent which ones do. The RosettaScripts framework represents kind of a sandbox in which various combinations of tasks and routines can be put together, sometimes in ways that are not guaranteed to work (we’ve never quite ensured that all combinations will work in all cases). There are also a number of new hypothetical combinations and compound routines, a subset of which will actually work. The example script was actually a bit overkill in the way it combines Movers for the sake of demonstration. In practice I tended to break things down into individual isolated steps, carefully examine the results, perhaps filter or tune individual Movers, and then only in special cases did I run a more complex protocol involving all of the Movers provided in the example at once. It all depends on what you’re after ultimately. Incidentally the most accurate results are generally obtained without using DesignProteinBackboneAroundDNA at all (more freedom->more error…)
- December 7, 2012 at 3:59 pm #8191
  Anonymous
  Thanks for your quick and helpful diagnose. You’re right. I read the log file again and found that the base pair C3:G10 is reported unpaired. I then examined the intermediate pdb output file (which is attached). This based pair seems lose the normal hydrogen bonding. Comparing to the input pdb which is a crystal structure, it seems like the normal hydrogen bonds in C:G pair is disturbed by either the first round of msd or bb protocol. I can also see amino acid residue E77 is mutated to M77 during the design process. Maybe the distorted base pair is the consequence of this mutation?
  
  I still want to include designs around this base pair since it contacts the binding protein. Is there a way that I can tell the Rosetta Script to restrain the normal base pair or at least don’t interrupt the original crystal structure? Another possibility that I can think is to introduce a resfile to control the mutation of E77 residue, although it may not prevent the base pair distortion. Any additional thought is appreciated.
- December 7, 2012 at 4:06 pm #8192
  Anonymous
  That’s a very good point. I tried multistate design and interface packer independently before running the combination. Not tried backbone design independently though.
  
  I just checked several multistate design results and one interface packer result models. I saw all multistate design output models have this C3:G10 base pair disturbed. The interface packer result is fine.
- December 7, 2012 at 8:48 pm #8194
  Anonymous
  I’m pretty vague on what this protocol is doing, but your resfile idea seems like a good one. You could also try adding a constraint that mimics the CG hydrogen bond to double-count the bond and make it “stronger” to the energy function.
  
  Is the DNA backbone moving or just the protein backbone? You may be able to tell it to not move that particular base pair with a resfile or with changes to your inputs?
- December 7, 2012 at 9:41 pm #8197
  Anonymous
  I tried to prevent E77 being mutated or direct E77R mutation with resfiles. However, the DNA base pair C3:G10 is still distorted in both tests and thus stopped the further round of DNA interface design.
  
  In another experiment, I tried to neglect the C3:G10 base pair in the script. This modification passed the test; and I have the whole protocol completed successfully. This is a kind of confirmation of the problem. But I really want to keep this base pair considered. So, skipping it is the last choice.
  
  I examined the output PDB and found DNA backbone coordinates remain as the input PDB. Only bases move. I wonder what energy or force pulls the C3:G10 pair apart from the original hydrogen bonding form. This movement seems not energetically feasible even with the protein context. I also noted that some other base pairs is more or less distorted comparing to the input crystal structure. But the distortion is not as severe as C3:G10 so that the protocol neglect those distortions.
  
  Can you please provide more details on how to ” try adding a constraint that mimics the CG hydrogen bond to double-count the bond and make it “stronger” to the energy function.”? Is this operation through the resfile or the script or some other way?
  
  Thank you.
- December 7, 2012 at 10:10 pm #8198
  Anonymous
  Very useful tip. I will try WCRC. By the way, I’m still on v3.3. Not sure if there are any differences to the current v3.4 in term of script supporting.
  
  I did find DnaNoPack in the published script and guessed that might be the DNA negligence switch. I tried to add DnaNoPack in the DnaInterfaceMultiStateDesign (the problematic mover in the protocol) by specifying it in task_operations = … after DnaInt. But running this test also resulted errors “Exit from: src/protocols/dna/DnaInterfaceMultiStateDesign.cc line: 238” and “protocols.dna.restrictDesignToProteinDNAInterface: Error: target type GUA does not correspond to an allowed type at position 2”. I think that I didn’t use DnaNoPack correctly. Can you please ask Justin how to properly use this task operation? Thanks.
- December 11, 2012 at 7:03 pm #8220
  Anonymous
  Thank you Justin for the suggestion. I just got a chance to try including WatsonCrickRotamerCouplings in both MultistateDesign and DesignProteinBackboneAroundDNA. But I see the similar problem as of that I didn’t call WatsonCrickRotamerCouplings. I’m not sure if WatsonCrickRotamerCouplings is supported. But at lease I didn’t see error for this part. The error message is same as the jobs that I run without using WatsonCrickRotamerCouplings. The key DNA based is still distorted. Can you please take a look at the script to check if I use WatsonCrickRotamerCouplings properly? I attached my script and the log file.
  
  I also tried to use DnaNoPack to replace DnaInt in MultistateDesign. The job can go through in this case. But the trade off is that DNA interaction will be ignored (since not DNA interface is specified, am I right?).
Author

Posts

Viewing 4 reply threads

You must be logged in to reply to this topic.