[gmx-users] pressure coupled systems explode

[aherz]

Hey,

I'm still working on the system where I pull two flexible diamod slabs in 
opposite
direction and study the distance dependent speed of the water in
between. I attached the mdp file below. The system is scaled extremely
in z and pressure looks wrong as well (see attached graph of both).
There are no errors or warning output during run.

Any ideas what could be going wrong here?

Thx,
Alex

<>

shear.mdp
Description: application/mdp
___
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] Is anyone also using lammps?s

[aherz]

Hey,

are you running single or double precision gromacs?
Afaik, depending on the circumstances the energy drift in gromacs can be
rather bad for single precision.

Alex


Peng Yi schrieb:
>
> On Wed, 28 Oct 2009, Mark Abraham wrote:
>
>> Peng Yi wrote:
>>>
>>> I am trying to simulate alkane melt and found out that gromacs and
>>> lammps gave different results, particularly the bonded interaction
>>> energy.
>>> I wonder if anyone has such experience.  Thanks,
>>
>> Even two installations of the same version of GROMACS can give
>> different results. The question is whether when using comparable
>> model physics you observe the same ensemble averages.
>>
>> Mark
>
> Hi, Mark,
>
> Thanks for reply!  The difference is statistically significant.  And I am
> wondering if it is caused by the integrator: Leap-frog for Gromacs and
> Velocity-verlet for Lammps.  Detail description of the comparison please
> see below:
>
> It is an NPT simulation of a melt of 240 n-octane molecules using
> united-atom model, i.e., CHx group is considered as one atom.  There are
> bond, angle, torsion and LJ interactions.  T=300K and P=1atm.
>
> Lammps uses nose-hoover thermostat and barostat, and Gromacs uses
> nose-hoover thermostat and Parranello-Rahman barostat.  Time constants
> for
> thermostat and barostat are 0.02ps and 2.0ps, respectively.
>
> If I use integration time 1fs, Lammps and Gromacs gave consistent
> results:
> Lammps   Gromacs
> Ebond(kJ/mol):2092 2146
> Eangle:   1757 1760
> Etors:2510 2500
> Elj+corr:-9238-9350
> Volume(nm^3): 66.7 66.5
>
> where energy fluctuation is 100 kJ/mol and volume fluctuation is 1 nm^3,
> Elj+corr is the total LJ energy including tail correction.
>
> However, if I use integration time 2fs, Lammps results do not change
> much, but Gromacs results changed a lot:
>
> Lammps   Gromacs
> Ebond(kJ/mol):2133 2700 Eangle:  
> 1799 1640
> Etors:2552 2200
> Elj+corr:-9292-9886 Volume:  
> 66.7 64.0
>
> The results given by Lammps is more reasonable because the Ebond should
> be equal to the total # of bonds times 1/2k_BT and Eangle should be equal
> to the total # of angles times 1/2k_BT.  At T=300K, 1/2k_BT=1.25 kJ/mol.
> 240 n-octanes have total 1680 bonds and 1440 angles.
>
> The bond and angle interactions are both harmonic functions.  Bond
> interaction constant kl=292880 kJ/mol/nm^2, corresponding to a bond
> ossilation period 16 fs.
>
> Is there something related to the integrator?
>
> Here I attached my grompp.mdp and topol.top files.
>
> ##
> grompp.mdp
> ##
>
> ; VARIOUS PREPROCESSING OPTIONS
> title= Yo
> cpp  = /usr/bin/cpp
> include  = define   =
>
> ; RUN CONTROL PARAMETERS
> integrator   = md
> tinit= 0
> dt   = 0.001
> nsteps   = 200
> init_step= 0
> comm-mode= Linear
> nstcomm  = 1
> comm-grps=
>
> ; OUTPUT CONTROL OPTIONS
> nstxout  = 5000
> nstvout  = 5000
> nstfout  = 5000
> nstcheckpoint= 1
> nstlog   = 1000
> nstenergy= 1000
> nstxtcout= 5000
> xtc-precision= 1000
> xtc-grps = energygrps   =
>
> ; NEIGHBORSEARCHING PARAMETERS
> nstlist  = 10
> ns_type  = grid
> pbc  = xyz
> rlist= 1.0025
> domain-decomposition = no
>
> ; OPTIONS FOR ELECTROSTATICS AND VDW
> coulombtype  = Cut-off
> rcoulomb-switch  = 0
> rcoulomb = 1.0025
> epsilon-r= 1
> vdw-type = Cut-off
> rvdw-switch  = 0; default rvdw
> = 1.0025; default 1 nm
> DispCorr = EnerPres
> ;table-extension  = 1.5
> fourierspacing   = 0.12
> fourier_nx   = 0
> fourier_ny   = 0
> fourier_nz   = 0
> pme_order= 4
> ewald_rtol   = 1e-05
> ewald_geometry   = 3d
> epsilon_surface  = 0
> optimize_fft = no
>
>
> ; OPTIONS FOR WEAK COUPLING ALGORITHMS
> Tcoupl   = nose-hoover
> tc-grps  = System
> tau_t= 0.02
> ref_t= 300.0
> Pcoupl   = Parrinello-Rahman
> Pcoupltype   = isotropic
> tau_p= 2.0
> compressibility  = 4.5e-5
> ref_p= 1.0
> andersen_seed= 815131
>
> ; GENERATE VELOCITIES FOR STARTUP RUN
> gen_vel   

Re: [gmx-users] direction_periodic

[aherz]

Hi,

thx for suggesting the workaround, just to make sure I understand the
workaround correctly:

I devide each slab in 2 sections, one section contains 90% of the atoms
(section A), the other the rest (section B).
Now I set the pbc_atom to the center atom of section A and pull it using
constraints?

Alex

Berk Hess schrieb:
> Hi,
>
> This is due to the periodicity issue of the COM calculation that I
> have mentioned before.
> The problem is that some atoms are at close to half a box length from
> the pbc_atom
> and those can jump back and forth between two periodic images in the
> distance calculations.
> This "noise" will make the constraint code crash, since it tries to
> correct for it immediately.
> The umbrella potential smooths this effect out somewhat and can
> therefore run stably,
> but you would still see the noise in the results.
>
> Fixing this is difficult, since it would require storing the periodic
> image of each atom
> in the pull group at the start of the simulation and determining the
> image for the COM
> calculation using the initial image. Also the checkpoint file should
> store the images.
> I would not like to put such code in the standard version.
>
> A workaround could be to pull on 90% of the slabs, leaving a part of
> 10% along x out.
> Then define the pbc_atom in the middle of the 90%. The 10% will just
> move along.
> This should solve your problem and should not produce artifacts.
>
> Berk
>
> > Date: Fri, 2 Oct 2009 10:25:21 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: Re: [gmx-users] direction_periodic
> >
> > You did suggest that, but it crashes at step 0, as said :)
> >
> > Alex
> >
> > Berk Hess schrieb:
> > > Hi,
> > >
> > > Then you should use constraint pulling instead of an umbrella
> potential.
> > > I have been wondering all the time why you are using a potential
> > > and not a constraint. I think I had suggested using a constraint some
> > > time ago, but I am not sure that I did.
> > >
> > > Berk
> > >
> > > > Date: Fri, 2 Oct 2009 09:45:42 +0200
> > > > From: alexander.h...@mytum.de
> > > > To: gmx-users@gromacs.org
> > > > Subject: Re: [gmx-users] direction_periodic
> > > >
> > > > Hey,
> > > >
> > > > I want to pull the diamonds with more or less exactly the speed
> I give
> > > > for the pulling without the massive noise
> > > > (in gromacs 3.3 this worked using afm type pulling, after some
> > > > equilibration the slabs settled to an almost constant
> > > > pull speed without soo much fluctuation using the same
> parameters I use
> > > > noew for umbrella).
> > > > So I tried using a constraint rather than umbrella, which alwas
> crashes
> > > > at the first step (even if I did some equilibration
> > > > using umbrella pulling beforehands).
> > > >
> > > > So how can I achieve a pull speed which is about constant 0.01
> nm/ps and
> > > > with fluctuations less than 10% of this speed?
> > > >
> > > > Thx,
> > > > Alex
> > > > ___
> > > > 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
> > >
> > >
> 
> > > See all the ways you can stay connected to friends and family
> > > 
> > >
> 
> > >
> > > ___
> > > 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
> >
> > ___
> > 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
>
> 
> What can you do with the new Windows Live? Find out
> 
> 
>
> ___
> gmx-users mailing listgmx-users@gromacs.org
> http:

Re: [gmx-users] direction_periodic

[aherz]

Hi,

