Re: [gmx-users] BUG in angular removal part??

[Xiaohu Li]

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.gromacs.org/pipermail/gmx-users/attachments/20110427/e5919199/attachment-0001.html

--

Message: 4
Date: Wed, 27 Apr 2011 08:24:52 +0200
From: David van der Spoel 
Subject: Re: [gmx-users] BUG in angular removal part??
To: Discussion list for GROMACS users 
Message-ID: <4db7b6b4.5090...@xray.bmc.uu.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 2011-04-26 19.38, Xiaohu Li wrote:
  

Hi, gromacs developers,
It seems that there is a bug regarding the angular moment removal. This
may not be very important for many users since most of them are doing
PBC where it is irrelevant, but if you are doing cluster or if you
really care the angular momentum like I
do(I want the angular momentum to be exactly zero since this corresponds
to some quantum resolved state), then it is important.
The angular momentum removal part in mdlib/vcm.c where it evaluate
moment of inertia is wrong, subroutine *update_tensor.
*Specifically, the diagonal part is not calculated right. According to
either */Classical Mechancs, by Goldstein or Theoretical Mechanics of
Particles and Continua, by A.L.Fetter and J.D.Walecka.
I_{xx}=\sum_{i} m_{i}*(r_{i}^2-x_{i}^2), where x can be x,y,z.
But the /**update_tensor gives
**/I_{xx}=\sum_{i} m_{i}*(x_{i}^2).
/*/I initially thought there could be some other routine to correct
update_tensor, but apparently, it is calculated according to that, and I
manually calculated them and turns out my theory is right, the
update_tensor is wrong as it stands.
/Again, this would not affect, say, 99.999% of the user, but it will
always be good to have a clean code.
Thanks

I found the eqn. in Goldstein p 195. I guess this takes care of the 
center of mass contribution. So if you center your system in the origin 
at time zero the present code should still work. However, we really 
should subtract the center of mass.

Mine certainly does not say the same thing. I'm using an older version of 
Goldstein by Addison-Wesley, 1950, seventh printing. Chapter 5, the third page, 
Eqn. 5-6 and 5-7. This does not match the code in gromacs.



  

/

/Xiaohu/
/




  


--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/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/Support/Mailing_Lists

[gmx-users] BUG in angular removal part??

[Xiaohu Li]

Hi, gromacs developers,
 It seems that there is a bug regarding the angular moment removal. 
This may not be very important for many users since most of them are 
doing PBC where it is irrelevant, but if you are doing cluster or if you 
really care the angular momentum like I
do(I want the angular momentum to be exactly zero since this corresponds 
to some quantum resolved state), then it is important.
 The angular momentum removal part in mdlib/vcm.c where it evaluate 
moment of inertia is wrong, subroutine *update_tensor.
  *Specifically, the diagonal part is not calculated right. 
According to either */Classical Mechancs, by Goldstein or Theoretical 
Mechanics of Particles and Continua, by A.L.Fetter and J.D.Walecka.

  I_{xx}=\sum_{i} m_{i}*(r_{i}^2-x_{i}^2), where x can be x,y,z.
 But the /**update_tensor gives
  **/I_{xx}=\sum_{i} m_{i}*(x_{i}^2).
  /*/I initially thought there could be some other routine to 
correct update_tensor, but apparently, it is calculated according to 
that, and I manually calculated them and turns out my theory is right, 
the update_tensor is wrong as it stands.
  /Again, this would not affect, say, 99.999% of the user, but it 
will always be good to have a clean code.

  Thanks
/

/Xiaohu/
/
--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/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/Support/Mailing_Lists

[gmx-users] Re: gmx-users Digest, Vol 83, Issue 153

[Xiaohu Li]

Message: 4
Date: Tue, 22 Mar 2011 22:26:04 +0800
From: " Ye MEI " 
Subject: Re: [gmx-users] New maintenance release: gromacs-4.5.4
To: " Discussion list for GROMACS users "   
Message-ID: <20110326031153...@itcs.ecnu.edu.cn>
Content-Type: text/plain;   charset="utf-8"


Check your error output, you need the -fPIC flag turned on when you are
compiling FFTW which will generate a shared object so that it can be linked
to other library.


Thank you for the new version of gromacs.
But the compilation of gromacs failed on my computer. The commands are as
follows:
make distclean
export CC=icc
export F77=ifort
export CXX=icc
export CFLAGS="-xS -I/apps/fftw3/include"
export FFLAGS="-xS -I/apps/fftw3/include"
export CXXFLAGS="-I/apps/fftw3/include"
export LDFLAGS="-L/apps/fftw3/lib -lfftw3f"
./configure --prefix=/apps/gromacs4.5 --with-fft=fftw3 --with-x
--with-qmmm-gaussian
make

and the error message is
icc  -shared  .libs/calcmu.o .libs/calcvir.o .libs/constr.o .libs/coupling.o
.libs/domdec.o .libs/domdec_box.o .libs/domdec_con.o .libs/domdec_network.o
.libs/domdec_setup.o .libs/domdec_top.o .libs/ebin.o .libs/edsam.o
.libs/ewald.o .libs/force.o .libs/forcerec.o .libs/ghat.o .libs/init.o
.libs/mdatom.o .libs/mdebin.o .libs/minimize.o .libs/mvxvf.o .libs/ns.o
.libs/nsgrid.o .libs/perf_est.o .libs/genborn.o .libs/genborn_sse2_single.o
.libs/genborn_sse2_double.o .libs/genborn_allvsall.o
.libs/genborn_allvsall_sse2_single.o .libs/genborn_allvsall_sse2_double.o
.libs/gmx_qhop_parm.o .libs/gmx_qhop_xml.o .libs/groupcoord.o .libs/pme.o
.libs/pme_pp.o .libs/pppm.o .libs/partdec.o .libs/pull.o .libs/pullutil.o
.libs/rf_util.o .libs/shakef.o .libs/sim_util.o .libs/shellfc.o .libs/stat.o
.libs/tables.o .libs/tgroup.o .libs/tpi.o .libs/update.o .libs/vcm.o
.libs/vsite.o .libs/wall.o .libs/wnblist.o .libs/csettle.o .libs/clincs.o
.libs/qmmm.o .libs/gmx_fft.o .libs/gmx_parallel_3dfft.o
 .libs/fft5d.o .libs/gmx_wallcycle.o .libs/qm_gaussian.o .libs/qm_mopac.o
.libs/qm_gamess.o .libs/gmx_fft_fftw2.o .libs/gmx_fft_fftw3.o
.libs/gmx_fft_fftpack.o .libs/gmx_fft_mkl.o .libs/qm_orca.o
.libs/mdebin_bar.o  -Wl,--rpath
-Wl,/home/ymei/gromacs-4.5.4/src/gmxlib/.libs -Wl,--rpath
-Wl,/apps/gromacs4.5/lib -lxml2 -L/apps/fftw3/lib
/apps/fftw3/lib/libfftw3f.a ../gmxlib/.libs/libgmx.so -lnsl  -pthread
-Wl,-soname -Wl,libmd.so.6 -o .libs/libmd.so.6.0.0
ld: /apps/fftw3/lib/libfftw3f.a(problem.o): relocation R_X86_64_32 against
`a local symbol' can not be used when making a shared object; recompile with
-fPIC
/apps/fftw3/lib/libfftw3f.a: could not read symbols: Bad value

However, it works fine for gromacs 4.5.3. Can anyone help?

Ye MEI

2011-03-22



From： Rossen Apostolov
Date： 2011-03-22  03:24:55
To： Discussion list for GROMACS development; Discussion list for GROMACS
users; gmx-announce
CC：
Subject： [gmx-users] New maintenance release: gromacs-4.5.4

Dear Gromacs community,
A new maintenance release of Gromacs is available for download at
ftp://ftp.gromacs.org/pub/gromacs/gromacs-4.5.4.tar.gz.
Some notable updates in this release:
* Fixed pdb2gmx picking up force field from local instead of library
directory
* Made pdb2gmx vsite generation work again for certain His namings.
* Fixed incorrect virial and pressure averages with certain nst...
values (instantaneous values correct)
* Fixed incorrect cosine viscosity output
* New -multidir alternative for mdrun -multi option
* Several minor fixes in analysis tools
* Several updates to the program documentation
Big thanks to all developers and users!
Happy simulating!
Rossen
--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/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/Support/Mailing_Lists

--

--
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/Support/Mailing_Lists/Search before posting!

End of gmx-users Digest, Vol 83, Issue 153
******



-- 
=
Xiaohu Li
Post-doctoral Research Associate
Department of Chemistry
Northwestern University
2145 Sheridan Road
Evanston IL 60208
U.S.A
=
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/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/Support/Mailing_Lists

[gmx-users] Re: gromacs QM/MM compilation with gaussian (Txema Mercero)

[Xiaohu Li]

gmx-users-requ...@gromacs.org wrote:

Send gmx-users mailing list submissions to
gmx-users@gromacs.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.gromacs.org/mailman/listinfo/gmx-users
or, via email, send a message with subject or body 'help' to
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 Topics:

   1. Re: Re: gromacs QM/MM compilation with gaussian (Txema
  Mercero) (Txema Mercero)


--

Message: 1
Date: Wed, 16 Feb 2011 14:39:30 +0100
From: Txema Mercero 
Subject: Re: [gmx-users] Re: gromacs QM/MM compilation with gaussian
(Txema  Mercero)
To: Discussion list for GROMACS users 
Cc: Joni Mujika , Gerrit Groenhof

Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

I get the same error which I attach this time:


  

Hi,
   are you
(1) Using PBC?
(2)If not using PBC, are you using simple or grid algorithm for neighbor 
search?
As far what I got from Dr. /Groenhof, qm/mm only works if pbc is used, 
however, what I found is that if you use grid search algorithm, the 
non-pbc case still runs.

Hope this helps.
/

-
Back Off! I just backed up md.log to ./#md.log.8#
Reading file topol.tpr, VERSION 4.5.3 (single precision)
QM/MM calculation requested.
there we go!
Layer 0
nr of QM atoms 24
QMlevel: RHF/6-31G

number of CPUs for gaussian = 1
memory for gaussian = 5000
accuracy in l510 = 8
NOT using cp-mcscf in l1003
Level of SA at start = 0
/software/g03Gromacs/g03gaussian initialised...

Back Off! I just backed up traj.trr to ./#traj.trr.3#

Back Off! I just backed up ener.edr to ./#ener.edr.3#

Steepest Descents:
   Tolerance (Fmax)   =  1.0e+02
   Number of steps= 1000
*** glibc detected ***
/software/gromacs-4.5.3-shared-ifort11_gauss/bin/mdrun: malloc():
memory corruption: 0x077711b0 ***
=== Backtrace: =
/lib64/libc.so.6[0x3ddcc724ac]
/lib64/libc.so.6(__libc_calloc+0xc0)[0x3ddcc73ce0]
/software/gromacs-4.5.3-shared-ifort11_gauss/lib/libgmx.so.6(save_calloc+0x32)[0x2b0e5ba08462]
/software/gromacs-4.5.3-shared-ifort11_gauss/lib/libmd.so.6(call_gaussian+0x81)[0x2b0e5b38cfd1]
/software/gromacs-4.5.3-shared-ifort11_gauss/lib/libmd.so.6(call_QMroutine+0x25)[0x2b0e5b384265]
/software/gromacs-4.5.3-shared-ifort11_gauss/lib/libmd.so.6(calculate_QMMM+0x665)[0x2b0e5b383bb5]
/software/gromacs-4.5.3-shared-ifort11_gauss/lib/libmd.so.6(do_force_lowlevel+0xd9)[0x2b0e5b2fcbd9]
/software/gromacs-4.5.3-shared-ifort11_gauss/lib/libmd.so.6(do_force+0xdaf)[0x2b0e5b35ae6f]
/software/gromacs-4.5.3-shared-ifort11_gauss/lib/libmd.so.6(do_steep+0x7d6)[0x2b0e5b314a26]
/software/gromacs-4.5.3-shared-ifort11_gauss/bin/mdrun[0x4149ba]
/software/gromacs-4.5.3-shared-ifort11_gauss/bin/mdrun[0x41dc03]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3ddcc1d974]
/software/gromacs-4.5.3-shared-ifort11_gauss/bin/mdrun(do_nm+0x4f1)[0x407069]
=== Memory map: 
0040-0046d000 r-xp  00:18 20054244
  /software/gromacs-4.5.3-shared-ifort11_gauss/bin/mdrun
0066d000-00672000 rw-p 0006d000 00:18 20054244
  /software/gromacs-4.5.3-shared-ifort11_gauss/bin/mdrun
00672000-00673000 rw-p 00672000 00:00 0
0770a000-077b6000 rw-p 0770a000 00:00 0  [heap]
3ddc80-3ddc81c000 r-xp  08:02 5751044
  /lib64/ld-2.5.so
3ddca1b000-3ddca1c000 r--p 0001b000 08:02 5751044
  /lib64/ld-2.5.so
3ddca1c000-3ddca1d000 rw-p 0001c000 08:02 5751044
  /lib64/ld-2.5.so
3ddcc0-3ddcd4c000 r-xp  08:02 5750905
  /lib64/libc-2.5.so
3ddcd4c000-3ddcf4c000 ---p 0014c000 08:02 5750905
  /lib64/libc-2.5.so
3ddcf4c000-3ddcf5 r--p 0014c000 08:02 5750905
  /lib64/libc-2.5.so
3ddcf5-3ddcf51000 rw-p 0015 08:02 5750905
  /lib64/libc-2.5.so
3ddcf51000-3ddcf56000 rw-p 3ddcf51000 00:00 0
3ddd00-3ddd082000 r-xp  08:02 5750931
  /lib64/libm-2.5.so
3ddd082000-3ddd281000 ---p 00082000 08:02 5750931
  /lib64/libm-2.5.so
3ddd281000-3ddd282000 r--p 00081000 08:02 5750931
  /lib64/libm-2.5.so
3ddd282000-3ddd283000 rw-p 00082000 08:02 5750931
  /lib64/libm-2.5.so
3ddd40-3ddd402000 r-xp  08:02 5750939
  /lib64/libdl-2.5.so
3ddd402000-3ddd602000 ---p 2000 08:02 5750939
  /lib64/libdl-2.5.so
3ddd602000-3ddd603000 r--p 2000 08:02 5750939
  /lib64/libdl-2.5.so
3ddd603000-3ddd604000 rw-p 3000 08:02 5750939
  /lib64/libdl-2.5.so
3ddd80-3ddd816000 r-xp  08:02 5751046
  /lib64/libpthread-2.5.so
3ddd816000-3ddda15000 ---p 00016000 08:02 5751046
  /lib64/libpthread-2.5.so
3ddda15000-3ddda16000 r--p 00015000 08:02 5751046
  /lib64/libpthread-2.5.so
3ddda16000-3ddda17000 rw-p 00016000 08:02 5751046
  /lib64/libpthread-2.5.so
3ddda17000-3ddda1b000 rw-p 3ddda17000 00:00 0
3dddc0-3dddc140

[gmx-users] Re: QMMM with ORCA

[Xiaohu Li]

Dear Gerrit,
Thanks for your comments. Strange enough, once I set up the
neighbour search from simple to grid, even the electronic embedding went
through. But I'm not sure if the calculation is right.
Generally, what happens if one is running a calculation without PBC
but the calculation actually goes through. Is there anything dramatic
happening?
Thank you again.


Xiaohu

On Fri, Jan 28, 2011 at 12:47 AM, Gerrit Groenhof  wrote:

> Dear Xiaohu,
>
> Thanks for bringing this up. The comment has been there for ever. Since I
> could not think of an application where one would not be using pbc at the
> time. However, your clusters prove me wrong.
>
> In any case, as a work-around, you may want to use a bigger box, with long
> enough cut-offs, no PME.
>
> Hope this gets you started,
>
> Gerrit
>
> On 27 Jan 2011, at 21:02, Xiaohu Li wrote:
>
> Dear GMX code writters,
>  Could anyone tell me why this comments in the code *mdlib/qmmm.c
> appear*?(version 4.5.3)
> at *line ~ 714*, in the beginning of subroutine* update_QMMMrec*
> ==
> */* updates the coordinates of both QM atoms and MM atoms and stores
>* them in the QMMMrec.
>*
>* NOTE: is NOT yet working if there are no PBC. Also in ns.c, simple
>* ns needs to be fixed!
> */*
> ==
> First of all, I have a non-PBC job with electronic embedding and it
> fails right in this routine. So I guess this is the reason, for non-PBC, it
> crashes. But for oniom, it went through. Is there any simple fix to have the
> non-PBC qmmm work? I'm also interested in doing non-PBC calculation(large
> cluster).
>
>
> Xiaohu
>
> On Thu, Jan 27, 2011 at 9:11 AM, Christoph Riplinger  > wrote:
>
>>  Hi Xiaohu,
>>
>> We are using gromacs/ORCA quite a lot. It works like any of the other
>> interfaced programs and whether you should use it depends on your needs to
>> the QM part of the QM/MM calculation.
>>
>> I am using gromacs 4.0.7, but I downloaded the 4.5.3 version to test it.
>>
>> I could not reproduce your problem with ONIOM. For the electrostatic
>> embedding bug, I agree. This didn't work in my test calculation, but my gdb
>> told me that the abort occured before the qm_orca.c was even called. I
>> suspect the bug is in the general qmmm.c code. I do not have access to the
>> other QM-programs and cannot test this, so if you have, could you please run
>> the same job with a different QM-program.
>>
>> Hope that helps
>>
>> Christoph
>>
>>
>>
>>
>> On 01/26/2011 06:48 AM, Xiaohu Li wrote:
>>
>> Hi, All,
>>  I'm trying to see if anybody has experience of using the interface of
>> gromacs and ORCA(since it's free). I know that the following link gave
>> information on how
>> http://wwwuser.gwdg.de/~ggroenh/qmmm.html#code<http://wwwuser.gwdg.de/%7Eggroenh/qmmm.html#code>
>>  But.But, the gromacs in the above link is quite old(3.2). I
>> download the latest 4.5.3 and followed the instructions in the above link
>> and I was trying to optimize an simple cluster(no pbc) where part of it are
>> treated using QM. here is the example mdp file
>>
>> =
>>  title   =  cpeptide
>> integrator  =  steep   ;integrator includes energy minimization
>> algorithms
>> dt  =  0.002; ps !
>> nsteps  =   1
>> nstlist =  1
>> ns_type =  simple
>> rlist   =  3.0
>> rcoulomb=  3.0
>> coulombtype = cut-off
>> vdwtype = cut-off
>> rvdw= 3.0
>> pbc =  no
>> periodic_molecules  =  no
>> constraints = none
>> energygrps  = qm_part mm_part
>> ; QM/MM calculation stuff
>> QMMM = yes
>> QMMM-grps = qm_part
>> QMmethod = rhf
>> QMbasis = 3-21G
>> QMMMscheme = oniom
>> QMcharge = 0
>> QMmult = 1
>> ;
>> ;   Energy minimizing stuff
>> ;
>> emtol   =  60   ; minimization thresold (kj/mol.nm-1)1
>> hartree/bohr= 49614.75241 kj/mol.nm-1  1 kj/mol.nm-1=2.01553e-5 hartree/bohr
>> emstep  =  0.01  ; minimization step in nm
>>
>> =
>>  I set up the BASENAME and ORCA_PATH as

[gmx-users] QMMM with ORCA

[Xiaohu Li]

Dear GMX code writters,
 Could anyone tell me why this comments in the code *mdlib/qmmm.c
appear*?(version 4.5.3)
at *line ~ 714*, in the beginning of subroutine* update_QMMMrec*
==
*/* updates the coordinates of both QM atoms and MM atoms and stores
   * them in the QMMMrec.
   *
   * NOTE: is NOT yet working if there are no PBC. Also in ns.c, simple
   * ns needs to be fixed!
