Feature #2594

Multi-level GMX API

Added by Prashanth Kanduri over 2 years ago. Updated about 2 years ago.

core library
Target version:


Make two aspects of the GMX API. The idea is to make the features of GROMACS accessible outside of the app, while simplifying development of new library features. This is in line with issue #2574.

User-Facing Code (app-agnostic)

This should be usable outside of GROMACS in custom MD codes as a non-bonded force calculator. In the same spirit as Scalapack routines can be called for basic matrix operations. Example:

// Input Data Feed
Particles particles(x, m, q, v);
Topology topology(bondTables, localTop);
Simulation simulaton(parameters, flags, box);
System system(particles, topology, simulation);
NBICalculator nbcalc(system, "gromacs");
for (i = 1:nSteps)
    forces = nbcalc.calculateForces();
    // Integration
    system.update(/* new particle coordinates */);

The interface only consists of data and objects relevant to the simulation from the user. User would basically read input and topology files and setup the simulation without being concerned about the underlying library.

The NBCalculator API would be external aiming to encapsulate GROMACS's implementation details from the end user. It caters to those who need a non-bonded force calculator much the same way as one might need a linear-system solver.

Developer-Facing Abstraction (gmx-specific)

This part would setup the GROMACS-specific data structures, domain decomposition, communicator, load balancing, etc concerning the force-calculations to initialize an IForceSchedule object which would then be called by the high level API.

class NBICalculator
    ScheduleBuilder scheduleBuilder_; // build & init schedules
    std::shared_ptr<IForceSchedule> schedule_; // compute forces/energy/potential
    MDBookKeeping mdBook; // maintain flags on DD, NS, etc

    NBICalculator(/* args */)
        /* init ScheduleBuilder 
        create GROMACS objects like DD, commrec,
        using the system data

        scheduleBuilder_.initSchedule(/* gmx-specific args */);
        schedule_ = scheduleBuilder.getSchedule();
        mdBook.init(schedule_, system)

    forceVector calculateForces()
        return schedule_->computeStep(mdBook.flags);

    void update()
     // updates if NS is needed, sets flags which quantities need to be computed

The schedule API underneath would have it's own high performance implementation that overlaps computation, communication and reduction tasks. There would be customized schedules for architecture. algorithms and physics being simulated. This would be a part of GROMACS itself and need not be exposed outside as its implementation details are not so important.

Feature Level Modularisation (iForceSchedule Abstraction)

Refer to #2574 for enabling customised schedules that can be used to overlap computation, communication and reduction tasks during an MD simulation. Concrete schedules would implemented specific to methods, architecture and physics.


#1 Updated by Prashanth Kanduri over 2 years ago

Also related to #2595.

Goals overlapping with #2585.

Development continues based on this patch:

#2 Updated by Gerrit Code Review Bot about 2 years ago

Gerrit received a related patchset '1' for Issue #2594.
Uploader: Mark Abraham ()
Change-Id: gromacs~master~Ic05633af3a723436fb95bed530f787698f6a4bb7
Gerrit URL:

Also available in: Atom PDF