ddg_monomer problem

[Anonymous]

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.

Lei

Error messages:

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:

total 1
1
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

[Anonymous]

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.

[Anonymous]

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.

Lei

[Anonymous]

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.

total 1
1
K 24 R

[Anonymous]

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?

[Anonymous]

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”.

[Anonymous]

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.

[Anonymous]

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.

[Anonymous]

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.

[Anonymous]

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

[Anonymous]

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”.

[Anonymous]

Yes, I looked it up in my copy of developer trunk, so it may be different from 3.3.

[Author]

Posts