did you look at the actual trajectory (trr/xtc) or the velocity of one
of the diamond slabs (using g_traj) ?
I do get a sawtooth style COM distance (pullx.xvg) but both the
veloc.xvg and the trajectory show that the slabs are not actually moving
much (the speed of the slab fluctuates wildly around 5e-3nm/ps in a
2500ps run when I'm pulling with 0.01nm/ps).

Alex

Berk Hess schrieb:
> Hi,
>
> I just ran a simulation with your input files.
> I only changed the geometry to direction_periodic and increased the
> rate to 0.1.
> The distance decreases linearly with a slight waviness due to the
> harmonic potential.
> The location of the reference group shows a sawtooth profile,
> as one would expect in a periodic system.
>
> So it seems to work fine for me.
>
> Berk
>
> > Date: Thu, 1 Oct 2009 10:24:54 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: Re: [gmx-users] direction_periodic
> >
> > Hey,
> >
> > did you find the time to look at it?
> >
> > Thx,
> > Alex
> >
> > Berk Hess schrieb:
> > > I am not sure I continued the simulation long enough.
> > > I'll run it again tomorrow.
> > >
> > > Berk
> > >
> > > > Date: Mon, 28 Sep 2009 16:57:19 +0200
> > > > From: alexander.h...@mytum.de
> > > > To: gmx-users@gromacs.org
> > > > Subject: Re: [gmx-users] direction_periodic
> > > >
> > > > Well..they do move forward for a few ps and then they move back
> (they
> > > > oscillate).
> > > > Did you check for a longer period?
> > > >
> > > > Alex
> > > >
> > > > Berk Hess schrieb:
> > > > > Strange...
> > > > > I tested the code on the files you sent me
> > > > > and the slabs were moving smoothly.
> > > > >
> > > > > Berk
> > > > >
> > > > > > Date: Mon, 28 Sep 2009 15:40:16 +0200
> > > > > > From: alexander.h...@mytum.de
> > > > > > To: gmx-users@gromacs.org
> > > > > > Subject: Re: [gmx-users] direction_periodic
> > > > > >
> > > > > > Hey,
> > > > > >
> > > > > > so using the new direction_periodic with some kernels that
> > > actually work
> > > > > > and the sources from the git (unmodified)
> > > > > > gives a nice smooth pull force but no actual mean displacement
> > > of the
> > > > > > groups to be pulled (on average they just stay where they
> are,see
> > > > > > attached graph). I'm still trying to pull them into opposite
> > > directions
> > > > > > though.
> > > > > >
> > > > > > I'm using this setup:
> > > > > > pull = umbrella
> > > > > > pull_geometry = direction_periodic
> > > > > > pull_ngroups = 1
> > > > > > pull_group0 = DIAM
> > > > > > pull_group1 = DIAM2
> > > > > > pulldim = Y N N
> > > > > > pull_k1 = 1000.0
> > > > > > pull_rate1 = 0.01
> > > > > > pull_vec1 = -1.0 0.0 0.0
> > > > > >
> > > > > > How can I make the two diamond slabs actually move in opposite
> > > > > > directions rather than just oscillating around their
> > > > > > initial positions?
> > > > > >
> > > > > > Thx,
> > > > > > Alex
> > > > > >
> > > > > > Berk Hess schrieb:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Don't use fortran.
> > > > > > > We will get rid of it before the 4.1 release.
> > > > > > >
> > > > > > > Berk
> > > > > > >
> > > > > > > > Date: Mon, 21 Sep 2009 16:17:17 +0200
> > > > > > > > From: alexander.h...@mytum.de
> > > > > > > > To: gmx-users@gromacs.org
> > > > > > > > Subject: Re: [gmx-users] direction_periodic
> > > > > > > >
> > > > > > > > Hey,
> > > > > > > >
> > > > > > > > ok, I checked this. It works ok with the assembly
> kernels on my
> > > > > local
> > > > > > > > machine, but it fails with fortran kernels
> > > > > > > > on the HPC and on my local machine.
> > > > > > > >
> > > > > > > > Alex
> > > > > > > >
> > > > > > > > Berk Hess schrieb:
> > > > > > > > > Yes.
> > > > > > > > >
> > > > > > > > > Berk
> > > > > > > > >
> > > > > > > > > > Date: Mon, 21 Sep 2009 14:42:43 +0200
> > > > > > > > > > From: alexander.h...@mytum.de
> > > > > > > > > > To: gmx-users@gromacs.org
> > > > > > > > > > Subject: Re: [gmx-users] direction_periodic
> > > > > > > > > >
> > > > > > > > > > With master branch you mean the code I get via
> > > > > > > > > >
> > > > > > > > > > |git clone git://git.gromacs.org/gromacs.git
> > > > > > > > > >
> > > > > > > > > > right?
> > > > > > > > > >
> > > > > > > > > > Alex
> > > > > > > > > > |
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Berk Hess schrieb:
> > > > > > > > > > > I tested on your system and got good results.
> > > > > > > > > > > There is still a tricky issue: the pull COM is still
> > > > > determined
> > > > > > > > > > > in the "standard" way by summing distances from the
> > > pbcatom.
> > > > > > > > > > > Therefore atoms should not change nearest image
> from he
> > > > > pbcatom.
> > > > > > > > > > > This would result in nasty noise in the pull COM and
> > > force.
> > > > > > > > > > >
> > > > > > > > > > > I would suggest that you try to run the master
> branch and
> > > > > check
> > > > > > > > > > > if that works.
> > > > > > > > > > >
> > > > > > > > > > > Ber

Re: [gmx-users] direction_periodic

[aherz]

Hey,

could you mail me the complete input files you are using for your test?
I'd like to compare them with the stuff I have to see what's wrong.

alexander.h...@mytum.de

Thx!

Berk Hess schrieb:
> Hi,
>
> I just ran a simulation with your input files.
> I only changed the geometry to direction_periodic and increased the
> rate to 0.1.
> The distance decreases linearly with a slight waviness due to the
> harmonic potential.
> The location of the reference group shows a sawtooth profile,
> as one would expect in a periodic system.
>
> So it seems to work fine for me.
>
> Berk
>
> > Date: Thu, 1 Oct 2009 10:24:54 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: Re: [gmx-users] direction_periodic
> >
> > Hey,
> >
> > did you find the time to look at it?
> >
> > Thx,
> > Alex
> >
> > Berk Hess schrieb:
> > > I am not sure I continued the simulation long enough.
> > > I'll run it again tomorrow.
> > >
> > > Berk
> > >
> > > > Date: Mon, 28 Sep 2009 16:57:19 +0200
> > > > From: alexander.h...@mytum.de
> > > > To: gmx-users@gromacs.org
> > > > Subject: Re: [gmx-users] direction_periodic
> > > >
> > > > Well..they do move forward for a few ps and then they move back
> (they
> > > > oscillate).
> > > > Did you check for a longer period?
> > > >
> > > > Alex
> > > >
> > > > Berk Hess schrieb:
> > > > > Strange...
> > > > > I tested the code on the files you sent me
> > > > > and the slabs were moving smoothly.
> > > > >
> > > > > Berk
> > > > >
> > > > > > Date: Mon, 28 Sep 2009 15:40:16 +0200
> > > > > > From: alexander.h...@mytum.de
> > > > > > To: gmx-users@gromacs.org
> > > > > > Subject: Re: [gmx-users] direction_periodic
> > > > > >
> > > > > > Hey,
> > > > > >
> > > > > > so using the new direction_periodic with some kernels that
> > > actually work
> > > > > > and the sources from the git (unmodified)
> > > > > > gives a nice smooth pull force but no actual mean displacement
> > > of the
> > > > > > groups to be pulled (on average they just stay where they
> are,see
> > > > > > attached graph). I'm still trying to pull them into opposite
> > > directions
> > > > > > though.
> > > > > >
> > > > > > I'm using this setup:
> > > > > > pull = umbrella
> > > > > > pull_geometry = direction_periodic
> > > > > > pull_ngroups = 1
> > > > > > pull_group0 = DIAM
> > > > > > pull_group1 = DIAM2
> > > > > > pulldim = Y N N
> > > > > > pull_k1 = 1000.0
> > > > > > pull_rate1 = 0.01
> > > > > > pull_vec1 = -1.0 0.0 0.0
> > > > > >
> > > > > > How can I make the two diamond slabs actually move in opposite
> > > > > > directions rather than just oscillating around their
> > > > > > initial positions?
> > > > > >
> > > > > > Thx,
> > > > > > Alex
> > > > > >
> > > > > > Berk Hess schrieb:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Don't use fortran.
> > > > > > > We will get rid of it before the 4.1 release.
> > > > > > >
> > > > > > > Berk
> > > > > > >
> > > > > > > > Date: Mon, 21 Sep 2009 16:17:17 +0200
> > > > > > > > From: alexander.h...@mytum.de
> > > > > > > > To: gmx-users@gromacs.org
> > > > > > > > Subject: Re: [gmx-users] direction_periodic
> > > > > > > >
> > > > > > > > Hey,
> > > > > > > >
> > > > > > > > ok, I checked this. It works ok with the assembly
> kernels on my
> > > > > local
> > > > > > > > machine, but it fails with fortran kernels
> > > > > > > > on the HPC and on my local machine.
> > > > > > > >
> > > > > > > > Alex
> > > > > > > >
> > > > > > > > Berk Hess schrieb:
> > > > > > > > > Yes.
> > > > > > > > >
> > > > > > > > > Berk
> > > > > > > > >
> > > > > > > > > > Date: Mon, 21 Sep 2009 14:42:43 +0200
> > > > > > > > > > From: alexander.h...@mytum.de
> > > > > > > > > > To: gmx-users@gromacs.org
> > > > > > > > > > Subject: Re: [gmx-users] direction_periodic
> > > > > > > > > >
> > > > > > > > > > With master branch you mean the code I get via
> > > > > > > > > >
> > > > > > > > > > |git clone git://git.gromacs.org/gromacs.git
> > > > > > > > > >
> > > > > > > > > > right?
> > > > > > > > > >
> > > > > > > > > > Alex
> > > > > > > > > > |
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Berk Hess schrieb:
> > > > > > > > > > > I tested on your system and got good results.
> > > > > > > > > > > There is still a tricky issue: the pull COM is still
> > > > > determined
> > > > > > > > > > > in the "standard" way by summing distances from the
> > > pbcatom.
> > > > > > > > > > > Therefore atoms should not change nearest image
> from he
> > > > > pbcatom.
> > > > > > > > > > > This would result in nasty noise in the pull COM and
> > > force.
> > > > > > > > > > >
> > > > > > > > > > > I would suggest that you try to run the master
> branch and
> > > > > check
> > > > > > > > > > > if that works.
> > > > > > > > > > >
> > > > > > > > > > > Berk
> > > > > > > > > > >
> > > > > > > > > > > > Date: Mon, 21 Sep 2009 14:31:34 +0200
> > > > > > > > > > > > From: alexander.h...@mytum.de
> > > > > > > > > > > > To: gmx-users@gromacs.org
> >

Re: [gmx-users] direction_periodic

[aherz]

Hey,

did you find the time to look at it?

Thx,
Alex

Berk Hess schrieb:
> I am not sure I continued the simulation long enough.
> I'll run it again tomorrow.
>
> Berk
>
> > Date: Mon, 28 Sep 2009 16:57:19 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: Re: [gmx-users] direction_periodic
> >
> > Well..they do move forward for a few ps and then they move back (they
> > oscillate).
> > Did you check for a longer period?
> >
> > Alex
> >
> > Berk Hess schrieb:
> > > Strange...
> > > I tested the code on the files you sent me
> > > and the slabs were moving smoothly.
> > >
> > > Berk
> > >
> > > > Date: Mon, 28 Sep 2009 15:40:16 +0200
> > > > From: alexander.h...@mytum.de
> > > > To: gmx-users@gromacs.org
> > > > Subject: Re: [gmx-users] direction_periodic
> > > >
> > > > Hey,
> > > >
> > > > so using the new direction_periodic with some kernels that
> actually work
> > > > and the sources from the git (unmodified)
> > > > gives a nice smooth pull force but no actual mean displacement
> of the
> > > > groups to be pulled (on average they just stay where they are,see
> > > > attached graph). I'm still trying to pull them into opposite
> directions
> > > > though.
> > > >
> > > > I'm using this setup:
> > > > pull = umbrella
> > > > pull_geometry = direction_periodic
> > > > pull_ngroups = 1
> > > > pull_group0 = DIAM
> > > > pull_group1 = DIAM2
> > > > pulldim = Y N N
> > > > pull_k1 = 1000.0
> > > > pull_rate1 = 0.01
> > > > pull_vec1 = -1.0 0.0 0.0
> > > >
> > > > How can I make the two diamond slabs actually move in opposite
> > > > directions rather than just oscillating around their
> > > > initial positions?
> > > >
> > > > Thx,
> > > > Alex
> > > >
> > > > Berk Hess schrieb:
> > > > > Hi,
> > > > >
> > > > > Don't use fortran.
> > > > > We will get rid of it before the 4.1 release.
> > > > >
> > > > > Berk
> > > > >
> > > > > > Date: Mon, 21 Sep 2009 16:17:17 +0200
> > > > > > From: alexander.h...@mytum.de
> > > > > > To: gmx-users@gromacs.org
> > > > > > Subject: Re: [gmx-users] direction_periodic
> > > > > >
> > > > > > Hey,
> > > > > >
> > > > > > ok, I checked this. It works ok with the assembly kernels on my
> > > local
> > > > > > machine, but it fails with fortran kernels
> > > > > > on the HPC and on my local machine.
> > > > > >
> > > > > > Alex
> > > > > >
> > > > > > Berk Hess schrieb:
> > > > > > > Yes.
> > > > > > >
> > > > > > > Berk
> > > > > > >
> > > > > > > > Date: Mon, 21 Sep 2009 14:42:43 +0200
> > > > > > > > From: alexander.h...@mytum.de
> > > > > > > > To: gmx-users@gromacs.org
> > > > > > > > Subject: Re: [gmx-users] direction_periodic
> > > > > > > >
> > > > > > > > With master branch you mean the code I get via
> > > > > > > >
> > > > > > > > |git clone git://git.gromacs.org/gromacs.git
> > > > > > > >
> > > > > > > > right?
> > > > > > > >
> > > > > > > > Alex
> > > > > > > > |
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Berk Hess schrieb:
> > > > > > > > > I tested on your system and got good results.
> > > > > > > > > There is still a tricky issue: the pull COM is still
> > > determined
> > > > > > > > > in the "standard" way by summing distances from the
> pbcatom.
> > > > > > > > > Therefore atoms should not change nearest image from he
> > > pbcatom.
> > > > > > > > > This would result in nasty noise in the pull COM and
> force.
> > > > > > > > >
> > > > > > > > > I would suggest that you try to run the master branch and
> > > check
> > > > > > > > > if that works.
> > > > > > > > >
> > > > > > > > > Berk
> > > > > > > > >
> > > > > > > > > > Date: Mon, 21 Sep 2009 14:31:34 +0200
> > > > > > > > > > From: alexander.h...@mytum.de
> > > > > > > > > > To: gmx-users@gromacs.org
> > > > > > > > > > Subject: [gmx-users] direction_periodic
> > > > > > > > > >
> > > > > > > > > > Hey,
> > > > > > > > > >
> > > > > > > > > > after some pain of merging the dev branch into our 4.0.5
> > > version
> > > > > > > I got
> > > > > > > > > > the new pull mode "direction_periodic"
> > > > > > > > > > running over the weekend. There's some weird
> rotation of the
> > > > > pulled
> > > > > > > > > > objects going on and pbc seem weird as well (there
> are water
> > > > > > > molecules
> > > > > > > > > > in those positions where I'd expect the periodic
> image of my
> > > > > diamond
> > > > > > > > > > slab which leaves the box at one side). I guess you
> > > tested the
> > > > > > > new pull
> > > > > > > > > > mode somehow, so any ideas what's going on here? I'm
> still
> > > > > trying to
> > > > > > > > > > perform the same experiment for which I send you the
> > > input files
> > > > > > > while
> > > > > > > > > > ago and for which you kindly implemented the new
> pull mode.
> > > > > > > > > >
> > > > > > > > > > Thx for your help,
> > > > > > > > > > Alex
> > > > > > > > > >
> > > > > > > > > > Berk Hess schrieb:
> > > > > > > > > > > I have committed a new pull geometry
> direction_periodic to
> > > > > the git
> > > > > > > >

Re: [gmx-users] direction_periodic

[aherz]

Well..they do move forward for a few ps and then they move back (they
oscillate).
Did you check for a longer period?

Alex

Berk Hess schrieb:
> Strange...
> I tested the code on the files you sent me
> and the slabs were moving smoothly.
>
> Berk
>
> > Date: Mon, 28 Sep 2009 15:40:16 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: Re: [gmx-users] direction_periodic
> >
> > Hey,
> >
> > so using the new direction_periodic with some kernels that actually work
> > and the sources from the git (unmodified)
> > gives a nice smooth pull force but no actual mean displacement of the
> > groups to be pulled (on average they just stay where they are,see
> > attached graph). I'm still trying to pull them into opposite directions
> > though.
> >
> > I'm using this setup:
> > pull = umbrella
> > pull_geometry = direction_periodic
> > pull_ngroups = 1
> > pull_group0 = DIAM
> > pull_group1 = DIAM2
> > pulldim = Y N N
> > pull_k1 = 1000.0
> > pull_rate1 = 0.01
> > pull_vec1 = -1.0 0.0 0.0
> >
> > How can I make the two diamond slabs actually move in opposite
> > directions rather than just oscillating around their
> > initial positions?
> >
> > Thx,
> > Alex
> >
> > Berk Hess schrieb:
> > > Hi,
> > >
> > > Don't use fortran.
> > > We will get rid of it before the 4.1 release.
> > >
> > > Berk
> > >
> > > > Date: Mon, 21 Sep 2009 16:17:17 +0200
> > > > From: alexander.h...@mytum.de
> > > > To: gmx-users@gromacs.org
> > > > Subject: Re: [gmx-users] direction_periodic
> > > >
> > > > Hey,
> > > >
> > > > ok, I checked this. It works ok with the assembly kernels on my
> local
> > > > machine, but it fails with fortran kernels
> > > > on the HPC and on my local machine.
> > > >
> > > > Alex
> > > >
> > > > Berk Hess schrieb:
> > > > > Yes.
> > > > >
> > > > > Berk
> > > > >
> > > > > > Date: Mon, 21 Sep 2009 14:42:43 +0200
> > > > > > From: alexander.h...@mytum.de
> > > > > > To: gmx-users@gromacs.org
> > > > > > Subject: Re: [gmx-users] direction_periodic
> > > > > >
> > > > > > With master branch you mean the code I get via
> > > > > >
> > > > > > |git clone git://git.gromacs.org/gromacs.git
> > > > > >
> > > > > > right?
> > > > > >
> > > > > > Alex
> > > > > > |
> > > > > >
> > > > > >
> > > > > >
> > > > > > Berk Hess schrieb:
> > > > > > > I tested on your system and got good results.
> > > > > > > There is still a tricky issue: the pull COM is still
> determined
> > > > > > > in the "standard" way by summing distances from the pbcatom.
> > > > > > > Therefore atoms should not change nearest image from he
> pbcatom.
> > > > > > > This would result in nasty noise in the pull COM and force.
> > > > > > >
> > > > > > > I would suggest that you try to run the master branch and
> check
> > > > > > > if that works.
> > > > > > >
> > > > > > > Berk
> > > > > > >
> > > > > > > > Date: Mon, 21 Sep 2009 14:31:34 +0200
> > > > > > > > From: alexander.h...@mytum.de
> > > > > > > > To: gmx-users@gromacs.org
> > > > > > > > Subject: [gmx-users] direction_periodic
> > > > > > > >
> > > > > > > > Hey,
> > > > > > > >
> > > > > > > > after some pain of merging the dev branch into our 4.0.5
> version
> > > > > I got
> > > > > > > > the new pull mode "direction_periodic"
> > > > > > > > running over the weekend. There's some weird rotation of the
> > > pulled
> > > > > > > > objects going on and pbc seem weird as well (there are water
> > > > > molecules
> > > > > > > > in those positions where I'd expect the periodic image of my
> > > diamond
> > > > > > > > slab which leaves the box at one side). I guess you
> tested the
> > > > > new pull
> > > > > > > > mode somehow, so any ideas what's going on here? I'm still
> > > trying to
> > > > > > > > perform the same experiment for which I send you the
> input files
> > > > > while
> > > > > > > > ago and for which you kindly implemented the new pull mode.
> > > > > > > >
> > > > > > > > Thx for your help,
> > > > > > > > Alex
> > > > > > > >
> > > > > > > > Berk Hess schrieb:
> > > > > > > > > I have committed a new pull geometry direction_periodic to
> > > the git
> > > > > > > > > master branch. It is not documented yet.
> > > > > > > > > It works the same at direction, but allows distances to be
> > > larger
> > > > > > > > > than half the box and does not add the pull force to the
> > > virial.
> > > > > > > > >
> > > > > > > > > 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
> > > > > > >
> > > > > > >
> > > > >
> > >
> --

Re: [gmx-users] direction_periodic

[aherz]

Hey,

so using the new direction_periodic with some kernels that actually work
and the sources from the git (unmodified)
gives a nice smooth pull force but no actual mean displacement of the
groups to be pulled (on average they just stay where they are,see
attached graph). I'm still trying to pull them into opposite directions
though.

I'm using this setup:
pull= umbrella
pull_geometry   = direction_periodic
pull_ngroups = 1
pull_group0  = DIAM
pull_group1  = DIAM2
pulldim = Y N N
pull_k1  = 1000.0
pull_rate1   = 0.01
pull_vec1= -1.0 0.0 0.0

How can I make the two diamond slabs actually move in opposite
directions rather than just oscillating around their
initial positions?

Thx,
Alex

Berk Hess schrieb:
> Hi,
>
> Don't use fortran.
> We will get rid of it before the 4.1 release.
>
> Berk
>
> > Date: Mon, 21 Sep 2009 16:17:17 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: Re: [gmx-users] direction_periodic
> >
> > Hey,
> >
> > ok, I checked this. It works ok with the assembly kernels on my local
> > machine, but it fails with fortran kernels
> > on the HPC and on my local machine.
> >
> > Alex
> >
> > Berk Hess schrieb:
> > > Yes.
> > >
> > > Berk
> > >
> > > > Date: Mon, 21 Sep 2009 14:42:43 +0200
> > > > From: alexander.h...@mytum.de
> > > > To: gmx-users@gromacs.org
> > > > Subject: Re: [gmx-users] direction_periodic
> > > >
> > > > With master branch you mean the code I get via
> > > >
> > > > |git clone git://git.gromacs.org/gromacs.git
> > > >
> > > > right?
> > > >
> > > > Alex
> > > > |
> > > >
> > > >
> > > >
> > > > Berk Hess schrieb:
> > > > > I tested on your system and got good results.
> > > > > There is still a tricky issue: the pull COM is still determined
> > > > > in the "standard" way by summing distances from the pbcatom.
> > > > > Therefore atoms should not change nearest image from he pbcatom.
> > > > > This would result in nasty noise in the pull COM and force.
> > > > >
> > > > > I would suggest that you try to run the master branch and check
> > > > > if that works.
> > > > >
> > > > > Berk
> > > > >
> > > > > > Date: Mon, 21 Sep 2009 14:31:34 +0200
> > > > > > From: alexander.h...@mytum.de
> > > > > > To: gmx-users@gromacs.org
> > > > > > Subject: [gmx-users] direction_periodic
> > > > > >
> > > > > > Hey,
> > > > > >
> > > > > > after some pain of merging the dev branch into our 4.0.5 version
> > > I got
> > > > > > the new pull mode "direction_periodic"
> > > > > > running over the weekend. There's some weird rotation of the
> pulled
> > > > > > objects going on and pbc seem weird as well (there are water
> > > molecules
> > > > > > in those positions where I'd expect the periodic image of my
> diamond
> > > > > > slab which leaves the box at one side). I guess you tested the
> > > new pull
> > > > > > mode somehow, so any ideas what's going on here? I'm still
> trying to
> > > > > > perform the same experiment for which I send you the input files
> > > while
> > > > > > ago and for which you kindly implemented the new pull mode.
> > > > > >
> > > > > > Thx for your help,
> > > > > > Alex
> > > > > >
> > > > > > Berk Hess schrieb:
> > > > > > > I have committed a new pull geometry direction_periodic to
> the git
> > > > > > > master branch. It is not documented yet.
> > > > > > > It works the same at direction, but allows distances to be
> larger
> > > > > > > than half the box and does not add the pull force to the
> virial.
> > > > > > >
> > > > > > > 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
> > > > >
> > > > >
> > >
> 
> > > > > Express yourself instantly with MSN Messenger! MSN Messenger
> > > > > 
> > > > >
> > >
> 
> > > > >
> > > > > ___
> > > > > 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
> > > >
> > > > ___
> > > > gmx-users mailing list gmx-users@gromacs.org
> > > > htt

Re: [gmx-users] Re: help with gmx C source code

[aherz]

You will have to set the right environment variable for CFLAGS to get
debug symbols:


cd gromacs_directory
CFLAGS="-O0 -g3"
./configure

might do the trick.

you can use gdb to check whether there are debug symbols in an executable.

Alex


Inon Sharony schrieb:
>
> reply to:
> http://lists.gromacs.org/pipermail/gmx-users/2009-September/045006.html
>
>
> "...
> My usual advice is to compile GROMACS with -g, get a graphical
> debugger(Totalview, ddd, insight, whatever) and spend a day stepping
> through ashort mdrun to get some understanding about what is really
> happening.
> You will find it simpler if you've set the environment
> variableGMX_NB_GENERIC=1 so that the nonbonded kernels are more
> transparent.
> ..."
>
>
>
>
> Dear Mark and other GMX users,
>
> I've been trying to compile GMX for debugging, as you suggested, and
> itappears that I'm not doing it correctly. I've added the "-g" flag
> onthe "make" command's "CFLAGS" variable, and the installation seemed
> tohave completed successfully, however when I try to preform some
> simpledebugging (suggested
> byhttp://www.gromacs.org/Developer_Zone/Programming_Guide/Programmers%27s_Guide)I
> get error messages.
> I've included the commands I ran for the installation of gromacs
> withdebugging enabled, and the debugging commands I issued and their
> result.
>
>
>
> A. *
> fftw-3.2.2 installation:
> 
>
> ./configure
> make
> make install
>
>
> B. 
>
> gromacs-4.0.5 installation in double-precission
> ---
>
> ./configure --disable-float
> make CFLAGS=-g
> make install
>
>
> C. *
>
> "cat /tmp/gdb_cmds":
> 
>
> break _gmx_error
> break do_force
> run -v
>
>
> D. **
>
> "gdb -x gdb_cmds /usr/bin/mdrun":
> -
>
> GNU gdb 6.8-debian
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i486-linux-gnu"...
> (no debugging symbols found)
> Function "_gmx_error" not defined.
> Make breakpoint pending on future shared library load? (y or [n])
> [answered N; input not
> from terminal]
> Function "do_force" not defined.
> Make breakpoint pending on future shared library load? (y or [n])
> [answered N; input not
> from terminal]
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> [Thread debugging using libthread_db enabled]
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
>
> --
> Inon   Sharony
> ינון שרוני
> +972(3)6407634
> atto.TAU.ac.IL/~inonshar
> Please consider your environmental responsibility before printing this
> e-mail.
>
> 
>
> ___
> 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

Re: [gmx-users] direction_periodic

[aherz]

Hey,

ok, I checked this. It works ok with the assembly kernels on my local
machine, but it fails with fortran kernels
on the HPC and on my local machine.

Alex

Berk Hess schrieb:
> Yes.
>
> Berk
>
> > Date: Mon, 21 Sep 2009 14:42:43 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: Re: [gmx-users] direction_periodic
> >
> > With master branch you mean the code I get via
> >
> > |git clone git://git.gromacs.org/gromacs.git
> >
> > right?
> >
> > Alex
> > |
> >
> >
> >
> > Berk Hess schrieb:
> > > I tested on your system and got good results.
> > > There is still a tricky issue: the pull COM is still determined
> > > in the "standard" way by summing distances from the pbcatom.
> > > Therefore atoms should not change nearest image from he pbcatom.
> > > This would result in nasty noise in the pull COM and force.
> > >
> > > I would suggest that you try to run the master branch and check
> > > if that works.
> > >
> > > Berk
> > >
> > > > Date: Mon, 21 Sep 2009 14:31:34 +0200
> > > > From: alexander.h...@mytum.de
> > > > To: gmx-users@gromacs.org
> > > > Subject: [gmx-users] direction_periodic
> > > >
> > > > Hey,
> > > >
> > > > after some pain of merging the dev branch into our 4.0.5 version
> I got
> > > > the new pull mode "direction_periodic"
> > > > running over the weekend. There's some weird rotation of the pulled
> > > > objects going on and pbc seem weird as well (there are water
> molecules
> > > > in those positions where I'd expect the periodic image of my diamond
> > > > slab which leaves the box at one side). I guess you tested the
> new pull
> > > > mode somehow, so any ideas what's going on here? I'm still trying to
> > > > perform the same experiment for which I send you the input files
> while
> > > > ago and for which you kindly implemented the new pull mode.
> > > >
> > > > Thx for your help,
> > > > Alex
> > > >
> > > > Berk Hess schrieb:
> > > > > I have committed a new pull geometry direction_periodic to the git
> > > > > master branch. It is not documented yet.
> > > > > It works the same at direction, but allows distances to be larger
> > > > > than half the box and does not add the pull force to the virial.
> > > > >
> > > > > 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
> > >
> > >
> 
> > > Express yourself instantly with MSN Messenger! MSN Messenger
> > > 
> > >
> 
> > >
> > > ___
> > > 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
> >
> > ___
> > 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
>
> 
> Express yourself instantly with MSN Messenger! MSN Messenger
> 
> 
>
> ___
> 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

Re: [gmx-users] direction_periodic

[aherz]

With master branch you mean the code I get via

|git clone git://git.gromacs.org/gromacs.git

right?

Alex
|



Berk Hess schrieb:
> I tested on your system and got good results.
> There is still a tricky issue: the pull COM is still determined
> in the "standard" way by summing distances from the pbcatom.
> Therefore atoms should not change nearest image from he pbcatom.
> This would result in nasty noise in the pull COM and force.
>
> I would suggest that you try to run the master branch and check
> if that works.
>
> Berk
>
> > Date: Mon, 21 Sep 2009 14:31:34 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: [gmx-users] direction_periodic
> >
> > Hey,
> >
> > after some pain of merging the dev branch into our 4.0.5 version I got
> > the new pull mode "direction_periodic"
> > running over the weekend. There's some weird rotation of the pulled
> > objects going on and pbc seem weird as well (there are water molecules
> > in those positions where I'd expect the periodic image of my diamond
> > slab which leaves the box at one side). I guess you tested the new pull
> > mode somehow, so any ideas what's going on here? I'm still trying to
> > perform the same experiment for which I send you the input files while
> > ago and for which you kindly implemented the new pull mode.
> >
> > Thx for your help,
> > Alex
> >
> > Berk Hess schrieb:
> > > I have committed a new pull geometry direction_periodic to the git
> > > master branch. It is not documented yet.
> > > It works the same at direction, but allows distances to be larger
> > > than half the box and does not add the pull force to the virial.
> > >
> > > 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
>
> 
> Express yourself instantly with MSN Messenger! MSN Messenger
> 
> 
>
> ___
> 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

[gmx-users] direction_periodic

[aherz]

Hey,

after some pain of merging the dev branch into our 4.0.5 version I got
the new pull mode "direction_periodic"
running over the weekend. There's some weird rotation of the pulled
objects going on and pbc seem weird as well (there are water molecules
in those positions where I'd expect the periodic image of my diamond
slab which leaves the box at one side). I guess you tested the new pull
mode somehow, so any ideas what's going on here? I'm still trying to
perform the same experiment for which I send you the input files while
ago and for which you kindly implemented the new pull mode.

Thx for your help,
Alex

Berk Hess schrieb:
> I have committed a new pull geometry direction_periodic to the git
> master branch. It is not documented yet.
> It works the same at direction, but allows distances to be larger
> than half the box and does not add the pull force to the virial.
>
> 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] generation of kernels

[aherz]

actually it's the other way around,
it should be

"nb_kernel410_f77_single.h"

but the c file contains

"nbkernel410_f77_single.h"

Alex


aherz schrieb:
> Hi,
>
> I'm having some problems compiling the latest development build from the
> git using fortran kernels.
> The nb_kernel_f77_single.c file includes lot's of headers which are
> incorrect
> (e.g. "nb_kernel410_f77_single.h") the proper file name has no underline
> after nb
> ("nbkernel410_f77_single.h"). I tried to fix this by hand in the c file
> but apparently the
> kernel sources are generated somehow (so my changes are overwritten).
> How can I fix this?
>
> Thx,
> Alex
> ___
> 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

[gmx-users] generation of kernels

[aherz]

Hi,

I'm having some problems compiling the latest development build from the
git using fortran kernels.
The nb_kernel_f77_single.c file includes lot's of headers which are
incorrect
(e.g. "nb_kernel410_f77_single.h") the proper file name has no underline
after nb
("nbkernel410_f77_single.h"). I tried to fix this by hand in the c file
but apparently the
kernel sources are generated somehow (so my changes are overwritten).
How can I fix this?

Thx,
Alex
___
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] non isotropic kinetic energy

