Dear List:
Has anyone attempted to implement the TIP5P water potential in LAMMPS? I’m a research staff in the University of Mosul, Iraq and I’m interested in doing this over the summer. I’m aware that the tip4p code would be the logical place to start, however if anyone has any further tips it would be greatly appreciated.
Question:
In my testing, the tip4p water simulations are ~ 3 times slower than the corresponding simulation with the tip3 potential (same number of water molecules, cutoffs etc). Is this to be expected? I’m having trouble seeing why there is such a dramatic slowdown, as the tip4 routine only requires a simple lookup to find the off-center oxygen charge. I’m worried that using such a scheme, the tip5 potential would be too slow for practical use.
Yours in discovery,
L. I.
I would talk to Ahmed Ismail (CCd), who implemented TIP4P.
Steve
2011/6/9 Lucifer Iscariot <[email protected]...>:
2011/6/10 Lucifer Iscariot <luciferiscariot@…43…460…>
Dear List:
Has anyone attempted to implement the TIP5P water potential in LAMMPS? I’m a research staff in the University of Mosul, Iraq and I’m interested in doing this over the summer. I’m aware that the tip4p code would be the logical place to start, however if anyone has any further tips it would be greatly appreciated.
Question:
In my testing, the tip4p water simulations are ~ 3 times slower than the corresponding simulation with the tip3 potential (same number of water molecules, cutoffs etc). Is this to be expected? I’m having trouble seeing why there is such a dramatic slowdown, as the tip4 routine only requires a simple lookup to find the off-center oxygen charge. I’m worried that using such a scheme, the tip5 potential would be too slow for practical use.
Yes, as the code stands now, a significant slowdown is to be expected, the reason is not the length of the additional code for computing the TIP4P interactions, but the number of times that code gets called during the execution. It’s pretty much an O(N_local^2) process, so a slowdown is inevitable. However, because the code for TIP5P is more or less the same as the TIP4P code—you’re returning two sets of locations based on the position of the three atoms, rather than one—the additional slowdown should be much smaller for TIP5P compared to TIP4P than for TIP4P versus the traditional code.
Also, it is probably possible to avoid the factor of 3 slowdown by implementing an array to store the additional locations, and using them instead to compute the forces and energies at each time step, rather than computing them “on-the-fly.” This would require significant changes to the algorithm, though, beyond just the update of the compute and find_M routines.
–AEI
Also, it is probably possible to avoid the factor of 3 slowdown by implementing an array to store the additional locations, and using them >instead to compute the forces and energies at each time step, rather than computing them "on-the-fly." This would require significant >changes to the algorithm, though, beyond just the update of the compute and find_M routines.
Not sure what you are referring to here. Nothing about TIP4P is O(N^2) that
I can recall. The find_M() routine is O(1), since it does a direct
lookup of where the extra H atoms are.
Steve
What I meant was that even though find_M is an O(1) process, it gets called a lot if your system is full of TIP4P water molecules. It might not be O(N^2), but the number of calls per processor is as large as O(N_neighbor x N_proc), where N_neighbor is the average number of neighbor atoms and N_proc is the number of atoms on the processor. This is potentially hundreds of thousands of calls during a time step.
If you could call find_M outside the main loop over atoms, and do it once per processor per time step, then you could cut the overhead down significantly. The periodic image issue might creep up again, but it could be relatively minor with respect to the total number of calls saved by the change.
–AEI
Hmmm. My intuition is that it wouldn't make much difference, but
it's worth a try. I'll put it on the todo list.
Steve