<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1454789473;
mso-list-type:hybrid;
mso-list-template-ids:-1405826330 2144399412 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:SimSun;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=white lang=EN-US link=blue vlink=purple>
<div class=WordSection1>
<p class=MsoNormal><span style='color:#1F497D'>Hi there,<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>I will definitely keep you
informed of my progress. In QTPIE, the screened Coulomb integral is actually
an overlap integral between two s-type GTOs. I found yesterday that this makes
implementation of the Ewald summation especially easy, because the interaction
between a Gaussian-blurred charge and a periodic lattice of Gaussian-blurred
charges should be exactly equal to the long-range part of the Ewald interaction
energy with a certain choice of the Gaussian width.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>You are right that I do need to
perform one periodic summation for each of the matrix elements in the
charge-transfer problem Mq=x (M contains Coulomb integrals, x contains overlap
integrals). For now, efficiency considerations aside, I plan to adopt the
Ewald-summation code already in GROMACS and see if it works.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>I ran some dynamics yesterday with
an infinite-sized cutoff and my system appeared to be frozen; this is probably
the “ordering” artifact you’re talking about. I’m working on implementing the
Ewald summation today and will give you more updates.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='color:#1F497D'>Lee-Ping <o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:
"Tahoma","sans-serif";color:windowtext'> gmx-developers-bounces@gromacs.org
[mailto:gmx-developers-bounces@gromacs.org] <b>On Behalf Of </b>Gerrit Groenhof<br>
<b>Sent:</b> Wednesday, October 13, 2010 2:34 AM<br>
<b>To:</b> Discussion list for GROMACS development<br>
<b>Subject:</b> Re: [gmx-developers] rlist larger than L/2 in simple neighbor
search<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>On 10/12/2010 06:49 PM, Lee-Ping Wang wrote: <o:p></o:p></p>
<p class=MsoNormal>Hi there,<o:p></o:p></p>
<p class=MsoNormal> <o:p></o:p></p>
<p class=MsoNormal>For the past few months, I’ve been adding a charge
equilibration model to GROMACS (to be specific, QTPIE – a refinement of QEq).
For the model to work properly, each atom must “see” each other atom in the
electrostatic interaction (it is a screened Coulomb interaction). This is
easy enough to do with pbc = no; I just set all the cutoffs to zero, and add a
new neighbor-list that includes excluded atom pairs.<o:p></o:p></p>
<p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><br>
Since we'd be interested in that, I would appreciate if you can keep us
informed of your progress.<br>
<br>
<br>
<o:p></o:p></span></p>
<p class=MsoNormal> <o:p></o:p></p>
<p class=MsoNormal>Now I would like to run the simulation with PBC turned on,
which means either implementing Ewald summation or using cutoffs for the
electrostatic interaction. When cutoffs are turned on (with or without
PBC), the model goes haywire even with very long cutoff lengths. I
haven’t implemented Ewald summation for the screened Coulomb interaction, and
I’m not sure if it’s worth the effort if an easier fix is possible.<o:p></o:p></p>
<p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><br>
If I recall correctly, the screened Coulomb here means the overlap integral
between s-type Slater functions. This interaction behave as a normal coulomb at
large distances, so that coudl explain the issues with increasing the cut-off.
But an Ewald expression will be difficult as well, since the all
pairs-wise interactions are required to compute the charge flow parameters. I
have so far only seen it applied to molecules. For non bonded system like a box
of water, a direct charge flow between atoms far apart is unlikely though.
Could one not simply scale also the charge transfer variables to zero with
distance as well?<br>
<br>
<o:p></o:p></span></p>
<p class=MsoNormal> <o:p></o:p></p>
<p class=MsoNormal>As a quick fix, I changed the simple neighbor-searching code
to set rcut = 1000000 when QTPIE is turned on.<o:p></o:p></p>
<p class=MsoNormal> <o:p></o:p></p>
<p class=MsoNormal>I am worried about the other possible consequences of my
change; will this adversely affect the molecular dynamics or create artifacts
in some unexpected way? <o:p></o:p></p>
<p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'>You
will get the ordinary artefacts caused by cutoff, like ordering etc.<br>
<br>
<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p> </o:p></span></p>
</div>
</body>
</html>