[gmx-users] gromacs.org_gmx-users Digest, Vol 148, Issue 63

Arnost Mladek arnost.mladek at gmail.com
Wed Aug 17 10:38:43 CEST 2016


Hi Tsjerk,

thank you so much for your advice. I totally agree with you - up to the fitting step, everything is OK. Yet, fitting to chain-A is clearly inevitable for me (at least the rotational fit) as I want to study the movement (sampling) of Chain-B’s COM (in x,y,z coordinate space) with respect to Chain-A’s COM, which is at (0,0,0). If the coordinates are correct, the Chain-B’s COM moves approximately on a sphere surface with radius of the restrained COM-COM distance. The translation part is not an issue - you can just subtract the Chain-A’s COM xyz coordinates from both COMs so you shift the Chain-A’s COM to the origin (0,0,0). The rotational part of the fitting is non-trivial.

Do you have any ideas how to resolve it?

Thank you!

Arnost

> On 17 Aug 2016, at 10:19, gromacs.org_gmx-users-request at maillist.sys.kth.se wrote:
> 
> Send gromacs.org_gmx-users mailing list submissions to
> 	gromacs.org_gmx-users at maillist.sys.kth.se
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users
> or, via email, send a message with subject or body 'help' to
> 	gromacs.org_gmx-users-request at maillist.sys.kth.se
> 
> You can reach the person managing the list at
> 	gromacs.org_gmx-users-owner at maillist.sys.kth.se
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gromacs.org_gmx-users digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: COM-COM distance: PBC problem (Tsjerk Wassenaar)
>   2. Re: CPU running doesn't match command line (Albert)
>   3. Re: HID error in amber14sb.ff (Nicolas Cheron)
>   4. Re: TPI and chemical potential (Gmx QA)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 17 Aug 2016 08:56:52 +0200
> From: Tsjerk Wassenaar <tsjerkw at gmail.com>
> To: Discussion list for GROMACS users <gmx-users at gromacs.org>
> Subject: Re: [gmx-users] COM-COM distance: PBC problem
> Message-ID:
> 	<CABzE1SgJZCsdLECuG=ZC19q0oK9m0FO=fZNWVL4WkDUcw-CZmg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> Hi Arnost,
> 
> When you fit with rotation the coordinates and the box are not on par
> anymore. Anything you do after that tries using PBC will fail. I guess that
> Plumed is trying to use the box to get the COM-COM distance. The only
> (practical) solution: don't fit.
> 
> Cheers,
> 
> Tsjerk
> 
> On Aug 17, 2016 00:24, "Arnost Mladek" <arnost.mladek at gmail.com> wrote:
> 
>> Dear Plumed users,
>> 
>> I've encountered one problem I'm unable to resolve. I use combination of
>> Gromacs 5.0.4 and Plumed 2.1.3 and what I want is to calculate restrained
>> distance between two center of masses (COMs) corresponding to two chains
>> within a dimeric protein. If I let Plumed to calculate COM-COM distances
>> "on-the-fly" (ie. during the simulation), I get correct results, let say
>> distances in the interval of (4,9 ; 5.3) with the average value of 5.1 nm
>> corresponding to the minimum of the restraining potential.
>> 
>> If I use Plumed as a stand-alone software and calculate the distances
>> along the trajectory via "plumed driver --mf_xtc trajectory.xtc --plumed
>> pl.dat", I get the same correct results. Up to this point, no problem.
>> 
>> However if I fit (rot+trans) the trajectory frames to chain-A using
>> GROMACS trjconv command (trjconv -f trajectory.xtc -s reference.tpr -o
>> fitted_trajectory.xtc -fit rot+trans -center) and then run the plumed
>> driver to calculate the distances from the fitted trajectory there are huge
>> jumps of several nm. It is obvious that the problem is somehow associated
>> with PBC and "WHOLEMOLECULES STRIDE=1 ENTITY0=protein" command within the
>> plumed script is unable to resolve it. I've tried various trajectory
>> transformations as suggested on GROMACS web page (http://www.gromacs.org/
>> Documentation/Terminology/Periodic_Boundary_Conditions), like "-pbc mol
>> -ur compact", "-pbc whole", "-pbc nojumps", etc. but nothing helped. As I
>> am unable to get the COM-COM distances using GROMACS alone, I am not sure
>> whether the problem relates to GROMACS or Plumed.
>> 
>> Thank you so much for your help.
>> 
>> AM
>> --
>> Gromacs Users mailing list
>> 
>> * Please search the archive at http://www.gromacs.org/
>> Support/Mailing_Lists/GMX-Users_List before posting!
>> 
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> 
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
>> send a mail to gmx-users-request at gromacs.org.
>> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 17 Aug 2016 09:07:14 +0200
> From: Albert <mailmd2011 at gmail.com>
> To: gmx-users at gromacs.org, Szil?rd P?ll 	<pall.szilard at gmail.com>
> Subject: Re: [gmx-users] CPU running doesn't match command line
> Message-ID: <57B40D22.10601 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Hello:
> 
> Here is the information that you asked for.
> 
>   gmx_mpi mdrun -s 7.tpr -v -g 7.log -c 7.gro -x 7.xtc -ntomp 8 -gpu_id 
> 0 -pin on
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> GROMACS:      gmx mdrun, VERSION 5.1.3
> Executable:   /soft/gromacs/5.1.3_intel/bin/gmx_mpi
> Data prefix:  /soft/gromacs/5.1.3_intel
> Command line:
>   gmx_mpi mdrun -s 7.tpr -v -g 7.log -c 7.gro -x 7.xtc -ntomp 8 -gpu_id 
> 0 -pin on
> 
> GROMACS version:    VERSION 5.1.3
> Precision:          single
> Memory model:       64 bit
> MPI library:        MPI
> OpenMP support:     enabled (GMX_OPENMP_MAX_THREADS = 32)
> GPU support:        enabled
> OpenCL support:     disabled
> invsqrt routine:    gmx_software_invsqrt(x)
> SIMD instructions:  AVX_256
> FFT library:        fftw-3.3.4-sse2
> RDTSCP usage:       enabled
> C++11 compilation:  disabled
> TNG support:        enabled
> Tracing support:    disabled
> Built on:           Thu Aug 11 16:15:26 CEST 2016
> Built by:           albert at cudaB [CMAKE]
> Build OS/arch:      Linux 3.16.7-35-desktop x86_64
> Build CPU vendor:   GenuineIntel
> Build CPU brand:    Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz
> Build CPU family:   6   Model: 62   Stepping: 4
> Build CPU features: aes apic avx clfsh cmov cx8 cx16 f16c htt lahf_lm 
> mmx msr nonstop_tsc pcid pclmuldq pdcm pdpe1gb popcnt pse rdrnd rdtscp 
> sse2 sse3 sse4.1
> sse4.2 ssse3 tdt x2apic
> C compiler:         /soft/intel/impi/5.1.3.223/bin64/mpicc GNU 4.8.3
> C compiler flags:    -mavx    -Wextra -Wno-missing-field-initializers 
> -Wno-sign-compare -Wpointer-arith -Wall -Wno-unused -Wunused-value 
> -Wunused-parameter  -
> O3 -DNDEBUG -funroll-all-loops -fexcess-precision=fast -Wno-array-bounds
> C++ compiler:       /soft/intel/impi/5.1.3.223/bin64/mpicxx GNU 4.8.3
> C++ compiler flags:  -mavx    -Wextra -Wno-missing-field-initializers 
> -Wpointer-arith -Wall -Wno-unused-function  -O3 -DNDEBUG 
> -funroll-all-loops -fexcess-pre
> cision=fast  -Wno-array-bounds
> Boost version:      1.54.0 (external)
> CUDA compiler:      /usr/local/cuda/bin/nvcc nvcc: NVIDIA (R) Cuda 
> compiler driver;Copyright (c) 2005-2016 NVIDIA Corporation;Built on 
> Wed_May__4_21:01:56_CDT
> _2016;Cuda compilation tools, release 8.0, V8.0.26
> CUDA compiler 
> flags:-gencode;arch=compute_20,code=sm_20;-gencode;arch=compute_30,code=sm_30;-gencode;arch=compute_35,code=sm_35;-gencode;arch=compute_37,code=
> sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_52,code=sm_52;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_61,code=sm_61;-gencode
> ;arch=compute_60,code=compute_60;-gencode;arch=compute_61,code=compute_61;-use_fast_math;; 
> ;-mavx;-Wextra;-Wno-missing-field-initializers;-Wpointer-arith;-Wal
> l;-Wno-unused-function;-O3;-DNDEBUG;-funroll-all-loops;-fexcess-precision=fast;-Wno-array-bounds;
> CUDA driver:        8.0
> CUDA runtime:       8.0
> 
> Running on 1 node with total 10 cores, 20 logical cores, 2 compatible GPUs
> Hardware detected on host cudaB (the node of MPI rank 0):
>   CPU info:
>     Vendor: GenuineIntel
>     Brand:  Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz
>     Family:  6  model: 62  stepping:  4
>     CPU features: aes apic avx clfsh cmov cx8 cx16 f16c htt lahf_lm mmx 
> msr nonstop_tsc pcid pclmuldq pdcm pdpe1gb popcnt pse rdrnd rdtscp sse2 
> sse3 sse4.1 ss
> e4.2 ssse3 tdt x2apic
>     SIMD instructions most likely to fit this hardware: AVX_256
>     SIMD instructions selected at GROMACS compile time: AVX_256
>   GPU info:
>     Number of GPUs detected: 2
>     #0: NVIDIA GeForce GTX 780 Ti, compute cap.: 3.5, ECC:  no, stat: 
> compatible
>     #1: NVIDIA GeForce GTX 780 Ti, compute cap.: 3.5, ECC:  no, stat: 
> compatible
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> 
>   gmx_mpi mdrun -s 7.tpr -v -g 7.log -c 7.gro -x 7.xtc -ntomp 8 -gpu_id 
> 1 -pin on -cpi -append -pinoffset 8
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> GROMACS:      gmx mdrun, VERSION 5.1.3
> Executable:   /soft/gromacs/5.1.3_intel/bin/gmx_mpi
> Data prefix:  /soft/gromacs/5.1.3_intel
> Command line:
>   gmx_mpi mdrun -s 7.tpr -v -g 7.log -c 7.gro -x 7.xtc -ntomp 8 -gpu_id 
> 1 -pin on -cpi -append -pinoffset 8
> 
> 
> Running on 1 node with total 10 cores, 20 logical cores, 2 compatible GPUs
> Hardware detected on host cudaB (the node of MPI rank 0):
>   CPU info:
>     Vendor: GenuineIntel
>     Brand:  Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz
>     SIMD instructions most likely to fit this hardware: AVX_256
>     SIMD instructions selected at GROMACS compile time: AVX_256
>   GPU info:
>     Number of GPUs detected: 2
>     #0: NVIDIA GeForce GTX 780 Ti, compute cap.: 3.5, ECC:  no, stat: 
> compatible
>     #1: NVIDIA GeForce GTX 780 Ti, compute cap.: 3.5, ECC:  no, stat: 
> compatible
> 
> Reading file 7.tpr, VERSION 5.1.3 (single precision)
> 
> Reading checkpoint file state.cpt generated: Wed Aug 17 09:01:46 2016
> 
> 
> Using 1 MPI process
> Using 8 OpenMP threads
> 
> 1 GPU user-selected for this run.
> Mapping of GPU ID to the 1 PP rank in this node: 1
> 
> Applying core pinning offset 8
> starting mdrun 'Title'
> 50000000 steps, 100000.0 ps (continuing from step 5746000, 11492.0 ps).
> step 5746080: timed with pme grid 60 60 84, coulomb cutoff 1.000: 2451.9 
> M-cycles
> 
> 
> 
> 
> 
> 
> 
> On 08/16/2016 05:27 PM, Szil?rd P?ll wrote:
>> Most of that copy-pasted info is not what I asked for and overall not
>> very useful. You have still not shown any log files (or details on the
>> hardware). Share the *relevant* stuff, please!
>> --
>> Szil?rd
>> 
>> 
>> On Tue, Aug 16, 2016 at 5:07 PM, Albert <mailmd2011 at gmail.com> wrote:
>>> Hello:
>>> 
>>> Here is my MDP file:
>>> 
>>> define                  = -DREST_ON -DSTEP6_4
>>> integrator              = md
>>> dt                      = 0.002
>>> nsteps                  = 1000000
>>> nstlog                  = 1000
>>> nstxout                 = 0
>>> nstvout                 = 0
>>> nstfout                 = 0
>>> nstcalcenergy           = 100
>>> nstenergy               = 1000
>>> nstxout-compressed      = 10000
>>> ;
>>> cutoff-scheme           = Verlet
>>> nstlist                 = 20
>>> rlist                   = 1.0
>>> coulombtype             = pme
>>> rcoulomb                = 1.0
>>> vdwtype                 = Cut-off
>>> vdw-modifier            = Force-switch
>>> rvdw_switch             = 0.9
>>> rvdw                    = 1.0
>>> ;
>>> tcoupl                  = berendsen
>>> tc_grps                 = PROT   MEMB   SOL_ION
>>> tau_t                   = 1.0    1.0    1.0
>>> ref_t                   = 310   310   310
>>> ;
>>> pcoupl                  = berendsen
>>> pcoupltype              = semiisotropic
>>> tau_p                   = 5.0
>>> compressibility         = 4.5e-5  4.5e-5
>>> ref_p                   = 1.0     1.0
>>> ;
>>> constraints             = h-bonds
>>> constraint_algorithm    = LINCS
>>> continuation            = yes
>>> ;
>>> nstcomm                 = 100
>>> comm_mode               = linear
>>> comm_grps               = PROT   MEMB   SOL_ION
>>> ;
>>> refcoord_scaling        = com
>>> 
>>> 
>>> I compiled Gromacs with the following settings, using Intel MPI:
>>> 
>>> env CC=mpicc CXX=mpicxx F77=mpif90 FC=mpif90 LDF90=mpif90
>>> CMAKE_PREFIX_PATH=/soft/gromacs/fftw-3.3.4:/soft/intel/impi/5.1.3.223 cmake
>>> .. -DBUILD_SHARED_LIB=OFF -DBUILD_TESTING=OFF
>>> -DCMAKE_INSTALL_PREFIX=/soft/gromacs/5.1.3_intel -DGMX_MPI=ON -DGMX_GPU=ON
>>> -DGMX_PREFER_STATIC_LIBS=ON -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda
>>> 
>>> 
>>> I tried it again with one of the job with options:
>>> 
>>> -ntomp 8 -pin on -pinoffset 8
>>> 
>>> 
>>> The two submitted jobs can still only use 8 CPU and the speed is extremely
>>> slow (10ns/day)....when I remove option "-pin on" from one of the job, it
>>> fasten a lot (32ns/day) and 16 CPU were used..... If I only submit one job
>>> with option "-pin on", I can obtain 52ns/day..........
>>> 
>>> 
>>> thx a lot
>>> 
>>> 
>>> On 08/16/2016 04:59 PM, Szil?rd P?ll wrote:
>>>> Hi,
>>>> 
>>>> Without log and hw configs, I it's hard to tell what's happening.
>>>> 
>>>> By turning off pinning the OS is free to move threads around and it
>>>> will try to ensure cores are utilized. However, by leaving threads
>>>> up-pinned you risk taking a significant performance hit. So I'd
>>>> recommend that you run with correct settings.
>>>> 
>>>> If you start with "-ntomp 8 -pin on -pioffset 8" (and you indeed have
>>>> 16 cores no HT), you should be able to see in htop the first eight
>>>> cores empty while the last eight occupied.
>>>> 
>>>> Cheers,
>>>> --
>>>> Szil?rd
>>> 
>>> --
>>> Gromacs Users mailing list
>>> 
>>> * Please search the archive at
>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!
>>> 
>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>> 
>>> * For (un)subscribe requests visit
>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a
>>> mail to gmx-users-request at gromacs.org.
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 17 Aug 2016 09:34:21 +0200
> From: Nicolas Cheron <nicolas.cheron.boulot at gmail.com>
> To: gmx-users at gromacs.org
> Subject: Re: [gmx-users] HID error in amber14sb.ff
> Message-ID:
> 	<CAA5k+esFOKi5fsthm9exi8O68B2ioU2kdECUQaoMrH-K_pYnhg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> Hi,
> 
> I had this problem and wrote to Viet Man who uploaded the force field. I am
> quoting his answer:
> 
> I have found the error come from HIP residues, diheral angle CB-CG-CD2-ND1 (=
> CT-CC-CW-NA). It causes by missing the improper dihedral angle information.
> To solve it, you may open file ffbonded.itp and add below line under line
> 730th
> NA  CW  CC  CT       4      180.00     4.60240     2
> 
> Nicolas
> 
> 
> 
> 2016-08-16 20:28 GMT+02:00 Mark Abraham <mark.j.abraham at gmail.com>:
> 
>> Hi,
>> 
>> Please search the archives - you're not the first person to notice that
>> with the user-contributed port of amber14, but nobody's reported back where
>> the problem might be.
>> 
>> Mark
>> 
>> On Tue, Aug 16, 2016 at 7:48 PM Hongbin Wan <tuf74538 at temple.edu> wrote:
>> 
>>> Hi all,
>>> 
>>> I am trying to run MD simulations with *amber14sb.ff (downloaded from
>>> gromacs forcefiled web)*
>>> 
>>> However, it always shows * No default Improper Dih. types *for HID when
>> to
>>> use grompp. Could anyone tell me how to solve this issue?
>>> 
>>> I had tried other forcefields, and they worked well.
>>> 
>>> Thanks!!
>>> -Hongbin
>>> --
>>> Gromacs Users mailing list
>>> 
>>> * Please search the archive at
>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
>>> posting!
>>> 
>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>> 
>>> * For (un)subscribe requests visit
>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
>>> send a mail to gmx-users-request at gromacs.org.
>>> 
>> --
>> Gromacs Users mailing list
>> 
>> * Please search the archive at http://www.gromacs.org/
>> Support/Mailing_Lists/GMX-Users_List before posting!
>> 
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> 
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
>> send a mail to gmx-users-request at gromacs.org.
>> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 17 Aug 2016 10:18:57 +0200
> From: Gmx QA <gmxquestions at gmail.com>
> To: Discussion list for GROMACS users <gmx-users at gromacs.org>
> Subject: Re: [gmx-users] TPI and chemical potential
> Message-ID:
> 	<CANftEdPAGaiKNNyLuW0Ryv880E_zs42hUcnVQe=+Uf=9zUu91g at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> Thanks again
> 
> In my hands at least, -pbc mol -ur compact seems to be necessary, as
> without it I get a lot of <infs> instead of actual numbers.
> 
> I tried to find a reference for the chemical potential of TIP3P, but
> haven't succeeded yet. Related to gromacs, I find one thread in the
> archives that claims that for TIP3p as well as SPC/E the agreement with
> experiment is reasonable, but with problems for TIP5P.
> 
> https://mailman-1.sys.kth.se/pipermail/gromacs.org_gmx-users/2014-May/089540.html
> 
> Also, does it matter if the rerun is performed on a NVT or NPT trajectory?
> This I could of course easily test, but it seems that formally at least the
> Widow formula is applicable to NVT only?
> 
> Anyway, I think I now know enough to proceed. How reliable are TPI results
> if I want to measure the chemical potential of a drug molecule? How hard
> are they to converge?
> 
> Best
> /PK
> 
> 
> 2016-08-16 16:38 GMT+02:00 Jo?o M. Damas <jmdamas at itqb.unl.pt>:
> 
>> I don't recall any necessary post-processing of the trajectory being
>> necessary, as it should deal well with PBC conditions.
>> 
>> I really don't know what is happening, but it seems like the fixes are
>> going in the right direction.
>> 
>> Try to plot the <mu> along time, to see if it's converging or not.
>> Depending on the trend, you may want to extend the simulation time. Other
>> reasons for incorrect excess chemical potential may be that the TIP3p model
>> may not reproduce well that quantity.
>> 
>> And yeah, it's kJ/mol.
>> 
>> Jo?o
>> 
>> On Tue, Aug 16, 2016 at 2:12 PM, Gmx QA <gmxquestions at gmail.com> wrote:
>> 
>>> Thanks Joao
>>> 
>>> The water box is equilibrated at 298K (I checked density and temperature
>>> with gmx energy, and they show no drift from reasonable averages).
>>> 
>>> However, I am a bit confused as I just tried the approach on the same
>>> trajectory, but extended to 2.5 ns and after one pass through trjconv
>> with
>>> -pbc mol -ur compact options.
>>> 
>>> This seems to work in the sense that I no longer get any infs, but the
>>> value of <mu>, while having the right magnitude, is still off by about a
>>> factor of 2.
>>> After 2.5 ns I get <mu> = -45 (I assume the unit is kJ/mol), whereas if i
>>> read correctly the chemical potential should be -23.5 or so. Can it be
>> that
>>> I now need to increase the run time of my water simulation even more?
>>> 
>>> Thanks
>>> /PK
>>> 
>>> 
>>> 
>>> 2016-08-16 13:47 GMT+02:00 Jo?o M. Damas <jmdamas at itqb.unl.pt>:
>>> 
>>>> Well, 50000 insertions per frame, doesn't look bad. 1 ns should not be
>> an
>>>> issue.
>>>> 
>>>> Well, actually that value normally starts at inf and should go to the
>>>> equilibrium <mu> as you increase sampling. But to be inf after 50000
>>>> inserts, it does sound weird.
>>>> 
>>>> How did you build your box of water? Is it equilibrated at that
>>> temperature
>>>> (298 K)?
>>>> Please make make that the water molecule to be inserted has the correct
>>>> geometrical coordinates and that it is centered at 0,0,0.
>>>> 
>>>> Jo?o
>>>> 
>>>> On Tue, Aug 16, 2016 at 12:45 PM, Gmx QA <gmxquestions at gmail.com>
>> wrote:
>>>> 
>>>>> Hi Joao
>>>>> 
>>>>> Thank you for your reply. My mdp-file is pasted below:
>>>>> 
>>>>> integrator  = tpi
>>>>> emtol         = 1000.0
>>>>> emstep      = 0.01
>>>>> nsteps        = 50000
>>>>> 
>>>>> nstlist         = 1
>>>>> cutoff-scheme   = group
>>>>> ns_type         = grid
>>>>> coulombtype     = pme
>>>>> rcoulomb        = 1.0
>>>>> rvdw            = 1.0
>>>>> pbc             = xyz
>>>>> nstxtcout = 5000
>>>>> 
>>>>> ; Temperature coupling is on
>>>>> tcoupl                 = V-rescale
>>>>> tc-grps                  = system
>>>>> tau_t                      = 0.1
>>>>> ref_t                        = 298
>>>>> 
>>>>> ; Pressure coupling is on
>>>>> pcoupl                      = no
>>>>> pcoupltype                          = isotropic
>>>>> tau_p                               = 2.0
>>>>> ref_p                   = 1.0
>>>>> compressibility     = 4.5e-5
>>>>> 
>>>>> ld_seed = -1
>>>>> 
>>>>> I am using the amber99sb forcefield for tip3p, so I believe the 1.0
>> nm
>>>>> cutoffs to be correct?
>>>>> 
>>>>> I have tried a couple different values for the number of insertions,
>>> and
>>>>> for some frames different values sometimes give non-inf results, but
>>> for
>>>>> the most part it does not seem to make a difference.
>>>>> 
>>>>> 1 ns is short, I agree, but since the value of <mu> (which I take to
>> be
>>>> the
>>>>> excess chemical potential I am after) immediately goes to inf when
>> the
>>>>> first mu=inf appears, extending does not make sense to me? Is the
>>>> chemical
>>>>> potential reported elsewhere as well?
>>>>> 
>>>>> Thanks
>>>>> /PK
>>>>> 
>>>>> 2016-08-16 12:35 GMT+02:00 Jo?o M. Damas <jmdamas at itqb.unl.pt>:
>>>>> 
>>>>>> Yes, all water atoms can't be with coordinates 0,0,0. I don't know
>>> how
>>>>> did
>>>>>> that even work... Weird.
>>>>>> 
>>>>>> 1 ns is very short time scale. Also, how many insertions are you
>>> trying
>>>>> per
>>>>>> frame? That could also help improve the sampling.
>>>>>> 
>>>>>> The inf values are normal as it just means that the water is too
>>>>> structured
>>>>>> and it's hard to insert a new water from the sampling point of
>> view.
>>>>>> 
>>>>>> Can you post the .mdp you used for the tpi?
>>>>>> 
>>>>>> Jo?o
>>>>>> 
>>>>>> On Tue, Aug 16, 2016 at 9:52 AM, Gmx QA <gmxquestions at gmail.com>
>>>> wrote:
>>>>>> 
>>>>>>> Please - anyone?
>>>>>>> 
>>>>>>> I gathered from the mail-list that maybe the entire molecule
>> (water
>>>> in
>>>>>> this
>>>>>>> case) should be centered on origo (rather than having all atoms
>> at
>>>>>> (0,0,0),
>>>>>>> but this gives me only a lot of inf for the chemical potential.
>>>>>>> 
>>>>>>> How can I calculate the excess chemical potential of water using
>>> TPI
>>>> in
>>>>>>> gromacs?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 2016-08-15 13:31 GMT+02:00 Gmx QA <gmxquestions at gmail.com>:
>>>>>>> 
>>>>>>>> Dear list
>>>>>>>> 
>>>>>>>> I am trying to teach myself how the test particle method for
>>> excess
>>>>>>>> chemical potential calculations work. To this end, I created a
>>>> small
>>>>>>> system
>>>>>>>> of about 900 water molecules (TIP3p), and simulated for 1 ns.
>>>>>>>> 
>>>>>>>> I then set up files for inserting an extra water molecule to
>>>>> calculate
>>>>>>> mu,
>>>>>>>> the chemical potential.
>>>>>>>> 
>>>>>>>> The end of my tpi_start.gro looks like this:
>>>>>>>> <snip>
>>>>>>>>  884SOL     OW 2650   2.466   0.788   2.747 -0.5599 -0.0387
>>>> 0.0570
>>>>>>>>  884SOL    HW1 2651   2.529   0.835   2.802  0.0024 -0.9901
>>>> 0.2261
>>>>>>>>  884SOL    HW2 2652   2.506   0.703   2.732 -1.4472 -0.3598
>>>> -0.5022
>>>>>>>>  885SOL     OW 2653   0.000   0.000   0.000  0.0000  0.0000
>>>> 0.0000
>>>>>>>>  885SOL    HW1 2654   0.000   0.000   0.000  0.0000  0.0000
>>>> 0.0000
>>>>>>>>  885SOL    HW2 2655   0.000   0.000   0.000  0.0000  0.0000
>>>> 0.0000
>>>>>>>>   3.01188   3.01188   3.01188
>>>>>>>> 
>>>>>>>> So I think this last water molecule is the one to be inserted.
>>> The
>>>>>>>> topology was also updated accordingly.
>>>>>>>> 
>>>>>>>> I then made a rerun like this:
>>>>>>>> 
>>>>>>>> $ gmx mdrun -v -deffnm tpi -rerun md.xtc
>>>>>>>> 
>>>>>>>> And the output is a series of lines like this:
>>>>>>>> 
>>>>>>>> Reading frame     180 time  900.000   mu  8.924e+00 <mu>
>>> 7.240e+00
>>>>>>>> mu  7.671e+00 <mu>  7.242e+00
>>>>>>>> mu  6.987e+00 <mu>  7.241e+00
>>>>>>>> mu  7.010e+00 <mu>  7.239e+00
>>>>>>>> mu  7.691e+00 <mu>  7.241e+00
>>>>>>>> mu  7.439e+00 <mu>  7.242e+00
>>>>>>>> mu  6.757e+00 <mu>  7.240e+00
>>>>>>>> mu  8.114e+00 <mu>  7.243e+00
>>>>>>>> mu  7.173e+00 <mu>  7.243e+00
>>>>>>>> mu  8.768e+00 <mu>  7.249e+00
>>>>>>>> Reading frame     190 time  950.000   mu  7.799e+00 <mu>
>>> 7.252e+00
>>>>>>>> mu  9.284e+00 <mu>  7.259e+00
>>>>>>>> mu  8.103e+00 <mu>  7.262e+00
>>>>>>>> mu  7.835e+00 <mu>  7.265e+00
>>>>>>>> mu  7.321e+00 <mu>  7.265e+00
>>>>>>>> mu  7.576e+00 <mu>  7.267e+00
>>>>>>>> mu  9.348e+00 <mu>  7.274e+00
>>>>>>>> mu  7.021e+00 <mu>  7.272e+00
>>>>>>>> mu  7.162e+00 <mu>  7.272e+00
>>>>>>>> mu  7.695e+00 <mu>  7.274e+00
>>>>>>>> Reading frame     200 time 1000.000   mu  7.104e+00 <mu>
>>> 7.273e+00
>>>>>>>> 
>>>>>>>> Now, is <mu> here the average computed chemical potential? What
>>> is
>>>>> the
>>>>>>> TPI
>>>>>>>> energy distribution being reported in the tpi.xvg-file?
>>>>>>>> 
>>>>>>>> I tried to google for the chemical potential of water and
>>> according
>>>>> to
>>>>>>>> e.g. [1] (page 13) it should be around -23.5 kJ/mol. I would
>>> really
>>>>>>>> appreciate if someone could comment on this, as I need to
>>>> understand
>>>>> it
>>>>>>>> before moving on to more relevant (for me) systems?.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> /PK
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> [1] Chemical potential of liquids and mixtures via Adaptive
>>>>> Resolution
>>>>>>> ...
>>>>>>>> <https://www.google.se/url?sa=t&rct=j&q=&esrc=s&source=web&
>>>>>>> cd=21&ved=0ahUKEwj-7-2gqMPOAhVFWiwKHdp4DYY4FBAWCBww
>>>>>>> AA&url=https%3A%2F%2Fopus4.kobv.de%2Fopus4-zib%2Ffiles%
>>>>>>> 2F5097%2FZIB-Report_14-25.pdf&usg=AFQjCNECRk9dif8TGxKJeeztHV6T_
>>>>>>> FmVuw&sig2=-vsjUB9HRdlcnt4vyKWcbw>
>>>>>>>> 
>>>>>>> --
>>>>>>> Gromacs Users mailing list
>>>>>>> 
>>>>>>> * Please search the archive at http://www.gromacs.org/
>>>>>>> Support/Mailing_Lists/GMX-Users_List before posting!
>>>>>>> 
>>>>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>>>>> 
>>>>>>> * For (un)subscribe requests visit
>>>>>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_
>> gmx-users
>>>> or
>>>>>>> send a mail to gmx-users-request at gromacs.org.
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Jo?o M. Damas
>>>>>> PhD Student
>>>>>> Protein Modelling Group
>>>>>> ITQB-UNL, Oeiras, Portugal
>>>>>> Tel:+351-214469613
>>>>>> --
>>>>>> Gromacs Users mailing list
>>>>>> 
>>>>>> * Please search the archive at http://www.gromacs.org/
>>>>>> Support/Mailing_Lists/GMX-Users_List before posting!
>>>>>> 
>>>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>>>> 
>>>>>> * For (un)subscribe requests visit
>>>>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users
>>> or
>>>>>> send a mail to gmx-users-request at gromacs.org.
>>>>> --
>>>>> Gromacs Users mailing list
>>>>> 
>>>>> * Please search the archive at http://www.gromacs.org/
>>>>> Support/Mailing_Lists/GMX-Users_List before posting!
>>>>> 
>>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>>> 
>>>>> * For (un)subscribe requests visit
>>>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users
>> or
>>>>> send a mail to gmx-users-request at gromacs.org.
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Jo?o M. Damas
>>>> PhD Student
>>>> Protein Modelling Group
>>>> ITQB-UNL, Oeiras, Portugal
>>>> Tel:+351-214469613
>>>> --
>>>> Gromacs Users mailing list
>>>> 
>>>> * Please search the archive at http://www.gromacs.org/
>>>> Support/Mailing_Lists/GMX-Users_List before posting!
>>>> 
>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>> 
>>>> * For (un)subscribe requests visit
>>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
>>>> send a mail to gmx-users-request at gromacs.org.
>>>> 
>>> --
>>> Gromacs Users mailing list
>>> 
>>> * Please search the archive at http://www.gromacs.org/
>>> Support/Mailing_Lists/GMX-Users_List before posting!
>>> 
>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>> 
>>> * For (un)subscribe requests visit
>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
>>> send a mail to gmx-users-request at gromacs.org.
>>> 
>> 
>> 
>> 
>> --
>> Jo?o M. Damas
>> PhD Student
>> Protein Modelling Group
>> ITQB-UNL, Oeiras, Portugal
>> Tel:+351-214469613
>> --
>> Gromacs Users mailing list
>> 
>> * Please search the archive at http://www.gromacs.org/
>> Support/Mailing_Lists/GMX-Users_List before posting!
>> 
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> 
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
>> send a mail to gmx-users-request at gromacs.org.
>> 
> 
> 
> ------------------------------
> 
> -- 
> Gromacs Users mailing list
> 
> * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!
> 
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> 
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-request at gromacs.org.
> 
> End of gromacs.org_gmx-users Digest, Vol 148, Issue 63
> ******************************************************



More information about the gromacs.org_gmx-users mailing list