- This topic has 11 replies, 2 voices, and was last updated 11 years, 8 months ago by Anonymous.
April 4, 2012 at 2:53 pm #1225Anonymous
Dear Rosetta users,
I am running ddg_monomer for a mutant following the instructions (renumbering the residues, pre-relax the structure, and build up a mutant file). The calculation for the wt runs okay. But when it reaches to the mutant. I got errors. Here are some information. I attached the flag file, cst file as well as the pre-relaxed pdb file. I appreciate your help.
ERROR: pose.residue(resnum).name1() == wt
ERROR:: Exit from: src/apps/public/ddg/ddg_monomer.cc line: 169
Command to run:
ddg_monomer.linuxgccrelease @../common_flags -in:file:s $PATH/pdb/pdb_reformat_newlist/cst.5AZU_0001.pdb -constraints::cst_file $PATH/pdb/pdb_reformat_newlist/5AZU.cst -ddg::mut_file 5AZU.mut > 5AZU.ddg
Input mutation file:
K 24 R
Last few lines of the ddg log file:
protocols.moves.ddGMover: 50 score before mutation: residue -380.307 fa_atr: -652.154 fa_rep: 37.787 fa_sol: 306.078 fa_intra_rep: 0.883 pro_close: 0.307 fa_pair: -9.828 hbond_sr_bb: -16.635 hbond_lr_bb: -54.789 hbond_bb_sc: -20.219 hbond_sc: -6.435 dslf_ss_dst: -1.856 dslf_cs_ang: 0.022 dslf_ss_dih: 0.000 dslf_ca_dih: 0.008 rama: -6.461 omega: 7.960 fa_dun: 72.666 p_aa_pp: -13.491 ref: -24.150
apps.public.ddg.ddg_monomer: reading in mutfile
apps.public.ddg.ddg_monomer: wt is K resnum is 24 and mut is R
April 4, 2012 at 3:02 pm #6899Anonymous
This is a guess, but your input mutation file does NOT list the PDB chain ID, which means it almost certainly uses Rosetta internal numbering (residues numbered from 1) instead of PDB numbering. PDB position 24 is K, but Rosetta position 24 is probably PDB S25, given that the PDB starts at 2. Reformat your input mutation file to count using numbering-from-1 instead of PDB numbering.
April 4, 2012 at 3:49 pm #6900Anonymous
Hi smlewis, Thank you so much for your fast response. This is helpful. I just noted it in the pdb file I attached. This pdb file is generated from the pre-relax run minimize_with_cst. I attached the original pdb file (which serves the input file of minimize_with_cst) that I already changed the residue number starting from 1. The original pdb starts with Ala1. But the output pdb file from minimize_with_cst truncates the Ala1 and starts with Glu2. Do you know how to avoid this to happen? Thanks.
April 4, 2012 at 5:06 pm #6905Anonymous
I see. Thanks. I will try this solution.
By the way, you mentioned “input mutation file does NOT list the PDB chain ID”. What’s the right format to add the chain information. Here is my current mutation file again.
K 24 R
April 4, 2012 at 5:18 pm #6908Anonymous
I pick the mutation file format just by chance that I wrote a script for auto generating lots of mutation files. Resfile shouldn’t be a big problem even though it looks a bit more complicated. Is it true that I cannot include the Chain ID in the mutation file?
April 4, 2012 at 4:58 pm #6902Anonymous
Andrew pointed out to me that you’ve got zero-occupancy atoms on the first residue. This is a general failure case not specific to minimize_with_cst. The fastest way to fix it is to either A) change the occupancies to 1, or pass “-ignore_zero_occupancy false”.
April 4, 2012 at 5:11 pm #6907Anonymous
I assume that’s the right format. Read the documentation page to learn about the formats: http://www.rosettacommons.org/manuals/archive/rosetta3.4_user_guide/d3/d28/ddg_monomer_application.html
The format you’re using isn’t wrong, it’s just that the format doesn’t include a PDB chain code, so therefore the digit must be a residue/rosetta ID, not a PDB ID. The resfile format allowed for ddg_monomer (see the documentation) DOES use PDB nomenclature; I guess it’s better for some purposes but not for others – the documentation implies it won’t work with mutations at multiple positions.
April 4, 2012 at 5:23 pm #6909Anonymous
A) The documentation says you can’t include a chain ID, that’s all I know.
Use the script you’ve got – just fix your input occupancies before minimization so that the alanine will stay intact, then re-do that step, and I’d guess it will work fine. If you’ve already got renumbered PDBs and a script system there’s no reason not to use them.
April 4, 2012 at 5:30 pm #6910Anonymous
No problem. I will fix the input occupancies. Probably it will start running. I was running ddg for ~100 structures. Only a few got problems probably all due to this occupancy problem. Thank you again for your help.
April 4, 2012 at 5:57 pm #6912Anonymous
I included “-ignore_zero_occupancy false” in the flag file for run minimize_with_cst. But got an error below. What the level should this parameter belong to? Can you please help to fix the problem? Thanks.
ERROR: Option matching -ignore_zero_occupancy not found in command line top-level context
April 4, 2012 at 6:09 pm #6913Anonymous
Just figured it out that I should use “-trust_missing_coords true” in Rosetta 3.3 which is same as the new “-ignore_zero_occupancy false”.
April 4, 2012 at 8:41 pm #6914Anonymous
Yes, I looked it up in my copy of developer trunk, so it may be different from 3.3.
- You must be logged in to reply to this topic.