Project

General

Profile

Feature #2594

Multi-level GMX API

Added by Prashanth Kanduri 4 months ago. Updated 4 months ago.

Status:
New
Priority:
Normal
Category:
core library
Target version:
Difficulty:
hard
Close

Description

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 */);
    nbcalc.update();
}

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
{
private:
    ScheduleBuilder scheduleBuilder_; // build & init schedules
    std::shared_ptr<IForceSchedule> schedule_; // compute forces/energy/potential
    MDBookKeeping mdBook; // maintain flags on DD, NS, etc

public:
    NBICalculator(/* args */)
    {
        /* init ScheduleBuilder 
        --------------------------*/
        /*
        create GROMACS objects like DD, commrec,
        using the system data
        */
        ...

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

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

    void update()
    {
        mdBook.sync(system); 
     // 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.

History

#1 Updated by Prashanth Kanduri 4 months ago

Also related to #2595.

Goals overlapping with #2585.

Development continues based on this patch:
https://gerrit.gromacs.org/#/c/8088/

Also available in: Atom PDF