[gmx-developers] velocity gradient in do_update_md

[Mark Abraham]

----- Original Message -----
From: Gaurav Goel <gauravgoeluta at gmail.com>
Date: Monday, June 14, 2010 6:24
Subject: [gmx-developers] velocity gradient in do_update_md
To: Discussion list for GROMACS development <gmx-developers at gromacs.org>

> Hello.
> 
> I'm trying to implement a velocity gradient in my simulations. The
> algorithm I'll be using is:
> 1. Define a thin "hot" slab in the xy-plane at z=0 and a "cold' slab
> at z=L/2 (L is the length of simulation box)
> 2. After every 'f' time steps replace the velocity of the 
> fastest atom
> in the cold slab with the slowest atom in the hot slab.
> 
> To achieve this I'll be modifying the do_update_md() subroutine in
> src/mdlib/update.c. Below is the call to this subroutine from void
> update()
> 
> do_update_md(start, homenr, dt, ekind->tcstat, ekind->grpstat,......)
> 
> within do_update_md() the loop over atoms is:
> for (n=start;n<start+homenr;n++) {
> ---------
> ---------
> }
> 
> I've a few questions regarding the working of this subroutine,
> especially when running mdrun in parallel. For successful
> implementation of my code I will need to-
> 
> A. loop over all atoms
> -Is the loop 'for (n=start;n<start+homenr;n++) {....}' over 
> all atoms
> in the box?

No, under DD, it's over all local atoms. That's the point of DD. You can see that this is true by inspecting start and homnr under a debugger. You'll need to either collect all coordinates like the trajectory-writing routines do, process, and send instructions back to the relevant processes (bad) or use MPI_Allreduce with a custom MPI min/max operator (is this atom in the slab? does it have an extremal speed?) to have available the global min and max on all processors, so that they're available on the ones that actually need them (less bad).
 
> B. locate the slowest (fastest) atom in hot (cold) slab.
> -Are the particle positions stored between [0,L] or [-L/2, L/2].

Neither, IIRC. There are routines that PBCify things as required.

Fastest performance probably requires keeping lists of the atoms in the respective slabs and updating them only on nstlist steps, rather than comparing all atoms to all the slab boundaries every time you need them...

Mark

> C. Exchange their velocities.
> 
> Thanks,
> Gaurav
> -- 
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the 
> www interface or send it to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20100615/6ab4edb1/attachment.html>