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

Remove soon-to-be-duplicate functionality from protocols.forcefield._topology_molecule_to_mol2 #152

Closed
j-wags opened this issue Dec 17, 2019 · 7 comments · Fixed by #184
Closed

Comments

@j-wags
Copy link
Member

j-wags commented Dec 17, 2019

@jthorton is working on integrating the functionality from https://github.com/openforcefield/propertyestimator/blob/master/propertyestimator/protocols/forcefield.py#L811-L931 back into the OpenFF Toolkit.

So, this is a bookmark to remember to remove this soon-to-be-duplicate code when possible, just so it doesn't start to diverge.

@SimonBoothroyd
Copy link
Contributor

SimonBoothroyd commented Dec 17, 2019

A PR from you or @jthorton when this is moved upstream would be welcomed!

@jchodera
Copy link
Member

Wait, why do we need mol2 files? I thought we had collectively decided not to use them, and to standardize on SDF instead.

@jchodera
Copy link
Member

@SimonBoothroyd : Note that you can feed SDF files to antechamber, which will then generate the horrible GAFF-specific mol2 files you can feed to LEaP:

antechamber -fi mdl -i input.sdf -fo mol2 -o output.gaff.mol2

@slochower
Copy link
Collaborator

If you want a mol2 without the GAFF atom types, just add -at sybyl.

@SimonBoothroyd
Copy link
Contributor

SimonBoothroyd commented Dec 18, 2019

Wait, why do we need mol2 files? I thought we had collectively decided not to use them, and to standardize on SDF instead.

I remember hearing rumblings of this but wasn't sure what was decided in the end - it would be fantastic if in future decisions like this could be captured in maybe a short blog post! If this is the case I'd be happy to make the switch at some point, although looking through the issue tracker it seems like SDF support may still be a pending feature?

(cc @j-wags)

@j-wags
Copy link
Member Author

j-wags commented Dec 18, 2019

Wait, why do we need mol2 files? I thought we had collectively decided not to use them, and to standardize on SDF instead.

The functionality for charged SDF reading/writing wasn't ready, and getting Parsley out on time was the first priority, so I made this function to get it done.

@jchodera
Copy link
Member

We're conflating different things here. @j-wags is referring to reading/writing charged SDF files for the Open Force Field Toolkit, and I was wondering if the mol2 files were used as input to antechamber for GAFF parameterization. I'm still not quite sure why you were using mol2 files.

In either case (OFF toolkit or antechamber/LEaP) you should not need mol2 files. I can help you get rid of them if I know why you were using them!

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 a pull request may close this issue.

4 participants