*/*
==
First of all, I have a non-PBC job with electronic embedding and it
fails right in this routine. So I guess this is the reason, for non-PBC, it
crashes. But for oniom, it went through. Is there any simple fix to have the
non-PBC qmmm work? I'm also interested in doing non-PBC calculation(large
cluster).


Xiaohu

On Thu, Jan 27, 2011 at 9:11 AM, Christoph Riplinger
wrote:

>  Hi Xiaohu,
>
> We are using gromacs/ORCA quite a lot. It works like any of the other
> interfaced programs and whether you should use it depends on your needs to
> the QM part of the QM/MM calculation.
>
> I am using gromacs 4.0.7, but I downloaded the 4.5.3 version to test it.
>
> I could not reproduce your problem with ONIOM. For the electrostatic
> embedding bug, I agree. This didn't work in my test calculation, but my gdb
> told me that the abort occured before the qm_orca.c was even called. I
> suspect the bug is in the general qmmm.c code. I do not have access to the
> other QM-programs and cannot test this, so if you have, could you please run
> the same job with a different QM-program.
>
> Hope that helps
>
> Christoph
>
>
>
>
> On 01/26/2011 06:48 AM, Xiaohu Li wrote:
>
> Hi, All,
>  I'm trying to see if anybody has experience of using the interface of
> gromacs and ORCA(since it's free). I know that the following link gave
> information on how
> http://wwwuser.gwdg.de/~ggroenh/qmmm.html#code<http://wwwuser.gwdg.de/%7Eggroenh/qmmm.html#code>
>  But.But, the gromacs in the above link is quite old(3.2). I
> download the latest 4.5.3 and followed the instructions in the above link
> and I was trying to optimize an simple cluster(no pbc) where part of it are
> treated using QM. here is the example mdp file
>
> =
>  title   =  cpeptide
> integrator  =  steep   ;integrator includes energy minimization
> algorithms
> dt  =  0.002; ps !
> nsteps  =   1
> nstlist =  1
> ns_type =  simple
> rlist   =  3.0
> rcoulomb=  3.0
> coulombtype = cut-off
> vdwtype = cut-off
> rvdw= 3.0
> pbc =  no
> periodic_molecules  =  no
> constraints = none
> energygrps  = qm_part mm_part
> ; QM/MM calculation stuff
> QMMM = yes
> QMMM-grps = qm_part
> QMmethod = rhf
> QMbasis = 3-21G
> QMMMscheme = oniom
> QMcharge = 0
> QMmult = 1
> ;
> ;   Energy minimizing stuff
> ;
> emtol   =  60   ; minimization thresold (kj/mol.nm-1)1
> hartree/bohr= 49614.75241 kj/mol.nm-1  1 kj/mol.nm-1=2.01553e-5 hartree/bohr
> emstep  =  0.01  ; minimization step in nm
>
> =
>  I set up the BASENAME and ORCA_PATH as told in the instruction.
> first of all, the normal electronic embedding just simply gave segmentation
> fault error right after the it prints information on number of steps of
> optimization.
>
>  So I switch to ONIOM, this time, at least, orca is called and energy and
> gradient are both generated. However, when it comes to read the energy and
> gradient, it always crashes when tried to read gradient, this is at *line
> 346* source code src/mdlib/qm_orca.c
> 
> sscanf(buf,"%lf\n", &QMgrad[k][XX]);
> 
> a segmentation fault error is printed. If I replace the &QMgrad[k][XX] by
> an temporary variable temp
>  sscanf(buf,"%lf\n", &temp);
> temp gets the correct value and if I use,
> QMgrad[k][XX]=temp
> and tries to print QMgrad[k][XX], a bus error will be printed.
> I did some research online, seems that usually this implies an memory bug
> in the code which is the most difficult bug one can ever encounter.
> So has anyone successfully used gromacs and orca to do QMMM?
> Generally, would anyone recommend using gromacs to do QMMM?
>
>  Cheers,
> Xiaohu
>
>
>


-- 
=

[gmx-users] Re: QMMM with ORCA

[Xiaohu Li]

Hi, All,
 Just want to share information on this thread.
 Regarding to the segmentation fault. I have found out that gromacs call
orca by write command to a buffer called buf. So for example, if the orca
path is
/usr/local/bin/orca
and the BASENAME(prefix of the *.tpr file) is longlonglonglonglonglong
then gromacs will write
/usr/local/bin/orca longlonglonglonglonglong.inp >>
longlonglonglonglonglong.out
to a buffer called buf.
 By default, this buffer has character length of 100(roughly line ~ 410)
char buf[100]
and it turns out that my orca_path plus the BASENAME is a really long
string, definitely exceeding 100. It seems that this is causing the problem
since after I increased the buf length to 1000, the optimization at least
runs and gradient has been read.
More will be updated if I find anything else.


Xiaohu


Hi, All,
> I'm trying to see if anybody has experience of using the interface of
> gromacs and ORCA(since it's free). I know that the following link gave
> information on how
> http://wwwuser.gwdg.de/~ggroenh/qmmm.html#code
> But.But, the gromacs in the above link is quite old(3.2). I
> download the latest 4.5.3 and followed the instructions in the above link
> and I was trying to optimize an simple cluster(no pbc) where part of it are
> treated using QM. here is the example mdp file
>
> =
> title   =  cpeptide
> integrator  =  steep   ;integrator includes energy minimization
> algorithms
> dt  =  0.002; ps !
> nsteps  =   1
> nstlist =  1
> ns_type =  simple
> rlist   =  3.0
> rcoulomb=  3.0
> coulombtype = cut-off
> vdwtype = cut-off
> rvdw= 3.0
> pbc =  no
> periodic_molecules  =  no
> constraints = none
> energygrps  = qm_part mm_part
> ; QM/MM calculation stuff
> QMMM = yes
> QMMM-grps = qm_part
> QMmethod = rhf
> QMbasis = 3-21G
> QMMMscheme = oniom
> QMcharge = 0
> QMmult = 1
> ;
> ;   Energy minimizing stuff
> ;
> emtol   =  60   ; minimization thresold (kj/mol.nm-1)1
> hartree/bohr= 49614.75241 kj/mol.nm-1  1 kj/mol.nm-1=2.01553e-5
> hartree/bohr
> emstep  =  0.01  ; minimization step in nm
>
> =
> I set up the BASENAME and ORCA_PATH as told in the instruction.
> first of all, the normal electronic embedding just simply gave segmentation
> fault error right after the it prints information on number of steps of
> optimization.
>
> So I switch to ONIOM, this time, at least, orca is called and energy and
> gradient are both generated. However, when it comes to read the energy and
> gradient, it always crashes when tried to read gradient, this is at *line
> 346* source code src/mdlib/qm_orca.c
> 
> sscanf(buf,"%lf\n", &QMgrad[k][XX]);
> 
> a segmentation fault error is printed. If I replace the &QMgrad[k][XX] by
> an
> temporary variable temp
>  sscanf(buf,"%lf\n", &temp);
> temp gets the correct value and if I use,
> QMgrad[k][XX]=temp
> and tries to print QMgrad[k][XX], a bus error will be printed.
> I did some research online, seems that usually this implies an memory bug
> in
> the code which is the most difficult bug one can ever encounter.
> So has anyone successfully used gromacs and orca to do QMMM?
> Generally, would anyone recommend using gromacs to do QMMM?
>
> Cheers,
> Xiaohu
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> http://lists.gromacs.org/pipermail/gmx-users/attachments/20110125/16819c97/attachment-0001.html
>
>
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/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/Support/Mailing_Lists

[gmx-users] Re: mdrun_mpi executable not found

[Xiaohu Li]

Message: 4
> Date: Wed, 26 Jan 2011 12:53:17 -0500
> From: Justin Kat 
> Subject: Re: [gmx-users] mdrun_mpi executable not found
> To: "jalem...@vt.edu" ,Discussion list for
> GROMACS
>users 
> Message-ID:
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thank you, I have been to that page probably a good 100 times by now.
>
> Was the 'No.' response with regards to my primary question? Or to the
> one within the parentheses?
>
> Suppose I remove my existing installation and reinstall, I am hoping
> to figure out when/where exactly should I specify
> --program-suffix=_mpi so as to not overwrite the pre-existing serial
> mdrun as I have mistakenly done so with my current installation.
>
>
> *./configure --enable-mpi --program-suffix=_mpi
> **make mdrun
> **make install-mdrun
> **make links*
>
> Lastly, if the above set of commands are incorrect, or will not carry
> out what I intend (to build a separate mdrun_mpi executable apart from
> the existing mdrun after a normal build), I am kindly requesting for a
> suitable revision.
>
> Have you tried
 ./configure --help
 to find out where the installation is?
by default gromacs will be installed at /usr/local/gromacs (according to
./configure --help).
If it's not installed there, do you have a openmpi or mpich compiler in your
path?
if not, then specify ./configure   --enable-mpi --program-suffix=_mpi
MPICC=

Xiaohu


>
>
> Thanks,
> Justin
>
>
> On 26/01/2011 8:50 AM, Justin Kat wrote:
> >* Alright. So meaning I should have instead issued:
> *>*
> *>* ./configure --enable-mpi --program-suffix=_mpi
>
>
> *>* make mdrun
> *>* make install-mdrun
> *>* make links
> *>*
> *>* to have installed an MPI-enabled executable called mdrun_mpi apart
> *>* from the existing mdrun executable? (Would I also need to append the
>
>
> *>* _mpi suffix when issuing the first two make and make install commands
> *>* above?
> *
> No. See http://www.gromacs.org/Downloads/Installation_Instructions
>
>
>
> Mark
>
> >*
> *>* Thanks,
> *>* Justin
> *>*
> *>* On Mon, Jan 24, 2011 at 8:08 PM, Justin A. Lemkul  vt.edu 
>
>
> *
> - Show quoted text -
> >*  http://lists.gromacs.org/mailman/listinfo/gmx-users>>> wrote:
> *>*
> *>*
> *>*
> *>* Justin Kat wrote:
>
> *>* > Thank you for the reply!
>
> *>* >
> *>* > hmm mdrun_mpi does not appear in the list of executables in
> *>* > /usr/local/gromacs/bin (and well therefore not in
> /usr/local/bin).
> *>* >
>
>
> *>* > Which set of installation commands that I used should have
> *>* compiled the
> *>* > mdrun_mpi executable? And how should I go about getting the
> *>* mdrun_mpi
>
>
> *>* > executable at this point?
> *>* >
> *>*
> *>* I see it now.  When you configured with --enable-mpi, you didn't
> *>* specify
> *>* --program-suffix=_mpi, so the installation procedure over-wrote
>
>
> *>* your existing
> *>* (serial) mdrun with an MPI-enabled one simply called "mdrun."  The
> *>* configure
> *>* output should have warned you about this.  You could, in theory,
>
>
> *>* simply re-name
> *>* your existing executable "mdrun_mpi" and then re-install a serial
> *>* mdrun, if you
> *>* need it.
> *>*
> *>* -Justin
>
>
> *>*
> *>* --
> *>* 
> *>*
> *>* Justin A. Lemkul
> *>* Ph.D. Candidate
> *>* ICTAS Doctoral Scholar
>
>
> *>* MILES-IGERT Trainee
> *>* Department of Biochemistry
> *>* Virginia Tech
> *>* Blacksburg, VA
> *
> >* jalemkul[at]vt.edu  | (540) 231-9080
>
>
> *
> >* http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
> *>*
> *>* 
>
>
> *>* --
> *
> >* gmx-users mailing list gmx-users at gromacs.org <
> http://lists.gromacs.org/mailman/listinfo/gmx-users>
> *>*  >
>
>
> *
> >* http://lists.gromacs.org/mailman/listinfo/gmx-users
> *>* Please search the archive at
> *>* http://www.gromacs.org/Support/Mailing_Lists/Search before
> posting!
>
>
> *>* Please don't post (un)subscribe requests to the list. Use the
> *
> >* www interface or send it to gmx-users-request at gromacs.org <
> http://lists.gromacs.org/mailman/listinfo/gmx-users>
>
>
> *>*  >.
> *
> >* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
>
> *>*
> *>*
> *
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> http://lists.gromacs.org/pipermail/gmx-users/attachments/20110126/389781fa/attachment-0001.html
>
> --
>
>
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the 

[gmx-users] QMMM with ORCA

[Xiaohu Li]

Hi, All,
 I'm trying to see if anybody has experience of using the interface of
gromacs and ORCA(since it's free). I know that the following link gave
information on how
http://wwwuser.gwdg.de/~ggroenh/qmmm.html#code
 But.But, the gromacs in the above link is quite old(3.2). I
download the latest 4.5.3 and followed the instructions in the above link
and I was trying to optimize an simple cluster(no pbc) where part of it are
treated using QM. here is the example mdp file
=
title   =  cpeptide
integrator  =  steep   ;integrator includes energy minimization
algorithms
dt  =  0.002; ps !
nsteps  =   1
nstlist =  1
ns_type =  simple
rlist   =  3.0
rcoulomb=  3.0
coulombtype = cut-off
vdwtype = cut-off
rvdw= 3.0
pbc =  no
periodic_molecules  =  no
constraints = none
energygrps  = qm_part mm_part
; QM/MM calculation stuff
QMMM = yes
QMMM-grps = qm_part
QMmethod = rhf
QMbasis = 3-21G
QMMMscheme = oniom
QMcharge = 0
QMmult = 1
;
;   Energy minimizing stuff
;
emtol   =  60   ; minimization thresold (kj/mol.nm-1)1
hartree/bohr= 49614.75241 kj/mol.nm-1  1 kj/mol.nm-1=2.01553e-5 hartree/bohr
emstep  =  0.01  ; minimization step in nm
=
I set up the BASENAME and ORCA_PATH as told in the instruction.
first of all, the normal electronic embedding just simply gave segmentation
fault error right after the it prints information on number of steps of
optimization.

So I switch to ONIOM, this time, at least, orca is called and energy and
gradient are both generated. However, when it comes to read the energy and
gradient, it always crashes when tried to read gradient, this is at *line
346* source code src/mdlib/qm_orca.c

sscanf(buf,"%lf\n", &QMgrad[k][XX]);

a segmentation fault error is printed. If I replace the &QMgrad[k][XX] by an
temporary variable temp
 sscanf(buf,"%lf\n", &temp);
temp gets the correct value and if I use,
QMgrad[k][XX]=temp
and tries to print QMgrad[k][XX], a bus error will be printed.
I did some research online, seems that usually this implies an memory bug in
the code which is the most difficult bug one can ever encounter.
So has anyone successfully used gromacs and orca to do QMMM?
Generally, would anyone recommend using gromacs to do QMMM?

Cheers,
Xiaohu
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/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/Support/Mailing_Lists

[gmx-users] RE: Important: Bugs in NEMD calculation

[Xiaohu Li]

On Wed, Jan 19, 2011 at 4:40 PM, Xiaohu Li  wrote:

>
> Message: 2
>> Date: Wed, 19 Jan 2011 23:23:12 +0100
>> From: Berk Hess 
>> Subject: RE: [gmx-users] RE: Important: Bugs in NEMD calculation
>> To: Discussion list for GROMACS users 
>> Message-ID: 
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>>
>>
>>
>> It seems you are right.
>> The density is calculated a few lines before 1/visc is stored, but it is
>> not being used.
>> Strange that this always went unnoticed, since it already seems to have
>> been wrong in 4.0.
>> The density of water is so close to 1000 that you wouldn't notice the
>> difference
>>
>> But in a quick test I don't get the correct viscosity either way.
>> I will have to find time for a thorough check.
>> Do you get the right answer by dividing by the missing density term in
>> src/mdlib/mdebin.c?
>>
>> Berk
>>
> Well, my force field can not reproduce the experiment anyway.
> However, the wrong way of calculating in NEMD(vol instead of dens) is
> getting visocisty much much lower than what I got from using g_energy -vis.
> If I'm understanding correctly, the one with visco.xvg(column 1 vs column
> 2) should be the one I'm supposed to look at, even with 12ns simulation,
> this does not converge, but roughly speaking the NEMD results with the vol
> replaced by rho(I wrote a outside script to calculate this) is on the same
> order of magnitude as the g_energy -vis using green-kudo(is that right?)
> expression.
>
> Xiaohu
>
>
>>
>> Date: Wed, 19 Jan 2011 14:48:32 -0600
>> From: xiaohuli...@gmail.com
>> To: gmx-users@gromacs.org
>> Subject: [gmx-users] RE: Important: Bugs in NEMD calculation
>>
>>
>>
>> Date: Wed, 19 Jan 2011 20:43:20 +0100
>>
>> From: Berk Hess 
>>
>> Subject: RE: [gmx-users] Important: Bugs in NEMD calculation
>>
>> To: Discussion list for GROMACS users 
>>
>> Message-ID: 
>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > 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 reviewed in /*Hess's paper at JCP 116 209 2002.*/
>>
>> > >   The version of gromacs I'm using is the development version.
>>
>> > > Notice that this version correct a previous but of 4.5.3, where you
>> uses
>>
>> > > NEMD, both the term V(eq. 21 on Hess's paper) and 1/eta(shear
>> viscosity
>>
>> > > inverse) are supposed to be written to the *.edr file, however,
>>
>> > > the 4.5.3 versions does not have this. This version can be retrieved
>> at
>>
>> > >
>> http://repo.or.cz/w/gromacs.git/commit/c83de86d65ce7135be6cef15e9100d7516e6d9a7
>>
>> > > *However, even this version is buggy since eta=A*rho/(V*k**2)(eq. 20
>>
>> > > Hess's paper)*. *I have performed simulation and has found out that
>> the
>>
>> > > V and eta which are written in *edr file does not match according to
>> the
>>
>> > > formula, a little further check on the source code mdebin.c under the
>>
>> > > directory src/mdlib shows that it is actually calculating
>>
>> > > eta=A*Volume/(V*k**2) where density of rho should have been used.
>> (This
>>
>> > > is at line 755 of mdebin.c ).
>>
>> > >  I hope everyone who is using this can be aware of this, if you
>> ever
>>
>> > > used this code to produce data, the V is correct from *edr, however,
>> you
>>
>> > > need to manuelly get your eta using the above formula.
>>
>> > >  For the GMX developers, I hope anyone of you can correct this
>> bug.
>>
>> > >
>>
>>
>>
>> I fixed this bug recently is the git release-4-5-patches branch.
>>
>> You can get the fix from git and it will be in the 4.5.4 release
>>
>> (no date yet).
>> Which one are you referring to? The one I got is the one you uploaded that
>> fixed the zero viscosity and 2*cosZ*vel-x i

[gmx-users] Re: gmx-users Digest, Vol 81, Issue 130

[Xiaohu Li]

> Message: 2
> Date: Wed, 19 Jan 2011 23:23:12 +0100
> From: Berk Hess 
> Subject: RE: [gmx-users] RE: Important: Bugs in NEMD calculation
> To: Discussion list for GROMACS users 
> Message-ID: 
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
>
> It seems you are right.
> The density is calculated a few lines before 1/visc is stored, but it is
> not being used.
> Strange that this always went unnoticed, since it already seems to have
> been wrong in 4.0.
> The density of water is so close to 1000 that you wouldn't notice the
> difference
>
> But in a quick test I don't get the correct viscosity either way.
> I will have to find time for a thorough check.
> Do you get the right answer by dividing by the missing density term in
> src/mdlib/mdebin.c?
>
> Berk
>
Well, my force field can not reproduce the experiment anyway.
However, the wrong way of calculating in NEMD(vol instead of dens) is
getting visocisty much much lower than what I got from using g_energy -vis.
If I'm understanding correctly, the one with visco.xvg(column 1 vs column 2)
should be the one I'm supposed to look at, even with 12ns simulation, this
does not converge, but roughly speaking the NEMD results with the vol
replaced by rho(I wrote a outside script to calculate this) is on the same
order of magnitude as the g_energy -vis using green-kudo(is that right?)
expression.

Xiaohu


>
> Date: Wed, 19 Jan 2011 14:48:32 -0600
> From: xiaohuli...@gmail.com
> To: gmx-users@gromacs.org
> Subject: [gmx-users] RE: Important: Bugs in NEMD calculation
>
>
>
> Date: Wed, 19 Jan 2011 20:43:20 +0100
>
> From: Berk Hess 
>
> Subject: RE: [gmx-users] Important: Bugs in NEMD calculation
>
> To: Discussion list for GROMACS users 
>
> Message-ID: 
>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
>
>
>
>
>
>
> > 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 reviewed in /*Hess's paper at JCP 116 209 2002.*/
>
> > >   The version of gromacs I'm using is the development version.
>
> > > Notice that this version correct a previous but of 4.5.3, where you
> uses
>
> > > NEMD, both the term V(eq. 21 on Hess's paper) and 1/eta(shear viscosity
>
> > > inverse) are supposed to be written to the *.edr file, however,
>
> > > the 4.5.3 versions does not have this. This version can be retrieved at
>
> > >
> http://repo.or.cz/w/gromacs.git/commit/c83de86d65ce7135be6cef15e9100d7516e6d9a7
>
> > > *However, even this version is buggy since eta=A*rho/(V*k**2)(eq. 20
>
> > > Hess's paper)*. *I have performed simulation and has found out that the
>
> > > V and eta which are written in *edr file does not match according to
> the
>
> > > formula, a little further check on the source code mdebin.c under the
>
> > > directory src/mdlib shows that it is actually calculating
>
> > > eta=A*Volume/(V*k**2) where density of rho should have been used. (This
>
> > > is at line 755 of mdebin.c ).
>
> > >  I hope everyone who is using this can be aware of this, if you
> ever
>
> > > used this code to produce data, the V is correct from *edr, however,
> you
>
> > > need to manuelly get your eta using the above formula.
>
> > >  For the GMX developers, I hope anyone of you can correct this bug.
>
> > >
>
>
>
> I fixed this bug recently is the git release-4-5-patches branch.
>
> You can get the fix from git and it will be in the 4.5.4 release
>
> (no date yet).
> Which one are you referring to? The one I got is the one you uploaded that
> fixed the zero viscosity and 2*cosZ*vel-x in edr file.
> This bug refers the wrong calculation of 1/eta.
>
>
>
>
>
> > Thanks for pointing that out. There also is a small issue in that the
>
> > volume is computed for a rectangular box
>
> >  vol  = box[XX][XX]*box[YY][YY]*box[ZZ][ZZ];
>
> >  dens = (tmass*AMU)/(vol*NANO*NANO*NANO);
>
> >
>
> > which would be incorrect for a non-rectangular box. You should however
>
> > use a rectangular box for this kind of calculations, although this is
>
> > not enforced by grompp.
>
>
>
> No.
>
> That formula is correct for any tr

[gmx-users] RE: Important: Bugs in NEMD calculation

[Xiaohu Li]

> Date: Wed, 19 Jan 2011 20:43:20 +0100
> From: Berk Hess 
> Subject: RE: [gmx-users] Important: Bugs in NEMD calculation
> To: Discussion list for GROMACS users 
> Message-ID: 
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
>
> > 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 reviewed in /*Hess's paper at JCP 116 209 2002.*/
> > >   The version of gromacs I'm using is the development version.
> > > Notice that this version correct a previous but of 4.5.3, where you
> uses
> > > NEMD, both the term V(eq. 21 on Hess's paper) and 1/eta(shear viscosity
> > > inverse) are supposed to be written to the *.edr file, however,
> > > the 4.5.3 versions does not have this. This version can be retrieved at
> > >
> http://repo.or.cz/w/gromacs.git/commit/c83de86d65ce7135be6cef15e9100d7516e6d9a7
> > > *However, even this version is buggy since eta=A*rho/(V*k**2)(eq. 20
> > > Hess's paper)*. *I have performed simulation and has found out that the
> > > V and eta which are written in *edr file does not match according to
> the
> > > formula, a little further check on the source code mdebin.c under the
> > > directory src/mdlib shows that it is actually calculating
> > > eta=A*Volume/(V*k**2) where density of rho should have been used. (This
> > > is at line 755 of mdebin.c ).
> > >  I hope everyone who is using this can be aware of this, if you
> ever
> > > used this code to produce data, the V is correct from *edr, however,
> you
> > > need to manuelly get your eta using the above formula.
> > >  For the GMX developers, I hope anyone of you can correct this bug.
> > >
>
> I fixed this bug recently is the git release-4-5-patches branch.
> You can get the fix from git and it will be in the 4.5.4 release
> (no date yet).
>
Which one are you referring to? The one I got is the one you uploaded that
fixed the zero viscosity and 2*cosZ*vel-x in edr file.
This bug refers the wrong calculation of 1/eta.


>
> > Thanks for pointing that out. There also is a small issue in that the
> > volume is computed for a rectangular box
> >  vol  = box[XX][XX]*box[YY][YY]*box[ZZ][ZZ];
> >  dens = (tmass*AMU)/(vol*NANO*NANO*NANO);
> >
> > which would be incorrect for a non-rectangular box. You should however
> > use a rectangular box for this kind of calculations, although this is
> > not enforced by grompp.
>
> No.
> That formula is correct for any triclinic box!
>
> Berk
>
> >
> > >
> > >
> > > Xiaohu
> > > *
> > >
> >
> >
> > --
> > David van der Spoel, Ph.D., Professor of Biology
> > Dept. of Cell & Molec. Biol., Uppsala University.
> > Box 596, 75124 Uppsala, Sweden. Phone:+46184714205.
> > sp...@xray.bmc.uu.sehttp://folding.bmc.uu.se
> > --
> > gmx-users mailing listgmx-users@gromacs.org
> > http://lists.gromacs.org/mailman/listinfo/gmx-users
> > Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/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/Support/Mailing_Lists
>
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> http://lists.gromacs.org/pipermail/gmx-users/attachments/20110119/1ffc9f59/attachment.html
>
> --
>
> --
> 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/Support/Mailing_Lists/Search before posting!
>
> End of gmx-users Digest, Vol 81, Issue 127
> **
>
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/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/Support/Mailing_Lists

[gmx-users] Important: Bugs in NEMD calculation

[Xiaohu Li]

Hi, All,
 I've found a bug in the NEMD calculation for viscosity. This has been
reviewed in *Hess's paper at JCP 116 209 2002.*
 The version of gromacs I'm using is the development version. Notice
that this version correct a previous but of 4.5.3, where you uses NEMD, both
the term V(eq. 21 on Hess's paper) and 1/eta(shear viscosity inverse) are
supposed to be written to the *.edr file, however,
the 4.5.3 versions does not have this. This version can be retrieved at
http://repo.or.cz/w/gromacs.git/commit/c83de86d65ce7135be6cef15e9100d7516e6d9a7
 *However, even this version is buggy since eta=A*rho/(V*k**2)(eq. 20
Hess's paper)*. *I have performed simulation and has found out that the V
and eta which are written in *edr file does not match according to the
formula, a little further check on the source code mdebin.c under the
directory src/mdlib shows that it is actually calculating
eta=A*Volume/(V*k**2) where density of rho should have been used. (This is
at line 755 of mdebin.c ).
I hope everyone who is using this can be aware of this, if you ever used
this code to produce data, the V is correct from *edr, however, you need to
manuelly get your eta using the above formula.
For the GMX developers, I hope anyone of you can correct this bug.



Xiaohu
*
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/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/Support/Mailing_Lists

[gmx-users] Re:Viscosity calculations

[Xiaohu Li]

On Mon, Jan 17, 2011 at 8:29 AM,  wrote:

> Send gmx-users mailing list submissions to
>gmx-users@gromacs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>http://lists.gromacs.org/mailman/listinfo/gmx-users
> or, via email, send a message with subject or body 'help' to
>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 Topics:
>
>   1. Re: Non integral charges (Erik Marklund)
>   2. Re: Non integral charges (Justin A. Lemkul)
>   3. Re: Viscosity calculations (Justin A. Lemkul)
>   4. Re: Non integral charges (Kavyashree M)
>   5. Secondary structure loss in implicit solvent simulations
>  (K. Singhal)
>   6. Re: Non integral charges (Vitaly Chaban)
>   7. Re: Re: Non integral charges (Justin A. Lemkul)
>
>
> --
>
> Message: 1
> Date: Mon, 17 Jan 2011 13:06:19 +0100
> From: Erik Marklund 
> Subject: Re: [gmx-users] Non integral charges
> To: Discussion list for GROMACS users 
> Message-ID: <4d3430bb.20...@xray.bmc.uu.se>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> It's pretty close to -1. The difference stems from floating point
> conversion errors. There's nothing to worry about.
>
> Erik
>
> Kavyashree M skrev 2011-01-17 13.02:
> > Dear gromacs users,
> >
> > while using grompp I got a message :
> >
> > " System has non-zero total charge: -9.98e-01"
> >
> > This is non integral charges. What should I add using genion?
> > +1 charge? Why am I getting such non integral charges?
> > I also checked for any breakage in the chain and found no such
> > ends.
> >
> > Kindly suggest
> >
> > With Regards
> > MKS
> >
> >
>
>
> --
> ---
> Erik Marklund, PhD student
> Dept. of Cell and Molecular Biology, Uppsala University.
> Husargatan 3, Box 596,75124 Uppsala, Sweden
> phone:+46 18 471 4537fax: +46 18 511 755
> er...@xray.bmc.uu.sehttp://folding.bmc.uu.se/
>
>
>
> --
>
> Message: 2
> Date: Mon, 17 Jan 2011 07:07:51 -0500
> From: "Justin A. Lemkul" 
> Subject: Re: [gmx-users] Non integral charges
> To: Discussion list for GROMACS users 
> Message-ID: <4d343117.2070...@vt.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
>
> Kavyashree M wrote:
> > Dear gromacs users,
> >
> > while using grompp I got a message :
> >
> > " System has non-zero total charge: -9.98e-01"
> >
> > This is non integral charges. What should I add using genion?
> > +1 charge? Why am I getting such non integral charges?
>
> Please see FAQ #30.
>
> http://www.gromacs.org/Documentation/FAQs
>
> -Justin
>
> > I also checked for any breakage in the chain and found no such
> > ends.
> >
> > Kindly suggest
> >
> > With Regards
> > MKS
> >
> >
>
> --
> 
>
> Justin A. Lemkul
> Ph.D. Candidate
> ICTAS Doctoral Scholar
> MILES-IGERT Trainee
> Department of Biochemistry
> Virginia Tech
> Blacksburg, VA
> jalemkul[at]vt.edu | (540) 231-9080
> http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin
>
> 
>
>
> --
>
> Message: 3
> Date: Mon, 17 Jan 2011 07:11:29 -0500
> From: "Justin A. Lemkul" 
> Subject: Re: [gmx-users] Viscosity calculations
> To: Discussion list for GROMACS users 
> Message-ID: <4d3431f1.8070...@vt.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
>
> Xiaohu Li wrote:
> > Hi,
> >I'm trying to calculate viscosities of a few ionic liquid and has
> > roughly read about Hess's paper JCP 116 209, 2002.
> > Follows are the questions that I have
> > (1) For the method which uses the fluctuations of the pressure tensor
> > using Green-Kubo relation. I used g_energy -f *.edr -s *.tpr -vis option
> > and has obtained
> > a few files such as evisco.xvg, eviscoi.xvg and visco.xvg
> > The evisco.xvg seems like the one I'm interested, since it has the title
> as
> > @title "Shear viscosity using Einstein relation"
> > and the unit seems also correct. This file has 5 column

[gmx-users] Viscosity calculations

[Xiaohu Li]

Hi,
   I'm trying to calculate viscosities of a few ionic liquid and has roughly
read about Hess's paper JCP 116 209, 2002.
Follows are the questions that I have
(1) For the method which uses the fluctuations of the pressure tensor using
Green-Kubo relation. I used g_energy -f *.edr -s *.tpr -vis option and has
obtained
a few files such as evisco.xvg, eviscoi.xvg and visco.xvg
The evisco.xvg seems like the one I'm interested, since it has the title as
@title "Shear viscosity using Einstein relation"
and the unit seems also correct. This file has 5 columns, if I understand it
correctly(by extrapolating from Hess's paper), the second to fourth columns
are the results from the off-diagonal elements of the pressure
tensor and the fifth one being the average. Hess's paper seems to be this
one(Figure 5). However, the results are way to low for the ionic liquid,
since I'm getting 1e-7 kg/m.s and way too low for a ionic liquid.
the eviscoi.xvg file seems to be some kind of integral of evisco.xvg which
I'm not quite getting what it is.
visco.xvg contains the shear viscosity and bulk viscosity, which again seems
to be the one I'm looking for. However, the shear viscosity I'm looking
is(the region which roughly is constant) about 3~5 times higher than the
experiment. The simulation is 12ns long. Of course, this could mean (1) the
force field is bad or (2) the Green-kudo converges too slowly as Hess
pointed out.
Since it is not getting any useful result, I turned to non-equilibrium MD by
applying a shear external force, which is in (2)
(2) I tried both NVT and NPT simulations which uses berendsen coupling bath.
and set up the cos_acceleration = 0.1 nm/ps^2.
However, I tried to use g_energy -f *edr -s *tpr and by selecting
the 1/Viscosity or 2CosZ*Vel-X option, the output are giving me zero data
points on all times.

I tried really hard on searching  results on the user list of gromacs but it
seems that there are quite a lot questions on this but not a single
satisfactory answer has been given, the most popular answer people gave is
refer to Hess's paper, but even though Hess was giving a good theoretical
background on this paper, practically on how to set up MD jobs is not
given.
So I would appreciate anyone's hint.

Cheers,

Xiaohu
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/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/Support/Mailing_Lists