Roadmap and ideas for Molly.jl development

[jgreener64]

This issue is a roadmap for Molly.jl development. Feel free to discuss things here or submit a PR. Bear in mind that significant refactoring will probably occur as the package develops.

Low hanging fruit

Want to get involved? These issues might be the place to start:

• Speedups to the code. Both on the level of individual functions and the overall algorithm. [Getting there]
• Look over the code to find mistakes in implementation. There will be some because...
• Test coverage is minimal. We need tests for the 'core' functions that are unlikely to change their return values, e.g. the force functions. [Done]

Bigger things to tackle

• Energy minimisation by gradient descent [Done].
• Add other forcefields. [Partly done]
• Add other thermostats/ensembles. [Partly done]
• Get it working on the GPU. [Done]
• Line by line checking of how a mature MD package works to see where we have missed things and to get an idea of how to organise the codebase in future. [Partly done]
• Neighbour list in a cubic lattice, and use of group lists. [Partly done]
• Setup of MD simulations, e.g. adding hydrogen, solvent. [Partly done]
• Trajectory/topology file format readers and writers. The current topology reader is not very robust. [Partly done]

Projects that will require more planning or will cause significant changes

• Abstracting the forcefield from the integration to allow different forcefields and integrators to be combined. [Done]
• Allow definition of custom forcefields. [Done]
• Parallelisation. [Done]

Okay, so this is less of a roadmap and more of a list of ideas to work on. But most or all of the above would be required to make this a package suitable for general use, so in a sense this is the roadmap.

[Zarasthustra]

To do: Add module for calculating Free Energy via Alchemical change ;)

[jgreener64]

"Abstracting the forcefield from the integration to allow different forcefields and integrators to be combined" and "Allow definition of custom forcefields" are now done.

[jarvist]

It may be interesting to see whether you can either directly use https://github.com/libAtoms/JuLIP.jl as a library (also https://github.com/libAtoms/NeighbourLists.jl), or at least be inspired by some of the code therein.

[jgreener64]

Thanks Jarvist, I have had a brief look at the code there but will dive a bit deeper.

[Zarasthustra]

Awhile ago I wrote some Julia code for EWALDS. It is verified for energy calculations against a NIST database. https://www.nist.gov/mml/csd/chemical-informatics-research-group/spce-water-reference-calculations-10%C3%A5-cutoff [https://www.nist.gov/sites/default/files/styles/480_x_480_limit/public/images/mml/csd/informatics_research/spce_schematic_3.jpg?itok=OTb11Rb_]<https://www.nist.gov/mml/csd/chemical-informatics-research-group/spce-water-reference-calculations-10%C3%A5-cutoff> SPC/E Water Reference Calculations - 10Å cutoff | NIST<https://www.nist.gov/mml/csd/chemical-informatics-research-group/spce-water-reference-calculations-10%C3%A5-cutoff> In this section, we provide sample configurations of SPC/E Water molecules[1] and report the various energy and force calculations for those configurations, where the coulombic contributions are computed using the traditional Ewald Summation Method[2]. These sample configurations and reference ... www.nist.gov Would you be interested in it? I have not taken its derivative yet to calculate force. It has been on my list of things to do, but I just don't seem to have time :S I have also added Rattle to my code for bond constraints... it is fairly straight forward too. Once your code has EWALD and Rattle, it will be a "full" code in my opinion. You would probably want to upgrade it to particle mesh ewald for MD, but that is purely performance. Braden

…

________________________________ From: Joe Greener <notifications@github.com> Sent: Wednesday, August 14, 2019 9:00 AM To: jgreener64/Molly.jl <Molly.jl@noreply.github.com> Cc: Braden Kelly <bkelly08@uoguelph.ca>; Comment <comment@noreply.github.com> Subject: Re: [jgreener64/Molly.jl] Roadmap and ideas for Molly.jl development (#2) Thanks Jarvist, I have had a brief look at the code there but will dive a bit deeper. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#2>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AECO7UOWNMZMPDMOU6A5VMDQEP6XBANCNFSM4GADVQTQ>.

[jgreener64]

Would you be interested in it?

Yes, definitely. If you could open a PR when you get a chance that would be great. I understand how it's hard to find time though, I only seem to get a few hours a month on this package these days.

[jgreener64]

There is a Julia interface to Chemfiles - building Molly on top of those types would allow easy reading and writing.

[hypnopump]

what are your thoughts on GPU acceleration or at least multi-core in CPU? In python it's really easy with joblib, cupy, jax... Don't know about the julia set of tools for that but might be worth an exploration

[jgreener64]

GPU acceleration is feasible using CuArrays.jl - it would probably involve refactoring into a style that uses broadcasting rather than for loops, but that's no bad thing anyway.

Multi-core CPU support has improved greatly in the recent Julia v1.3 release so this is another avenue to explore, though I personally don't have much experience there.

Another point to add here is the ability to differentiate through molecular simulations using Zygote.jl, which is an exciting use case and something that Julia is well-suited for.

[cortner]

I was unfortunately unaware of this package until now. (Or maybe I saw it and have forgotten...) Anyhow, I wonder whether there is any chance to combine Molly and JuLIP, or at least make them compatible.

With JuLIP I deliberately stayed quite close to ASE, to make sure that I can have a relatively thin interface. But this has led to some design decision that I‘ve since regretted. So in principle at least I‘m quite open to restructuring JuLIP to make it work with Molly.

Another possibility would be to make JuLIP really library for potentials, but let Molly focus on managing configurations, MD, geometry optimisation, etc ...

But maybe it is easiest to leave them separate and not worry too much about this. I‘m curious though what people think.

[cortner]

Regarding the neighbourlist - this is surely something that we can share. I believe my list is fairly fast, it is based on matscipy. The main downside for Molly is that it uses the same cutoff for all atoms. It would need to be generalised so that different atoms can have a different cutoff.

I‘ve also started playing around with implementing various iterators over the neighbourlist to have a more functional style in implementing potentials. I‘m less sure how well that worked.

[jgreener64]

Thanks for commenting @cortner. Once I get some time for this package, diving into JuLIP is definitely on the list of priorities to see what can be combined. Certainly with things you have optimised, like the neighbour list, there is room for Molly to use or build on that.

[cortner]

or extract shared functionality so that JuLIP and Molly become effectively frontends...