Generating ITP file for use with create_goVirt.py

[yummy-hat]

Hello,

For proteins that don't start numbering at 1, the .itp file generated by -govs-moltype doesn't match the files generated by create_goVirt.py. For example, I have residues 2-718, but they are labeled a2ar_1 through a2ar_717 in the martinize2-generated a2ar.itp. After running create_goVirt.py with --misres 1, I get the grompp error "Atomtype a2ar_1 not found"

Can there be an option to renumber the virtual beads generated by martinize2? At least in my case, something like "-resid input" would be perfect if it applied to a2ar.itp.

[pckroon]

Hi,

is this a duplicate of #519? I'm not sure the fix of that got released yet, otherwise you could give the master branch a try (at your own peril ;) ).
Which version of martinize/vermouth are you using?

[yummy-hat]

Duplicate of #518, sorry! Doesn't seem to be fixed in version 0.9.3.dev3. I get the same issue with the master branch.

For me, I need the bead types to be named based on _old_resid, since that's what create_goVirt.py expects. I just changed

vermouth-martinize/vermouth/processors/go_vs_includes.py

Line 132 in 1fba29e

'atype': '{}_{}'.format(prefix, atom['resid']),

to 'atype': '{}_{}'.format(prefix, atom['_old_resid']),

Hopefully I'm not misunderstanding something. The files seem correct.

Side note that create_goVirt.py parses grep output to find contacts from the rCSU server .map file, but this fails on my system. Without the --text flag to grep, the output is just "binary file matches." Not sure why bash treats it as a binary file. Happens on bash version 4.4.20 but not 4.2.46.

[fgrunewald]

@yummy-hat did you set the '-resid input' flag? If not please provide your pdb and full command so we can trace it back.

[fgrunewald]

@yummy-hat did you set the '-resid input' flag? If not please provide your pdb and full command so we can trace it back.

please ignore this. we don't need it anymore. @pckroon this should be an easy fix but breaks the Go model for multi-chain proteins (for which it shouldn't be used anyways).

[pckroon]

Duplicate of #518, sorry!

@yummy-hat No worries :) I prefer the occasional duplicate over hidden issues that make martinize unusable.

@fgrunewald I'll reiterate my opinion on investing time in the Go model: I see 3 options. a) implement Go properly; b) Quick-fix as you suggest; c) remove everything Go related until someone implements option a.