Hi,
The -testverlet option is only for testing (as the name implies).
Please set the mdp option cutoff-scheme = Verlet
Also please update to 4.6.3, as this, potential, issue might have already been
resolved.
With the Verlet scheme the CPU and GPU should give the same, correct or
incorrect,
to reproduce the viscosity calculation of SPC water by Berk Hess
(JCP 116, 2002) using cos_acceleration in Gromacs. The answer I get is 2
orders of magnitude out.
My topology file and parameter file is appended at the bottom of this email.
I run g_energy and get
Energy
Hi,
You're using thread-MPI, but you should compile with MPI. And then start as
many processes as total GPUs.
Cheers,
Berk
From: chris.ne...@mail.utoronto.ca
To: gmx-users@gromacs.org
Date: Wed, 24 Apr 2013 17:08:28 +
Subject: [gmx-users] How to use multiple nodes, each with 2 CPUs
Hi,
Twin-range will lead to extra errors, which could be negligible or not.
But the errors should be the same and have the same effects in different
versions.
I think nothing has changed in the twin-range treatment from 4.5 to 4.6, but I
am not 100% sure.
Which version with twin-range matches
Hi,
The PME settings you mention won't make any difference.
I don't see anything that can explain the differnce.
But are you sure that the difference is statistically relevant?
How did you determine sigma?
There could be long time correlations in your system.
Have you check the temperature? You
Hi,
I don't know enough about the details of Lustre to understand what's going on
exactly.
But I think mdrun can't do more then check the return value of fsync and
believe that the file is completely flushed to disk. Possibly Lustre does some
syncing, but doesn't actually flush the file
Hi,
The code compiled, so the compiler is not the issue.
I guess mdrun picked up GPU 0, which it should have ignored. You only want to
use GPU 1.
Could you try running:
mdrun -ntmpi 1 -gpu_id 1
Cheers,
berk
Date: Thu, 28 Mar 2013 10:51:58 +0200
Subject: Re: [gmx-users] no CUDA-capable
-scheme = Verlet
and run grompp to get a new tpr file.
Cheers,
Berk
From: iitd...@gmail.com
Date: Thu, 28 Mar 2013 14:57:16 +0530
Subject: Re: [gmx-users] no CUDA-capable device is detected
To: gmx-users@gromacs.org
On Thu, Mar 28, 2013 at 2:41 PM, Berk Hess g...@hotmail.com wrote:
Hi
Hi,
Gromacs calls fsync for every checkpoint file written:
fsync() transfers (flushes) all modified in-core data of (i.e., modi-
fied buffer cache pages for) the file referred to by the file descrip-
tor fd to the disk device (or other permanent storage device) so that
Hi,
Note that the linear algebra in Gromacs is limited to eigenvalue solving in two
analysis tools,
the MD engine does not use any (large) linear algebra.
So linear algebra library performance is irrelevant, except for the cases where
users
would want to repeated uses one of the two tools with
Date: Thu, 7 Mar 2013 14:54:39 +0200
From: eyurt...@abo.fi
To: gmx-users@gromacs.org
Subject: RE: [gmx-users] Re: [gmx-developers] Gromacs 4.6.1 ATLAS/CUDA
detection problems...
On Thu, 7 Mar 2013, Berk Hess wrote:
Hi,
Note that the linear algebra in Gromacs
Hi,
There are two scripts make_gromos_rtp in the scripts directory which were used
to convert Gromos AA topologies to rtp entries.
Cheers,
Berk
From: stephane.a...@cea.fr
To: gmx-users@gromacs.org
Date: Thu, 14 Feb 2013 11:34:59 +
Subject:
Hi,
With tau_t=2 the sd1 integrator should be ok.
But in 4.6.1, which will be released this week, the performance issues with the
sd integrator are fixed.
Cheers,
Berk
Date: Wed, 13 Feb 2013 09:19:46 +0300
From: jmsstarli...@gmail.com
To: gmx-users@gromacs.org
Subject: [gmx-users] on the
Hi,
You don't need SLI for multi-GPU simulations in Gromacs.
But you do need a real MPI library and configure Gromacs with -DGMX_MPI=on
Then you need to start Gromacs with (depending on you MPI library):
mpirun -np #GPUs mdrun
If anything, the performance of Gromacs should have gotten better
, Berk Hess g...@hotmail.com wrote:
One last thing:
Maybe a macro is not set, but we can actually query the number of
processors.
Could you replace the conditional that gets triggered on my machine:
#if defined(_SC_NPROCESSORS_ONLN)
to
#if 1
So we can check
Hi,
All AMBER force fields in Gromacs which are also available in AMBER have been
validated against energies from the AMBER package.
Cheers,
Berk
Date: Wed, 6 Feb 2013 13:48:13 +0200
From: g...@bioacademy.gr
To: gmx-users@gromacs.org
Subject:
Hi,
This looks like our CPU detection code failed and the result is not handled
properly.
What hardware are you running on?
Could you mail the 10 lines from the md.log file following: Detecting
CPU-specific acceleration.?
Cheers,
Berk
Date: Tue, 5
time: AVX_128_FMA
Table routines are used for coulomb: FALSE
Table routines are used for vdw: FALSE
I am not too sure about the details for that setup, but the brand looks
about right.
Do you need any other information?
Thanks for looking into it!
2013/2/5 Berk Hess g...@hotmail.com
Hi
for sysconf argument values */
From /etc/issue:
Welcome to openSUSE 12.2 Mantis - Kernel \r (\l)
From uname -a:
Linux kafka 3.4.11-2.16-desktop #1 SMP PREEMPT Wed Sep 26 17:05:00 UTC 2012
(259fc87) x86_64 x86_64 x86_64 GNU/Linux
2013/2/5 Berk Hess g...@hotmail.com
Hi,
This is the same
your workaround, thanks!
2013/2/5 Berk Hess g...@hotmail.com
OK, then this is an unhandled case.
Strange, because I am also running OpenSUSE 12.2 with the same CPU, but
use gcc 4.7.1.
I will file a bug report on redmine.
Could you also post the header of md.log which gives all
,
although both options are available there. The difference I am told results
in a smaller area/lipid for the bilayers.
Best,
Jesper
On Jan 24, 2013, at 1:09 PM, Berk Hess g...@hotmail.com wrote:
Hi,
I am not a fan of especially switching the potential, as that produces
artifacts
Hi,
Performance in single precision on Tesla cards is often lower than on GTX cards.
The only reason to buy Telsa cards is double precision, reliability and fanless
cards for clusters.
I have a GTX 660 Ti, which is much cheaper than a GTX 670, but should have
nearly the same
performance in
Hi,
I am not a fan of especially switching the potential, as that produces
artifacts.
Shifting is less harmful, but unnecessary in nearly all cases.
But I do realize some force fields require this (although you can probably find
a cut-off
setting at which results would be very similar).
Hi,
The virial has no meaning per atom.
And you can't get the virial per atom out of Gromacs, it is never calculated in
that way (see the manual for details).
A special local pressure version of Gromacs exists, but even there you won't
get a virial per atom.
Cheers,
Berk
, 2013 at 4:45 PM, Berk Hess g...@hotmail.com wrote:
The issue I'm referring to is about a factor of 2 in update and
constraints, but here it's much more.
I just found out that the SD update is not OpenMP threaded (and I even
noted in the code why this is).
I reopened the issue
Hi,
Unfortunately this is not a bug, but a feature!
We made the non-bondeds so fast on the GPU that integration and constraints
take more time.
The sd1 integrator is almost as fast as the md integrator, but slightly less
accurate.
In most cases that's a good solution.
I closed the redmine
Date: Wed, 16 Jan 2013 16:20:32 +0100
Subject: Re: [gmx-users] 60% slowdown with GPU / verlet and sd integrator
From: mark.j.abra...@gmail.com
To: gmx-users@gromacs.org
We should probably note this effect on the wiki somewhere?
Mark
On Wed, Jan 16, 2013 at 3:44 PM, Berk Hess
Hi,
As the new Verlet cut-off scheme, also used on the GPU, uses separate non-bonded
coordinate and force buffers, implementing this will require very little code
changes.
All real variables in the nbnxn_atomdata_t data structure and in all code
operating
on them should be replaced by floats.
Date: Thu, 29 Nov 2012 08:58:50 -0500
From: jalem...@vt.edu
To: gmx-users@gromacs.org
Subject: Re: [gmx-users] Electrostatic field in atoms - GROMACS is not
reading table interaction functions for bonded interactions
On 11/29/12 8:18 AM, Ariana
: Discontinuity in first time-step velocities
for diatomic molecule locally coupled to thermal drain
tcoupl =v-rescale
See grompp .mdp below
Inon Sharony
ינון שרוני
Berk Hess [via GROMACS] ml-node+s5086n4999279...@n6.nabble.com כתב:
Hi,
You can't have ret_t=0 with Nose-Hoover.
We
Hi,
You can't have ret_t=0 with Nose-Hoover.
We should add a check for this.
Cheers,
Berk
Date: Thu, 28 Jun 2012 11:15:15 +0300
From: inons...@tau.ac.il
To: gmx-users@gromacs.org
Subject: [gmx-users] Discontinuity in first time-step velocities for diatomic
molecule locally coupled to
Hi,
This is the same issue as in your other mail: ref_t should be 0.
Cheers,
Berk
Date: Tue, 3 Jul 2012 17:38:37 +0300
From: inons...@tau.ac.il
To: gmx-users@gromacs.org
Subject: [gmx-users] Nose-Hoover does not couple
I'm performing a
:
-- Message: 3 Date: Mon, 19 Mar 2012
18:34:31 +0100 From: Berk Hess g...@hotmail.com Subject: RE:
[gmx-users] problem with g_bar To: Discussion list for GROMACS users
gmx-users@gromacs.org Message-ID:
col113-w32c019ba58913fec173e168e...@phx.gbl Content-Type:
text/plain; charset=iso
Hi,
Yes, there is a problem with different temperature variables being single and
double precision.
Does the one line change below fix the problem?
Cheers,
Berk
-if ( ( *temp != barsim-temp) (*temp 0) )
+if ( !gmx_within_tol(temp,barsim-temp,GMX_FLOAT_EPS) (*temp 0) )
Date:
Hi all,
The NAIS Centre in Edinburgh is holding a Workshop on State-of-the-Art
Algorithms for Molecular Dynamics on May 2-4.
The days before this workshop, April 30-May 2, I and David Hardy from NAMD will
organize a tutorial on the use of GPUs and parallel computing. Here, among
other things,
Hi,
For systems or your size, they should run about equally fast.
Berk
From: davidmcgiv...@gmail.com
To: gmx-users@gromacs.org
Subject: Re: [gmx-users] 4 x Opteron 12-core or 4 x Xeon 8-core ?
Date: Thu, 20 Jan 2011 14:39:14 +0100
Dear Carsten,
Thanks for the advice!
The thing is
Date: Wed, 19 Jan 2011 19:13:12 +0100
From: sp...@xray.bmc.uu.se
To: gmx-users@gromacs.org
Subject: Re: [gmx-users] Important: Bugs in NEMD calculation
On 2011-01-19 18.36, Xiaohu Li wrote:
Hi, All,
I've found a bug in the NEMD calculation for viscosity. This has
been
Date: Wed, 19 Jan 2011 20:52:13 +0100
From: sp...@xray.bmc.uu.se
To: gmx-users@gromacs.org
Subject: Re: [gmx-users] Important: Bugs in NEMD calculation
On 2011-01-19 20.43, Berk Hess wrote:
Date: Wed, 19 Jan 2011 19:13:12 +0100
From: sp...@xray.bmc.uu.se
To: gmx-users
Subject: [gmx-users] RE: Important: Bugs in NEMD calculation
Date: Wed, 19 Jan 2011 20:43:20 +0100
From: Berk Hess g...@hotmail.com
Subject: RE: [gmx-users] Important: Bugs in NEMD calculation
To: Discussion list for GROMACS users gmx-users@gromacs.org
Message-ID: col113
Yes.
The pow function is expensive though. The code will run much faster
if you can use rinvsix, such as check for 2*rinvsix c6/c12.
(I forgot the factor 2 in my previous mail).
Berk
From: makoto-yon...@aist.go.jp
To: gmx-users@gromacs.org
Date: Tue, 11 Jan 2011 10:10:56 +0900
Subject:
Date: Mon, 10 Jan 2011 14:04:34 +0100
From: sp...@xray.bmc.uu.se
To: gmx-users@gromacs.org
Subject: Re: [gmx-users] truncated LJ potential
On 2011-01-10 13.39, Makoto Yoneya wrote:
Dear GROMACS experts:
I'd like to use a modified Lennard-Jones potential (smoothly truncated at
From: makoto-yon...@aist.go.jp
To: gmx-users@gromacs.org
Date: Mon, 10 Jan 2011 23:57:46 +0900
Subject: [gmx-users] truncated LJ potential
Dear David and Hess:
Thanks a lot for quick replies.
please look into gromacs' table potential functionality, it is described
in the
and many thanks for attention dear Berk.
Alan
From: Berk Hess g...@hotmail.com
Subject: RE: [gmx-users] RE: [ atomtypes ] are not case sensitive?
Hi,
I don't know if any thinking went into the (non) case specifity of atom types.
Nearly all string comparisons in Gromacs are not case specific
Hi,
I think the problem is epsilon_r=80, which reduces your electrostatics
interactions
by a factor of 80.
Berk
Date: Mon, 13 Dec 2010 17:46:14 -0500
From: jalem...@vt.edu
To: gmx-users@gromacs.org
Subject: Re: [gmx-users] pathologically expanding box
Greg Bowman wrote:
Hello,
Hi,
No this is actually a bug in tpbconv.
-nsteps will not work, because that uses a normal int, not a 64-bit integer.
-dt should work, but on line 531 of src/kernel/tpbconv.c (int) should be
replaced by (gmx_large_int_t).
But are you sure you want to add a millisecond to your simulation time?
Hi,
I fixed the bug for 4.5.4.
If you want an unlimited number of steps, use:
tpbconv -nsteps -1
Berk
From: g...@hotmail.com
To: gmx-users@gromacs.org
Subject: RE: [gmx-users] Re: tpbconv extension
Date: Mon, 13 Dec 2010 17:44:53 +0100
Hi,
No this is actually a bug in tpbconv.
Sorry, I mistook a million ps for a millisecond, this is a microsecond.
The maximum number of steps in version 4.0 is INT_MAX, which is 2,147,483,647.
From the name of your tpr file it seems you are not exceeding this,
so I don't know what's wrong exactly.
But for this reason (and many other
would work on a server with older version of Gromacs
i.e. 4.0...
Ram
On Mon, Dec 13, 2010 at 6:04 PM, Berk Hess g...@hotmail.com wrote:
Sorry, I mistook a million ps for a millisecond, this is a microsecond.
The maximum number of steps in version 4.0 is INT_MAX, which is
2,147,483,647
Hi,
Note that it is impossible to decompose a free energy (difference), which a PMF
is,
uniquely into different energy or force components.
A free energy is not simply the sum of energy terms, but is the result of how
different energy terms together affect the accessible phase space.
The effect
Subject: Re: [gmx-users] Hard Spheres
From: sascha.hem...@bci.tu-dortmund.de
To: gmx-users@gromacs.org
Date: Thu, 9 Dec 2010 08:56:54 +0100
On Wed, Dec 8, 2010 at 4:01 AM, Sascha Hempel
sascha.hem...@bci.tu-dortmund.de wrote:
Hi all!
I am trying to add
Hi,
There have been some issues with version 4.5.1 and energy files and
continuation.
But I don't recall them being this fatal.
Anyhow, it would be better to upgrade to version 4.5.3, which contains several
bug fixes.
Berk
From: mstu...@slb.com
To: gmx-users@gromacs.org
Date: Wed, 8 Dec 2010
Hi,
Unfortunately constraints can not be applied to virtual sites and grompp
apparently
does not not check for this. I will add a check.
Constraints between virtual sites can lead to very complex constraint equations
between the masses involved. Thus the general case if difficult to implement.
Hi,
The integrator is not the issue. The cut-off setup is.
You should use interactions that go smoothly to zero with a buffer region in
the neighborlist.
Use for instance shift for LJ interactions. PME could be switched, but that is
a much smaller
contribution. Use rlist about 0.3 nm larger
Hi,
Maybe it is not so clear from the topology table in the manual, but when you
supply
sigma and epsilon as non-bonded parameters, as for OPLS, the nonbond_params
section also expects sigma and epsilon.
So it seems you could not set only C6 to zero.
However there is an, undocumented, trick: if
Hi,
Note that grompp prints the atomtype that causes the problems.
You should copy the last line of share/top/charmm27.ff/gb.itp and rename MCH3
to MCH3S.
I have fixed this for 4.5.3 and I have also made the grompp error messages
clearer.
Berk
From: zhn...@gmail.com
To:
= 1.0
ewald_geometry= 3dc
nwall= 2
wall_type= 9-3
wall_r_linpot= 1
wall_atomtype = opls_966 opls_968
wall_density= 9-3 9-3
wall_ewald_zfac= 3
pbc= xy
fourierspacing = 0.18
Regards
Vinoth
On Tue, Nov 2, 2010 at 3:41 PM, Berk Hess g
Hi,
I saw your message, but I wanted to discuss with others before answering.
I have not had a chance for that yet, but I can answer anyhow.
1. This is a mistake. The person converting the original Charmm files edited
his conversion
script, but the special cases can not be treated with this
I forgot to say that for the water models the rtp entries are only used to
recognize
the atoms. For the topology the itp files in the .ff dir are used.
Berk
From: g...@hotmail.com
To: gmx-users@gromacs.org
Subject: RE: [gmx-users] Single atom charge group implementation for
CHARMM27 in
Hi,
With wall_r_linpot your wall potential is linear from 1 nm downwards.
Since the LJ force is negative at 1 nm, your atoms are attracted to the walls.
But why not simply use two interfaces? You get double the sampling for free
and you do not have to bother with complicated wall setups.
Berk
xy. any
help is highly appreciated.
Regards
Vinoth
On Tue, Nov 2, 2010 at 1:37 PM, Berk Hess g...@hotmail.com wrote:
Hi,
With wall_r_linpot your wall potential is linear from 1 nm downwards.
Since the LJ force is negative at 1 nm, your atoms are attracted to the walls.
But why not simply
: kmvin...@gmail.com
To: gmx-users@gromacs.org
Hi Berk
Thank you once again. How can i use thick layers and what is the procedure? can
you explain it bit more on this?
Regards
Vinoth
On Tue, Nov 2, 2010 at 3:18 PM, Berk Hess g...@hotmail.com wrote:
Hi,
I have not heard about such issues
Well, it seems that any double precision energy file can not be read by 4.5.1
or 4.5.2 code.
This is such a serious issue that we should bring out 4.5.3 within a week.
If you only need the box, g_traj can produce that.
If you need other energies you can use a 4.5.1 g_energy for the moment.
Hi,
Another comment on your interaction settings.
You did not mail if you are using shift or switch for vdw.
But I guess that both probably don't match exactly what Charmm does.
Since the switching range is so long and this is where a large part
of the dispersion attraction acts, this might have
Hi,
We haven't observed any problems running with threads over 24 core AMD nodes
(4x6 cores).
Berk
From: ckut...@gwdg.de
Date: Thu, 21 Oct 2010 12:03:00 +0200
To: gmx-users@gromacs.org
Subject: [gmx-users] Gromacs 4.5.1 on 48 core magny-cours AMDs
Hi,
does anyone have experience
Hi,
You have very strange and complex cut-off settings in Gromacs.
What Charmm settings are you trying to mimic?
Berk
Date: Thu, 21 Oct 2010 15:03:51 +0200
From: jakobtorwei...@tuhh.de
To: gmx-users@gromacs.org
Subject: [gmx-users] CHARMM36 lipid bilayers
Dear gmx-users,
recently Pär
Hi,
You can simply use plain unix cat, that will be much faster and does not use
memory.
If you want the time of the frames right, run trjconv with the right option on
the catted
frames.
Berk
Date: Wed, 13 Oct 2010 08:41:17 +0200
From: sp...@xray.bmc.uu.se
To: gmx-users@gromacs.org
Hi,
Have you checked that your numbers are converged?
Such differences can easily occur when you don't sample enough.
You will have to try very many orientations before you hit the right one
which satisfies all hydrogen bonds.
I tested PME a long time ago. Then it worked correctly.
But it could
Hi,
It's bugzilla 579:
http://bugzilla.gromacs.org/show_bug.cgi?id=579
Actually the title is wrong, the pressure was correct, the pressure scaling,
and thus the density, not.
Berk
Date: Thu, 7 Oct 2010 12:28:15 +0200
Subject: Re: [gmx-users] Re: Problem with pressure coupling
From:
To: gmx-users@gromacs.org
Hi,
thanks for fixing this, Berk. Silly me, I did not include RESOLVED
bugs in my original search and therefore missed it.
Ondrej
On Thu, Oct 7, 2010 at 12:38, Berk Hess g...@hotmail.com wrote:
Hi,
It's bugzilla 579:
http://bugzilla.gromacs.org/show_bug.cgi
Date: Wed, 6 Oct 2010 11:53:56 +0200
Subject: Re: [gmx-users] charmm tip5p in Gmx 4.5.2
From: szilard.p...@cbr.su.se
To: gmx-users@gromacs.org
Hi,
Does anyone have an idea about what time the Gmx 4.5.2 will be released?
Soon, if everything goes well in a matter of days.
And in
I think you don't want to use the gmx2 force field.
It does say DEPRECATED without reason.
Berk
Date: Tue, 5 Oct 2010 21:13:46 +0800
From: kecy...@sina.com
To: gmx-users@gromacs.org
Subject: [gmx-users] Use the TIP4P water model in the gmx2 force field
Hello, I want to use the tip4p water
Hi,
Units are listed in the large table in the topology section of the pdf manual.
(hint: the energy unit everywhere in Gromacs is always kJ/mol and length always
nm)
Berk
Date: Tue, 5 Oct 2010 15:14:18 +0200
From: apanczakiew...@gmail.com
To: gmx-users@gromacs.org
Subject: [gmx-users]
Hi,
We had issues with 4.1 series compilers, but we are not longer sure if there
really
are issues in 4.1.2 and 4.1.3. I would surely avoid 4.1.0 and 4.1.1.
But we found that one or two issues in Gromacs only showed up with 4.1.2 and
4.1.3,
but there were problems in Gromacs, not gcc.
So we
Hi,
I think you are looking at the wrong issue.
Unless your concentration is ridiculously high, the dispersion heterogeneity
will be irrelevant.
Furthermore, at distances were the correction works, the distribution will be
close to homogenous.
But you do have an issue with dispersion
Hi,
The frame time has to be within 0.5*frame spacing of the wanted frame.
If you have checkpoint files, you can use those.
Berk
Date: Mon, 4 Oct 2010 02:24:57 -0700
From: floris_buel...@yahoo.com
To: gmx-users@gromacs.org
Subject: [gmx-users] last frame in trr
Hi,
I want to write
Hi,
You don't need MPI within one machine.
Gromacs 4.5 has a built in thread-mpi library that gets built automatically.
Berk
Date: Tue, 28 Sep 2010 10:22:30 +0200
From: domm...@icp.uni-stuttgart.de
To: gmx-users@gromacs.org
Subject: Re: [gmx-users] MPI and dual-core laptop
-BEGIN
Hi,
g_rdf -surf mol counts the number of atoms within a distance r from the surface,
i.e. the atoms which have a distance of less than r to the closest atom of the
molecule.
Since the surface can be complex and dynamic, normalization is difficult.
Berk
From: ch...@nus.edu.sg
To:
Hi,
For pure water (no ions, no external electric field), reaction field does fine
even with a short cut-off, e.g. 0.9 nm
(use reaction-field-zero if you need good energy conservation).
In case you have long-range fields, use no-cutoff at all (all cut-off to 0 in
the mdp file)
when you system
Hi,
Yes.
Cubic spline interpolation means piecewise interpolation with third order
polynomials.
The terms says nothing about which derivatives are continuous.
Cubic spline interpolation is often used to interpolate between points where
only
the function value itself is provided and in that
Hi,
To avoid complex book keeping and parameter checking, you can only run with no
tabulated interactions
or all tabulated interactions.
But there are standard tables for LJ+Coulomb in the share/top directory.
I don't know what you mean with surface.
A uniform surface can be done with a
Hi,
I think you shouldn't enable fortran.
Berk
From: f.affin...@cineca.it
To: gmx-users@gromacs.org
Subject: Re: [gmx-users] error on compilation on BlueGene/P
Date: Mon, 20 Sep 2010 17:50:48 +0200
... and if I add the --enable-bluegene flag :
Hi,
Could you file a bugzilla?
And what do you mean with -dlb on?
on is not an option, the options are: auto, yes, no
Thanks,
Berk
Date: Mon, 20 Sep 2010 12:22:18 -0700
From: musta...@onid.orst.edu
To: gmx-users@gromacs.org
Subject: [gmx-users] Getting some interesting errors.
Hi,
For position restraints there is an mdp option refcoord_scaling that sets how
the reference positions are affected by pressure scaling.
Berk
Date: Thu, 16 Sep 2010 21:15:38 -0400
From: jalem...@vt.edu
To: gmx-users@gromacs.org
Subject: Re: [gmx-users] about NPT run
zhongjin
Hi,
No, you should never change the charges in a force field!
Run pdb2gmx again with the -nochargegrp option.
That will make the size of all charge groups a single atom.
This will be done automatically in the 4.5.2 release which will be out soon.
Berk
Date: Fri, 17 Sep 2010 02:32:31 -0700
Hi,
The choice of charge is significant even with PME, because of the way
Gromacs makes the neighborlists.
As I mailed before, use the -nochargegrp option of pdb2gmx with the Charmm27 ff.
Berk
Date: Fri, 17 Sep 2010 11:46:36 +0200
From: qia...@gmail.com
To: gmx-users@gromacs.org
Subject:
for any insights you can give.
Tom
Berk Hess wrote:
Hi,
No, you should never change the charges in a force field!
Run pdb2gmx again with the -nochargegrp option.
That will make the size of all charge groups a single atom.
This will be done automatically in the 4.5.2 release
to implement an option to use the CHARMM approach for
treating charge groups (as I understand it when any atom is within the
cutoff then the whole charge group is included).
Sorry for the fairly long message and thanks for any insights you can give.
Tom
Berk Hess wrote:
Hi,
No, you should
Hi,
Of the cheap models I would think tip4p 2001 is the best.
This has been parametrized to reproduce the phase diagram of water
and does surprisingly well.
Berk
From: vvcha...@gmail.com
Date: Fri, 17 Sep 2010 16:01:50 -0400
To: gmx-users@gromacs.org
Subject: [gmx-users] force field to
Hi,
Someone forgot to edit topsort.c when added a new dihedral type.
I fixed it for 4.5.2.
The fix is an addition of one line, see below.
Berk
diff --git a/src/gmxlib/topsort.c b/src/gmxlib/topsort.c
index fbf7aa4..128e57f 100644
--- a/src/gmxlib/topsort.c
+++ b/src/gmxlib/topsort.c
@@ -61,6
Hi,
I don't understand what exactly you want to reproduce.
Standard tip3p and Charmm tip3p are different models, so the density does not
have to be identical.
The Gromacs Charmm FF implementation paper:
http://pubs.acs.org/doi/full/10.1021/ct900549r
gives 1002 for tip3p and 1015 for charmm
Hi,
We did some checking.
The value of the density for tip3p reported in the Gromacs Charmm ff
implementation of 1001.7 is incorrect.
This should have been 985.7. The number of 1014.7 for Charmm tip3p is correct.
I would expect that the difference with your number is mainly due to the
shorter
Hi,
My last comment was not correct. Sorry, too many numbers in my head.
Both your density numbers are too low, more than can be explained by LJ cut-off
settings.
How did you determine the density?
g_density does not give the correct number. The number in our paper for tip3p
(not Charmm
Date: Tue, 14 Sep 2010 13:11:47 +0200
Subject: RE: [gmx-users] Regular vs. CHARMM TIP3P water model
From: nicolas.sa...@cermav.cnrs.fr
To: gmx-users@gromacs.org
Hi,
I don't understand what exactly you want to reproduce.
Standard tip3p and Charmm tip3p are different models, so
Hi,
The choice of constraint algorithm is irrelevant for the results.
As I understood Charmm tip3p has less structure than standard tip3p
and it would not surprise me if the density is different.
But I have never closely looked at Charmm tip3p properties myself.
Berk
Date: Tue, 14 Sep 2010
Hi,
There were several issues which I fixed.
But my test file/system did not give problems with the buggy code.
Could you test it on your system (use release-4-5-patches)?
Thanks,
Date: Tue, 14 Sep 2010 09:12:18 -0400
From: jalem...@vt.edu
To: gmx-users@gromacs.org
Subject: [gmx-users]
Good.
I just calculated tip3p energies for a Charmm tip3p trajectory.
Standard tip3p gives 1.1 kJ/mol per water molecule higher energies.
Thus the LJ on H's gives significant extra attraction which increases the
density.
Berk
Date: Tue, 14 Sep 2010 15:49:03 +0200
Subject: RE: [gmx-users]
Hi,
There is no problem at all and you only got notices, not errors.
In Gromacs version 4.0 and before each frame in an energy file always contained
the energy averages
over the whole simulation up to the current step. For proper checkpointing we
therefore had to write
an energy energy file
Hi,
Gromacs 4.5 compiles with a built-in thread mpi library by default.
So you don't need --enable-mpi.
With built in thread-mpi mdrun has an option -nt with by default uses all
threads.
Berk
From: lida...@gmail.com
Date: Sat, 11 Sep 2010 05:19:57 -0400
Subject: Re: [gmx-users] About
scrubbed). I could also just patch the
relevant parts of version 4.5.1 and test that out. If this would be
feasible, then what specific lines should I modify?
-Kevin
Date: Thu, 9 Sep 2010 17:19:36 +0200
From: Berk Hess g...@hotmail.com
Subject: RE: [gmx-users] Overflow problem with test
as intended, isn't it?
Well, I know I could be a bit confused
Javier
El 09/09/10 17:19, Berk Hess escribió:
Hi,
I realized now that this is an SSE issue.
Normally you would get NAN (or is it INF?). That is treated correctly
in the GROMACS TPI code.
But in SSE a float wraps around
1 - 100 of 981 matches
Mail list logo
