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

[Feenstra, K.A.]

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.