<p dir="ltr"><br>
On Jan 9, 2014 7:44 AM, &quot;James&quot; &lt;<a href="mailto:jamesresearching@gmail.com">jamesresearching@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Dear Erik, David and other Gromacs developers,<br>
&gt;<br>
&gt; 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>

&gt;<br>
&gt; 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>
&gt;<br>
&gt; (Erik) &quot;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&quot;<br>
&gt;<br>
&gt; I&#39;m not sure what exactly is meant by &quot;local topology&quot;. Where is &quot;rebalancing between domains&quot; 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&#39;ll need to drill into either or both to find how to propagate whatever it is you need.</p>
<p dir="ltr">&gt; (David) &quot;There is a function in mtop_util.h that will give you the global atom number&quot;<br>
&gt;<br>
&gt; 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&#39;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>

<p dir="ltr">Mark</p>
<p dir="ltr">&gt; Thank you again for your help.<br>
&gt;<br>
&gt; With best regards,<br>
&gt;<br>
&gt; James<br>
&gt;<br>
&gt;<br>
&gt; On 31 December 2013 18:15, Erik Lindahl &lt;<a href="mailto:erik.lindahl@scilifelab.se">erik.lindahl@scilifelab.se</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi James,<br>
&gt;&gt;<br>
&gt;&gt; On 31 Dec 2013, at 08:15, James &lt;<a href="mailto:jamesresearching@gmail.com">jamesresearching@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; Dear Gromacs developers,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; 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>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; 1. If I understand correctly, ii and jj are atom numbers for atom i and atom j. These don&#39;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>

&gt;&gt;<br>
&gt;&gt; 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>

&gt;&gt;<br>
&gt;&gt; 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>

&gt;&gt;<br>
&gt;&gt; &gt; 2. What units are the positions ix, iy, iz (again in nb_generic.c)?<br>
&gt;&gt;<br>
&gt;&gt; nm - same as in the gro files, but it differs from PDB files that use Angstrom.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; 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>
&gt;&gt;<br>
&gt;&gt; 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>

&gt;&gt;<br>
&gt;&gt; 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>

&gt;&gt;<br>
&gt;&gt; &gt; 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>
&gt;&gt;<br>
&gt;&gt; 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>

&gt;&gt; &gt;<br>
&gt;&gt; &gt; 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>

&gt;&gt;<br>
&gt;&gt; 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>

&gt;&gt;<br>
&gt;&gt; Cheers,<br>
&gt;&gt;<br>
&gt;&gt; Erik<br>
&gt;&gt; --<br>
&gt;&gt; Gromacs Developers mailing list<br>
&gt;&gt;<br>
&gt;&gt; * Please search the archive at <a 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>
&gt;&gt;<br>
&gt;&gt; * Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists">http://www.gromacs.org/Support/Mailing_Lists</a><br>
&gt;&gt;<br>
&gt;&gt; * For (un)subscribe requests visit<br>
&gt;&gt; <a 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 href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>

&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Gromacs Developers mailing list<br>
&gt;<br>
&gt; * Please search the archive at <a 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>
&gt;<br>
&gt; * Can&#39;t post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists">http://www.gromacs.org/Support/Mailing_Lists</a><br>
&gt;<br>
&gt; * For (un)subscribe requests visit<br>
&gt; <a 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 href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>

</p>