Re: [gmx-users] TPI Results differ in v4.5.7 and v4.6.1

2013-06-29 Thread João M . Damas
Niels,

Which force-field did you use? I guess an uncharged CH4 shouldn't be giving
different results for TPI when changing coulomb... Actually, coulomb is
turned off if there's no charge in the particles to insert, if I remember
the code correctly.

João


On Mon, Jun 24, 2013 at 3:40 PM, Niels Müller u...@nielsm.de wrote:

 Hi João,

 Indeed your instinct seems to be good! When switching the Coulomb-Type to
 Cut-Off, there doesn't seem to be a difference between 4.6 and 4.5.
 Apparently its an issue with the PME sum. We will investigate further.


 Am 24.06.2013 um 14:42 schrieb João M. Damas jmda...@itqb.unl.pt:

  Niels,
 
  This is very interesting. At our group, a colleague of mine and I have
 also
  identified differences in the TPI integrator between 4.0.X and 4.5.X, but
  we still haven't had the time to report it properly, since we are using a
  slightly modified version of the TPI algorithm.
 
  Instinctively, we were attributing it to some different behaviours in the
  RF that are observed between those versions. We also know that the TPI
  algorithm began allowing PME treatment from 4.5.X onwards, so maybe there
  are some differences going on the electrostatics level? But, IIRC, no
  modifications to the TPI code were on the release notes from 4.5.X to
  4.6.X...
 
  We'll try to find some time to report our findings as soon as possible.
  Maybe they are related.
 
  Best,
  João
 
 
  On Mon, Jun 24, 2013 at 10:19 AM, Niels Müller u...@nielsm.de wrote:
 
  Hi GMX Users,
 
  We are computing the chemical potential of different gas molecules in a
  polymer melt with the tpi integrator.
  The computations are done for CO2 and CH4.
  The previous computations were done with v4.5.5 or 4.5.7 and gave equal
  results.
 
  I recently switched to gromacs version 4.6.1, and the chemical potential
  computed by this version is shifted by a nearly constant factor, which
 is
  different for the two gas molecules.
  We are perplexed what causes this shift. Was there any change in the new
  version that affects the tpi integration? I will provide the mdp file we
  used below.
 
  The tpi integration is run on basis of the last 10 ns of a 30 ns NVT
  simulation with 'mdrun -rerun'.
 
  Best regards,
  Niels.
 
  #
  The mdp file:
  #
 
  ; VARIOUS PREPROCESSING OPTIONS
  cpp  = cpp
  include=
  define  =
 
  ; RUN CONTROL PARAMETERS
  integrator   = tpi
  ; Start time and timestep in ps
  tinit= 0
  dt   = 0.001
  nsteps   = 100
  ; For exact run continuation or redoing part of a run
  init_step= 0
  ; mode for center of mass motion removal
  comm-mode= Linear
 
  ; number of steps for center of mass motion removal
  nstcomm  = 1
  ; group(s) for center of mass motion removal
  comm-grps=
 
  ; LANGEVIN DYNAMICS OPTIONS
  ; Temperature, friction coefficient (amu/ps) and random seed
  bd-fric  = 0.5
  ld-seed  = 1993
 
  ; ENERGY MINIMIZATION OPTIONS
  ; Force tolerance and initial step-size
  emtol= 100
  emstep   = 0.01
  ; Max number of iterations in relax_shells
  niter= 20
  ; Step size (1/ps^2) for minimization of flexible constraints
  fcstep   = 0
  ; Frequency of steepest descents steps when doing CG
  nstcgsteep   = 1000
  nbfgscorr= 10
 
  ; OUTPUT CONTROL OPTIONS
  ; Output frequency for coords (x), velocities (v) and forces (f)
  nstxout  = 100
  nstvout  = 0
  nstfout  = 0
  ; Checkpointing helps you continue after crashes
  nstcheckpoint= 100
  ; Output frequency for energies to log file and energy file
  nstlog   = 100
  nstenergy= 100
  ; Output frequency and precision for xtc file
  nstxtcout= 0
  xtc-precision= 1000
  ; This selects the subset of atoms for the xtc file. You can
  ; select multiple groups. By default all atoms will be written.
  xtc-grps =
  ; Selection of energy groups
  energygrps   =
 
  ; NEIGHBORSEARCHING PARAMETERS
  ; nblist update frequency
  nstlist  = 5
  ; ns algorithm (simple or grid)
  ns_type  = grid
  ; Periodic boundary conditions: xyz (default), no (vacuum)
  ; or full (infinite systems only)
  pbc  = xyz
  ; nblist cut-off
  rlist= 0.9
  domain-decomposition = no
 
  ; OPTIONS FOR ELECTROSTATICS AND VDW
  ; Method for doing electrostatics
  coulombtype  = pme
  rcoulomb-switch  = 0
  rcoulomb = 0.9
  ; Dielectric constant (DC) for cut-off or DC of reaction field
  epsilon-r= 1
  ; Method for doing Van der Waals
  vdw-type   

[gmx-users] g_energy units

