Issue with numbering of Go Virtual sites

[Raul-araya-secchi]

While generating the CG files for a protein using the Gō-MARTINI I got into the following problem:

The AA pdb file starts at residue 22. So I used the -input option on martinize2 to keep the numbering. However, the resulting P.itp file has the numberings for the virtual sites starting at 1. When I run create_goVirt.py all the definitions taken from the rCSU server also start from 22.

So, how can I also force that the creation of the virtual sites starting from the same number as the AA.pdb?

[fgrunewald]

Hi @Raul-araya-secchi,

Response

Thanks for reporting the problem. It seems to be a bug. The only solution is to renumber the input pdb file appropriately to start at 1.

Technical Details

In the code fragment below _old_resid would have to be propagated in order for the top level script to correctly overwrite the resids when the output file is being written. https://github.com/marrink-lab/vermouth-martinize/blob/1fba29ead1d78faf0ff709799c420517d38cef96/vermouth/processors/go_vs_includes.py#L129-L138

To Do

• [ ] patch code
• [ ] check that it works with server and create_goVirt.py
• [ ] implement test

[pckroon]

https://github.com/marrink-lab/vermouth-martinize/blob/master/bin/martinize2#L760 This should be moved to above where the go vsite processor gets invoked. Or go part has to be moved down. And/or set 'resid input' whenever govs are requested.

[fgrunewald]

@pckroon that's not really needed as long as the old_resid get's propagated to the virtual sites done by the go processor

[pckroon]

Sure there are other solutions, but why not use the mechanisms we already have?

[fgrunewald]

that's basically what I was suggesting. Otherwise you end up with nodes that do not have the old_resid attribute ...

[fgrunewald]

@Romumrn is this issue something you could take care of as well? Paulo told me you had some time to get familiar with martinize /vermouth

[fgrunewald]

related problem; go-Virts are now sorted apparently, which they weren't before !?! this feels like it has the same origin

[fgrunewald]

the issue should be solved