<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;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{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;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:1710061556;
mso-list-type:hybrid;
mso-list-template-ids:305300940 -1826338126 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:4;
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’ve gotten the QTPIE interaction
to work with PBC using a custom-designed shift function; the matrix elements
are taken smoothly to zero at the cutoff radius. This ensures that there
is no force discontinuity, which I’ve found causes some artifacts in the
dynamics and energy minimization. <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'>Implementing the Ewald summation
has been a bit problematic, because as you said, there needs to be a pairwise
decomposition of the electrostatic energy in computing the matrix elements.
I think I have something that works, but the forces aren’t implemented
yet, and it’s expensive because it requires a double loop in the k-space
summation (the normal Ewald summation only needs a single loop). Hopefully,
the shift function will perform well enough and I won’t worry so much
about the Ewald summation.<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 am trying to build the QTPIE
forces into the “fshift” vector to get the pressures right, but I
don’t have any way of telling whether my calculated pressures are correct.
I suspect there is a problem, since the box keeps on blowing up if I turn
pressure coupling on, but I need some reference method to compare against; how
do you all make sure that the pressure is being computed properly? Do you
simply repeat energy calculations at different box sizes and compute the
pressure by finite difference?<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'>Thanks,<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:l1 level1 lfo3'><![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 style='margin-bottom:12.0pt'><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>
<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 style='margin-bottom:12.0pt'><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?<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 style='margin-bottom:12.0pt'><span style='font-size:12.0pt;
font-family:"Times New Roman","serif"'>You will get the ordinary artefacts
caused by cutoff, like ordering etc.<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>