2013-06-29 Thread Leandro Bortot
Dear users,
 is the energy output from g_energy really in kJ/mol?

 As an example, I wanted to know which isoform of a protein forms the
most stable dimer. I calculated the potential energy of the interaction
between two monomers of the dimer and I got -2000 kJ/mol for one isoform
and -4000 kJ/mol for the other.

 Shouldn't it be J/mol?
 If these values are really in kJ/mol, how can I interpret it in terms
of molecular scale? -2000 or -4000 kJ/mol sure is a lot of energy for
such scale, in which the energies are typically at the order or 10s of
kJ/mol.
 I know I'm not accounting for the entropic effects, but I have never
seen an entropy contribution in the scales of 1000 kJ/mol either...
 Is it the case as these energy values are somewhat arbitrary and I can
only say that one isoform has 2x the interaction energy of the other?


 I know this is not a bad structure with high energy case. I have
been wondering about the values from g_energy for quite a long time and I
have seen it in many different systems.

 my calculation procedure was as follows:
  From a standard explicit solvent MD trajectory (md.trr) I
extracted only the protein with trjconv, creating the file md_protein.trr.
I used tpbconv to do the same with the md.tpr file, creating
md_protein.tpr. Then I re-ran the MD over this trajectory with mdrun: mdrun
-s md_protein.tpr -rerun md_protein.trr -deffnm protein. The potential
energy of the dimer was extracted from the created protein.edr file. The
same was made for both chains A and B using an index file created with
make_ndx. The dimer interaction energy was calculated as Potential_AB -
(Potential_A + Potential_B).
  Is this wrong?


 Any help would be greatly appreciated.

Thank you in advance,
Leandro Bortot
-- 
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


Re: [gmx-users] g_energy units

2013-06-29 Thread Mark Abraham
What (change in) free-energy difference are you trying to measure? How
do these potential energy (differences) relate to them?

Mark

On Sat, Jun 29, 2013 at 7:13 PM, Leandro Bortot leandro@gmail.com wrote:
 Dear users,
  is the energy output from g_energy really in kJ/mol?

  As an example, I wanted to know which isoform of a protein forms the
 most stable dimer. I calculated the potential energy of the interaction
 between two monomers of the dimer and I got -2000 kJ/mol for one isoform
 and -4000 kJ/mol for the other.

  Shouldn't it be J/mol?
  If these values are really in kJ/mol, how can I interpret it in terms
 of molecular scale? -2000 or -4000 kJ/mol sure is a lot of energy for
 such scale, in which the energies are typically at the order or 10s of
 kJ/mol.
  I know I'm not accounting for the entropic effects, but I have never
 seen an entropy contribution in the scales of 1000 kJ/mol either...
  Is it the case as these energy values are somewhat arbitrary and I can
 only say that one isoform has 2x the interaction energy of the other?


  I know this is not a bad structure with high energy case. I have
 been wondering about the values from g_energy for quite a long time and I
 have seen it in many different systems.

  my calculation procedure was as follows:
   From a standard explicit solvent MD trajectory (md.trr) I
 extracted only the protein with trjconv, creating the file md_protein.trr.
 I used tpbconv to do the same with the md.tpr file, creating
 md_protein.tpr. Then I re-ran the MD over this trajectory with mdrun: mdrun
 -s md_protein.tpr -rerun md_protein.trr -deffnm protein. The potential
 energy of the dimer was extracted from the created protein.edr file. The
 same was made for both chains A and B using an index file created with
 make_ndx. The dimer interaction energy was calculated as Potential_AB -
 (Potential_A + Potential_B).
   Is this wrong?


  Any help would be greatly appreciated.

 Thank you in advance,
 Leandro Bortot
 --
 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 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


Re: [gmx-users] Installation on Ubuntu 12.04LTS

2013-06-29 Thread Mare Libero
Thanks guys! I think it's working now. Just in case others may run into the 
same difficulties, I am summarizing below what worked for me.

I installed both gcc-4.4 and gcc-4.7 from synaptic. Then updated CUDA to 5.0, 
with the package cuda_5.0.35_linux_64_ubuntu11.10-1.run available from the 
nvidia site. Compiling cuda toolkit will require gcc-4.4, so I had to 
temporarily change some links:
sudo ln -s /usr/bin/gcc-4.4 /usr/bin/gcc
sudo ln -s /usr/bin/g++-4.4 /usr/bin/g++


Then I installed the toolkit and the samples:
sudo ./cuda_5.0.35_linux_64_ubuntu11.10-1.run -toolkit

Installing the CUDA samples required some extra packages on my system:
sudo apt-get install freeglut3
sudo ln -s /usr/lib/x86_64-linux-gnu/libglut.so.3 /usr/lib/libglut.so
sudo ./cuda_5.0.35_linux_64_ubuntu11.10-1.run -samples

Then update my .bashrc:
export 
LD_LIBRARY_PATH=/usr/local/cuda-5.0/lib64/:/usr/local/cuda-5.0/lib:$LD_LIBRARY_PATH
export PATH=/usr/local/cuda-5.0/bin/:$PATH

