[gmx-developers] Suggestions about neighbor search(plz delete the previous one)

[Mark Abraham]

Indeed. If there are separate groups for (say) temperature coupling of
solvent and solute, then the (group kernel) neighbour searching is
already only between group pairs. So only in the
solvent-group-solute-group neighbour search can the question arise,
and then only for some fraction of the interactions. Maybe that's even
pre-sorted somehow so that the inefficient case does not arise in this
scenario - but don't quote me!

If Mark wants to examine further on a system of interest, he could
readily drop in some counters to put_in_list_at to see how often the
inefficient case occurs, and look at the end of the .log files to
judge the relative frequency of the types of kernel calls.

Mark


On Sat, Jul 27, 2013 at 1:04 AM, Feenstra, K.A. <k.a.feenstra at vu.nl> wrote:
> Dear Tianwu,
>
> In a typical biomolecular simulation, there are at least 100x more water molecules than solute, often even 100x more water atoms than solute atoms. In terms of interactions, this means many 1000's (up to 10k) more w-w interactions. Therefore, these were implemented as a special case. IIRC there are further special cases for LJ-LJ only and for Coul-Coul only intactions. Water-anything is not a large fraction of most simulated systems.
>
> Best,
>
> Anton.
>
>
> Op 27 jul. 2013 om 00:22 heeft "Tianwu Zang" <tz4 at rice.edu> het volgende geschreven:
>
>> Dear all,
>> I have gone through the neighbor search part of GROMACS and found that the basic logic of function "put_in_list_t" is as below:
>>
>> if charge group i is water
>> {
>>   neighbor_list vdwc = VDWQQ_WATER
>>
>>   if charge group j is water
>>     add j to neighbor_list vdwc_ww
>>   else
>>     add j to neighbor_list vdwc
>> }
>> else
>> {
>>   neighborlist vdwc = VDWQQ
>>   add j to neighborlist vdwc
>> }
>>
>> However,  there are many cases that charge group i is not water but charge group j is water, and these cases are not considered into this algorithm currently. In practice, it can be found that many water molecules will be split when added into the neighbor lists of a charge group: atom "OW" will be filled into neighbor_list VDWQQ (NBlist 0) and two atoms "HW" will be filled into neighbor_list QQ (NBlist 2) separately. Therefore, when calculating non-bonded interactions, the NB kernel will be called three times.
>>
>> If we modify the algorithm such that even if charge group i is not water, charge group j will still be put into neighbor_list VDWQQ_WATER (NBlist 6) if it is water, then for every pair of solvent-nonsolvent charge group non-bonded interaction, NB kernel will be called only once, and considering the water optimization, the computing time for calling kernel VDWQQ_WATER once should be smaller than calling kernel VDWQQ once plus kernel QQ twice. Also, considering the current VDWQQ_WATER kernel is dealing with the cases that i is water but j is not, we need to add a similar kernel which will compute the cases that j is water but i is not.
>>
>> I am not quite sure if there are other considerations, but as far as I can see this approach might further reduce the non-bonded interaction computing time.
>>
>> Thanks!
>> -Mark
>>
>> --
>> 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.
> --
> 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.