[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
-----BEGIN PGP SIGNED MESSAGE-----
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
melt.
Any help is appreciated!
Cheers
konstantin
- --
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOJqOQAAoJEBfd2kJEvB25N/IH/RtpRAWTjXUdXEG3N90zmy09
0WwaqE53/oEAn3r3sluxivA+/eshBqc2fIyhbJb1WO7jkX5ikRirYaUJ1spmtN9x
77hvDnCwWw1/CdWXxg09FqEIy2SmC0ouXU6KLF58MlmKxfIwSwgFalHnrxfkvBo5
pT2nnMHOQMd/aHx9ZxjMnrpM6LWpdSimpes/AoUCb/3VvEj2aSCWeF8n6OijSG7r
c9krYr9KIvS30Klshha1K7RNA2PrmjiegbixomnTFCFdMuTdrBpeebqL60Rke6a5
67lL26k+nB0++Ar59doK/n+EQ/l7D1u7UBNpEx6aFusnCWv7W1Z/V7emHJsA+Xg=
=oTLm
-----END PGP SIGNATURE-----
More information about the gromacs.org_gmx-developers
mailing list