SMILES to PolymerizeIt! ready files

[tramp037]

Description

This pull request provides functionality for using SMILES and the MuPT representation to generate PolymerizeIt! ready files to perform reactions and generate polymer configurations.

Todos

Notable points that this PR has either accomplished or will accomplish.

• Generate PolymerizeIt! ready directory and input files from provided .gro and .top files for monomers and dimer
• Identify dimer of two monomers and a given reaction template through SMILES/SMARTS strings using RDKit
• Identify reacting atoms of the monomers and corresponding atoms in the dimer using SMARTS string matching in RDKit
• Match dimer atoms with the corresponding monomer using the MuPT representation topology
• Perform automatic atom typing and generate .gro and .itp files for the molecules with openff and coordinates from the MuPT representation
• Full workflow for generating PolymerizeIt! ready directory and input files from SMILES/SMARTS strings for monomers and reaction template
• Complete 10 iterations of PolymerizeIt! with polyamide and ensure reactions occur properly
• Complete 10 iterations of PolymerizeIt! with epoxy and ensure reactions occur properly
• Move examples in tests folder to mupt-examples
• Decrease the dependency on shell scripts

Questions

Status

• Implement all TODOs
• Verify tests have passed
• Ready to go

[sbkashif]

Thanks @tramp037 for getting started with integrating PolymerizeIt into MuPT. We can first work internally on incorporating the feedback provided in yesterday's meeting and address the failing tests before making it ready for review.

Failing tests

The first test fails with the following error:

ERROR: file or directory not found: ellipsoidal_chain_placement.ipynb
collecting ... collected 0 items

I am unclear on why this particular notebook is a part of the CI workflow. However, it looks like it has something to do with polymer generation from SMILES (MuPT-hub/mupt-examples#20). It may have some necessary checks related to the following MuPT functions that we are importing in https://github.com/tramp037/mupt/blob/polymerizeit/mupt/reactions/polymerizeit/react_pi.py:

from mupt.interfaces.rdkit import primitive_from_rdkit, primitive_to_rdkit
from mupt.interfaces.smiles import primitive_from_smiles
from mupt.geometry.shapes import PointCloud

If so, it would be worthwhile to look at it, but I am not sure where to access it from. It is not available in the main branch, and the branch it was merged from (builder-improvements) has also been deleted.

Maybe @timbernat can guide us further on this. Do we really need to pass this test to integrate our functionality into MuPT?

MuPT integration

We are probably looking at something like make_pi to be the front-facing module for running PolymerizeIt via MuPT.

In that case, would it make sense to provide the variable values via a config file? That may help users better track multiple runs with minor tweaks in variables, though it would be fine to keep both options open.

In any case, we need to think about what the minimum possible inputs would be to run a MuPT workflow. We can probably have only "science-related" variables declared here (like monomer SMILES strings and processing conditions like T, P, density, etc.). Then, variables required by the PolymerizeIt! config file (currently called the inputs file)—like reaction criteria, cross-linking criteria, charge update criteria, etc.—could be passed to a separate config file internally. We will have a default flowchart like you have currently, but the MuPT module help string should contain enough details to point users to the PolymerizeIt config file variables if they need to tweak the protocol flowchart.

[timbernat]

The first test fails with the following error:

That's my bad, I renamed an example as part of examples #20 you mentioned but forgot to update the notebook runner call. I just updated that now and verified CI on main passes; give the CI another run on the fork and see if that allows the tests to complete.

Do we really need to pass this test to integrate our functionality into MuPT?

The test does need to pass yes, but it's not your responsibility to get it working here; I broke it, and I'll fix it

I am unclear on why this particular notebook is a part of the CI workflow

Because we also want to ensure that code updates don't break examples, or that examples don't break as dependencies update. These are called after the main code tests are run (here, if you're curious). We may consider having the notebook tests be a separate CI run, though that of course means each CI run has to individually install a mupt-capable environment, which comes with extra overhead. There are tradeoffs for either approach

In that case, would it make sense to provide the variable values via a config file?
variables required by the PolymerizeIt! config file (currently called the inputs file)...could be passed to a separate config file internally

That would make the most sense, and is what I'm starting to move towards in #20 mentioned earlier. We want be as explicit as we can and hard-code as little as possible at this phase, even if it means the code is a little more verbose/requires more setup. Eventually I'll be stripping out and generalizing the reaction mapping components, and the PI/REACTER subpackages will mostly handle the specifics of generating valid inputs given a config (separate logic from parameters)

[codecov]

Codecov Report

❌ Patch coverage is 0% with 625 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
mupt/reactions/polymerizeit/write_pi.py	0.00%	285 Missing ⚠️
mupt/reactions/polymerizeit/react_pi.py	0.00%	247 Missing ⚠️
mupt/reactions/polymerizeit/gmx_simple.py	0.00%	71 Missing ⚠️
mupt/reactions/polymerizeit/make_pi.py	0.00%	20 Missing ⚠️
mupt/reactions/polymerizeit/__init__.py	0.00%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!