Custom molname

[csbrasnett]

add a flag to allow users to specify the molname prefix that gets written into files.

This probably solves the problem where you have multiple go models in your system as discussed here, and potentially #35 too.

[csbrasnett]

took longer sorting out the tests than I'd like, but I think this should work.

in short, add -name to allow users to specify the prefix name of the molecule to be more customisable rather than just 'molecule_{0..n}'.

The main other change is then that the -go-moltype argument is removed so that the atomnames are taken from the molname automatically. This will then allow users with multiple Go models of different proteins to have them in the same system, so that the additional [ atomtype ] and [ nonbond_params ] directives don't have overlapping definitions.

[csbrasnett]

Did we reach any consensus on what we wanted to do with this in the end?

[pckroon]

You're the closest to the actual users, what do you think they want/need?

[csbrasnett]

You're the closest to the actual users, what do you think they want/need?

perfect timing for a group meeting poll tomorrow!

[csbrasnett]

The consensus is that this is a good thing!

[pckroon]

"this" is a bit ambiguous ;)

[csbrasnett]

aha ok, the idea of a -name flag to 1) name your molecules as you want and 2) avoid multiple definitions from multiple Go models in your system would be appreciated by the user community

[pckroon]

I'm not sure I quite understand what you mean by 2), and how does this relate to the merge all that's currently in the pipeline?

[csbrasnett]

If you have 2 different proteins that you've made and validated go models for separately, then at the moment they'll both be called molecule_0, with associated go_atomtypes.itp that run molecule_0_1...molecule_0_n.

If you then build a system that contains both proteins, when it comes to preparing the system for simulation, your top file will at some point need to include both files, which means that you have 1) atom definitions multiply defined, and 2) some apparent nonbonded interactions that shouldn't be there/can't be defined, because there'll be a different number of BB virtual sites on the different proteins.

This PR tries to fix this, so that you give your own prefix for the protein that you're CGing, then for Go models, the virtual site atoms are at least called different things so they can be included multiple times over without error at preprocessing.

For any other protein, it just means that the [ moleculetype ] name is something vaguely more memorable than just molecule_0.

I realise this clashes with what you said earlier about CGing a whole atomistic system in one go, but I don't think that's how most people are using martinize

[pckroon]

Alright, sounds good.
Is this already implemented/ready for review?

[csbrasnett]

yep, should all be contained here!

[pckroon]

LGTM!