[aherz]

)
> > > > -type of constraint algo for water (so lincs, shake or settle, we
> > > > modified the spc/e water molec definition to change this)
> > > > -changing system size so that the box length is equal in all 3
> dim (as
> > > > said, magnifies problem)
> > > > -rotating system (error rotates with system)
> > > > -use smaller time step of 1fs (no difference)
> > > >
> > > > We ran a simulation with flexible water (so bonds instead of
> > > > constraints) , here the error vanishes!
> > > > Also, we ran similar sims with amber, where the error does not
> appear at
> > > > all (for constraint water).
> > > >
> > > > We found out about this problem while doing surface tension/contact
> > > > angle calculations.
> > > > The surf tens calced via virial differs from the surf tens
> calculated
> > > > via pressure tensor (unless one corrects
> > > > for the anisotropic kinetic energy). A simple way to see the
> deficit is
> > > > trying to calc the average pressure tensor from the average virial
> > > > tensor (using the simple def from the gromacs manual
> > > P_ij=2/V(Ekin-Vir_ij):
> > > > a) assuming equidistributed kinetic energy (ekin/3 per dim)
> > > > b) using the anisotropic ekin which can be extracted from a trr
> with a
> > > > tool (source attached) if velocities have been written to the trr.
> > > >
> > > > All this appears to hint at a problem with the constraints for the
> > > > waters and might also hint at an incorrect ensemble as a
> consequence.
> > > >
> > > > Alex
> > > >
> > > > sample input file (several variants of this file have been used):
> > > >
> > > > title = pure water
> > > > cpp = /usr/bin/cpp
> > > > integrator = md
> > > > nsteps = 250
> > > > nstlist = 50
> > > > nstxout = 1000
> > > > nstvout = 1000
> > > > nstlog = 1000
> > > > dt = 0.002
> > > > nstcomm = 200
> > > > comm-mode = linear
> > > > constraints = h-bonds
> > > > nstenergy = 100
> > > > ns_type = grid
> > > > coulombtype = pme
> > > > fourierspacing = 0.12
> > > > pme_order = 4
> > > > rlist = 0.9
> > > > rvdw = 0.9
> > > > rcoulomb = 0.9
> > > > tcoupl = Berendsen
> > > > tc_grps = SOL
> > > > energygrps = SOL
> > > > tau_t = 0.4
> > > > ref_t = 300
> > > >
> > > >
> > > >
> > > > David van der Spoel schrieb:
> > > > > aherz wrote:
> > > > >> Hi,
> > > > >>
> > > > >> we're running simulations of a water slab sandwiched by vacuum
> > > (ca. 2k
> > > > >> waters, 3x3x12 nm^3 box) in NVT
> > > > >> and look at the pressure tensor. We are surprised to find
> that the
> > > > >> kinetic energy is equivalent (within statistical uncertainty) for
> > > x and
> > > > >> y dim(parallel to the interface) but not in z dim. This
> appears to
> > > > >> violate the equipartition theorem?
> > > > >>
> > > > >> This is gromacs 3.0 and 4.0 using berendsen thermostat.
> > > > >
> > > > > First, try it with a real thermostat, second please report some
> > > numbers.
> > > > >
> > > > >>
> > > > >> Alex
> > > > >> ___
> > > > >> 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
> > > > >
> > > > >
> > > >
> > >
> > >
> 
> > > See all the ways you can stay connected to friends and family
> > > <http://www.microsoft.com/windows/windowslive/default.aspx>
> > >
> ---

