Open csbrasnett opened 4 months ago
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...
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
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:
cons:
#include "en_bonds.itp"
in their[ bonds ]
directive in their molecule's itp file