Unambiguous restraints for server submission

I am trying to submit a HADDOCK 2.4 server run for docking with unambiguous restraints for a fatty acid modification , per feedback from this post Docking a protein with a fatty acid side chain

When I try to upload the restraints as a plain text ascii file I get the following error message but I am not sure how to resolve the error

HADDOCK restraints TBL file

Am I improperly formatting the file? (I have it saved as a text file with ascii encoding) or did define the restraints incorrectly?
I have the restraints defined as

assign (resid 26 and name SG and segid A) (resid 26 and name O03 and segid A) 4.6 0.1 0.1

assign (resid 26 and name SG and segid A) (resid 26 and name O02 and segid A) 3.1 0.1 0.1

assign (resid 26 and name N and segid A) (resid 26 and name C01 and segid A) 1.4 0.1 0.1

1 Like

I don’t see the error message the server is giving you…
Something must be missing.
The restraints look ok to me.

Is there any incompatibility with a flexible region adjacent to a set of unambiguous restraints?
The lipidated residue is at the end of a series of residues which I am setting as fully flexible, the error persists whether or not the acylated residue itself is also set as flexible.
I am able to successfully submit the run if I exclude just the restraints file, so I’m sure it’s the source of the problem.

Should not be the case.

Did you input the restraint file as unambiguous restraint? And not ambiguous, which would clash with defined active residues?

Can you share your run and restraint file?

Ah, that must be the cause
I input a set of active residues and then supplied the restraint file as unambiguous restraints, the ambiguous restraint option was greyed out.

This was the most recent run I attempted without the restraints supplied https://bianca.science.uu.nl/haddock2.4/run/7619074893/19264-NDM1_Triacyl_HETATM_LOLA
The forum will not let me upload the actual restraints file but it is an ascii text file with the following lines

assign (resid 26 and name SG and segid A) (resid 26 and name O03 and segid A) 4.6 0.1 0.1
assign (resid 26 and name SG and segid A) (resid 26 and name O02 and segid A) 3.1 0.1 0.1
assign (resid 26 and name N and segid A) (resid 26 and name C01 and segid A) 1.4 0.1 0.1

So I should supply a single file under the ambiguous restraints prompt that contains both the pairwise interactions between the two molecules and the restraints for the acyl-chains?

Your restraints should go into the unambiguous category. You do need expert access level for that. Do you have it?

Hi
I am running into a very similar problem with uploading unambiguous restraints files to the HADDOCK 2.4 server. I am getting what I presume is an error message (red box containing “HADDOCK restraints TBL file”) whenever I try to upload an unambiguous restraints file.
I even get this same error message when using the files from the HADDOCK crosslink tutorials:
https://www.bonvinlab.org/education/HADDOCK24/HADDOCK24-Xlinks/ (the pdb files PRE5 and PUP2, together with the crosslinking restraints given in the “solution” pasted into a text file). Any advice on what I might be doing wrong would be much appreciated.

OK - I solved this problem by putting the extension .tbl on the end of my restraints file.

Do you have expert or guru level access?
If not request it in your registration page.

But if you are getting similar errors on the 2.2 and 2.4 servers you must be doing something wrong

Detail all the steps you are doing

Thanks for the quick reply (and for developing HADDOCK, which is outstanding). I do have guru level access.
Yes I was indeed doing something wrong in saving the restraints file. Using notepad++ in Windows, I was saving as a “Normal text file (.txt)" in Notepad++ and this was not working. I changed this and saved as file type "All types (.*)” in Notepad++ and added a .tbl extension to the filename. The restraints file was then recognized when I uploaded it.

Thanks for the explanation Charles.

It seems we are quite strict with the extension in this case :slight_smile:

We will try to have a more explicit error message for this.