Re: [gmx-users] non isotropic kinetic energy

[aherz]

Hm,

apparently there are constraint algorithms which don't change the ensemble
(e.g. http://www.informaworld.com/smpp/content~db=all~content=a750934359).
The equipartition theorem requires that the energy depends on
no other powers of v but v^2
(http://www.whfreeman.com/modphysics/PDF/8-2c.pdf)
 which should be the case for the md systems including constraints
(lj pot and estatic only depend on the particles' positions). So as far
as I can see the
equipartition theorem should hold in td equilibrum for these systems. So
the constraints
might modify the ensemble which could lead to all kinds of trouble?

The water molecules at the interface are oriented but taking the above
paragraph into
account this shouldn't cause any trouble.

By the way,
did you find a chance to look at the pulling problem we discussed before
last week?

Thx,
Alex


Berk Hess schrieb:
> I have been looking at very similar things recently.
>
> Your result could actually be correct.
> If the water orders at the interface you should have a difference
> in Ekin components, since the constraints, which remove kinetic energy
> are not ordered isotropically in space.
> You should be able to quantify this by looking at the order of the water
> normal.
>
> Berk
>
> > Date: Thu, 10 Sep 2009 18:11:16 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org; felix.sedlme...@ph.tum.de
> > Subject: Re: [gmx-users] non isotropic kinetic energy
> > CC:
> >
> > Hi,
> >
> > we took a couple of days to reexamine this and try out a couple of
> things:
> >
> > -On small interfacial systems (ca. 2k spc/e water molecules sandwiched
> > by vacuum)
> > the difference between ekin_x/y and ekin_z is 20 to 60kJ/mol depending
> > on the specific system/settings
> > (e.g. see attached file of averaged ekin (x/y/z) over time).
> > -On larger interfacial systems the difference grows (up to several
> > 100kJ/mol for ca. 32k spc/e water).
> >
> > The following settings make no difference (so the error persists even if
> > we change the setting):
> > -thermostat (we tryed nose-hoover, berendsen and no thermostat)
> > -estatics (cut-off instead of pme)
> > -type of constraint algo for water (so lincs, shake or settle, we
> > modified the spc/e water molec definition to change this)
> > -changing system size so that the box length is equal in all 3 dim (as
> > said, magnifies problem)
> > -rotating system (error rotates with system)
> > -use smaller time step of 1fs (no difference)
> >
> > We ran a simulation with flexible water (so bonds instead of
> > constraints) , here the error vanishes!
> > Also, we ran similar sims with amber, where the error does not appear at
> > all (for constraint water).
> >
> > We found out about this problem while doing surface tension/contact
> > angle calculations.
> > The surf tens calced via virial differs from the surf tens calculated
> > via pressure tensor (unless one corrects
> > for the anisotropic kinetic energy). A simple way to see the deficit is
> > trying to calc the average pressure tensor from the average virial
> > tensor (using the simple def from the gromacs manual
> P_ij=2/V(Ekin-Vir_ij):
> > a) assuming equidistributed kinetic energy (ekin/3 per dim)
> > b) using the anisotropic ekin which can be extracted from a trr with a
> > tool (source attached) if velocities have been written to the trr.
> >
> > All this appears to hint at a problem with the constraints for the
> > waters and might also hint at an incorrect ensemble as a consequence.
> >
> > Alex
> >
> > sample input file (several variants of this file have been used):
> >
> > title = pure water
> > cpp = /usr/bin/cpp
> > integrator = md
> > nsteps = 250
> > nstlist = 50
> > nstxout = 1000
> > nstvout = 1000
> > nstlog = 1000
> > dt = 0.002
> > nstcomm = 200
> > comm-mode = linear
> > constraints = h-bonds
> > nstenergy = 100
> > ns_type = grid
> > coulombtype = pme
> > fourierspacing = 0.12
> > pme_order = 4
> > rlist = 0.9
> > rvdw = 0.9
> > rcoulomb = 0.9
> > tcoupl = Berendsen
> > tc_grps = SOL
> > energygrps = SOL
> > tau_t = 0.4
> > ref_t = 300
> >
> >
> >
> > David van der Spoel schrieb:
> > > aherz wrote:
> > >> Hi,
> > >>
> > >> we're running simulations of a water slab sandwiched by vacuum
> (ca. 2k
> > >> waters, 3x3x12 nm^3 box) in NVT
> > >> and look at the pressure tensor. We are surprised to find that the
> > >&

[gmx-users] non isotropic kinetic energy

[aherz]

Hi,

we're running simulations of a water slab sandwiched by vacuum (ca. 2k
waters, 3x3x12 nm^3 box) in NVT
and look at the pressure tensor. We are surprised to find that the
kinetic energy is equivalent (within statistical uncertainty) for x and
y dim(parallel to the interface) but not in z dim. This appears to
violate the equipartition theorem?

This is gromacs 3.0 and 4.0 using berendsen thermostat.

Alex
___
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] t_trxframe speed units

