No.
The ONLY difference between bonds type 8 and type 9 is that type 8 generates
exclusions
while type 9 does not (see table 5.4 in the manual).
Simply changing from type 9 to 8 will generate the exclusions.
Berk
Date: Tue, 29 Sep 2009 17:52:03 +0200
From: albita...@virgilio.it
To: gmx-users@g
Are you really sure about this and that this is with bond type 8?
The whole point of having a tabulated bond type 8 and 9
is that 8 does generate exclusions and 9 does not.
Berk
Date: Tue, 29 Sep 2009 14:17:37 +0200
From: albita...@virgilio.it
To: gmx-users@gromacs.org
Subject: R: RE: R: RE: [g
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
> >
&g
= 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:
>
Your system could be unstable.
You can check for large forces with mdrun -pforce
I don't know what a reasonable range of forces is, you can try 5000.
If you have instabilities, you should get large forces printed
before you get the fatal error.
Berk
Date: Fri, 25 Sep 2009 14:10:08 +0200
From: a
I think the text below "Fatal error:" explains pretty clearly why this
interaction is missing.
Berk
Date: Fri, 25 Sep 2009 13:04:28 +0200
From: mariagorano...@gmail.com
To: gmx-users@gromacs.org
Subject: [gmx-users] martini simulation problem with unsaturated lipid
Hello
I get this error whil
working well now, Can you explain Why it
didn't worked for prime number?
Thanks & Regards,
Vivek
2009/9/25 Berk Hess
Hi,
Why do you want to run on exactly 57 nodes?
That is a nasty prime number.
I guess 56 or 60 nodes would work fine.
Berk
Date: Fri, 25 Sep 2009 14:39:27 +
Hi,
Why do you want to run on exactly 57 nodes?
That is a nasty prime number.
I guess 56 or 60 nodes would work fine.
Berk
Date: Fri, 25 Sep 2009 14:39:27 +0530
From: viveksharma.i...@gmail.com
To: gmx-users@gromacs.org
Subject: [gmx-users] Error while scaling mdrun for more number of nodes.
H
> Date: Fri, 25 Sep 2009 08:23:37 +1000
> From: mark.abra...@anu.edu.au
> To: gmx-users@gromacs.org
> Subject: Re: [gmx-users] BUG in GROMACS 4.0.5,related to very log
> total integration time
>
> Daniel Adriano Silva M wrote:
> > Dear GROMACS users and developers.
> >
> > I don known
Hi,
You don't mention what kind of benchmark system tou are using for these tests.
A too small system could explain these results.
Berk
Date: Thu, 24 Sep 2009 07:01:04 -0700
From: flormart...@yahoo.com.ar
To: gmx-users@gromacs.org
Subject: [gmx-users] trying to get better performance in a Rock
You should put the cflags on the configure command line, I use:
configure --enable-debug CFLAGS="-O0 -msse2 -g"
Berk
Date: Thu, 24 Sep 2009 16:51:45 +0300
From: inons...@tau.ac.il
To: gmx-users@gromacs.org
Subject: [gmx-users] Re: Re: help with gmx C source code
This is not nonsense, it is exactly what is says.
The distance between two atoms is more than 10 times as large as your table
length.
Maybe you are somehow having issues with periodic boundary conditions.
Is you box size close to 23?
Berk
Date: Thu, 24 Sep 2009 12:32:36 +0200
From: albita...@
> Date: Tue, 22 Sep 2009 11:19:56 +0200
> From: schl...@uni-mainz.de
> To: gmx-users@gromacs.org
> Subject: [gmx-users] Re: Re: Re: Re: Re: Re: umbrella potential
>
> Only an idea:
> If you start your pulling simulations (to get the windows) your spring
> start at some point (0.9nm?) and then m
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
> > > Fr
ewald_zfac = 3
Berk Hess wrote:
Hi,
Nearly all the information is in the mdp options page, but it is a bit concise.
The only really missing information is that there is not cut-off for the wall.
All atoms feel the force of one or both walls.
The density is required to determine the i
Hi,
I guess the problem is in src/gmxlib/futil.c,
where several string buffers that contain the path are of size 512.
In Gromacs 4.1 they will be 4096.
You can try replacing all numbers 512 by 4096 in src/gmxlib/futil.c.
Berk
> From: alanwil...@gmail.com
> Date: Mon, 21 Sep 2009 13:59:54 +0100
it
>
> 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.
> > Ther
ct 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
Hi,
Nearly all the information is in the mdp options page, but it is a bit concise.
The only really missing information is that there is not cut-off for the wall.
All atoms feel the force of one or both walls.
The density is required to determine the interaction strength of the wall
for the 9-3
> Date: Mon, 21 Sep 2009 09:11:24 +0200
> From: anna.marabo...@isa.cnr.it
> To: gmx-users@gromacs.org
> Subject: [gmx-users] Re: Re: problems running REMD on grids
>
> Dear Mark,
>
> I passed your suggestion to omit the -s flag to the person who developed the
> scripts to launch GROMACS on the
You should also be aware that when you determine a PDF for a distance
constrained in 3D, you will always get a "trivial" entropy contribution
of -2 kT log(r), which will eventually make all curves tend downwards.
Berk
> Date: Sun, 20 Sep 2009 20:28:02 -0400
> From: jalem...@vt.edu
> To: gmx-user
Hi,
You seem to be trying to decouple a 9 residue peptide from the rest of the
system.
This "brute-force" approach will only work when you have an enormous amount
of computer power and you will have to tune all your parameters carefully.
You should consider if this approach is feasible.
You cra
I don't know if this is worth all the troube.
Gromacs performance is not very dependent on FFT speed (unless you
choose your parameters badly). FFTW is faster than anything else
on most platforms (often including hardware vendor specific FFT's).
Simply sticking to FFTW will probably never result i
> Date: Fri, 18 Sep 2009 16:24:21 +1000
> From: mark.abra...@anu.edu.au
> To: gmx-users@gromacs.org
> Subject: Re: [gmx-users] Can Gromacs produce the data from NMR?
>
> Chih-Ying Lin wrote:
> >
> >
> > HI
> > Can Gromacs produce the data from NMR?
>
> No, if my guess at what "data" you mean
Hi,
The only program that really uses chain identifiers is pdb2gmx.
It uses chain identifiers to recognize different protein (or DNA)
molecules that appear sequentially in pdb files.
All other programs will read chain identifiers and write them out again.
Also Gromacs will add chain identifiers f
core i7, with 4 (or fewer) tasks each on their own real core it would
be
mpirun -np 4 taskset 0x55 mdrun
I don't have access to a cpu with hyperthreading right now so I can't check
whether it actually works, though.
Sander
On Sep 15, 2009, at 18:41 , Berk Hess wrote:That is incorrect.
That is incorrect.
A Core I7 is about 40% faster with hyperthreading turned off.
A Core I7 is about 65% faster with hyperthreading turned on
and running 8 processes.
What you should NOT do (but which can happen very easily)
is running on a Core I7 with hyperthreading turned on and using
only 4 p
> Date: Wed, 16 Sep 2009 01:58:02 +1000
> From: mark.abra...@anu.edu.au
> To: gmx-users@gromacs.org
> Subject: Re: [gmx-users] question about using new potential in groamcs
>
> 青 叶 wrote:
> > Hello everybody:
> >I have read GROMACS' manual and found that the non-bond interaction
> > in
to the virial.
Berk
> Date: Tue, 15 Sep 2009 17:48:32 +0200
> From: alexander.h...@mytum.de
> To: gmx-users@gromacs.org
> Subject: Re: [gmx-users] non isotropic kinetic energy
>
> Berk Hess schrieb:
> > Yes, we can agree that they are rigid bodies.
> >
>
up.
Berk
> Date: Tue, 15 Sep 2009 12:57:59 +0200
> From: alexander.h...@mytum.de
> To: gmx-users@gromacs.org
> Subject: Re: [gmx-users] non isotropic kinetic energy
>
> Berk Hess schrieb:
> > Equipartitioning only works per degree of freedom, not per atom.
> >
&g
Equipartitioning only works per degree of freedom, not per atom.
It works for translation and rotation of a water molecule,
but that requires a transformation from atomic to COM trans and rot
coordinates.
The standard Ekin in Gromacs determines translational kinetic energy.
Of the three rotation
ce over
> equipartition of energy in the system. I'm still not convinced the
> ensemble is correct.
>
> Alex
>
>
> Berk Hess schrieb:
> > Equipartitioning still holds.
> > The issue here is that constraints remove degrees of freedom.
> > If you remo
If mdrun hangs -maxh won't help.
You can kill mdrun using the kill command.
But since mdrun catches signals, you might need kill -9 (the 'KILL' signal).
Berk
> Date: Mon, 14 Sep 2009 10:56:43 -0400
> From: jalem...@vt.edu
> To: gmx-users@gromacs.org
> Subject: Re: [gmx-users] Limit mdrun runtime
Hi,
You have explicitly specified md_0_1_prev.cpt instead of md_0_1.cpt as
checkpoint.
So you are using the previous checkpoint instead of the last one.
The final result will be fine, but you will be redoing part of a simulation
that you had already done.
Berk
> Date: Mon, 14 Sep 2009 14:59:54
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
> l
> Date: Sat, 12 Sep 2009 02:35:28 +1000
> From: mark.abra...@anu.edu.au
> To: gmx-users@gromacs.org
> Subject: Re: [gmx-users] R: problems running REMD on grids
>
> Anna Marabotti wrote:
> > I'm re-sending the message below because it seems to me that it has not
> > arrived to the list.
> > Ple
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 quanti
Hi,
You don't say at all what your systems looks like, so it is difficult to give
proper advice.
As far as electrostatics is concerned, this scaling has very little effect
on the accuracy of the results.
For the Lennard-Jones interaction however, the longer cut-off
puts many more pairs in the int
You don't need a gro file.
If you do, for instance, grompp -h
you will see that all Gromacs programs can read pdb as well as gro.
Berk
Date: Wed, 9 Sep 2009 17:29:15 -0700
From: kgp.a...@gmail.com
To: gmx-users@gromacs.org
Subject: [gmx-users] bypassing pdb2gmx
hi everyone,
I have a pdb file of
Are you sure your initial distance is -3.5 along (0,0,-1),
this means the distance is actually +3.5 in z.
Another issue could be that 3.5 is more than half the box size.
I think we should add a check for too long distances,
so users get a clear error message and they do not need to contact
the ma
Hi,
The LIE approach might work in vacuum (although the vacuum itself is a gross
approximation).
But I don't see how you can do that in solution.
The only way to get a reasonable estimate is by doing free-energy calculations,
either PMF or growing the ligand.
Another possibility could be implic
Things are a bit confusing here.
SETTLE versus other constraint algorithm is chosen at the topology level
by putting [ settle ] or [ constraints ] sections in your topology.
With of the other constraint algorithms (LINCS or SHAKE) is used
for the constraints in the [ constraints ] sections is set
nder.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:
> > Thin
:47:05 +0200
From: Berk Hess
Subject: RE: [gmx-users] question about PME
To: Discussion list for GROMACS users
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
This is tricky matter.
The direct interaction between the ions is 1/(4 pi eps0) r (ignoring periodi
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
This is tricky matter.
The direct interaction between the ions is 1/(4 pi eps0) r (ignoring periodic
effects).
However, the interaction is screened by the water and therefore the effective
interaction is 1/(4 pi eps0 epsr) r, where epsr is the dielectric constant of
the water model.
The periodi
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 th
nt
> 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
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?
>
&
Hi,
g_msd calculates the msd for molecules, not for atoms.
I guess that would explain the result when you half the chain length.
It might also explain the box size effects, since whole chains will
still have a reduction in MSD due to periodiciy with a box of 3 Rg.
If you run g_msd without -mol y
I meant 3 instead of 30 ps.
I would say 1 ps is too short for systems with a phase with large molecules___
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs
Hi,
This problem is not very strange at all.
Different CPU's have different efficiencies for different types of code.
In this case the Opteron and new Xeon have measurably different
(although probably not more than 20%) relative performance
for particle-particle and PME interactions.
Also, your
Unfortunately the manual was made before these lines where removed
from the mdrun help text.
Berk
Date: Wed, 2 Sep 2009 12:40:23 -0400
Subject: Re: [gmx-users] Gromacs 4.0.4 - Pull.pdo File
From: vhariharan2.grom...@gmail.com
To: gmx-users@gromacs.org
Hello,
Thanks for the info.á The informati
: mariagorano...@gmail.com
To: gmx-users@gromacs.org
I will change the tau_p values, and report back. This might take more than a
week though.
maria
On Wed, Sep 2, 2009 at 5:16 PM, Berk Hess wrote:
It might actually affect the center of mass motion removal,
because you would be scaling your
_algorithm = Lincs
unconstrained_start = no
lincs_order = 4
lincs_warnangle = 30
On Wed, Sep 2, 2009 at 4:33 PM, Berk Hess wrote:
Hi,
I am 99.99% sure that there is no problem with COM motion removal in Gromacs.
Could you post your mdp parameters?
Berk
>
Hi,
I am 99.99% sure that there is no problem with COM motion removal in Gromacs.
Could you post your mdp parameters?
Berk
> From: x.peri...@rug.nl
> To: gmx-users@gromacs.org
> Subject: Re: [gmx-users] Martini simulation problem in recentering trajectory
> so that the bilayer is at the center
d.
>
> 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
Hi,
Gromacs 4 no longer has ppa and pdo files.
The pull parameters are part of the mdp options, have a look at the manual.
Berk
Date: Wed, 2 Sep 2009 09:40:56 -0400
From: vhariharan2.grom...@gmail.com
To: gmx-users@gromacs.org
Subject: [gmx-users] Gromacs 4.0.4 - Pull.pdo File
Hello,
My .mdp
nd 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 p
e 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
t;
> 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
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
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
n't know how
> many times I've made that mistake and couldn't find it myself...
>
> Thanks,
> Bob
>
> On Tue, Sep 1, 2009 at 2:34 AM, Berk Hess wrote:
> > Hi,
> >
> > Firstly, you are not constraining (runtype=constraint), but using a harmonic
&g
Hi,
If something is periodic or cyclic only depends on the coordinates,
in the topology there is no difference.
That is the reason for the periodic_molecules mdp option.
You will have to manually add the bond, angles, dihedrals and pairs
for the periodic (or cyclic) bond to the topology.
Berk
Hi,
Gromacs has the half as a pre-factor in the potential.
Note that in 4.0.5 there is a g_wham program which can automatically
do the WHAM analysis on the mdrun output.
Berk
> Date: Tue, 1 Sep 2009 13:19:32 +0800
> From: mirc...@sjtu.edu.cn
> To: gmx-users@gromacs.org
> Subject: [gmx-users] F
Hi,
Firstly, you are not constraining (runtype=constraint), but using a harmonic
umbrella potential.
Secondly, your distance of 28.9 nm seems enormous, maybe you mixed
up nanometers and Angstroms here?
Thirdly, I would strongly suggest to switch to Gromacs 4.0.5.
I have completely rewritten the
p; mask );
Berk
> Date: Mon, 31 Aug 2009 15:39:05 +0200
> From: alexander.h...@mytum.de
> To: gmx-users@gromacs.org
> Subject: Re: [gmx-users] continuation
>
> Hi,
>
> yes, the trr is 7GB.
>
> Alex
>
> Berk Hess schrieb:
> > Hi,
> >
> > -appe
Hi,
No, that assumes that all points are independent.
Which they might be, but they are usually not.
It is still not clear to me if you want the error of the exponential
difference of the error of the direct energies.
g_analyze -ee will give you an error estimate, but only based
on the printed
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: g
I don't understand what you want exactly.
Your g_energy command does exponential averaging, that happens
on the printed data points. So there g_analyze or any program will do fine.
For the original data g_energy gives the exact standard deviation
over all MD steps, called RMSD.
But do you really
des only energy calculations, but not forces?
>
> Regards,
> Leonid
>
>
> From: gmx-users-boun...@gromacs.org [gmx-users-boun...@gromacs.org] On Behalf
> Of Berk Hess [g...@hotmail.com]
> Sent: Thursday, August 27, 2009 2:59 PM
> To:
There is a misunderstanding here about noticing.
For efficiency reasons, the code does not check if atoms are beyond the table
length.
So the code does not care about or notice anything.
However, you do care, since you do not want random forces.
(Although in nearly all cases the force will be, o
for LJ and coulomb may also be checked out?
Geraldine
-E-mail d'origine-
De : Berk Hess
A : Discussion list for GROMACS users
Envoyé le : Jeudi, 27 Août 2009 13:45
Sujet : RE: [gmx-users] PULL CODE AND NpT ensemble
Hi,
I would use v-rescal
Hi,
Gromacs does not do anything special for frozen atoms.
You have to make sure that you do not calculate forces between frozen atoms,
if you want the virial to be correct.
Berk
> Date: Thu, 27 Aug 2009 14:46:47 +0200
> From: alexander.h...@mytum.de
> To: gmx-users@gromacs.org
> Subject: [gmx-
Hi,
I would use v-rescale and Berendsen pressure coupling.
Although Berendsen pressure coupling, strictly speaking, does not give the
correct ensemble,
in practice it produces negligible artifacts, unless you are looking at
pressure/volume fluctuations.
Berk
To: gmx-users@gromacs.org
Date: Th
Hi,
No, this is not correct.
A interaction beyond the cut-off + table-extension will get a random energy and
force
depending on what is stored in the memory of your computer beyond the table___
gmx-users mailing listgmx-users@gromacs.org
http://lis
Hi,
Did you try to load the file into xmgrace?
That will give you more readable output.
I don't know what you mean with Psi.
s2 is , where U is the interaction energy between the inserted
molecule and the system. V is the volume of that frame.
The entry s4 gives the average potential energy: .
T
You simply replace pull=umbrella with pull=constraint.
Strictly speaking this is not correct in Gromacs when you have bond constraints
between parts of the molecule that you pull and do not pull,
in practice I have not seen any artifacts when the pull groups are not very
small.
Berk
Date: Mon,
Hi,
I don't understand what you want or why you want this.
If it is necessary (you have constraint in your molecule between different
charge groups and you run in parallel with domain decomposition)
Gromacs will automatically use P-LINCS.
Berk
> Date: Mon, 24 Aug 2009 19:24:32 +0800
> From: dcp
> Date: Sat, 22 Aug 2009 20:01:19 -0400
> From: jalem...@vt.edu
> To: gmx-users@gromacs.org
> Subject: Re: [gmx-users] Re: Pull to separate dimer
>
>
>
> Ragnarok sdf wrote:
> > Hi Justin, yes the intention is to pull the dimer apart within the
> > plane of the bilayer. I've ran a few
Hi,
For systems with vacuum the automatic domain decomposition setup does
not do a good job. It currently decomposes based on the box dimensions,
not on the actual atom distribution in the box.
I was thinking of improving this a bit for 4.1.
I would guess -dd 4 2 1 will give the best performance
> From: rolf.is...@rwth-aachen.de
> To: gmx-users@gromacs.org
> Date: Tue, 11 Aug 2009 12:14:12 +0200
> Subject: [gmx-users] many charges within one atom
>
> Hi everybody,
>
> I'm trying to run simulations with a charge distribution within one single
> atom. Is there a way to create a molecul
No, it should be exactly opposite.
I guess you must have done something wrong (forgot to run grompp or mdrun?).
Exclusions only affect non-bonded interactions.
Pair interactions do not influence and are not influenced by the exclusions
section
or non-bonded interactions.
Berk
Date: Mon, 10 Aug
> Date: Mon, 10 Aug 2009 22:11:57 +1000
> From: mark.abra...@anu.edu.au
> To: gmx-users@gromacs.org
> Subject: Re: [gmx-users] About exclusion of non-bonded interaction for pairs
> of energy groups
>
> Berk Hess wrote:
> >
> >
> >> Date: Mon, 10 Au
> Date: Mon, 10 Aug 2009 20:52:31 +1000
> From: mark.abra...@anu.edu.au
> To: gmx-users@gromacs.org
> Subject: Re: [gmx-users] About exclusion of non-bonded interaction for pairs
> of energy groups
>
> Lee Soin wrote:
> > Hello!
> > Sorry to bother you again, but I have another question. I ha
All the discussion is mainly a matter about how paranoid you are.
A Berendsen barostat does not generate a proper ensemble.
But it does get the average pressure right. The questions is how large
the effects of the "ensemble error" is. I would say that in practice
this would be negligible compared
cess? or some further
suggestions?
thanks a lot!
regards,
Baofu Qiao
Berk Hess wrote:
I think this might be a bug in the checkpointing code.
The negative number is correct, these are the lower 32 bits of the file offset.
But they are combined incorrectly with the higher part.
Could yo
gmx-users-requ...@gromacs.org
>
> You can reach the person managing the list at
> gmx-users-ow...@gromacs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gmx-users digest..."
>
>
> Today's To
Hi,
Never ever use switched cut-off's!
Switched cut-off's can give extremely strong artifacts.
In 4.1 grompp will warn you about this.
Switch gives you correct energies at short range, but incorrect forces
in the switching region.
What you want is correct forces up to (nearly) the cut-off.
Shift
w = 0
output filename = T298.xtc
file_offset_high = 0
file_offset_low = 2144960064
output filename = T298.edr
file_offset_high = 0
file_offset_low = 19540796
***
It seems that the difference is: there is a negative number
(-2020699160) in the former case.
My guess would be that for some reason (which I don't know),
your xtc file has not been written to disk completely.
You can check this by using gmxdump -cp on your checkpoint file
and looking at the size of the xtc file.
Berk
> Date: Fri, 7 Aug 2009 10:19:35 +0200
> From: qia...@gmail.com
> To:
Good question.
I guess the best proper solution would be to use a Parrinello-Rahman barostat.
But in Gromacs this is currently not implemented in a reversible way.
In practice I think the issues with the Berendsen thermostat are not relevant.
It does not generate the correct pressure and volume
Hi,
First, please switch to 4.0.5, I have put several fixes in the pull code
in the 4.0 minor releases.
You did not specify pull_init1, nor pull_start, this means you start pulling
at a distance of 0, which means the center of the bilayer.
Setting
pull_start = yes
should fix your problem.
Berk
> 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
spherical integration.
On Aug 4, 2009, at 10:41 AM, Berk Hess wrote:Hi,
You can look at the code yourself :)
I coded this and -or (which I assume you are talking about)
is G with 1/nm as a unit.
It gives the probability that a particle has moved a distance r.
The 1/nm is the normalization to make the
Hi,
You can look at the code yourself :)
I coded this and -or (which I assume you are talking about)
is G with 1/nm as a unit.
It gives the probability that a particle has moved a distance r.
The 1/nm is the normalization to make the values bin-size independent.
Might it be that the difference
No, you can not use pair parameter generation at all with Buckingham,
since 1-4 interactions are always LJ and you can not convert Buckingham
to LJ parameters. Unfortunately Gromacs 4.0 does not check for gen-pairs=yes,
Gromacs 4.1 will give a fatal error when you turn it on.
Dispersion correctio
Ah, I can make some more advertisement for my own work.
Have a look at this paper:
http://dx.doi.org/10.1021/jp0641029
Berk
> Date: Fri, 31 Jul 2009 20:40:31 -0400
> From: jalem...@vt.edu
> To: gmx-users@gromacs.org
> Subject: Re: [gmx-users] GROMACS parameterization
>
>
>
> rams rams wrote:
> >
> > 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"
> >
301 - 400 of 1087 matches
Mail list logo
