Add #ifdef GO_VIRT definitions into main force field file

[csbrasnett]

Currently we have a complicated route to including the particle and nonbonded definitions into martini_v3.0.0.itp when the go model is used. Given these are flexibly included, and the go model is now integrated into martinize, I don't think there's any particular reason that we shouldn't just write these inclusions in directly for all users?

[csbrasnett]

@ricalessandri @danielpastor97 any thoughts on this?

[ricalessandri]

Personally, I don't see any cons to including them (if this makes other things easier). I think for a while during the development of M3 the martini_v3.0.0.itp file did contain those #ifdef GO lines and as I recall they aren't many - meaning that this won't increase the file size. Don't see any other cons. Few people open this file anyway.

But perhaps @fgrunewald and @paulocts have more thoughts/opinions?

[fgrunewald]

After thinking on this for a while, I'm against including them in the martini_v3.0.0.itp. The issue is that one would have to copy this file every time to a new folder when using a Go model. Sure it works for a tutorial setup showing how easy it is, but if you do more than one protein it quickly adds and the itp file is rather large already.

@csbrasnett @pckroon Coming to think of it, I'd suggest we make martinize2 write a usuable topology file. The only thing one would have to do is define where the martini setup lives on the computer. One way would be pip install martini, so having the files installable and expose paths and so on. The other option would be having the user provide an eviroment variable or CLI argument.

[csbrasnett]

If we make martinize2 make a usable file like you say, won't that break once someone uses >1 Go model like you say anyway? Unless we add a bunch of flags to additively write to existing .tops?

[fgrunewald]

you mean for the case that there is more than one Go model protein? How does that even work at the moment? Isn't there some overlap between the VS definitions?

[csbrasnett]

Yeah that’s what I was thinking/wondering, I realised I don’t actually have any idea. There must be conflicting definitions in the atom types that tbh I have no idea how people get around atm

On Fri, 25 Oct 2024 at 09:59, Dr. Fabian Grunewald @.***> wrote:

you mean for the case that there is more than one Go model protein? How does that even work at the moment? Isn't there some overlap between the VS definitions?

— Reply to this email directly, view it on GitHub https://github.com/Martini-Force-Field-Initiative/Martini-Force-Field-Initiative.github.io/issues/41#issuecomment-2437142658, or unsubscribe https://github.com/notifications/unsubscribe-auth/AILSZXTP2FLLLEH5B7LJIPLZ5H27FAVCNFSM6AAAAABQGA3PQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZXGE2DENRVHA . You are receiving this because you were mentioned.Message ID: <Martini-Force-Field-Initiative/Martini-Force-Field-Initiative.github. @.***>

[pckroon]

I'm all in favour of having martinize2 generate fully ~operational battle stations~ functional topologies. Maybe we should take martini_v3.0.0.itp as a template, add in the interactions/particles needed inline (rather than #include), and dump that system specific itp next to the topol.top? That would fix the multiple protein part (since we can just generate system unique particle names (molname+'govs'+idx, uuid, ...).

As for where to get martini_v3.0.0.itp, it could be an option to add it to the vermouth-martinize data files. Way back when I suggested to create a repo for the force field files, but this got shot down as being to complicated, maybe times changed?

[csbrasnett]

There's the martini-forcefields repo that does this now, but I don't know how many people actually use it as a reference over the website etc.

I like the idea of doing the filtering in martinize (as opposed to grompp I guess?) but I think that'll get tricky the moment people start combining systems/adding different molecules etc?

To me there's some kind of streamlined process where you can: 1) specify an existing topology file (although -p is already taken...) read that in to some object, 2) work out if you have extra particle definitions arising from other proteins with Go models,
3) do the usual martinize stuff on the protein that you want to martinize at this stage 4) write out the new topology file to adapt the system, along with the new extra particle definitions.

I think in terms of actionable things before that can happen, the first thing we could do would be let the user define the molname on input? atm, everything is molecule{0..n}, and the virtual sites we get from go bonds are molecule{0..n}_{0..m}. This means someone has a system with multiple Go models, the atomtypes get redefined (but with the same name) for each molecule, which I think will cause problems. If we sort this we should also fix https://github.com/marrink-lab/vermouth-martinize/issues/585 at the same time

Also, I'm not sure how the topologies are written for go files at the minute are correct? at least when I was doing something the other day, the fact that I had #define go_virt etc in martini_v3.0.0.itp and #include go_nbparams.itp etc in my .top file seemed to cause some conflicts. I'll check this next week to confirm it wasn't just me doing something stupid

[csbrasnett]

made a PR on this subject here, any opinions welcome :smile_cat: