Free energy/dual topologies/exclusions

GROMACS version:2021.4
GROMACS modification: No

I would like to calculate a relative binding free energy difference between two
ligands in a protein’s binding site, and I am struggling with the topology there.
The ligands are similar, but have a portion that changes. I want to set up a dual
topology approach. And here I have to make sure that the atoms in
the two parts of the ligand that are different in topology A (lambda=0) and B (lambda=1), do not interact, as they basically overlap. Now, do I have to define
the corresponding exclusions explicitely/manually, or is this perhaps done
automatically by the free energy implementation?

I understand that this question wouid not arise if I used a single topology
approach , but this would not work here because I’d have to turn constraints
into harmonic bonds, and vice versa.

On a related note: when googling for answers to this question I came across
a relatively recent discussion of the developers:

If one of the involved people happens to read this, please let me know whether
the issues discussed there might affect the type of calculation I describe here!

And another one - there is this paper:
Can anybody enlighten me - is this related to the discussion on github
linked above, or is this something entirely different?


Yes, the gitlab issue has this use case and several solution.

If all interactions between the two ligands are within the cut-off, the simplest solution is likely to put both ligands in a single moleculetype and use exclusions to exclude all atom pairs between the two ligands.

Thanks for the reply!
My ligand, when fully extended is about 18Angstrom long. If I understood
the issue correctly, this means I’d have to use a cut-off at least that large (18A).
BTW are we talking about rlist here, or rcoulomb, or both?

For perturbed atoms it’s rlist.

The other option is the different LJ parameter trick mentioned on gitlab.

I’ll just use a larger rlist for now then, if I leave rcoulomb and rvdw at,
say, 12Angstrom, and use a larger nstlist (~40) the performance penalty I pay
for that is probably small.
I am not sure i fully understood the other option, it certainly sounds like
something that would need to be automated, doing that by hand could be
quite error-prone.
thanks again!