RE: [gmx-users] Normalization in g_rdf

2009-11-24 Thread Berk Hess

Hi,

If you have N molecules with total volume which is significantly less than the 
unit-cell,
as is the case for ions in solvent, the RDF of the N molecules againt themselves
will converge to (N-1)/N.

Berk

 Date: Tue, 24 Nov 2009 01:27:27 +0100
 From: ondrej.marsa...@gmail.com
 To: gmx-users@gromacs.org
 Subject: [gmx-users] Normalization in g_rdf
 
 Dear all,
 
 I would like to understand better the way g_rdf performs
 normalization. I have two unexpected results:
 
 1) In a simple simulation of atomic ions in water in a cubic box, I
 get RDFs that clearly reach a constant value at large enough
 distances, but that value is somewhat lower than one. The simulation
 is NpT, could that be a problem for the normalization?
 
 2) In a simulation in a dodecahedron, I get an unexpected decrease in
 the RDF at larger distances (for free ions in solution). Is there some
 know problem with normalization in triclinic cells? Is the RDF perhaps
 not truncated soon enough?
 
 If these should work better than they do for me, I will of course
 check my simulations again. I would just like to check first if this
 is to be expected.
 
 Thanks,
 Ondrej
 -- 
 gmx-users mailing listgmx-users@gromacs.org
 http://lists.gromacs.org/mailman/listinfo/gmx-users
 Please search the archive at http://www.gromacs.org/search before posting!
 Please don't post (un)subscribe requests to the list. Use the 
 www interface or send it to gmx-users-requ...@gromacs.org.
 Can't post? Read http://www.gromacs.org/mailing_lists/users.php
  
_
New Windows 7: Simplify what you do everyday. Find the right PC for you.
http://windows.microsoft.com/shop-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php

Re: [gmx-users] Normalization in g_rdf

2009-11-24 Thread Omer Markovitch
On Tue, Nov 24, 2009 at 02:27, Ondrej Marsalek ondrej.marsa...@gmail.comwrote:

 Dear all,

 I would like to understand better the way g_rdf performs
 normalization. I have two unexpected results:

 1) In a simple simulation of atomic ions in water in a cubic box, I
 get RDFs that clearly reach a constant value at large enough
 distances, but that value is somewhat lower than one. The simulation
 is NpT, could that be a problem for the normalization?

 g(r) should fluctuate around 1 at large distances, say 9 Angstroms for pure
water.


 2) In a simulation in a dodecahedron, I get an unexpected decrease in
 the RDF at larger distances (for free ions in solution). Is there some
 know problem with normalization in triclinic cells? Is the RDF perhaps
 not truncated soon enough?

Try calculating it for much larger distances, if you have PBC this should
not be a problem even with the current docecahedron.

--Omer.
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php

Re: [gmx-users] g_msd = The MSD and periodic boundary condition

2009-11-24 Thread Omer Markovitch
On Fri, Nov 20, 2009 at 01:32, Chih-Ying Lin chihying2...@gmail.com wrote:

 So, how can I remove the periodic boundary condition to get the truly
 movement of the atoms between the two time steps ?


Removing PBC and placing atoms back into their true location is easy. In
general, if an atom has moved more than half of the box between two
consecutive timesteps then it has jumped over the box.
You can see for example eq. 19  20 in doi:10.1063/1.2968608 .
--Omer.
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php

Re: [gmx-users] How to make carbon nanotube infinite?

2009-11-24 Thread Cun Zhang
hi, Justin. Thank you for your patience !

I'm still in trouble with infinite CNT simulation.

I'm trying to simulate the interaction of  a infinite (16,0) CNT(CNT_A) with
832 atoms and water. I'm using x2top to generate the CNT.itp with
share-bonds. The idea is that I generate a (16,0) CNT(CNT_B) with 960 atoms
( more 4 layer  than CNT_A. Each layer has 32 atoms ).
When I use CNT.itp generated by  CNT_A and x2top, it works. But when I use
the CNT.itp which has share-bonds information, it can't work.


The process I'm doing CNT simulation is as follows:
# the CNT_new.pdb is a (16,0) CNT with 960 atoms.
# I add the custom forcefield parameters to tmp.top, and change the number
of a charge group to 32, then rename it CNT.itp at the end.

x2top -f CNT_new.pdb -o tmp.top -ff gmx -nopbc -nopairs -noparam -name CNT


