Dealing with dimers

Hellow everybody
I have problems using Haddock for dimers. I’ve received several different messages:

  1. Using pdb (from pdb databse)
    There was an inconsistency in your data

Error message

First pdb file contains multiple forms of the same residue. This is not supported in the current form. If you would like to supply multiple conformations, please create an ensemble

  1. using a pdb with only one chain (but is a dimer)
    There was an inconsistency in your data

Error message

First pdb file contains multiple residues with number 1335 in chain

How could I create an ensemble to analyze a dimer?

thank you in advance

When docking a dimer, you have to make sure the numbering of the two chains is not overlapping. Which means you will have to renumber them and use a single chainID.
This can be easily done using our freely available PDB tools:

http://github.com/haddocking/pdb-tools

for example using the pdb_selchain.py and pdb_reres.py tools

Another related problem is that for high resolution structures, you might have multiple occurrence of a side-chain, which will also give problems. This can be removed using the pdb_delocc.py tool. Read more on the gitHub repository.

1 Like

One example of the above (assuming you have installed our pdb-tools into ~/software/pdb-tools):

~/software/pdb-tools/pdb_selchain.py -B 1GGR.pdb |\ ~/software/pdb-tools/pdb_reres.py -501 |\ ~/software/pdb-tools/pdb_delocc.py >my-renumbered-pdb-file.pdb

This will effectively select chain B, renumber it starting at 501 and remove any possible double occupancy side-chains

Hi, i AM WORKING WITH DIMERS TOO. I RENUMBER MY BOTH CHAINS, NON HAVE TWO RESIDES ON SAME NUMBER BUT EVEN THOUGH I GOT THIS MESSAGE " There was an inconsistency in your data

Error message

First pdb file contains multiple residues with number 75 in chain A
Directory of the run: http://milou.science.uu.nl/serviceresults/HADDOCK2.2/945986900/test12"

WHAT SHOULD I DO NOW??

Somthing is still wrong in your input PDB for chain A.
Check carefully your input PDB for duplications of residue 75… e.g.

grep " 75 " my-pdb-file

(you can also send me the file privately)

Residue 75 in your PDB file has two instances of the O atom, which is why the server complains.

ATOM 575 N ARG A 75 26.487 23.911 9.480 1.00 20.00 N ATOM 576 CA ARG A 75 25.108 24.163 9.088 1.00 20.00 C ATOM 577 C ARG A 75 24.336 22.882 8.761 1.00 20.00 C ATOM 578 O ARG A 75 24.935 21.812 8.857 1.00 20.00 O ... ATOM 586 O ARG A 75 23.159 22.993 8.421 1.00 20.00 O

And the same applies to residue 150. These were may-be terminal oxygens? OXT?

Further our pdb-tools also have a handy script to check the proper formatting of PDB files:

pdb_format.py my-pdb-file

Hello again
I have done all the changes (selchain,reres,deloc), but I have still errors

There was an inconsistency in your data

Error message

First pdb file contains multiple forms of the same residue. This is not supported in the current form. If you would like to supply multiple conformations, please create an ensemble
ATOM 122 CA AGLN A 18 35.630 58.694 29.098 0.50 29.12

When I chek the format of the pdb, I get that “the line are too short” (78 instead of 80) for all the residues Do you know what is the problem with the pdb?
thanks a lot

Strange - the PDB you sent me worked fine for me (short test) after I removed the oxygens…

As for double occupancies, you can remove those with our pdb_delocc.py script (was in the example I gave earlier in this thread)

Hi,
i want to use expert interface of Haddock. How can i get the authorisation for that?

By contacting the support email for haddock, which you already did. You access as been upgraded.

Got an other error
" There was an error in rigid body stage of the docking.

For more information, check the following CNS output files for error messages:
FAILED
complex_run1_it0_refine_1.out
If you are unsure how to correct the error, visit the HADDOCK website, check out the HADDOCK discuss group, or send a mail to haddock.support@gmail.com

The output of HADDOCK is here.
The file containing your docking parameters is here."

How to resolve this now??

In order to help you will have to provide all the details of your input parameters and possibly a link to the failed run (eventually outside this forum). Without information we simple can’t help you…

Most likely cause: something is wrong with your input restraints / definition of active passive residues for HADDOCK

Dear Concern,

After all these errors, i got my results… But now the problem is my peptide is docked somewhere in between my dimer and make it like monomer. here is my result file " http://milou.science.uu.nl/serviceresults/HADDOCK2.2/9266963745/dimer/".
i don’t expect this result…Do you have any idea what where i am making mistake now… Please have a look in result file and let me know…
Pleaseeee

Looking at your data, the active residues you give for your dimer to not form a contiguous surface on the protein and to satisfy them the complex is distorted… The question is: how confident are you in your data?

Please refer to the protein-ligand topic for dealing with protein-ligand docking

http://ask.bioexcel.eu/t/protein-ligand-docking/58

1 Like

Dear all, I have an issue with dimers because I work with antibody.
I usualy renumber the chains before Haddock and it works fine but now I have one chain that has A, B and C right after the number (ie 82A, 101A, 101B…) when I use pdb_reres the A,B and C remain in the the new numbering scheme. Is there some suggestion to eliminate A, B, C?

“Your PDB contains multiple residues with number 52 in chain H or duplicated atom names.
ATOM 2052 N PRO H 52 10.192 -20.531 58.620 1.00 25.00 (Offending Line) <–
ATOM 32 N ARG 3 11.281 86.699 94.383 0.50 35.88 N (Example Valid Line)”

Our pdb-tools should be able to do the trick. Use for that pdb_delinsertion

Also available now as a web server at https://bianca.science.uu.nl/pdbtools/submit

Note that this will shift the numbering as those A,B,C insertions will now become normally numbered

Check also our antibody - antigen docking protocol preprint http://arxiv.org/abs/2005.03283