GoModel VS beads built on pre-existing VS beads can cause MD engine issues.

[Lp0lp]

Virtual site beads built based on the position of pre-existing virtual sites can be the source of issues in multiple MD engines.

This can happen when introducing the GoModel VS beads on top of a bead which itself is already a VS.

Does not impact the current Martini protein models, but can impact other models currently in development.

My suggestion would be for add_virtual_sites in the VirtualSiteCreator to check whether its corresponding backbone bead is itself a Virtual site and if so, it would inherit its construction Interaction. Inheriting the backbone beads VS construction would place the bead exactly in the same place but its construction would not depend on an already existing VS. If the backbone is not itself a VS, the standard type 1 VS would be put in place as is already the case. I guess this should be possible, as at this point in the workflow the Links have already been processed, right?

See:

vermouth-martinize/vermouth/rcsu/go_vs_includes.py

Line 70 in a3037bc

def add_virtual_sites(self, molecule, prefix, backbone, atomname, charge=0):

What do you guys think? Do you have any other ideas on how to get around this? I might have some time to propose some code for this.

Cheers

[pckroon]

Virtual site beads built based on the position of pre-existing virtual sites can be the source of issues in multiple MD engines.

What's the issue exactly? Is it VS using other VS for their construction, or really just the 1:1 VS on top of another VS?

If it's the second I propose actually adding a separate processor at the end of the pipeline to deal with these cases (and enumerating all VSes to find them is fine). Downside it means you'd probably need to rewrite a lot of interactions.
Can VSes carry non-bonded interactions (i.e. LJ, charge)? If so, how do you combine those? And if so, I think this is a bug in the respective MD engine.