Finally confirm that CUDA 5.0 is the defoult compiler:
nvcc -version


Now I changed back the gcc links to install gromacs:
sudo ln -s /usr/bin/gcc-4.7 /usr/bin/gcc
sudo ln -s /usr/bin/g++-4.7 /usr/bin/g++

CUDA apparently check which gcc version is used, and will complain for gcc 
version above 4.6. Gromacs on the other end will require gcc-4.7. I found a 
solution on a blog, and comment out the compiler-check in the CUDA header file 
/usr/local/cuda-5.0/include/host_config.h


Comment out:
//#if __GNUC__  4 || (__GNUC__ == 4  __GNUC_MINOR__  6)
//#error -- unsupported GNU version! gcc 4.7 and up are not supported!
//#endif /* __GNUC__ 4 || (__GNUC__ == 4  __GNUC_MINOR__  6) */


Now I could cmake/make/install gromacs:
cmake .. -DGMX_GPU=ON -DGMX_BUILD_OWN_FFTW=ON
make
sudo make install


And add the /usr/local/gromacs/bin/ directory to my path.


I am still trying to fix the issues with the intel compiler. The gcc compiled 
version benchmark at 52ns/day with the lysozyme in water tutorial.


Thanks again.




 From: Szilárd Páll szilard.p...@cbr.su.se
To: Mare Libero marelibe...@yahoo.com; Discussion list for GROMACS users 
gmx-users@gromacs.org 
Sent: Thursday, June 27, 2013 10:47 AM
Subject: Re: [gmx-users] Installation on Ubuntu 12.04LTS
 

On Thu, Jun 27, 2013 at 12:57 PM, Mare Libero marelibe...@yahoo.com wrote:
 Hello everybody,

 Does anyone have any recommendation regarding the installation of gromacs 4.6 
 on Ubuntu 12.04? I have the nvidia-cuda-toolkit that comes in synaptic 
 (4.0.17-3ubuntu0.1 installed in /usr/lib/nvidia-cuda-toolkit) and the drivers 
 304.88.
 Apparently, this is not compatible with gcc-4.5 and higher. When I issue:


 $ cmake .. -DGMX_GPU=ON -DCUDA_TOOLKIT_ROOT_DIR=/usr/lib/nvidia-cuda-toolkit 
 -DGMX_BUILD_OWN_FFTW=ON
 $ make

 the compilation ends with:

 In file included from 
 /usr/lib/nvidia-cuda-toolkit/include/cuda_runtime.h:59:0,
                  from command-line:0:
 /usr/include/host_config.h:82:2: error: #error -- unsupported GNU version! 
 gcc 4.5 and up are not supported!

 If I downgrade to gcc-4.4 this error disappears, but gromacs compilation 
 fails with a different error:

 cc1plus: error: unrecognized command line option -fexcess-precision=fast
 CMake Error at cuda_tools_generated_pmalloc_cuda.cu.o.cmake:198 (message):
   Error generating
   
/home/me/Downloads/gromacs-4.6.2/build/src/gmxlib/cuda_tools/CMakeFiles/cuda_tools.dir//./cuda_tools_generated_pmalloc_cuda.cu.o

 make[2]: *** 
 [src/gmxlib/cuda_tools/CMakeFiles/cuda_tools.dir/./cuda_tools_generated_pmalloc_cuda.cu.o]
  Error 1
 make[1]: *** [src/gmxlib/cuda_tools/CMakeFiles/cuda_tools.dir/all] Error 2
 make: *** [all] Error 2

I guess what happens is that you are using gcc 4.5 for the CPU code
and gcc 4.4 as the nvcc host compiler. However, the compiler options
used for gcc (CMAKE_CXX_FLAGS) get propagated to nvcc;
-fexcess-precision=fast is supported by gcc 4.5, but not by 4.4, hence
the error when compiling CUDA code.


 Also, I tried the Intel compilers that comes with the non-commercial  Intel 
 c++ composer XE (which I believe are recommended). The compilation produces a 
 number of warnings, and then dies with the following error:


 $ CC=/opt/intel/bin/icc  cmake .. -DGMX_GPU=ON 
 -DCUDA_TOOLKIT_ROOT_DIR=/usr/lib/nvidia-cuda-toolkit -DGMX_BUILD_OWN_FFTW=ON

 [ 63%] Building C object share/template/CMakeFiles/template.dir/template.c.o
 make[2]: *** No rule to make target `src/gmxlib/libgmx.so.8', needed by 
 `share/template/template'.  Stop.
 make[1]: *** [share/template/CMakeFiles/template.dir/all] Error 2
 make: *** [all] Error 2

This should work, but CUDA 4.0 is ancient surely does not support icc
13. I suggest that you get CUDA 5.0 and use gcc 4.7 (or a new icc). If
you really want to stick to CUDA 4.0, try using gcc 4.4 as the general
C++ compiler (CMAKE_CXX_COMPILER) which should avoid the above error.

 Thanks in advance for your help,

 Al

 --
 gmx-users mailing list    gmx-users@gromacs.org