<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/09/2014 07:30 PM, Mark Abraham
wrote:<br>
</div>
<blockquote
cite="mid:CAMNuMAQFMJ5_bjfU1buKSzPEPEEhLShh_ddyczUoxPPG9xvPCQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<p dir="ltr"><br>
On Jan 9, 2014 7:44 AM, "James" <<a moz-do-not-send="true"
href="mailto:jamesresearching@gmail.com">jamesresearching@gmail.com</a>>
wrote:<br>
><br>
> Dear Erik, David and other Gromacs developers,<br>
><br>
> Thank you very much for your replies. They were very
helpful! I have run with just one thread and I can now see how
to extract i-j VDW and short-range coulomb potentials (shared
equally between pairs) and by tracing the temperature evaluation
I think I have found the appropriate place for extracting
kinetic energy and velocities.<br>
><br>
> I wonder if I may follow up about the atomic numbering. I
will need to move to parallel calculation as soon as possible,
and I have been thinking about the comments:<br>
><br>
> (Erik) "you can write functionality to move the properties
you need (just as we move charge, etc) into the local topology
when we do rebalancing between domains"<br>
><br>
> I'm not sure what exactly is meant by "local topology".
Where is "rebalancing between domains" performed? Would you mind
expanding this explanation a little more or giving an example?</p>
<p dir="ltr">See code in runner.c and md.c, probably near
init_domain_decomposition or domain_decomposition. You'll need
to drill into either or both to find how to propagate whatever
it is you need.</p>
<p dir="ltr">> (David) "There is a function in mtop_util.h that
will give you the global atom number"<br>
><br>
> Are you referring to the gmx_mtop_atomlookup_init function?
I looked at other places in the code where this is called; I
assume I would have to somehow pass *mtop to the force
subroutine? If evaluating this is expensive, as Erik suggests, I
suppose I could do this outside of the force loop.</p>
<p dir="ltr">No, that is a global topology, and local atom indices
won't help. IIRC gmx_local_topology_t is the data type. You
should want to build an array at domain-decomposition time that
can be looked up at each following integration step with a local
atom index. Or simulate with pen and paper for better speed ;-)</p>
</blockquote>
The array is already there: cr->dd->gatindex<br>
<br>
Cheers,<br>
<br>
Berk<br>
<blockquote
cite="mid:CAMNuMAQFMJ5_bjfU1buKSzPEPEEhLShh_ddyczUoxPPG9xvPCQ@mail.gmail.com"
type="cite">
<p dir="ltr">Mark</p>
<p dir="ltr">> Thank you again for your help.<br>
><br>
> With best regards,<br>
><br>
> James<br>
><br>
><br>
> On 31 December 2013 18:15, Erik Lindahl <<a
moz-do-not-send="true"
href="mailto:erik.lindahl@scilifelab.se">erik.lindahl@scilifelab.se</a>>
wrote:<br>
>><br>
>> Hi James,<br>
>><br>
>> On 31 Dec 2013, at 08:15, James <<a
moz-do-not-send="true"
href="mailto:jamesresearching@gmail.com">jamesresearching@gmail.com</a>>
wrote:<br>
>><br>
>> > Dear Gromacs developers,<br>
>> ><br>
>> > To measure thermal conductivity using Green-Kubo I
am trying to extract the i-j atomic forces from nb_generic.c and
I wonder if anyone could help me with some basic questions?<br>
>> ><br>
>> > 1. If I understand correctly, ii and jj are atom
numbers for atom i and atom j. These don't seem to correspond to
the atoms in the order that they were read in (PDB file),
however. How can I recover this order, or what is the new order?<br>
>><br>
>> That would be “ii” and “jnr” in the master branch. If
you are only using a single thread this should correspond to the
atom order in the input (although C always starts counting at
0). However, when we run in parallel the domain decomposition
will mean that the particle indices change (frequently) as
particules move across node boundaries.<br>
>><br>
>> There are routines you can use to find the global atom
indices, but you don’t want to call those from the innermost
kernel. Instead I would recommend using a single thread while
you develop, and later when you want to enable parallelization
you can write functionality to move the properties you need
(just as we move charge, etc) into the local topology when we do
rebalancing between domains.<br>
>><br>
>> > 2. What units are the positions ix, iy, iz (again
in nb_generic.c)?<br>
>><br>
>> nm - same as in the gro files, but it differs from PDB
files that use Angstrom.<br>
>> ><br>
>> > 3. nb_generic is within the loop i = i0 to i1-1 in
nonbonded.c. What is this loop? Somehow related to different
interaction types?<br>
>><br>
>> At one point we experimented with multithreading
parallelism over this loop (thus the indices), but now the
outermost loop is over different neighborlists. A certain
particle will have different neighborlists for neighbors that
only have charge, only Lennard-Jones, and both LJ+charge.<br>
>><br>
>> Having said that, for the future we are likely moving
entirely to the new style “verlet” kernels currently used for
GPUs (and that will likely be default for CPUs in Gromacs-5.0
too), but we still need to write a generic kernel there.<br>
>><br>
>> > 4. Later, I will also want to extract the
instantaneous kinetic and potential energy of the atom in the
same time-step - any advice is very welcome.<br>
>><br>
>> For kinetic energy you can just look at how we
calculate temperature - this is easy. Potential energy is
complex if you use lattice summation (PME), since you then would
need to modify the grid interpolation to get potentials of
individual particles.<br>
>> ><br>
>> > 5. Out of interest, I notice many of the files in
the release-4-6 branch are in include/ but the same files are in
legacyheaders/ in the master branch. Why is this? Which should I
be developing against?<br>
>><br>
>> We are moving pretty fast right now due to a switch
from C to partial C++, which also involves a lot of cleaning-up
and modularization. The master branch is the future, but
legacyheaders is stuff that still hasn’t been modularized.<br>
>><br>
>> Cheers,<br>
>><br>
>> Erik<br>
>> --<br>
>> Gromacs Developers mailing list<br>
>><br>
>> * Please search the archive at <a
moz-do-not-send="true"
href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a>
before posting!<br>
>><br>
>> * Can't post? Read <a moz-do-not-send="true"
href="http://www.gromacs.org/Support/Mailing_Lists">http://www.gromacs.org/Support/Mailing_Lists</a><br>
>><br>
>> * For (un)subscribe requests visit<br>
>> <a moz-do-not-send="true"
href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a>
or send a mail to <a moz-do-not-send="true"
href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
><br>
><br>
><br>
> --<br>
> Gromacs Developers mailing list<br>
><br>
> * Please search the archive at <a moz-do-not-send="true"
href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a>
before posting!<br>
><br>
> * Can't post? Read <a moz-do-not-send="true"
href="http://www.gromacs.org/Support/Mailing_Lists">http://www.gromacs.org/Support/Mailing_Lists</a><br>
><br>
> * For (un)subscribe requests visit<br>
> <a moz-do-not-send="true"
href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a>
or send a mail to <a moz-do-not-send="true"
href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>