Clarification on Contact Map Differences in Martinize2

[ZhuDaoScience]

Dear Vermouth Developers,

I hope this message finds you well. I wanted to bring to your attention a potential discrepancy I noticed between the contact maps generated by Martinize2 and those from the web server (http://info.ifpan.edu.pl/~rcsu/rcsu/index.html).

For instance, in the case of ASP residues, the OD1 and OD2 atoms appear to be assigned to Type 2 in Martinize2, whereas according to the rules outlined in the relevant article (https://pubmed.ncbi.nlm.nih.gov/26723590/), they should be assigned to Type 10.

To ensure consistency between the two platforms, I kindly suggest a careful comparison of the contact maps generated by Martinize2 and the web server.

Thank you for your attention to this matter. Please let me know if you need any further details.

Best regards,
ZhuDaoScience

[csbrasnett]

Hi,

The implementation of the contact map in vermouth is based on the C code underlying the webserver stored at this repository, so any discrepancies in the data are a result of this. I can see from the article though that indeed the OD1/2 atoms should be of type 10 rather than type 2, so I'll fix this asap.

The development of the contact map in vermouth was done carefully to ensure consistency between the results of the calculation here and in the web server. Small discrepancies between the two may arise because the server makes certain assumptions about the format of the pdb file while vermouth doesn't, and so may provide a more precise answer. While there may be minor differences between the two contact maps, I don't expect this to propagate through to a resulting Gō model of a protein, because of the additional processing that occurs. That said, if you find improvements that can be made to the contact map code in either accuracy or speed, PR welcome!

Chris

[ZhuDaoScience]

Hi Chris,

I’ve identified additional discrepancies between the current code implementation and the web server regarding atom type assignments and parameters (inferred from the web server’s output map file). Below are the key corrections needed:

1. Radius Parameters

• Water radius: Should be 1.42 (currently 1.4).
• Enlargement factor: Should be 1.244455060259808 (derived from (26/7)^(1/6)).

2. Atom Type Corrections

The following atom types in PROTEIN_MAP need updating to match the web server:

Residue	Atom	Current	Correct
ARG	NH1	3	9
ARG	NH2	3	9
ASP	OD1	2	10
ASP	OD2	2	10
GLU	OE1	2	10
GLU	OE2	2	10
LYS	NZ	3	9

I believe these adjustments will ensure more consistency with the web server’s output.

For reference, my implementation is available here:
GitHub: OVrCSU

[csbrasnett]

Hi @ZhuDaoScience I've been looking at this again.

I was wondering if you might please share the details of the proteins you've compared in the readme.md of your implementation so I can have more of a look at what might be going on? If you can share the script that you've used to make the comparisons between the implementations that would also be helpful too.

FWIW, I've been testing the vermouth implementation on a quite large structure from alphafold (this one), and both with and without the changes you suggest, I'm not getting a contact map that's any different to the one from the server. Incidentally, I'm not sure if you've seen, but the correct link for the server is now this one: http://pomalab.ippt.pan.pl/GoContactMap/.

For reference, I've been testing the branch using martinize2 -f AF-F4J339-F1-model_v4.pdb -x cg.pdb -o topol.top -go -go-write-file, and testing the implementation you provide with python3 OVrCSU/OVrCSU.py -f AF-F4J339-F1-model_v4.pdb, and comparing them to a contact map obtained from the new server linked above.

Either way, I've started a branch containing the updated code here. I haven't changed the radius values as you suggest - I'm not sure where those numbers are derived from, they don't appear in the paper referenced as far as I can tell? At least, if I use them, then there is substantial deviation from the result obtained from the contact map.

[ZhuDaoScience]

Hi, @csbrasnett I have shared the reference protein structure and contact map in the provided link, along with scripts comparing atom and residue contacts from the server, the OVrCSU script, and Vermouth. The reference map was generated by the original OVrCSU server from the original Martini tutorial, but the server has been unavailable for at least a month. The map we’re using for comparison is from a year ago.

The PomaLab server uses the same script as the GoMartini ContactMapGenerator, which differs from the original OVrCSU implementation. This means the reference contact map isn’t identical to Vermouth’s output. Upon closer inspection, we found that Vermouth initially used a water radius of 2.8, which is actually the diameter, not the radius, leading to calculation errors. An off-by-one indexing issue (0 vs. 1) in the _make_surface function also contributed to discrepancies.

To resolve this, I derived the correct water radius (1.42) by back-calculating from the reference atom contact map. The reference also provided the correct atom types and interaction types, including the OXT atom’s type assignment (1). The enlargement factor (1.244455060259808) was taken from the original OV contact paper, calculated as (26/7)^(1/6), using the inflection point distance.

I’ve updated Vermouth’s contact_map.py script to align with these corrections. The new results show much better agreement with the reference map, as demonstrated in the comparison notebook CompareResidueContacts_Martinize2.ipynb.

[csbrasnett]

Thanks. So, I think there are 2 issues here as far as you're concerned (?):

1. The new server differs from the old server, and this is a problem for you because the old server has now been decommissioned. I don't know to what extent the back end of the server changed between the old one and new one. My understanding is none, but that may be wrong. Certainly, as far as the new published version of the Go model is concerned, the new server is the one to use to generate contact maps (and the current implementation of the code in vermouth is based on that)

2. There are some minor parameter errors in the current vermouth implementation. I agree that we've taken the diameter and called it the radius, but I think (could be wrong, have not investigated extensively) that this gets dealt with correctly in factors of 2 around the place. Regardless, the value of 1.40 is taken from the paper used as a reference for this. The difference between 1.24 and your value for the enlargement factor is a rounding error, so I don't expect it will have a significant impact on the accuracy of the rest of the code.

I can see from the notebooks you provided that none of the scripts quite align precisely with your test system - some have additional and missing contacts, others just missing, so I think there's still some way to go before we can completely agree on total alignment of implementations.

For 1), we need to ensure consistency across different user groups. I am reluctant to change anything substantially at the moment, as from my testing on a number of systems, the contacts identified from the server and from the current vermouth implementation are identical. However, to investigate the issue further, I will contact the server maintenance team to find out why the new and old servers may differ in their outputs. Once I have an answer on this, I think we can revisit 2) to understand better what might be going on.

Hope that sounds ok? Thanks again for raising this issue, I just want to ensure that we have consistency!

[ZhuDaoScience]

This sounds OK to me. However, I should clarify that the old server was previously maintained by K. Wolek and M. Cieplak although no longer available, while the new server is managed by the Poma lab. These are two distinct servers with different contact outputs.

The GoMartini2 paper and the original GoMartini3 tutorial relied on the old server for contact map generation, and many existing works depend on its output. For consistency, I believe it would be better to use the same contact map generator as before.