[aherz]

I understand.
I would look at it myself, but the time for my thesis is running out so
I cannot spend much time
looking at issues unrelated to my actual problem. Next week sounds great.

Alex

Berk Hess schrieb:
> I should have time next week to do this.
> The problem with these kind of things is that you have
> to make sure that it works under all conditions and that grompp
> should have checks for all conditions under which it does not work.
>
> Berk
>
>   
>> Date: Fri, 4 Sep 2009 13:27:46 +0200
>> From: alexander.h...@mytum.de
>> To: gmx-users@gromacs.org
>> Subject: Re: [gmx-users] t_trxframe speed units
>>
>> sure,
>>
>> I'll update to the head revision as soon as a fix is available.
>> Any idea how long this will take?
>>
>> Alex
>>
>> Berk Hess schrieb:
>> 
>>> Thinking about this, I will probably not fix it in 4.0,
>>> but only in git master for 4.1.
>>>
>>> There are several issues with pulling "infinitely" long/far.
>>> One of them is that you can no longer determine the virial contribution
>>>   
>>> 
>>>
>>> ___
>>> 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

Re: [gmx-users] t_trxframe speed units

[aherz]

sure,

I'll update to the head revision as soon as a fix is available.
Any idea how long this will take?

Alex

Berk Hess schrieb:
> Thinking about this, I will probably not fix it in 4.0,
> but only in git master for 4.1.
>
> There are several issues with pulling "infinitely" long/far.
> One of them is that you can no longer determine the virial contribution.
> Also, grompp should check that you do not pressure coupl in the direction
> that you pull.
>
> Berk
>
> > Date: Fri, 4 Sep 2009 12:45:04 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: Re: [gmx-users] t_trxframe speed units
> >
> > Great!
> >
> > Berk Hess schrieb:
> > > Ah, now I see what the problem is.
> > > The pull code works correctly when the distance is shorter or longer
> > > than half the box length. But when the distance crosses half the box
> > > length,
> > > the code might take the "wrong" periodic distance.
> > > I'll see if I can fix this.
> > >
> > > Berk
> > >
> > >
> 
> > > From: g...@hotmail.com
> > > To: gmx-users@gromacs.org
> > > Subject: RE: [gmx-users] t_trxframe speed units
> > > Date: Fri, 4 Sep 2009 10:25:09 +0200
> > >
> > > Hi,
> > >
> > > Could you mail me your input files?
> > >
> > > Berk
> > >
> > > > Date: Fri, 4 Sep 2009 10:05:27 +0200
> > > > From: alexander.h...@mytum.de
> > > > To: gmx-users@gromacs.org
> > > > Subject: Re: [gmx-users] t_trxframe speed units
> > > >
> > > > Hi
> > > >
> > > > yes, I tried pull_start=yes (you also suggested trying constraint
> > > > instead of umbrella, which I tried as well).
> > > > my box is rectangular.
> > > >
> > > > Alex
> > > >
> > > > Berk Hess schrieb:
> > > > > Hi,
> > > > >
> > > > > The only thing I suggested was using pull_start=yes,
> > > > > otherwise you will start at a "random" distance and you will have
> > > enormous forces.
> > > > > Did you try that?
> > > > >
> > > > > Do you have a rectangular or a triclinic box?
> > > > >
> > > > > Berk
> > > > >
> > > > >
> > > > >> Date: Thu, 3 Sep 2009 18:00:44 +0200
> > > > >> From: alexander.h...@mytum.de
> > > > >> To: gmx-users@gromacs.org
> > > > >> Subject: Re: [gmx-users] t_trxframe speed units
> > > > >>
> > > > >> Hey,
> > > > >>
> > > > >> I tried everything you suggested and a couple more things and
> > > still it
> > > > >> is not possible to get a reasonable speed
> > > > >> for the pulled groups (always way beyond the 0.01nm/ps set in
> the mdp
> > > > >> file and mostly containing some high frequence patttern probably
> > > related
> > > > >> to pbc). (I tried: constraint, pbcatoms, direction,position and
> > > using no
> > > > >> ref group).
> > > > >>
> > > > >> Can I send you a small sample system with the problem or is there
> > > > >> something else I can do?
> > > > >>
> > > > >> Thx,
> > > > >> Alex
> > > > >>
> > > > >> Berk Hess schrieb:
> > > > >>
> > > > >>> But you can not talk about popping back, since there is pbc.
> > > > >>> What matters is how the pull code determines the distance.
> > > > >>> At least in 4.0.4 and 4.0.5 it add the rate*t before doing pbc,
> > > > >>> such that it pulls smoothly even if the distance is larger than
> > > the box
> > > > >>>
> > > > >>>
> > >
> 
> > > > >>>
> > > > >>> ___
> > > > >>> 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
> > > >
> > > > ___
> > > > 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
> > >
> > >
> 
> > > Express yourself instantly with MSN Messenger! MSN Messenger
> > > 
> > >
> 
> > > What can you do with the new Windows Live? Find out
> > > 
> > >
> 
> > >
> > > ___
> > > gmx-users mailing list gmx-users@gromacs.org
> > > http://lists.gromacs.org/mailman/listinfo/gmx-users
> > > Please

Re: [gmx-users] t_trxframe speed units

[aherz]

Great!

Berk Hess schrieb:
> Ah, now I see what the problem is.
> The pull code works correctly when the distance is shorter or longer
> than half the box length. But when the distance crosses half the box
> length,
> the code might take the "wrong" periodic distance.
> I'll see if I can fix this.
>
> Berk
>
> 
> From: g...@hotmail.com
> To: gmx-users@gromacs.org
> Subject: RE: [gmx-users] t_trxframe speed units
> Date: Fri, 4 Sep 2009 10:25:09 +0200
>
> Hi,
>
> Could you mail me your input files?
>
> Berk
>
> > Date: Fri, 4 Sep 2009 10:05:27 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: Re: [gmx-users] t_trxframe speed units
> >
> > Hi
> >
> > yes, I tried pull_start=yes (you also suggested trying constraint
> > instead of umbrella, which I tried as well).
> > my box is rectangular.
> >
> > Alex
> >
> > Berk Hess schrieb:
> > > Hi,
> > >
> > > The only thing I suggested was using pull_start=yes,
> > > otherwise you will start at a "random" distance and you will have
> enormous forces.
> > > Did you try that?
> > >
> > > Do you have a rectangular or a triclinic box?
> > >
> > > Berk
> > >
> > >
> > >> Date: Thu, 3 Sep 2009 18:00:44 +0200
> > >> From: alexander.h...@mytum.de
> > >> To: gmx-users@gromacs.org
> > >> Subject: Re: [gmx-users] t_trxframe speed units
> > >>
> > >> Hey,
> > >>
> > >> I tried everything you suggested and a couple more things and
> still it
> > >> is not possible to get a reasonable speed
> > >> for the pulled groups (always way beyond the 0.01nm/ps set in the mdp
> > >> file and mostly containing some high frequence patttern probably
> related
> > >> to pbc). (I tried: constraint, pbcatoms, direction,position and
> using no
> > >> ref group).
> > >>
> > >> Can I send you a small sample system with the problem or is there
> > >> something else I can do?
> > >>
> > >> Thx,
> > >> Alex
> > >>
> > >> Berk Hess schrieb:
> > >>
> > >>> But you can not talk about popping back, since there is pbc.
> > >>> What matters is how the pull code determines the distance.
> > >>> At least in 4.0.4 and 4.0.5 it add the rate*t before doing pbc,
> > >>> such that it pulls smoothly even if the distance is larger than
> the box
> > >>>
> > >>>
> 
> > >>>
> > >>> ___
> > >>> 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
> >
> > ___
> > 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
>
> 
> Express yourself instantly with MSN Messenger! MSN Messenger
> 
> 
> What can you do with the new Windows Live? Find out
> 
> 
>
> ___
> 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

Re: [gmx-users] t_trxframe speed units

[aherz]

Hi

yes, I tried pull_start=yes (you also suggested trying constraint
instead of umbrella, which I tried as well).
my box is rectangular.

Alex

Berk Hess schrieb:
> Hi,
>
> The only thing I suggested was using pull_start=yes,
> otherwise you will start at a "random" distance and you will have enormous  
> forces.
> Did you try that?
>
> Do you have a rectangular or a triclinic box?
>
> Berk
>
>   
>> Date: Thu, 3 Sep 2009 18:00:44 +0200
>> From: alexander.h...@mytum.de
>> To: gmx-users@gromacs.org
>> Subject: Re: [gmx-users] t_trxframe speed units
>>
>> Hey,
>>
>> I tried everything you suggested and a couple more things and still it
>> is not possible to get a reasonable speed
>> for the pulled groups (always way beyond the 0.01nm/ps set in the mdp
>> file and mostly containing some high frequence patttern probably related
>> to pbc). (I tried: constraint, pbcatoms, direction,position and using no
>> ref group).
>>
>> Can I send you a small sample system with the problem or is there
>> something else I can do?
>>
>> Thx,
>> Alex
>>
>> Berk Hess schrieb:
>> 
>>> But you can not talk about popping back, since there is pbc.
>>> What matters is how the pull code determines the distance.
>>> At least in 4.0.4 and 4.0.5 it add the rate*t before doing pbc,
>>> such that it pulls smoothly even if the distance is larger than the box
>>>   
>>> 
>>>
>>> ___
>>> 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

Re: [gmx-users] t_trxframe speed units

[aherz]

Hey,

I tried everything you suggested and a couple more things and still it
is not possible to get a reasonable speed
for the pulled groups (always way beyond the 0.01nm/ps set in the mdp
file and mostly containing some high frequence patttern probably related
to pbc). (I tried: constraint, pbcatoms, direction,position and using no
ref group).

Can I send you a small sample system with the problem or is there
something else I can do?

Thx,
Alex

