mBuild 2.0 Release Discussion

[chrisjonesBSU]

This a thread where users/developers can post overall goals/features they would like to be supported in a second stable version of mBuild.

Here are some ideas to get the discussion started:

• Faster and more feature rich energy minimization steps
• Improved bulk polymer system configuration (e.g. random walks)
• Improved polymer builder features (double bonds, cross-linking, etc...)
• Improve ease of use for biomolecular systems (e.g. proteins)
• Improve coarse grain and back mapping transformations
• Support non-atomistic systems (for example, ellipsoidal polymers, patchy particles)
• Use the unyt library in mBuild
• Expand recipes section with more commonly used molecules and polymers
• Improve performance for large systems, build out some bench marking workflows
• Visualization widgets for use in Jupyter Notebooks
• Implementation with VMD 2.0
• Add HOOMD to energy minimize

Please add any thoughts or ideas (even if they seem far-fetched) about what kinds of features you would like to see in mBuild 2.0.

Also see:

• Foyer 2.0 Release Discussion

[chrisjonesBSU]

An idea I've had, and one we discussed on the dev call. Have something analogous to packing.py but for creating molecular configurations (whereas packing.py creates bulk/system level configurations). Maybe we call this configuration.py or conformation.py.

An obvious example would be a simple hard-sphere self-avoiding random walk that creates chain configurations that we then use to update the configuration of a polymer built in the polymer builder. I started working on this a bit already. Maybe we can start a separate issue for this idea specifically.

[chrisjonesBSU]

Another idea that came up on the dev call is adding Hoomd-Blue as a backend option to energy_minimize as well as having more energy minimization methods that involve more than relaxing bonds, angles, and dihedrals. For example, shrinking to a target bulk density, remove overlapping particles, etc..

[CalCraven]

I think this post has some useful suggestions for creating a branch structure for working on mBuild 2.0
https://nvie.com/posts/a-successful-git-branching-model/

In this vein of thinking, we could just simply add a develop branch in which we add features for mBuild 2.0. All other hotfixes/bugfixes we add main.

Now, looking at hoomd, they use a trunk-major, trunk-minor, trunk-patch flow where each PR is based on when that feature would be introduced. I like this, but would require more oversight of exactly where each feature needs to be slotted in when the PR is opened.

What do you all think?

[chrisjonesBSU]

Yeah, a main and develop approach seems simpler and more manageable. I remember we did this before (maybe it was just on GMSO) and decided to stop because it was causing some issues. They were diverging too much when they probably shouldn't have? This was at a point when GMSO was still under pretty heavy development and ongoing changes, so maybe that was the issue. Either way, even with just 2 branches we'll have to stay on top of choosing the right one.

[CalCraven]

@ptc2ug suggests that for optimization, we should consider Julia or some Python compiler code that we could leverage for some of the more heavy duty methods we're considering in version 2.0.

[CalCraven]

@andresorderica has also suggested some polymer crosslinking routines he has been developing could be generalized to mBuild 2.0.

[daico007]

Some integration with VMD could be nice (maybe as a plugin for setting up systems). Plus, with VMD 2.0 coming out and making progress on Python kernel support, so would be a good opportunity for this.

[chrisjonesBSU]

I like that idea @daico007. I was also thinking that some mbuild specific jupyter notebook widgets that align with visualization would be really useful, especially since jupyter notebooks are sort of the "GUI" for mBuild before moving scripts/molecule files to a production workflow. For example, a widget that lets you filter by name when visualizing, maybe a widget that lets you toggle particle indices on/off when visualizing a molecule...I'm sure we could come up with lots of ideas.

[CalCraven]

We could also add some brief simple calculation methods more tightly coupled to like Freud as well for validating configurations.