Open hw-protein opened 2 years ago
Hi @hw-protein
First of all, thanks for your feedback.
I don't know if this is a bug because the insertion is correctly addressed (to my knowledge and expectations). But, for what I understood, you were expecting VAL106
to become VAL105
, is that it? The philosophy of pdbtools
is "one-tool-one-job". Therefore, I think other tools should take the residue number correction. You may need to chain several tools for example: 1. split the chain in two, 2. correct the numbers, 3. merge the chain again.
pdb_selres -:100 my.pdb > first_100.pdb
pdb_selres -102: my.pdb > second_half.pdb
pdb_shiftres --1 second_half.pdb > shifted.pdb
pdb_merge first_100.pdb shifted.pdb | pdb_fixinsert > final.pdb
This could be an approach if your PDB has only one chain.
@JoaoRodrigues Do you think the example reported by @hw-protein is a real bug of pdb_fixinsert
?
I was expecting VAL106
(in 2-2) to become VAL107
(as in 1-2). Because input protein (1-1) and input protein(2-1) is essentially same. The only difference is there is missing residue( ex. not resolved) in input protein(2-1)
I would like to ask about the algorithm of this program.
1)Can "pdb_fixinsert" also be used for PDB files where there is missing residue in ATOM line? For example, the structure of residue 100B and 101 is not determined. Therefore, there is no ATOM line for residue number 100B and 101. Can "pdb_fixinsert" renumber input PDB considering this kind of missing using SEQRES line?
2) I thought that this program creates a reference sequence through the SEQRES line and renumbers the ATOM line information by aligning it with the reference sequence. Is it right?
I think the second question is related with first question.
Can "pdb_fixinsert" renumber input PDB considering this kind of missing using SEQRES line?
No. pdb_fixinsert
operates only by reading the ATOM/HETATM
lines. Therefore, I don't expect VAL102
to become VAL107
because 100B
and ASP101
are not there, contrarily to 1-1. pdb_fixinsert
behaves as we expect it to behave. The 2-2 scenario is correct to our expectations and tests.
Having clarified your concerns and the fixinsert
algorithm, I see this is not a bug, but instead feature request :wink: Thanks for this insightful conversation! :rocket:
@JoaoRodrigues @amjjbonvin should pdb_fixinsert
give priority to SEQRES
lines in case they are present? Is this a feature we would be willing to add?
Cheers,
pdb_fixinsert does not perform renumbering properly when a residue with insertion code is missing.
For example, 1-1) Input : full PDB of 7JMO heavy chain
1-2) Ouput of pdb_fixinsert , for this case work successful
However, when I delete the residue with number 100B and 101
2-1) Input, delete line for residue number 100B and 101
2-2) Output, WRONG numbering compare it with 1-2. Different residue numbering with 1-2