[gmx-developers] Dynamic Temperature Coupling Groups and Parallel Implementation

Konstantin Koschke koschke at mpip-mainz.mpg.de
Wed Jul 20 11:44:48 CEST 2011

Hash: SHA1

Dear developers,

I'm a bit lost in the following issue and I hope that my questions are
qualified for the developers list:

My aim is to restrict the 'stochastic velocity rescaling' thermostat to
a certain geometric region, e.g. a slab. What I did so far: I used the
concept of temperature coupling groups and put my (single) atoms into
certain groups, based on their instantaneous (e.g.) z-coordinate. This
results in slabs, where each slab has its own ref-t and tau-t.
(http://www.mpip-mainz.mpg.de/~koschke/dynamicTCexample.png visualizes
the different tc-groups using different colors).
By updating cTC[atom index] in do_update_md() (e.g. at each step) and
recounting the number of degrees of freedom nrdf for each coupling
group, I was able to implement "dynamic TC groups" for the serial
version of mdrun.

Problems arise as soon as one needs a parallel implementation of the
above idea (I won't use MPI communication; shared memory only, threaded
runs are all I need). When the data gets split/copied to the different
domains and distributed among threads, opts->nrdf becomes a local
variable and recounting nrdf for each tc group stops being trivial. That
is because do_update_md() can not access a global nrdf[] variable (it
does not exist). One workaround would be, to pass the reference of the
"original" opts variable to each thread, allowing them to increase a
global nrdf[] as needed and thus, recount and update nrdf correctly
(this workaround would only work for shared memory architectures -
again, that would be ok; I am aware of the need for mutexes).

I was wondering if you see a smarter way of updating cTC[] and nrdf[] in
the parallel version of mdrun. My suggested workaround gets increasingly
dirty with each modified line of code. Also, I am not sure where I can
find the "original" inputrec->opts->nrdf variable - I thought mdrunner()
in runner.c is the place to look, but debugging runner.c makes my brain

Any help is appreciated!


- -- 
Konstantin Koschke
Max Planck Institute for Polymer Research
Theory Group
PO Box 3148
D 55021 Mainz, Germany

phone: +49 6131 379 481
email: koschke at mpip-mainz.mpg.de
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/


More information about the gromacs.org_gmx-developers mailing list