<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Dear all,
<div class=""><br class="">
</div>
<div class="">Following the discussion in today’s roundtable, here is the github repository of the integrator framework draft: <a href="https://github.com/ptmerz/gromacs" class="">https://github.com/ptmerz/gromacs</a> This is planned to be made more easily
accessible by uploading it to a sandbox branch on gerrit once these are ready (soon), but if your project would benefit from earlier access to these drafts, please feel free to look around. If you don’t have an immediate stake in this effort, you can probably
ignore this email. As this repo was not necessarily meant to be shared with more than a few close collaborators, the documentation is not everywhere yet at the level I would like to have it to submit these changes for general review on gerrit. I’ll therefore
try to outline the draft in the next few paragraphs, and link to some additional resources at then end of the email.</div>
<div class=""><br class="">
</div>
<div class="">The big picture of this effort is to rewrite the integrator loop of GROMACS using a modular approach and introducing Monte Carlo capability. The modularity aims at making the single instructions as independent as possible, allowing for a certain
level of recomposition and parallelism, helping the development of new algorithms and task-parallelism. The addition of MC will allow to explore hybrid MC/MD algorithms, which show promise to enhance sampling in condensed simulations, and other algorithms
such as an MC barostat.</div>
<div class=""><br class="">
</div>
<div class="">The draft on github is a fork of the main GROMACS repo, and has last been rebased 2 months ago. Rebasing it to the tip of current master should be reasonably easy. Most of the work was done in a single branch,
<a href="https://github.com/ptmerz/gromacs/tree/integrator" class="">https://github.com/ptmerz/gromacs/tree/integrator</a>. It encompasses the high-level changes necessary to move from the current integrator (do_md() function) to a more modular approach. This
is done by first creating a copy of do_md(), do_md_simple(), and rip out all functionality except for a basic leap-frog and velocity-verlet NVE loop (however, keeping things like trajectory & energy writing, and domain decomposition in place). The functionality
is then developed one by one into elements which are able to be called via a unified, argument-less run function. This requires these elements to bind some data via pointers - not a nice solution, but later changes explore how to reduce these dependencies.
After developing all needed functionality into these type of elements, the new framework can be put to work, reducing the setup of the integrator (more or less common for all integrator flavors) to about 250 lines, and the definition (i.e. the place where
the order of the operations is defined) to about 50 lines of code. This is reached at commit 0e34a97. Later commits then explore ways to improve the data management - defining clear owners for pieces of data, and defining interfaces for others to interact
with this data.</div>
<div class=""><br class="">
</div>
<div class="">Two approaches to the life-time of tasks are explored. In one case, present in commit 0e34a97 and onwards, elements register tasks, i.e. the function they want to run at each step, before the first step of the integrator, forming the integrator
loop as a rigid list of functions being called repeatedly. In the other case, a queue is created instead of a list - all tasks are pre-computed ahead of time, such that the integrator is not a loop anymore, but a (FIFO) queue of tasks. This queue is currently
filled at neighbor-searching steps, i.e. all tasks that need to be ran by any element before the next neighbor searching step are known ahead of time. Most of the development of the elements is identical for both approaches, such that the second approach is
simply formulated as a commit on top of the first approach (in a separate branch,
<a href="https://github.com/ptmerz/gromacs/tree/scheduler_v1" class="">https://github.com/ptmerz/gromacs/tree/scheduler_v1</a>). In both approaches, multi-stepping can easily be incorporated by nesting loops over elements - we could, for example, imagine to
call a non-bonded force element once before looping 4 times over a bonded-force element and some velocity and position propagating elements, which would result in a larger time-step for the non-bonded forces compared to the bonded forces.</div>
<div class=""><br class="">
</div>
<div class="">We are currently working on exploring ways to express the position and velocity propagators in a general, extensible, yet performant way - ideally, leap-frog, velocity-verlet, and any other integrator we’d be interested in (including temperature
and pressure coupling) would be expressed by a few elements such as a position and a velocity propagator. These changes are not yet on github, but let me know if you have an interest in discussing these changes.</div>
<div class=""><br class="">
</div>
<div class="">As said, regarding documentation, these changes might not yet all be documented enough to be self-explanatory. I have a wiki page which describes some of the ideas and all commits, <a href="https://github.com/ptmerz/gromacs/wiki/GROMACS---New-Integrator-Framework" class="">https://github.com/ptmerz/gromacs/wiki/GROMACS---New-Integrator-Framework</a>.
I find this a useful tool to keep an overview over the chain of dependent changes, and quickly jump to the relevant ones. Otherwise, I am happy to share my presentation from the last Göttingen developer workshop, where I have been talking about most concepts
used here: <a href="https://www.dropbox.com/s/yt95913dkzc72k1/Goettingen_2018-Integrator-Pascal_Merz.pdf?dl=0" class="">https://www.dropbox.com/s/yt95913dkzc72k1/Goettingen_2018-Integrator-Pascal_Merz.pdf?dl=0</a>. And I am more than happy to answer any questions,
on github or via email or by setting up a call.</div>
<div class=""><br class="">
</div>
<div class="">I am grateful for any feedback, and looking forward to share this on more standard GROMACS resources soon!</div>
<div class=""><br class="">
</div>
<div class="">Pascal</div>
<div class=""><br class="">
</div>
<div class="">PS: A word about testing, since I was asked today - as all changes until now were not intended to change how the integrator functions, but rather how its expressed, all changes have been tested by ensuring that on a few systems, the legacy do_md()
(which is unchanged for now), and the new approach have identical positions, velocities, forces and energies for a few steps. This test is introduced early in the chain of commits. </div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">
<div class="">Pascal Merz</div>
<div class="">Research Associate, Shirts Group</div>
<div class="">Dept. of Chemical and Biological Engineering</div>
<div class="">University of Colorado Boulder</div>
<div class=""><a href="mailto:pascal.merz@colorado.edu" class="">pascal.merz@colorado.edu</a></div>
<div class=""><br class="">
</div>
</div>
<br class="Apple-interchange-newline">
</div>
<br class="">
</div>
</body>
</html>