<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 18/10/2011 5:40 AM, J. Nathan Scott wrote:
<blockquote
cite="mid:CAHktqcEcTm1CzkPe4aYmDJ+oKDZy3usFhNPzHNHm+XTVV_o+sA@mail.gmail.com"
type="cite">Hello fellow GMX users,<br>
<br>
I've been digging in the archives and haven't yet found a good
response to this question, so I thought I'd ask again, since I see
from a post just last month others are still interested in this
subject as well. Is it possible in Gromacs to periodically
update/change the charges on a given molecule or residue during
the course of a simulation?<br>
</blockquote>
<br>
Not currently, but it would not be hard to do.<br>
<br>
<blockquote
cite="mid:CAHktqcEcTm1CzkPe4aYmDJ+oKDZy3usFhNPzHNHm+XTVV_o+sA@mail.gmail.com"
type="cite">What I am envisioning is having a production
simulation running, and then every "x" amount of time, the current
checkpoint file gets read and processed by an external routine
that calculates charges on the residue or molecule of interest,
which are then fed back into Gromacs to continue the run. Is it
possible to execute an external program from within a Gromacs
simulation? I know this functionality must be in there somewhere,
since Gromacs can communicate with external QM software, but I'm
not sure if a charge modification scheme could make use of the
same built-in I/O methods.<br>
</blockquote>
<br>
GROMACS is a normal C program, and can execute an external program.
Obviously this will still be inefficient if GROMACS was running in
parallel, since you have to have an I/O phase before and after the
external program and probably the other processors cannot do
anything useful. You would then have to re-distribute the charge
vector over any GROMACS parallel nodes.<br>
<br>
<blockquote
cite="mid:CAHktqcEcTm1CzkPe4aYmDJ+oKDZy3usFhNPzHNHm+XTVV_o+sA@mail.gmail.com"
type="cite">
<br>
Is such a scheme possible? I realize an alternative method would
be to stop the run, do some calculation to recalculate the
charges, and then perhaps use some simple code to modify the .top
file directly, and finally grompp out a new tpr file and continue
the run. Lather, rinse, repeat. I'm guessing this could be rather
slow because of needing to call grompp over and over and the need
to continually restart the simulation. <br>
</blockquote>
<br>
This would be slower still, but reliable and easy for proving the
method.<br>
<br>
<blockquote
cite="mid:CAHktqcEcTm1CzkPe4aYmDJ+oKDZy3usFhNPzHNHm+XTVV_o+sA@mail.gmail.com"
type="cite">
<br>
For what it's worth, my interest lies mainly in excited state
chromophores and I'd be using modified ZINDO code to calculate
charges every x number of steps. This calculation is *very* fast,
even for large chromophores, therefore my focus on other
performance bottlenecks.<br>
</blockquote>
<br>
Ideally, GROMACS code would be linked with ZINDO and call the
correct function directly. This shouldn't be too bad since you
merely need an array of coordinates (and some other data which can
be hard-coded somehow) as input, and the charges out. You should
probably get one or other of the crude hacks working first, to judge
how much value the speed-up might have.<br>
<br>
Mark<br>
<br>
<blockquote
cite="mid:CAHktqcEcTm1CzkPe4aYmDJ+oKDZy3usFhNPzHNHm+XTVV_o+sA@mail.gmail.com"
type="cite">
<br>
I would be extremely grateful for any feedback on this subject,
particularly from anyone who has done a similar thing successfully
and cares to share any tips or code.<br clear="all">
<br>
-- <br>
----------<br>
J. Nathan Scott, Ph.D.<br>
Postdoctoral Fellow<br>
Department of Chemistry and Biochemistry<br>
Montana State University<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>