Berk Hess schrieb:
> But you can not talk about popping back, since there is pbc.
> What matters is how the pull code determines the distance.
> At least in 4.0.4 and 4.0.5 it add the rate*t before doing pbc,
> such that it pulls smoothly even if the distance is larger than the box.
> But if your force constant is only 1000 it might lag by a lot.
> Furthermore, if you did not use pull_start, it might start at a random
> distance with an enormous force.
>
> Berk
>
> > Date: Wed, 2 Sep 2009 15:48:56 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: Re: [gmx-users] t_trxframe speed units
> >
> > Yes, the diamond moves through the complete sim box (eg. from left to
> > right) before it pops back to the left side due to pbc.
> > But looking at the diamond speed (which is increasing) it looks as if
> > the afm tip is not shifted back to the left side when it leaves the sim
> > box at the right side. If that was the case then the distance of the tip
> > and the group would increase all the time
> > (after the diamond has been shifted back to the left side the first time
> > due to pbc but the afm is not shifted back) which would explain the
> > increasing speed of the diamond.
> >
> > Let me rephrase the question, what happens with the pull position when
> > it reaches the box boundaries??
> > Is it shifted back (so pull_pos[XX]-=box[XX][XX]) or not? Also, are the
> > atoms shifted back when they leave the box?
> >
> > Berk Hess schrieb:
> > > I don't understand what you want to say.
> > > The diamond does move a lot right?
> > >
> > > I think the main problem might be that you use an umbrella potential
> > > will an very small force constant (for such large groups).
> > > Try using pull=constraint.
> > > (and use pull_start=yes)
> > >
> > > Berk
> > >
> > > > Date: Wed, 2 Sep 2009 15:22:45 +0200
> > > > From: alexander.h...@mytum.de
> > > > To: gmx-users@gromacs.org
> > > > Subject: Re: [gmx-users] t_trxframe speed units
> > > >
> > > > hm..
> > > >
> > > > after thinking about this for a sec I'd say I'm missing an option to
> > > > apply the pbc to the pull position.
> > > > Currently it looks as if the position of the "afm tip" is moving in
> > > > absolute coordinates further and further away from the original
> position
> > > > while the diamonds stay in the original box due to applied pbc.
> > > > Therefore the distance of the diamond to the
> > > > "afm tip" is increasing and hence the force grows bigger and
> bigger. If
> > > > I could apply the pbc to the afm position as well then
> > > > everything would work as expected??
> > > >
> > > > Alex
> > > >
> > > > Berk Hess schrieb:
> > > > > Then you were lucky with Gromacs 3.
> > > > > The pull code in Gromacs 3 does not treat pbc at all,
> > > > > so I am surprised that it worked.
> > > > >
> > > > > I just realized that pull_pbcatom is always set in Gromacs 4.
> > > > > Maybe it would be enough to add pull_start=yes.
> > > > >
> > > > > Berk
> > > > >
> > > > > > Date: Wed, 2 Sep 2009 14:38:35 +0200
> > > > > > From: alexander.h...@mytum.de
> > > > > > To: gmx-users@gromacs.org
> > > > > > Subject: Re: [gmx-users] t_trxframe speed units
> > > > > >
> > > > > > I will try this, thx for the help.
> > > > > >
> > > > > > Anyways, what is the correct way to do what I want with
> gromacs 4?
> > > > > > (apparently the setup I tryed to use worked for gromacs 3,
> since I
> > > > > > ported the input data
> > > > > > from old sims and now I'm trying to recreate the old results).
> > > > > >
> > > > > > Alex
> > > > > >
> > > > > > Berk Hess schrieb:
> > > > > > > The simple issue is that a center of mass is not uniquely
> defined
> > > > > > > for a periodic group of particles.
> > > > > > > If you work on the velocity level, this problem is easy to
> solve.
> > > > > > > But the pull code works on the coordinate level.
> > > > > > >
> > > > > > > Try with pull_pbcatom set, it might work.
> > > > > > >
> > > > > > > Berk
> > > > > > >
> > > > > > >
> > > > > > >> Date: Wed, 2 Sep 2009 14:11:11 +0200
> > > > > > >> From: alexander.h...@mytum.de
> > > > > > >> To: gmx-users@gromacs.org
> > > > > > >> Subject: Re: [gmx-users] t_trxframe speed units
> > > > > > >>
> > > > > > >> We wanted to use 2 slabs so that the net impuls is conserved.
> > > > > > >> Also I'm looking at the slip length, so I actually want to
> > > > > extract the
> > > > > > >> velocity profile of the water in between the two diamond
> > > slabs. I'm
> > > > > > >> pulling in x (the pull setup is reproduced at the botto

Re: [gmx-users] Gromacs 4.0.4 - Pull.pdo File

[aherz]

Hi,

in gromacs 4 the pulling commands are part of the mdp file so copy the
contents of your ppa file into your mdp file.

Alex

V Hariharan schrieb:
> Hello,
>
> My .mdp file, .ppa file and mdrun command are provided below.  After
> running a constraint simulation, I am not getting a .pdo file output
> with the forces between two groups I've specified in my .ppa file.  I
> have set a value for nstfout in the .mdp file (as shown), and used the
> -pd option in the mdrun command.  Anything I'm not seeing/doing
> correctly? Since I've already run the simulation without getting a
> .pdo output, is there any command to extract that data without
> re-reunning the simulation?  All suggestions are appreciated! Thanks.
>
>
>
> *.MDP FILE*
>
> title= MD Simulation
> cpp= /lib/cpp
> constraints= none
> integrator= md
> dt= 0.002
> nsteps= 5
> nstcomm=
> nstxout= 200
> nstxtcout= 200
> nstvout= 0
> nstfout= 1
> nstlist= 10
> ns_type= grid
> rlist= 1.0
> coulombtype= PME
> rcoulomb=
> vdwtype= cut-off
> rvdw=
> fourierspacing=
> fourier_nx=
> fourier_ny=
> fourier_nz=
> pme_order=
> ewald_rtol=
> optimize_fft= yes
> pbc= xyz
>
> ; Berendsen Temperature Coupling
> tcoupl= berendsen
> tc-grps= protein non-protein
> tau_t= 0.1 0.1
> ref_t= 300 300
>
> ; Parinello-Rahman Pressure Coupling
> pcoupl= Parrinello-Rahman
> pcoupltype= isotropic
> tau_p= 1.0
> compressibility= 4.5e-5
> ref_p= 1.0
>
> ; Generate Velocities
> gen_vel= yes
> gen_temp= 300.0
> gen_seed= 173529
>
> *.PPA FILE*
>
> title= Pull Parameters for 3BPAdelDAL
> pull= constraint
> pull_geometry= distance
> pull_dim= Y Y Y
> pull_group0= CTerminus
> pull_group1= NTerminus
>
> *MDRUN COMMAND*
>
> mdrun -s md.tpr -pi pull.ppa -pn index.ndx -x md_traj.xtc -po
> kifpull.ppa -pd pull.pdo -o md.trr -c kif_md.pdb -e md.edr -g md.log
> 
>
> ___
> 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

Re: [gmx-users] t_trxframe speed units

[aherz]

Yes, the diamond moves through the complete sim box (eg. from left to
right) before it pops back to the left side due to pbc.
But looking at the diamond speed (which is increasing) it looks as if
the afm tip is not shifted back to the left side when it leaves the sim
box at the right side. If that was the case then the distance of the tip
and the group would increase all the time
(after the diamond has been shifted back to the left side the first time
due to pbc but the afm is not shifted back) which would explain the
increasing speed of the diamond.

Let me rephrase the question, what happens with the pull position when
it reaches the box boundaries??
Is it shifted back (so pull_pos[XX]-=box[XX][XX]) or not? Also, are the
atoms shifted back when they leave the box?

Berk Hess schrieb:
> I don't understand what you want to say.
> The diamond does move a lot right?
>
> I think the main problem might be that you use an umbrella potential
> will an very small force constant (for such large groups).
> Try using pull=constraint.
> (and use pull_start=yes)
>
> Berk
>
> > Date: Wed, 2 Sep 2009 15:22:45 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: Re: [gmx-users] t_trxframe speed units
> >
> > hm..
> >
> > after thinking about this for a sec I'd say I'm missing an option to
> > apply the pbc to the pull position.
> > Currently it looks as if the position of the "afm tip" is moving in
> > absolute coordinates further and further away from the original position
> > while the diamonds stay in the original box due to applied pbc.
> > Therefore the distance of the diamond to the
> > "afm tip" is increasing and hence the force grows bigger and bigger. If
> > I could apply the pbc to the afm position as well then
> > everything would work as expected??
> >
> > Alex
> >
> > Berk Hess schrieb:
> > > Then you were lucky with Gromacs 3.
> > > The pull code in Gromacs 3 does not treat pbc at all,
> > > so I am surprised that it worked.
> > >
> > > I just realized that pull_pbcatom is always set in Gromacs 4.
> > > Maybe it would be enough to add pull_start=yes.
> > >
> > > Berk
> > >
> > > > Date: Wed, 2 Sep 2009 14:38:35 +0200
> > > > From: alexander.h...@mytum.de
> > > > To: gmx-users@gromacs.org
> > > > Subject: Re: [gmx-users] t_trxframe speed units
> > > >
> > > > I will try this, thx for the help.
> > > >
> > > > Anyways, what is the correct way to do what I want with gromacs 4?
> > > > (apparently the setup I tryed to use worked for gromacs 3, since I
> > > > ported the input data
> > > > from old sims and now I'm trying to recreate the old results).
> > > >
> > > > Alex
> > > >
> > > > Berk Hess schrieb:
> > > > > The simple issue is that a center of mass is not uniquely defined
> > > > > for a periodic group of particles.
> > > > > If you work on the velocity level, this problem is easy to solve.
> > > > > But the pull code works on the coordinate level.
> > > > >
> > > > > Try with pull_pbcatom set, it might work.
> > > > >
> > > > > Berk
> > > > >
> > > > >
> > > > >> Date: Wed, 2 Sep 2009 14:11:11 +0200
> > > > >> From: alexander.h...@mytum.de
> > > > >> To: gmx-users@gromacs.org
> > > > >> Subject: Re: [gmx-users] t_trxframe speed units
> > > > >>
> > > > >> We wanted to use 2 slabs so that the net impuls is conserved.
> > > > >> Also I'm looking at the slip length, so I actually want to
> > > extract the
> > > > >> velocity profile of the water in between the two diamond
> slabs. I'm
> > > > >> pulling in x (the pull setup is reproduced at the bottom of
> the old
> > > > >> mail) and I'm using pbc in 3d.
> > > > >>
> > > > >> What is the problem with pulling the diamond slabs at const
> speed? I
> > > > >> don't actually care where exactly they are.
> > > > >> I only care about the boundary condition at the diamond water
> > > interface
> > > > >> (so that the diamond moves along the surface
> > > > >> with v=cst). I mean, I'm pulling with "direction" not distance,
> > > why does
> > > > >> "direction" care about the COM distance?
> > > > >>
> > > > >> Would it work with absolute coords (empty pullgroup0,
> > > pullgroup1=DIAM1
> > > > >> and pullgroup2=DIAM2)??
> > > > >>
> > > > >> Alex
> > > > >>
> > > > >> Berk Hess schrieb:
> > > > >>
> > > > >>> Ah, maybe now I understand the issue.
> > > > >>> Are you pulling in x and are the slabs periodic in x?
> > > > >>> That will not work, as the COM is not defined in a periodic
> > > direction
> > > > >>>
> > > > >>>
> > >
> 
> > > > >>>
> > > > >>> ___
> > > > >>> 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.
> > > > >

Re: [gmx-users] t_trxframe speed units

[aherz]

hm..

after thinking about this for a sec I'd say I'm missing an option to
apply the pbc to the pull position.
Currently it looks as if the position of the "afm tip" is moving in
absolute coordinates further and further away from the original position
while the diamonds stay in the original box due to applied pbc.
Therefore the distance of the diamond to the
"afm tip" is increasing and hence the force grows bigger and bigger. If
I could apply the pbc to the afm position as well then
everything would work as expected??

Alex

Berk Hess schrieb:
> Then you were lucky with Gromacs 3.
> The pull code in Gromacs 3 does not treat pbc at all,
> so I am surprised that it worked.
>
> I just realized that pull_pbcatom is always set in Gromacs 4.
> Maybe it would be enough to add pull_start=yes.
>
> Berk
>
> > Date: Wed, 2 Sep 2009 14:38:35 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: Re: [gmx-users] t_trxframe speed units
> >
> > I will try this, thx for the help.
> >
> > Anyways, what is the correct way to do what I want with gromacs 4?
> > (apparently the setup I tryed to use worked for gromacs 3, since I
> > ported the input data
> > from old sims and now I'm trying to recreate the old results).
> >
> > Alex
> >
> > Berk Hess schrieb:
> > > The simple issue is that a center of mass is not uniquely defined
> > > for a periodic group of particles.
> > > If you work on the velocity level, this problem is easy to solve.
> > > But the pull code works on the coordinate level.
> > >
> > > Try with pull_pbcatom set, it might work.
> > >
> > > Berk
> > >
> > >
> > >> Date: Wed, 2 Sep 2009 14:11:11 +0200
> > >> From: alexander.h...@mytum.de
> > >> To: gmx-users@gromacs.org
> > >> Subject: Re: [gmx-users] t_trxframe speed units
> > >>
> > >> We wanted to use 2 slabs so that the net impuls is conserved.
> > >> Also I'm looking at the slip length, so I actually want to
> extract the
> > >> velocity profile of the water in between the two diamond slabs. I'm
> > >> pulling in x (the pull setup is reproduced at the bottom of the old
> > >> mail) and I'm using pbc in 3d.
> > >>
> > >> What is the problem with pulling the diamond slabs at const speed? I
> > >> don't actually care where exactly they are.
> > >> I only care about the boundary condition at the diamond water
> interface
> > >> (so that the diamond moves along the surface
> > >> with v=cst). I mean, I'm pulling with "direction" not distance,
> why does
> > >> "direction" care about the COM distance?
> > >>
> > >> Would it work with absolute coords (empty pullgroup0,
> pullgroup1=DIAM1
> > >> and pullgroup2=DIAM2)??
> > >>
> > >> Alex
> > >>
> > >> Berk Hess schrieb:
> > >>
> > >>> Ah, maybe now I understand the issue.
> > >>> Are you pulling in x and are the slabs periodic in x?
> > >>> That will not work, as the COM is not defined in a periodic
> direction
> > >>>
> > >>>
> 
> > >>>
> > >>> ___
> > >>> 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
> >
> > ___
> > 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
>
> 
> Express yourself instantly with MSN Messenger! MSN Messenger
> 
> 
>
> ___
> 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

Re: [gmx-users] t_trxframe speed units

[aherz]

I will try this, thx for the help.

Anyways, what is the correct way to do what I want with gromacs 4?
(apparently the setup I tryed to use worked for gromacs 3, since I
ported the input data
from old sims and now I'm trying to recreate the old results).

Alex

Berk Hess schrieb:
> The simple issue is that a center of mass is not uniquely defined
> for a periodic group of particles.
> If you work on the velocity level, this problem is easy to solve.
> But the pull code works on the coordinate level.
>
> Try with pull_pbcatom set, it might work.
>
> Berk
>
>   
>> Date: Wed, 2 Sep 2009 14:11:11 +0200
>> From: alexander.h...@mytum.de
>> To: gmx-users@gromacs.org
>> Subject: Re: [gmx-users] t_trxframe speed units
>>
>> We wanted to use 2 slabs so that the net impuls is conserved.
>> Also I'm looking at the slip length, so I actually want to extract the
>> velocity profile of the water in between the two diamond slabs. I'm
>> pulling in x (the pull setup is reproduced at the bottom of the old
>> mail) and I'm using pbc in 3d.
>>
>> What is the problem with pulling the diamond slabs at const speed? I
>> don't actually care where exactly they are.
>> I only care about the boundary condition at the diamond water interface
>> (so that the diamond moves along the surface
>> with v=cst). I mean, I'm pulling with "direction" not distance, why does
>> "direction" care about the COM distance?
>>
>> Would it work with absolute coords (empty pullgroup0, pullgroup1=DIAM1
>> and pullgroup2=DIAM2)??
>>
>> Alex
>>
>> Berk Hess schrieb:
>> 
>>> Ah, maybe now I understand the issue.
>>> Are you pulling in x and are the slabs periodic in x?
>>> That will not work, as the COM is not defined in a periodic direction
>>>   
>>> 
>>>
>>> ___
>>> 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

Re: [gmx-users] t_trxframe speed units

[aherz]

We wanted to use 2 slabs so that the net impuls is conserved.
Also I'm looking at the slip length, so I actually want to extract the
velocity profile of the water in between the two diamond slabs. I'm
pulling in x (the pull setup is reproduced at the bottom of the old
mail) and I'm using pbc in 3d.

What is the problem with pulling the diamond slabs at const speed? I
don't actually care where exactly they are.
I only care about the boundary condition at the diamond water interface
(so that the diamond moves along the surface
with v=cst). I mean, I'm pulling with "direction" not distance, why does
"direction" care about the COM distance?

Would it work with absolute coords (empty pullgroup0, pullgroup1=DIAM1
and pullgroup2=DIAM2)??

Alex

Berk Hess schrieb:
> Ah, maybe now I understand the issue.
> Are you pulling in x and are the slabs periodic in x?
> That will not work, as the COM is not defined in a periodic direction.
>
> If your slabs are very rigid, you might be lucky that it works
> when you choose pull_pbcatoms for both groups that do not separate
> more than half a box.
>
> But this experiment is much simpler with a single diamond slab
> and the deform option to shear the box.
> You can get the force from the off-diagonal pressure element.
>
> Berk
>
>   
>> Date: Wed, 2 Sep 2009 13:40:48 +0200
>> From: alexander.h...@mytum.de
>> To: gmx-users@gromacs.org
>> Subject: Re: [gmx-users] t_trxframe speed units
>>
>> I'm studying shear flow, so I exspect the two slabs to be pulled in
>> opposite x direction with the pull speed given.
>> Looking at pull.xvg the slabs are pulled apart with about 1.5nm/ps until
>> the box end (in x) is reached, then they jump back due to pbc. So this
>> is what I would exspect, exept that the speed is much too high.
>>
>> hm..looking at the com speed vs time as per "g_traj -com -ov -n" for the
>> first diamond slab only,
>> the speed keeps increasing (see attached screenshot). Have I enabled a
>> non constant pull rate somehow??
>>
>> Alex
>>
>> Berk Hess schrieb:
>> 
>>> Hi,
>>>
>>> Yes, speed is in nm/ps.
>>> g_traj -com -ov -n will give the the speed of the slabs as a function
>>> of time.
>>>
>>> If the speed is really 1.2 nm/ps, they should have moved 6 nm in 5 ns,
>>> which is probably not the case, right?
>>>
>>> Could it be that you have pbc issues?
>>> The distance between the two slabs could be taken within the box
>>> or over the boundaries.
>>> Have a look at pullx.xvg to see if it does what you expect.
>>> (the time derivative of pullx.xvg should also give the speed
>>> difference of the slabs).
>>>
>>> Berk
>>>
>>>   
 Date: Wed, 2 Sep 2009 11:39:22 +0200
 From: alexander.h...@mytum.de
 To: gmx-users@gromacs.org
 Subject: [gmx-users] t_trxframe speed units

 Hey,

 I averaged the speed of the diamond slabs, so I wrote a small gmx
 
>>> tools which averages t_trxframe.v[i] where i iterates over the diam atoms.
>>>   
 I calc the avrg speed for a production run of 5ns after 0.5ns equilib
 
 

 ___
 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

Re: [gmx-users] t_trxframe speed units

[aherz]

I'm studying shear flow, so I exspect the two slabs to be pulled in
opposite x direction with the pull speed given.
Looking at pull.xvg the slabs are pulled apart with about 1.5nm/ps until
the box end (in x) is reached, then they jump back due to pbc. So this
is what I would exspect, exept that the speed is much too high.

hm..looking at the com speed vs time as per "g_traj -com -ov -n" for the
first diamond slab only,
the speed keeps increasing (see attached screenshot). Have I enabled a
non constant pull rate somehow??

Alex

Berk Hess schrieb:
> Hi,
>
> Yes, speed is in nm/ps.
> g_traj -com -ov -n will give the the speed of the slabs as a function
> of time.
>
> If the speed is really 1.2 nm/ps, they should have moved 6 nm in 5 ns,
> which is probably not the case, right?
>
> Could it be that you have pbc issues?
> The distance between the two slabs could be taken within the box
> or over the boundaries.
> Have a look at pullx.xvg to see if it does what you expect.
> (the time derivative of pullx.xvg should also give the speed
> difference of the slabs).
>
> Berk
>
> > Date: Wed, 2 Sep 2009 11:39:22 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: [gmx-users] t_trxframe speed units
> >
> > Hey,
> >
> > I averaged the speed of the diamond slabs, so I wrote a small gmx
> tools which averages t_trxframe.v[i] where i iterates over the diam atoms.
> > I calc the avrg speed for a production run of 5ns after 0.5ns equilib.
> > I get an avrg speed of 1.2 [nm/ps], so this is not just some
> fluctuation (last time I only looked at the last frame output by gromacs).
> >
> > t_trxframe::v contains the speed in [nm/ps] right?
> >
> > Could someone please comment on this? Why are the diamonds considerably
> > faster then the pull speed pull_rate1??
> > This is gromacs4.0.5 by the way.
> > Thx,
> > Alex
> >
> > using still this setup:
> >
> > Here is the pull setup:
> > pull = umbrella
> > pull_geometry = direction
> > pull_ngroups = 1
> > pull_group0 = DIAM
> > pull_group1 = DIAM2
> > pulldim = Y Y Y
> > pull_k1 = 1000.0
> > pull_rate1 = 0.01
> > pull_vec1 = -1.0 0.0 0.0
> >
> > and following geometry:
> >
> > box_z_max
> > water_slab
> > diam1
> > water_slab
> > diam2
> > box_z_min
> >
> > rest of the mdp:
> > title = 2 diamond surfaces
> > cpp = /usr/bin/cpp
> > integrator = md
> > nsteps = 250
> > nstlist = 50
> > nstxout = 50
> > nstvout = 50
> > nstxtcout = 0
> > nstlog = 1000
> > dt = 0.002
> > constraints = h-bonds
> > nstenergy = 100
> > ns_type = grid
> > coulombtype = pme
> > fourierspacing = 0.12
> > pme_order = 4
> > rlist = 0.8
> > rvdw = 0.8
> > rcoulomb = 0.8
> > tcoupl = berendsen
> > tc_grps = DIAM DIAMCNST DIAM2 DIAMCNST2 SOL
> > energygrps = DIAM DIAMCNST DIAM2 DIAMCNST2 SOL
> > tau_t = 0.4 0.4 0.4 0.4 0.4
> > ref_t = 300 300 300 300 300
> > compressibility = 0.0 4.5E-5
> > tau_p = 1.0 1.0
> > ref_p = 1.0 1.0
> > Pcoupl = berendsen
> > Pcoupltype = semiisotropic
> > gen_vel = no
> >
> >
> >
> >
> > ___
> > 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
>
> 
> See all the ways you can stay connected to friends and family
> 
> 
>
> ___
> 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

[gmx-users] t_trxframe speed units

[aherz]

Hey,

I averaged the speed of the diamond slabs, so I wrote a small gmx tools which 
averages t_trxframe.v[i] where i iterates over the diam atoms.
I calc the avrg speed for a production run of 5ns after 0.5ns equilib.
I get an avrg speed of 1.2 [nm/ps], so this is not just some fluctuation (last 
time I only looked at the last frame output by gromacs).

t_trxframe::v contains the speed in [nm/ps] right?

Could someone please comment on this? Why are the diamonds considerably
faster then the pull speed pull_rate1??
This is gromacs4.0.5 by the way.
Thx,
Alex

using still this setup:

Here is the pull setup:
pull= umbrella
pull_geometry   = direction
pull_ngroups = 1
pull_group0  = DIAM
pull_group1  = DIAM2
pulldim = Y Y Y
pull_k1  = 1000.0
pull_rate1   = 0.01
pull_vec1= -1.0 0.0 0.0

and following geometry:

box_z_max
water_slab
diam1
water_slab
diam2
box_z_min

rest of the mdp:
title= 2 diamond surfaces
cpp  = /usr/bin/cpp
integrator   = md
nsteps   = 250
nstlist  = 50
nstxout  = 50
nstvout  = 50
nstxtcout= 0
nstlog   = 1000
dt   = 0.002
constraints  = h-bonds
nstenergy= 100
ns_type  = grid
coulombtype  = pme
fourierspacing   = 0.12
pme_order= 4
rlist= 0.8
rvdw = 0.8
rcoulomb = 0.8
tcoupl   = berendsen
tc_grps  = DIAM DIAMCNST DIAM2 DIAMCNST2 SOL
energygrps   = DIAM DIAMCNST DIAM2 DIAMCNST2 SOL
tau_t= 0.4 0.4 0.4 0.4 0.4
ref_t= 300 300 300 300 300
compressibility  = 0.0 4.5E-5
tau_p= 1.0 1.0
ref_p= 1.0 1.0
Pcoupl   = berendsen
Pcoupltype   = semiisotropic
gen_vel  = no




___
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] gro file format /pulling

[aherz]

Hi,

I'm pulling 2 diamond slabs (which enclose two water slabs) in opposite
direction
with pull_rate1=0.01 (nm/ps) in x direction (pbc in 3d).
Now looking at the gro file that is finally output when the sim is
finshied and averaging
the speeds of the two diamonds I get ca. +/-1.78 (I guess  [nm/ps])
(different signs cause the
diamond slabs are pulled in opposite direction). Looking at the
trajectory, the pulling
looks ok (so the diamonds have ca. const speed in opposite direction).

Now, is the speed I get from the gro file actually in nm/ps and how does
it relate to my
0.01 nm/ps pull_rate1 (shouldn't it be ca. 0.01 nm/ps)??

Here is the pull setup:
pull= umbrella
pull_geometry   = direction
pull_ngroups = 1
pull_group0  = DIAM
pull_group1  = DIAM2
pulldim = Y Y Y
pull_k1  = 1000.0
pull_rate1   = 0.01
pull_vec1= -1.0 0.0 0.0

___
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] continuation

[aherz]

Hi,

yes, the trr is 7GB.

Alex

Berk Hess schrieb:
> Hi,
>
> -append yes is incorrect, it should be -append without the yes.
> In this case this error has no effect though.
>
> Is your trr file larger than 2 GB?
> We have fixed a bug with this in the upcoming 4.0.6 release.
>
> Berk
>
> > Date: Fri, 28 Aug 2009 16:48:07 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: [gmx-users] continuation
> >
> > Hi,
> >
> > I'm trying to continue a sim using:
> >
> > old cmd line + -cpi state.cpt -append yes
> >
> > where old cmd line =
> > mpirun -np 1 $GROMACS_T37/mdrun -s shear -c shear_final -g shear_final
> > -o shear
> >
> > All files exist.
> >
> > and I get:
> >
> > ---
> > Program mdrun, VERSION 4.0.5
> > Source code file: checkpoint.c, line: 1248
> >
> > Fatal error:
> > Truncation of file shear.trr failed.
> > ---
> >
> > What's the problem??
> >
> > Thx,
> > Alex
> > ___
> > 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
>
> 
> Express yourself instantly with MSN Messenger! MSN Messenger
> 
> 
>
> ___
> 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

[gmx-users] continuation

[aherz]

Hi,

I'm trying to continue a sim using:

old cmd line + -cpi state.cpt -append yes

where old cmd line =
mpirun -np 1 $GROMACS_T37/mdrun -s shear -c shear_final -g shear_final
-o shear

All files exist.

and I get:

---
Program mdrun, VERSION 4.0.5
Source code file: checkpoint.c, line: 1248

Fatal error:
Truncation of file shear.trr failed.
---

What's the problem??

Thx,
Alex
___
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] Pressure for froozen atoms

[aherz]

Hi guys,

does gromacs use the following scheme to calculate the virial/pressure
for systems including froozen atoms:
http://www.ccp5.ac.uk/infoweb/wsmith22/wsmith22/wsmith22.html
??

Thx,
Alex
___
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] pulling

[aherz]

Hey,

has anyone actually succeeded doing pulling with gromacs 4.0.5 keeping
the distance between
a froozen and a non froozen group (so not pulling into a direction but
just applying the harmonic potential to the distance).
If so, could you send me the mdp file showing how you set up the whole
thing?
Or if you got it working for two non froozen groups that'd be as good.

Thx,
Alex
___
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: pulling

[aherz]

Hm..setting

 > >>> pull_geometry = direction
 > >>> pull_vec1 = 0 0 1
 
should fix the pbc prob or do I need to set pull_pbcatom0 as well?
Cause it still aint working using these settings (without the
pull_pbcatom0).

Thx,
Alex

Berk Hess schrieb:
> No (completely) frozen groups are treated correctly.
> I had to look in (my own) code again, but for a fully frozen group
> the inverse mass is set to 0 in the pull code.
>
> Berk
>
> > Date: Fri, 31 Jul 2009 12:49:55 +0200
> > From: schl...@uni-mainz.de
> > To: gmx-users@gromacs.org
> > Subject: [gmx-users] Re: pulling
> >
> > Could it also be possible that 'pull = distance' makes problems because
> > it pulls both groups and here one group is frozen? Only an idea, i have
> > never tried to pull a frozen molecule.
> > Thomas
> >
> >
> > > --
> > >
> > > Message: 5
> > > Date: Fri, 31 Jul 2009 12:38:19 +0200
> > > From: Berk Hess 
> > > Subject: RE: [gmx-users] pulling
> > > To: Discussion list for GROMACS users 
> > > Message-ID: 
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > >
> > > Ah, then you could have a pbc problem for determining the COM of
> the slab,
> > > since you slab is thicker than half the box.
> > > You have to set pull_pbcatom0 to an atom in the middle of the slab.
> > >
> > > pull_init1 doesn't change.
> > > The only thing the geometry change affects is the direction you
> pull in.
> > > With distance you could be unlucky that it takes the distance
> > > in the opposite direction.
> > >
> > > Berk
> > >
> > >> Date: Fri, 31 Jul 2009 12:32:13 +0200
> > >> From: alexander.h...@mytum.de
> > >> To: gmx-users@gromacs.org
> > >> Subject: Re: [gmx-users] pulling
> > >>
> > >> Thx for the quick reply!
> > >>
> > >> I use 4.0.5, pbc z=yes
> > >> Box height = 17.5nm
> > >> gld slab is from z=0 to z= 9.5;
> > >> So distance=5.5 should give 1.0nm above surface right?
> > >>
> > >> What do I have to put for pull_init1 if i use direction??
> > >>
> > >> Thx,
> > >> Alex
> > >>
> > >> Berk Hess schrieb:
> > >>> Hi,
> > >>>
> > >>> I hope you are using 4.0.5, I fixed several bug in the pull code for
> > >>> older 4.0 versions.
> > >>>
> > >>> The problems you are seing could be due to pbc.
> > >>> Do you have pbc in Z, and what is the height of your box?
> > >>>
> > >>> A safer setup is:
> > >>> pull_geometry = direction
> > >>> pull_vec1 = 0 0 1
> > >>> But they should give the same answers if you do not have pbc issues.
> > >>>
> > >>> Berk
> > >>>
> >  Date: Fri, 31 Jul 2009 12:13:07 +0200
> >  From: alexander.h...@mytum.de
> >  To: gmx-users@gromacs.org
> >  Subject: [gmx-users] pulling
> > 
> >  Hey,
> > 
> >  I appear to have serious trouble understanding how to set up
> the pulling
> >  properly.
> > 
> >  I have many configurations of a protein partially adsorbed to a
> froozen
> >  surface (the configs differ
> >  in the amount of the protein that has been desorbed).
> >  Now I want the pulling to keep the distance of the desorbed end
> of the
> >  protein to the surface using the harmonic pot.
> >  Now the documentation is not very clear how this all works so I ran
> >  several experiments to figure it out but I failed.
> >  I use the following options:
> > 
> >  ;PULLING
> >  pull = umbrella
> >  pull_geometry = distance
> >  pull_dim = N N Y
> >  pull_nstxout = 1000
> >  pull_nstfout = 1000
> >  pull_ngroups = 1
> >  pull_group0 = GLD
> >  pull_group1 = ASN
> >  pull_vec1 = 0.0 0.0 0.0
> >  pull_init1 = 5.27778
> >  pull_rate1 = 0.0
> >  pull_k1 = 100
> > 
> > 
> >  where gld is the surface and asn is the end residue of the
> protein and
> >  pull_init1 is set to the desired COM distance of the two
> >  groups (gld is froozen). I use the same settings for all runs, only
> >  changing pull_init1 to get the desired distance.
> >  Now for some reason using this setup either pulls the ASN end
> of the
> >  protein completely onto the surface or very far away from it
> depending
> >  on the value I use for pull_init1.
> >  So the distance between what and what shall I put for
> pull_init1? What
> >  else is wrong?
> > 
> >  Thx,
> >  Alex
> >  ___
> >  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
> > >>>
> 
> > >>> Express yourself instantly with MSN Messenger! MSN Messenger
> > >>> 

Re: [gmx-users] pulling

[aherz]

Thx for the quick reply!

I use 4.0.5, pbc z=yes
Box height = 17.5nm
gld slab is from z=0 to z= 9.5;
So distance=5.5 should give 1.0nm above surface right?

What do I have to put for pull_init1 if i use direction??

Thx,
Alex

Berk Hess schrieb:
> Hi,
>
> I hope you are using 4.0.5, I fixed several bug in the pull code for
> older 4.0 versions.
>
> The problems you are seing could be due to  pbc.
> Do you have pbc in Z, and what is the height of your box?
>
> A safer setup is:
> pull_geometry = direction
> pull_vec1 = 0 0 1
> But they should give the same answers if you do not have pbc issues.
>
> Berk
>
> > Date: Fri, 31 Jul 2009 12:13:07 +0200
> > From: alexander.h...@mytum.de
> > To: gmx-users@gromacs.org
> > Subject: [gmx-users] pulling
> >
> > Hey,
> >
> > I appear to have serious trouble understanding how to set up the pulling
> > properly.
> >
> > I have many configurations of a protein partially adsorbed to a froozen
> > surface (the configs differ
> > in the amount of the protein that has been desorbed).
> > Now I want the pulling to keep the distance of the desorbed end of the
> > protein to the surface using the harmonic pot.
> > Now the documentation is not very clear how this all works so I ran
> > several experiments to figure it out but I failed.
> > I use the following options:
> >
> > ;PULLING
> > pull = umbrella
> > pull_geometry = distance
> > pull_dim = N N Y
> > pull_nstxout = 1000
> > pull_nstfout = 1000
> > pull_ngroups = 1
> > pull_group0 = GLD
> > pull_group1 = ASN
> > pull_vec1 = 0.0 0.0 0.0
> > pull_init1 = 5.27778
> > pull_rate1 = 0.0
> > pull_k1 = 100
> >
> >
> > where gld is the surface and asn is the end residue of the protein and
> > pull_init1 is set to the desired COM distance of the two
> > groups (gld is froozen). I use the same settings for all runs, only
> > changing pull_init1 to get the desired distance.
> > Now for some reason using this setup either pulls the ASN end of the
> > protein completely onto the surface or very far away from it depending
> > on the value I use for pull_init1.
> > So the distance between what and what shall I put for pull_init1? What
> > else is wrong?
> >
> > Thx,
> > Alex
> > ___
> > 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
>
> 
> Express yourself instantly with MSN Messenger! MSN Messenger
> 
> 
>
> ___
> 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

[gmx-users] pulling

[aherz]

Hey,

I appear to have serious trouble understanding how to set up the pulling
properly.

I have many configurations of a protein partially adsorbed to a froozen
surface (the configs differ
in the amount of the protein that has been desorbed).
Now I want the pulling to keep the distance of the desorbed end of the
protein to the surface using the harmonic pot.
Now the documentation is not very clear how this all works so I ran
several experiments to figure it out but I failed.
I use the following options:

;PULLING
pull = umbrella
pull_geometry= distance
pull_dim = N N Y
pull_nstxout = 1000
pull_nstfout = 1000
pull_ngroups = 1
pull_group0  = GLD
pull_group1  = ASN
pull_vec1= 0.0 0.0 0.0
pull_init1   =   5.27778
pull_rate1   = 0.0
pull_k1  = 100


where gld is the surface and asn is the end residue of the protein and
pull_init1 is set to the desired COM distance of the two
groups (gld is froozen). I use the same settings for all runs, only
changing pull_init1 to get the desired distance.
Now for some reason using this setup either pulls the ASN end of the
protein completely onto the surface or very far away from it depending
on the value I use for pull_init1.
So the distance between what and what shall I put for pull_init1? What
else is wrong?

Thx,
Alex
___
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] TI with nonbond_params

[aherz]

Hi,

I'm running a TI perturbing the lennard jones parametters of an ion.
In addition I have specified the lj interaction of that ion with water
using nonbond_params like this:

#include "ffG53a6.itp"

[ atomtypes ]
;name   at.num   mass charge  ptypec6  c12
 NaMod   CA1  0.0000.000   A   7.20e-52.1025e-08

[ nonbond_params ]
;A  B1c6c12
NaMod  OW   1   -5.116e-7  2.35335e-7

[ moleculetype ]
; Name nrexcl
CatC6  1

[ atoms ]
;   nr   type  resnr residue  atom   cgnr chargemass
typeBchargeB  massB
1  NaMod   1 CAT  CA110.0   22.9898
DUM  0.0  22.9898

#include "spc.itp"

#include "ions.itp"

[ system ]
; Name
Solvated Cation with inverted C6 in water

[ molecules ]
; Compound  #mols
CatC6   1
SOL   893

Will gromacs perturb the nonbond_params or will it only perturb the
parameters specified in atomtypes?
So are the lennard jones params actually going to 0 or are they fixed at
the values specified for nonbond_params no matter what lambda value I use?

Thx,
Alex

___
gmx-users mailing listgmx-users@gromacs.org
http://www.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