bash sharebond_script   # create share bonds

editconf -f CNT.pdb -o -box 3.8 3.8 5.614

genbox -cp out -cs -p CNT -o b4em.pdb  #The simulation box size can be seen
in b4em.pdb

pymol b4em.pdb  #remove water. After editing it,I save it as b4em.pdb
too.Now the information about box size is losing. I don't know why.I'm not
familar with it :)

editconf -f b4em.pdb -o b4em -box 3.8 3.8 5.614 # Add the information about
box size
vim CNT.top #change the number of water to make it the same as b4em.pdb
grompp -f em -o em -c b4em -p CNT -maxwarn 5
mpirun -np 4 mdrun_mpi -v -s em -e em -o em -c after_em
grompp -f grompp -o pr -c after_em -p CNT -maxwarn 5
mpirun -np 4 mdrun_mpi -v -s pr -e pr -o pr -c after_pr

The sharebond_scrip code:

#!/bin/bash
sed -e '/^ *83[3-9].*UNK/d' -e '/^ *8[4-9][0-9].*UNK/d' -e '/^
*9[0-9][0-9].*UNK/d'  CNT.itp tmp # remove the atoms whose number is larger
than 832 in [ atoms ].
for((i=833;i=960;i=i+1))   # change the number(i) of atoms which is larger
than 832 to i-832.
do
j=$((i-832))
N=$((3-${#j}))
L='   '
j=${L:1:N}$j
sed -i s/ $i / $j / tmp
done
awk '!a[$0]++' tmpCNT.itp # make the CNT.itp file have no repetitive rows

I upload a log file for more information in there (
http://4message.net/blog/wp-content/uploads/2009/11/CNT.tar.bz2 )

Cun Zhang wrote:
  Hi, Justin.
  Thank you for your help! I was intended to reply the third question
  after I retryed the simulation under your advice,but I haven't enough
 time
  to do it. It's too late :)
 
  Just now, I do a simulation. All seems ok. I will check it again.
 
  Thank you again!
 
  Cun Zhang
 
 pymol b4em.pdb # I write a python script to remove the SOL
  molecules
in the Carbon nanotube.
 
  Are there any solvent molecules interfering with the cross-boundary
  bonds?
 
 
  No.I use pymol to remove all residues which is far from the egdes 0.7A .
 
 

 OK.

 
 editconf -f b4em.pdb -o b4em.gro -box 3.8 3.8 5.614 #rebuild
  the box.
 
  Why are you doing this?
 
 
  The b4em.pdb generated by genbox have no information about box size. So
  I use editconf to generate it.
 

 That is not true.  Gromacs can handle a number of coordinate file types,
 and box
 dimensions are written to the CRYST1 line in the .pdb file.  You should
 never
 have to re-define your box unless you are doing some very advanced
 manipulations
 (which you are not, in the case of simply solvating a structure).

NOTE 1 [file CNT.top, line unknown]:
  The largest charge group contains 32 atoms.
  Since atoms only see each other when the centers of geometry of
  the charge
  groups they belong to are within the cut-off distance, too
  large charge
  groups can lead to serious cut-off artifacts.
  For efficiency and accuracy, charge group should consist of a
  few atoms.
  For all-atom force fields use: CH3, CH2, CH, NH2, NH, OH, CO2,
  CO, etc.
   
 
  Pay attention to this note.  A charge group of 32 atoms is huge.
 
 
  So what's your suggestion about the number of a charge group?
 

 The note from grompp is quite detailed, and even gives examples of
 appropriate
 charge group sizes.

 -Justin

 
  --
  Blog: http://blog.4message.net

 --
 

 Justin A. Lemkul
 Ph.D. Candidate
 ICTAS Doctoral Scholar
 Department of Biochemistry
 Virginia Tech
 Blacksburg, VA
 jalemkul[at]vt.edu | (540) 231-9080
 http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin





-- 
Blog: http://blog.4message.net
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php

RE: [gmx-users] Normalization in g_rdf

2009-11-24 Thread Berk Hess

Hi,

g_rdf limits the distance to half the minimum periodic image distance.
So the volume normalization is always simply  4 pi r^2.
It uses the starting unit-cell with a factor of 0.99.
So you would only see strange effects when the box length reduces
more than 1% due to pressure coupling.

Berk

 Date: Tue, 24 Nov 2009 13:23:30 +0100
 Subject: Re: [gmx-users] Normalization in g_rdf
 From: ondrej.marsa...@gmail.com
 To: gmx-users@gromacs.org
 
 On Tue, Nov 24, 2009 at 13:01, Omer Markovitch omer...@gmail.com wrote:
 
  On Tue, Nov 24, 2009 at 02:27, Ondrej Marsalek ondrej.marsa...@gmail.com
  wrote:
 
  Dear all,
 
  I would like to understand better the way g_rdf performs
  normalization. I have two unexpected results:
 
  1) In a simple simulation of atomic ions in water in a cubic box, I
  get RDFs that clearly reach a constant value at large enough
  distances, but that value is somewhat lower than one. The simulation
  is NpT, could that be a problem for the normalization?
 
  g(r) should fluctuate around 1 at large distances, say 9 Angstroms for pure
  water.
 
 Indeed. However, see also Berk's remark. It seems to match very well
 for my system.
 
 
 
  2) In a simulation in a dodecahedron, I get an unexpected decrease in
  the RDF at larger distances (for free ions in solution). Is there some
  know problem with normalization in triclinic cells? Is the RDF perhaps
  not truncated soon enough?
 
  Try calculating it for much larger distances, if you have PBC this should
  not be a problem even with the current docecahedron.
 
 Maybe I am missing something, but the range that g_rdf considers is
 hardwired - half the smallest box length with PBC, 3x the largest one
 without PBC. Is there a way to include contributions from multiple
 images of the unit cell?
 
 BTW, if g_rdf really only considers the box edge lengths and
 disregards angles, it would make sense that normalization is broken in
 general cells at larger distances, no?
 
 Ondrej
 
 
  --Omer.
 
 
  --
  gmx-users mailing listgmx-users@gromacs.org
  http://lists.gromacs.org/mailman/listinfo/gmx-users
  Please search the archive at http://www.gromacs.org/search before posting!
  Please don't post (un)subscribe requests to the list. Use the
  www interface or send it to gmx-users-requ...@gromacs.org.
  Can't post? Read http://www.gromacs.org/mailing_lists/users.php
 
 -- 
 gmx-users mailing listgmx-users@gromacs.org
 http://lists.gromacs.org/mailman/listinfo/gmx-users
 Please search the archive at http://www.gromacs.org/search before posting!
 Please don't post (un)subscribe requests to the list. Use the 
 www interface or send it to gmx-users-requ...@gromacs.org.
 Can't post? Read http://www.gromacs.org/mailing_lists/users.php
  
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php

Re: [gmx-users] Normalization in g_rdf

2009-11-24 Thread Ondrej Marsalek
Hi again,

I thought pressure coupling is handled by g_rdf. Looking at the code,
it seems that the block starting with:

/* Must init pbc every step because of pressure coupling */

takes care of that, so even with a relatively big volume change at the
beginning, it should not be a problem. Is that not the case?

Ondrej


On Tue, Nov 24, 2009 at 16:12, Berk Hess g...@hotmail.com wrote:
 Hi,

 g_rdf limits the distance to half the minimum periodic image distance.
 So the volume normalization is always simply  4 pi r^2.
 It uses the starting unit-cell with a factor of 0.99.
 So you would only see strange effects when the box length reduces
 more than 1% due to pressure coupling.

 Berk
--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php


Re: [gmx-users] How to make carbon nanotube infinite?

2009-11-24 Thread Justin A. Lemkul



Cun Zhang wrote:

hi, Justin. Thank you for your patience !

I'm still in trouble with infinite CNT simulation.

I'm trying to simulate the interaction of  a infinite (16,0) CNT(CNT_A) 
with 832 atoms and water. I'm using x2top to generate the CNT.itp with 
share-bonds. The idea is that I generate a (16,0) CNT(CNT_B) with 960 
atoms ( more 4 layer  than CNT_A. Each layer has 32 atoms ).
When I use CNT.itp generated by  CNT_A and x2top, it works. But when I 
use the CNT.itp which has share-bonds information, it can't work.



The process I'm doing CNT simulation is as follows:
# the CNT_new.pdb is a (16,0) CNT with 960 atoms.
# I add the custom forcefield parameters to tmp.top, and change the 
number of a charge group to 32, then rename it CNT.itp at the end.


x2top -f CNT_new.pdb -o tmp.top -ff gmx -nopbc -nopairs -noparam -name 
CNT  


bash sharebond_script   # create share bonds



The script below is renumbering and removing atoms.  Why are you doing this?  I 
thought the purpose of CNT_new was to generate a larger structure?



editconf -f CNT.pdb -o -box 3.8 3.8 5.614



Now you are manipulating CNT.pdb - is this the correct next step?  If this 
actually pertains to CNT_new.pdb, then the box size is insufficient to hold the 
larger structure.  But now I'm just confused as to what you're doing.


genbox -cp out -cs -p CNT -o b4em.pdb  #The simulation box size can be 
seen in b4em.pdb


pymol b4em.pdb  #remove water. After editing it,I save it as b4em.pdb 
too.Now the information about box size is losing. I don't know why.I'm 
not familar with it :)


editconf -f b4em.pdb -o b4em -box 3.8 3.8 5.614 # Add the information 
about box size

vim CNT.top #change the number of water to make it the same as b4em.pdb
grompp -f em -o em -c b4em -p CNT -maxwarn 5
mpirun -np 4 mdrun_mpi -v -s em -e em -o em -c after_em


Does energy minimization work?  What did the potential energy and maximum force 
converge to?  Again, what is the purpose of -maxwarn 5?  Are there errors that 
grompp is generating that you are simply trying to bypass?  This is generally a 
bad idea.


-Justin


grompp -f grompp -o pr -c after_em -p CNT -maxwarn 5
mpirun -np 4 mdrun_mpi -v -s pr -e pr -o pr -c after_pr

The sharebond_scrip code:

#!/bin/bash
sed -e '/^ *83[3-9].*UNK/d' -e '/^ *8[4-9][0-9].*UNK/d' -e '/^ 
*9[0-9][0-9].*UNK/d'  CNT.itp tmp # remove the atoms whose number is 
larger than 832 in [ atoms ].
for((i=833;i=960;i=i+1))   # change the number(i) of atoms which is 
larger than 832 to i-832.

do
j=$((i-832))
N=$((3-${#j}))
L='   '   
j=${L:1:N}$j

sed -i s/ $i / $j / tmp
done
awk '!a[$0]++' tmpCNT.itp # make the CNT.itp file have no repetitive rows

I upload a log file for more information in there ( 
http://4message.net/blog/wp-content/uploads/2009/11/CNT.tar.bz2 )





--


Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin


--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/mailing_lists/users.php


RE: [gmx-users] Normalization in g_rdf

2009-11-24 Thread Berk Hess

Hi,

Sure g_rdf takes care of pressure coupling, but the cut-off of the rdf plot is 
set from the initial frame.
So if your volume fluctuates a lot, you might have incorrect normalization very 
close to the cut-off.
But in normal liquid simulations the box length will never change more than 
1%.

Berk

 Date: Tue, 24 Nov 2009 17:12:44 +0100
 Subject: Re: [gmx-users] Normalization in g_rdf
 From: ondrej.marsa...@gmail.com
 To: gmx-users@gromacs.org
 
 Hi again,
 
 I thought pressure coupling is handled by g_rdf. Looking at the code,
 it seems that the block starting with:
 
 /* Must init pbc every step because of pressure coupling */
 
 takes care of that, so even with a relatively big volume change at the
 beginning, it should not be a problem. Is that not the case?
 
 Ondrej
 
 
 On Tue, Nov 24, 2009 at 16:12, Berk Hess g...@hotmail.com wrote:
  Hi,
 
  g_rdf limits the distance to half the minimum periodic image distance.
  So the volume normalization is always simply  4 pi r^2.
  It uses the starting unit-cell with a factor of 0.99.
  So you would only see strange effects when the box length reduces
  more than 1% due to pressure coupling.
 
  Berk
 -- 
 gmx-users mailing listgmx-users@gromacs.org
 http://lists.gromacs.org/mailman/listinfo/gmx-users
 Please search the archive at http://www.gromacs.org/search before posting!
 Please don't post (un)subscribe requests to the list. Use the 
 www interface or send it to gmx-users-requ...@gromacs.org.
 Can't post? Read http://www.gromacs.org/mailing_lists/users.php
  
_
New Windows 7: Simplify what you do everyday. Find the right PC for you.
http://windows.microsoft.com/shop-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php

Re: [gmx-users] Normalization in g_rdf

2009-11-24 Thread Ondrej Marsalek
Ah, now I see what you meant. Then it is fine. That is a separate
issue and is not really a problem for me.

Thank you,
Ondrej


On Tue, Nov 24, 2009 at 17:39, Berk Hess g...@hotmail.com wrote:
 Hi,

 Sure g_rdf takes care of pressure coupling, but the cut-off of the rdf plot
 is set from the initial frame.
 So if your volume fluctuates a lot, you might have incorrect normalization
 very close to the cut-off.
 But in normal liquid simulations the box length will never change more
 than 1%.

 Berk

 Date: Tue, 24 Nov 2009 17:12:44 +0100
 Subject: Re: [gmx-users] Normalization in g_rdf
 From: ondrej.marsa...@gmail.com
 To: gmx-users@gromacs.org

 Hi again,

 I thought pressure coupling is handled by g_rdf. Looking at the code,
 it seems that the block starting with:

 /* Must init pbc every step because of pressure coupling */

 takes care of that, so even with a relatively big volume change at the
 beginning, it should not be a problem. Is that not the case?

 Ondrej


 On Tue, Nov 24, 2009 at 16:12, Berk Hess g...@hotmail.com wrote:
  Hi,
 
  g_rdf limits the distance to half the minimum periodic image distance.
  So the volume normalization is always simply  4 pi r^2.
  It uses the starting unit-cell with a factor of 0.99.
  So you would only see strange effects when the box length reduces
  more than 1% due to pressure coupling.
 
  Berk
 --
 gmx-users mailing list gmx-users@gromacs.org
 http://lists.gromacs.org/mailman/listinfo/gmx-users
 Please search the archive at http://www.gromacs.org/search before posting!
 Please don't post (un)subscribe requests to the list. Use the
 www interface or send it to gmx-users-requ...@gromacs.org.
 Can't post? Read http://www.gromacs.org/mailing_lists/users.php

 
 New Windows 7: Simplify what you do everyday. Find the right PC for you.
 --
 gmx-users mailing list    gmx-us...@gromacs.org
 http://lists.gromacs.org/mailman/listinfo/gmx-users
 Please search the archive at http://www.gromacs.org/search before posting!
 Please don't post (un)subscribe requests to the list. Use the
 www interface or send it to gmx-users-requ...@gromacs.org.
 Can't post? Read http://www.gromacs.org/mailing_lists/users.php

--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php


[gmx-users] Group Cl not found in indexfile

2009-11-24 Thread SHANG Yuan
Hi,gmx-users,
  I'm following Kerrigan's GROMACS Tutorial for Drug-Enzyme Complex, but
encounter with some problems(my GMX version is 4.0).
  firstly, after genion -s trp_b4ion.tpr -o trp_b4em.gro -nname Cl -nn 9
command, I add Cl 9 at the end of trp.top file, and the following
grompp command will always fail,complaining No such moleculetype
Cl,for GROMOS96,only CL- 9 work here.After correct this error, I go
on through this tutorial and come with a second problem
   Just after energy minimization, I type grompp -f em.mdp -c
trp_b4ion.gro -p trp.top -o trp_b4ion.tpr, the program
indicates:Group Cl not found in indexfile. I change the Cl in the
line tc_grps=protein sol IN4 Cl of pr.mdp file to CL or CL-,but
neither can fix this problem.
   would any kind spirit help?
   Thanks in advance.

Yuan SHANG


-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php


[gmx-users] Genbox

2009-11-24 Thread Lum Nforbi
Hello all,

   How long does it usually take genbox to run?

Thanks,

Lum
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php

[gmx-users] Continue simulation

2009-11-24 Thread Jack Shultz
Is it ok just to use tpbconv, even though we get this message
Continuation should be done by loading a checkpoint file with mdrun -cpi?

++

I have tried mdrun using the -cpi flag
mdrun -v -x -c -o -e -cpo next.cpt -cpi md.cpt -deffnm md

Then when I run the next using the next.cpt, it seems to do the next
time interval because it is actually taking time to compute timesteps

mdrun -v -x -c -o -e -cpo next2.cpt -cpi next.cpt -deffnm md

using the checkpoint, i get less standard output telling me the
tototal simulation time

while preping the mdrun using  tpbconv -s md.tpr -f md.trr -e md.edr
-time 2 -o next.tpr

I get this output.

starting mdrun 'Protein in water'
1500 steps,  3.0 ps (continuing from step 500,  1.0 ps).
step 500, will finish Wed Nov 25 00:15:43 2009
step 700, remaining runtime:   258 s

So should there be any difference in the results then?

-- 
Jack

http://drugdiscoveryathome.com
http://hydrogenathome.org
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php


Re: [gmx-users] Coulomb Interactions

2009-11-24 Thread Mark Abraham

nishap.pa...@utoronto.ca wrote:

Hi!

Does anyone know how I can turn off the coulomb interactions in the .mdp 
file? I tried to change the values of rcoulomb to 0, but it doesn't work.


There's no ready way to do this and it's normally not a sensible thing 
to do. Zeroing the charges in the .top file will work. rcoulomb == 0 has 
a different meaning, if you read section 7.3.


Mark
--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/mailing_lists/users.php


Re: [gmx-users] Continue simulation

2009-11-24 Thread Mark Abraham

Jack Shultz wrote:

Is it ok just to use tpbconv, even though we get this message
Continuation should be done by loading a checkpoint file with mdrun -cpi?


It depends on your objective, and you haven't told us enough about your 
.tpr and why your simulation stopped for us to know. See 
http://www.gromacs.org/Documentation/How-tos/Doing_Restarts and 
http://www.gromacs.org/Documentation/How-tos/Extending_Simulations


Mark


++

I have tried mdrun using the -cpi flag
mdrun -v -x -c -o -e -cpo next.cpt -cpi md.cpt -deffnm md

Then when I run the next using the next.cpt, it seems to do the next
time interval because it is actually taking time to compute timesteps

mdrun -v -x -c -o -e -cpo next2.cpt -cpi next.cpt -deffnm md

using the checkpoint, i get less standard output telling me the
tototal simulation time

while preping the mdrun using  tpbconv -s md.tpr -f md.trr -e md.edr
-time 2 -o next.tpr

I get this output.

starting mdrun 'Protein in water'
1500 steps,  3.0 ps (continuing from step 500,  1.0 ps).
step 500, will finish Wed Nov 25 00:15:43 2009
step 700, remaining runtime:   258 s

So should there be any difference in the results then?


--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/mailing_lists/users.php


Re: [gmx-users] Continue simulation

2009-11-24 Thread Justin A. Lemkul



Jack Shultz wrote:

Is it ok just to use tpbconv, even though we get this message
Continuation should be done by loading a checkpoint file with mdrun -cpi?



Please see the last paragraph in the Version 4 section here:

http://www.gromacs.org/Documentation/How-tos/Extending_Simulations


++

I have tried mdrun using the -cpi flag
mdrun -v -x -c -o -e -cpo next.cpt -cpi md.cpt -deffnm md

Then when I run the next using the next.cpt, it seems to do the next
time interval because it is actually taking time to compute timesteps

mdrun -v -x -c -o -e -cpo next2.cpt -cpi next.cpt -deffnm md

using the checkpoint, i get less standard output telling me the
tototal simulation time

while preping the mdrun using  tpbconv -s md.tpr -f md.trr -e md.edr
-time 2 -o next.tpr


This is the obsolete way to continue a simulation, i.e. version 3.3.3 and 
earlier.  Follow the instructions in the above link for version 4.


-Justin



I get this output.

starting mdrun 'Protein in water'
1500 steps,  3.0 ps (continuing from step 500,  1.0 ps).
step 500, will finish Wed Nov 25 00:15:43 2009
step 700, remaining runtime:   258 s

So should there be any difference in the results then?



--


Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin


--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/mailing_lists/users.php


[gmx-users] Re: How to make carbon nanotube infinite?

2009-11-24 Thread Cun Zhang
Thank you, Justin !

 I have add the output generated by grompp and mdrun at the end.


 Cun Zhang wrote:
  hi, Justin. Thank you for your patience !
 
  I'm still in trouble with infinite CNT simulation.
 
  I'm trying to simulate the interaction of  a infinite (16,0) CNT(CNT_A)
  with 832 atoms and water. I'm using x2top to generate the CNT.itp with
  share-bonds. The idea is that I generate a (16,0) CNT(CNT_B) with 960
  atoms ( more 4 layer  than CNT_A. Each layer has 32 atoms ).
  When I use CNT.itp generated by  CNT_A and x2top, it works. But when I
  use the CNT.itp which has share-bonds information, it can't work.
 
 
  The process I'm doing CNT simulation is as follows:
  # the CNT_new.pdb is a (16,0) CNT with 960 atoms.
  # I add the custom forcefield parameters to tmp.top, and change the
  number of a charge group to 32, then rename it CNT.itp at the end.
 
  x2top -f CNT_new.pdb -o tmp.top -ff gmx -nopbc -nopairs -noparam -name
  CNT
 
  bash sharebond_script   # create share bonds
 

 The script below is renumbering and removing atoms.  Why are you doing
 this?  I
 thought the purpose of CNT_new was to generate a larger structure?


I hope generate sharing bonds between the atoms at the top edge and the
atoms at the bottom edge of CNT by x2top. But the parameter -pbc does not
work. So I add 4 layers at the top of CNT.pdb and rename it CNT_new.pdb,
that is, the front 832 rows of them are same.

The  atoms of No. 833-960 in CNT_new.pdb can be seen the bottom 4 layers of
atoms of No.1-128 of CNT.pdb translated up a box hight. So after generating
the topology file and renaming atoms of No. 833-960 to No.1-128 in the
topology file (use the command 'x2top -nopbc') the topology file  of
CNT_new.pdb should be the same as the topology file of CNT.pdb with sharing
bonds (and angles, diherals) ( use the command 'x2top -pbc' ).

That's why I write that script.  Hope you understand what I mean. Of course,
The other reason is that I'm not familar with how to generate CNT's topology
file, so I use x2top to do it. That's easier relatively.



  editconf -f CNT.pdb -o -box 3.8 3.8 5.614
 

 Now you are manipulating CNT.pdb - is this the correct next step?  If this
 actually pertains to CNT_new.pdb, then the box size is insufficient to hold
 the
 larger structure.  But now I'm just confused as to what you're doing.


This is the information when I run this command. I think it's ok.

system size :  1.270  1.270  5.472 (nm)
center  : -0.000  0.000  2.736 (nm)
box vectors :  0.000  0.000  0.000 (nm)
box angles  :   0.00   0.00   0.00 (degrees)
box volume  :   0.00   (nm^3)
shift   :  1.900  1.900  0.071 (nm)
new center  :  1.900  1.900  2.807 (nm)
new box vectors :  3.800  3.800  5.614 (nm)
new box angles  :  90.00  90.00  90.00 (degrees)
new box volume  :  81.07   (nm^3)




  genbox -cp out -cs -p CNT -o b4em.pdb  #The simulation box size can be

  seen in b4em.pdb
 
  pymol b4em.pdb  #remove water. After editing it,I save it as b4em.pdb
  too.Now the information about box size is losing. I don't know why.I'm
  not familar with it :)
 
  editconf -f b4em.pdb -o b4em -box 3.8 3.8 5.614 # Add the information
  about box size
  vim CNT.top #change the number of water to make it the same as
 b4em.pdb
  grompp -f em -o em -c b4em -p CNT -maxwarn 5
  mpirun -np 4 mdrun_mpi -v -s em -e em -o em -c after_em

 Does energy minimization work?  What did the potential energy and maximum
 force
 converge to?  Again, what is the purpose of -maxwarn 5?  Are there errors
 that
 grompp is generating that you are simply trying to bypass?  This is
 generally a
 bad idea.


 Yes, EM work.
Steepest Descents converged to Fmax  1000 in 9 steps
Potential Energy  = -9.5444641e+04
Maximum force =  8.6610358e+02 on atom 832
Norm of force =  2.2713820e+02

There are two notes,no warnings,no errors when grompp.
When I run the MD,errors come:
50 steps,250.0 ps.
There were 64 inconsistent shifts. Check your topology
step 0
t = 0.003 ps: Water molecule starting at atom 7226 can not be settled.
Check for bad contacts and/or reduce the timestep.
Wrote pdb files with previous and current coordinates

t = 0.004 ps: Water molecule starting at atom 7217 can not be settled.
Check for bad contacts and/or reduce the timestep.
Wrote pdb files with previous and current coordinates

---
Program mdrun, VERSION 4.0.5
Source code file: ../../../../src/mdlib/nsgrid.c, line: 357

Range checking error:
Explanation: During neighborsearching, we assign each particle to a grid
based on its coordinates. If your system contains collisions or parameter
errors that give particles very high velocities you might end up with some
coordinates being +-Infinity or NaN (not-a-number). Obviously, we cannot
put these on a grid, so this is usually where we detect those errors.
Make sure your system is properly energy-minimized and that the potential
energy seems 

[gmx-users] Re: How to make carbon nanotube infinite?

2009-11-24 Thread Justin A. Lemkul



Cun Zhang wrote:

snip

I hope generate sharing bonds between the atoms at the top edge and the 
atoms at the bottom edge of CNT by x2top. But the parameter -pbc does 
not work. So I add 4 layers at the top of CNT.pdb and rename it 
CNT_new.pdb, that is, the front 832 rows of them are same. 
 
The  atoms of No. 833-960 in CNT_new.pdb can be seen the bottom 4 layers 
of atoms of No.1-128 of CNT.pdb translated up a box hight. So after 
generating the topology file and renaming atoms of No. 833-960 to 
No.1-128 in the topology file (use the command 'x2top -nopbc') the 
topology file  of CNT_new.pdb should be the same as the topology file of 
CNT.pdb with sharing bonds (and angles, diherals) ( use the command 
'x2top -pbc' ).




This still makes no sense to me at all.  You're creating duplicate atoms at one 
end of the structure to make them have the same atom numbers of those at the 
other end of the molecule?  Forgive my confusion, I simply don't know what 
you're doing.  The concept of bonding is not that parameters are shared, it is 
the following:


Consider atoms A and Z, residing at the ends of a CNT, as shown here (with 
vertical lines indicating the boundaries of the unit cell):


|   |
| A . . . . . . . Z |
|   |

You simply need to define a bond in the topology between A and Z, no renumbering 
or fancy tricks required, just add the bond to the [bonds] directive:


[ bonds ]
...
A Z 1

That gives the following:

|   |
|-A . . . . . . . Z-|
|   |

This bond then spans the periodic boundary.

I'm surprised the EM worked, but I am still unclear on your approach thus far.

snip


NOTE 1 [file CNT.top, line unknown]:
  The largest charge group contains 32 atoms.
  Since atoms only see each other when the centers of geometry of the charge
  groups they belong to are within the cut-off distance, too large charge
  groups can lead to serious cut-off artifacts.
  For efficiency and accuracy, charge group should consist of a few atoms.
  For all-atom force fields use: CH3, CH2, CH, NH2, NH, OH, CO2, CO, etc.



These notes are not simply printed for your entertainment.  If you have a 
32-atom charge group, you will have potentially severe artifacts, especially if 
you are using cutoff electrostatics, which you are (see additional comments 
below).  Please read in the manual about how to properly define charge groups.


snip


NOTE 2 [file em.mdp, line unknown]:
  You are using a plain Coulomb cut-off, which might produce artifacts.
  You might want to consider using PME electrostatics.



Again, heed the note.  I cannot think of a solid reason for a modern simulation 
being conducted using cutoff electrostatics, unless the goal is to prove that 
such a method is less accurate than a more modern technique like PME.  Again, 
these notes are your friend.  I see that they return during your PR attempts. 
You should not ignore the advice that grompp is giving you.  The artifacts of 
plain cutoffs are well-documented.


Several other resources to consider using:

http://www.gromacs.org/Documentation/How-tos/Carbon_Nanotube

http://www.gromacs.org/Documentation/Terminology/Blowing_Up

-Justin

--


Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin


--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/mailing_lists/users.php


Re: [gmx-users] Re: How to make carbon nanotube infinite?

2009-11-24 Thread Justin A. Lemkul



Justin A. Lemkul wrote:

snip


NOTE 2 [file em.mdp, line unknown]:
  You are using a plain Coulomb cut-off, which might produce artifacts.
  You might want to consider using PME electrostatics.


I also just noticed that you have not specified periodic_molecules = yes in 
the .mdp file.  This is certainly problematic, as your CNT will experience 
extreme repulsion at the box edges.


I also remembered something else to consider: in x2top from version 3.3.3, the 
-pbc option was functional.  You could perhaps use this version to create your 
initial topology to avoid all the manipulation after the fact.


-Justin

--


Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin


--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/mailing_lists/users.php