[gmx-developers] Parallelism in trajectory analysis tools

[Kutzner, Carsten]

Hi,

> On 20. Aug 2018, at 09:15, David van der Spoel <spoel at xray.bmc.uu.se> wrote:
> 
> Den 2018-08-20 kl. 08:25, skrev Mark Abraham:
>> Hi,
>> As Roland noted, there was some work done at ORNL. Teemu's original plan embraced the possibility of parallel analysis, but there's no implementation in master branch.
>> I don't have a clear picture of a use case that has enough need of compute that the per-frame workload would not be dominated by overheads from I/O and the analysis workflow runner. Peter Kasson suggested local pressure some time (IIRC). Perhaps there are some goodness-of-fit post-simulation analyses for SAXS/SANS/CryoEM that might motivate?
Currently there is the ‘full correlation analysis’ tool as a draft in gerrit
that would benefit from MPI parallelism https://gerrit.gromacs.org/#/c/7552/.

We have another in-house GROMACS tool that would benefit from (MPI-)parallel
execution of trajectory frames. In both these examples the reading of the data from disk
is not the bottleneck, but actually the processing.

> 
> Simple things like RDF and Hbond can be very time consuming. It would not be hard to fix a few of these to use OpenMP of course. Is that to be preferred?
I would assume that OpenMP should be a good way to incorporate all availble
cores on a node (if that is enough parallelism for the job). It does not hurt
in the code base as one can easily remove any OpeMP related pragmas later,
if another parallel mechanism is in place.

Carsten