Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

External EN bonds itp #596

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

csbrasnett
Copy link
Collaborator

Add a flag, -ew, to write out bonds for elastic networks to an external en_bonds.itp file, in the style of Go or Olive bonds.

This has been motivated by some work on visualising cg molecules at martini_vis for now. If the bonds are written out externally, then they can be used (after some editing elsewhere) to visualise the elastic network separately to the bonds inherent in the molecule. Maybe this is useful, maybe it isn't, it's a feature at least!

pros:

  • might be able to visualise elastic networks better

cons:

  • relies on users actually writing #include "en_bonds.itp" in their [ bonds ] directive in their molecule's itp file

- added extra argument in martinize2
- added conditionals for workflow in apply_rubber_band.py
- added write out for bonds in gmx/topology.py
- added new argument to calls of ApplyRubberBand in test_apply_rubber_band.py
- changed handling of _rubber_bands in apply_rubber_band.py
Copy link
Member

@pckroon pckroon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the feature.
As for the implementation, I have the following suggestion: Don't have the RubberBands processor return the bonds, instead just add them to the molecule. The ITP writer can then select which interactions to write where based on some sort of selector. This would also allow it to write the appropriate #include statement. This will at some point also allow you to easily write other bonds or I don't know, dihedrals to external files. It'll also make the BondParam namedtuple superfluous.

bin/martinize2 Outdated Show resolved Hide resolved
Comment on lines 357 to 370
if eb_write:
rubber_band = BondParam(atoms = (from_key, to_key),
btype=bond_type,
length=length,
fc=force_constant,
meta={'group': 'Rubber band'})
ebs.append(rubber_band)
else:
molecule.add_interaction(
type_='bonds',
atoms=(from_key, to_key),
parameters=[bond_type, length, force_constant],
meta={'group': 'Rubber band'},
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fewer if statements is better, so I suggest always gathering the rubber band interactions into a list, and at the end decide whether or not you add the interactions to the molecule or not

Copy link
Collaborator Author

@csbrasnett csbrasnett May 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, thanks! Do you want them in a list from here, or to add directly to the molecule with appropriate meta to identify later? Probably don't have time to implement this week but I can have a think about how to edit what

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just add them to the molecule directly, and find them again later based on the meta attributes.

csbrasnett and others added 3 commits May 23, 2024 08:43
if -ew specified, change the interaction type of the added EN bonds so that they are processed once martinize2 gets to the itp writing.
- change conditionals in apply_rubber_band.py so that interaction type is changed depending on how network is to be written
- move writing functionality from topology.py to itp.py
- itp.py ids interaction type for elastic network to be written externally and writes as appropriate.
@csbrasnett
Copy link
Collaborator Author

csbrasnett commented May 23, 2024

ok, I think this is closer to how you want this to be handled? But, I don't think either of us are happy with this solution, so I'll keep working at something cleaner

edit: ok, so this is failing the integration test because there's now an #include written halfway through a file that the parser can't handle...

@pckroon
Copy link
Member

pckroon commented May 23, 2024

Jup, definitely in the right direction. My original idea was to not add an extra interaction type ('el_bonds'), but rather, iterate over interactions and grouping them using some form of selection function. For example, all interactions that have meta={'group': 'Rubber bands'} go in one file, and all interactions that have a meta classifying them as scFix interactions to go somewhere else, all interactions involving an SC4 go to a third, and everything else stays in the main file. Or something like that. This probably involves some sort of itertools.groupby and some juggling with selector functions.

Also, the #include doesn't need to be in the [bonds] directive, does it? Just put them at the end of the file. That way you can also cram multiple types of interactions (bonds, angles) in the same external file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants