[gmx-users] Re: problem in g_membed

[pavithrakb]

Thank you so much sir.
the entire thread was highly useful.





--
View this message in context: 
http://gromacs.5086.x6.nabble.com/problem-in-g-membed-tp5009503p5010188.html
Sent from the GROMACS Users Forum mailing list archive at Nabble.com.
-- 
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] energy conservation / frozen atoms

[S. Alireza Bagherzadeh]

Hi All,

I am simulating a system in which I have two solid surfaces and I keep them
frozen during simulations. I also exclude the interactions between its
atoms to avoid spurious contribution to the virial pressure due to large
forces between them as suggested in the manual.

I run a nvt for equilibration and then I do the production run in an nve
ensemble; however, I am not getting good energy conservation. There is a
huge energy drift...


When I remove the solid surfaces, I will only have water molecules and
united atom methane molecules in my system. Using the same protocol I
obtain a very good energy conservation...

Any insight on what might be wrong in my system would be very appreciated.


Here is the mdp file:

;
;File 'mdout_nve.mdp' was generated
;By user: onbekend (0)
;On host: onbekend
;At date: Sun Jul 28 18:13:02 2013
;

; VARIOUS PREPROCESSING OPTIONS
; Preprocessor information: use cpp syntax.
; e.g.: -I/home/joe/doe -I/home/mary/roe
include  =
; e.g.: -DPOSRES -DFLEXIBLE (note these variable names are case sensitive)
define   =

; RUN CONTROL PARAMETERS
integrator   = md
; 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
; Part index is updated automatically on checkpointing (keeps files
separate)
simulation_part  = 1
; mode for center of mass motion removal
comm-mode= Linear
; number of steps for center of mass motion removal
nstcomm  = 100
; group(s) for center of mass motion removal
comm-grps=

; LANGEVIN DYNAMICS OPTIONS
; Friction coefficient (amu/ps) and random seed
bd-fric  = 0
ld-seed  = 1993

; ENERGY MINIMIZATION OPTIONS
; Force tolerance and initial step-size
emtol= 10
emstep   = 0.01
; Max number of iterations in relax_shells
niter= 20
; Step size (ps^2) for minimization of flexible constraints
fcstep   = 0
; Frequency of steepest descents steps when doing CG
nstcgsteep   = 1000
nbfgscorr= 10

; TEST PARTICLE INSERTION OPTIONS
rtpi = 0.05

; OUTPUT CONTROL OPTIONS
; Output frequency for coords (x), velocities (v) and forces (f)
nstxout  = 0
nstvout  = 0
nstfout  = 0
; Output frequency for energies to log file and energy file
nstlog   = 500
nstcalcenergy= -1
nstenergy= 500
; 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 = HYDW HYDG SOL GAS SiO2 SiOH
; Selection of energy groups
energygrps   = HYDW HYDG SOL GAS SiO2 SiOH

; NEIGHBORSEARCHING PARAMETERS
; nblist update frequency
nstlist  = 10
; ns algorithm (simple or grid)
ns_type  = grid
; Periodic boundary conditions: xyz, no, xy
pbc  = xyz
periodic_molecules   = no
; nblist cut-off
rlist= 1.7
; long-range cut-off for switched potentials
rlistlong= -1

; OPTIONS FOR ELECTROSTATICS AND VDW
; Method for doing electrostatics
coulombtype  = PME-Switch
rcoulomb_switch  = 1.3
rcoulomb = 1.5
; Relative dielectric constant for the medium and the reaction field
epsilon_r= 1
epsilon_rf   = 1
; Method for doing Van der Waals
vdw-type = shift
; cut-off lengths
rvdw-switch  = 1.3
rvdw = 1.5
; Apply long range dispersion corrections for Energy and Pressure
DispCorr = EnerPres
; Extension of the potential lookup tables beyond the cut-off
table-extension  = 1
; Seperate tables between energy group pairs
energygrp_table  =
; Spacing for the PME/PPPM FFT grid
fourierspacing   = 0.12
; FFT grid size, when a value is 0 fourierspacing will be used
fourier_nx   = 0
fourier_ny   = 0
fourier_nz   = 0
; EWALD/PME/PPPM parameters
pme_order= 6
ewald_rtol   = 1e-06
ewald_geometry   = 3d
epsilon_surface  = 0
optimize_fft = yes

; IMPLICIT SOLVENT ALGORITHM
implicit_solvent = No

; GENERALIZED BORN ELECTROSTATICS
; Algorithm for calculating Born radii
gb_algorithm = Still
; Frequency of calculating the Born radii inside rlist
nstgbradii   = 1
; Cutoff for Born radii calculation; the contribution from atoms
; between rlist and rgbradii is updated every nstlist steps
rgbradii = 1
; Dielectric coefficient of the implicit solvent
gb_epsilon_solvent 

Re: [gmx-users] Re: problem in g_membed

[Justin Lemkul]

On 7/29/13 9:03 PM, pavithrakb wrote:

I would have made a blunder by selecting the POPE membrane.
But, that paper (one which used POPE for human protein) was published in
ACS-Journal of Chemical Information and Modeling.
I thought following high standard papers are trust worthy.
Thank you so much sir. I will start learning the basics before continuing
the simulation.



One should always read with a critical eye.  Good journals got that way for a 
reason, but the peer review system is not flawless.  I have seen very bad papers 
in very good journals.  Question everything until you're satisfied that you 
understand what the authors did and why.


-Justin

--
==

Justin A. Lemkul, Ph.D.
Postdoctoral Fellow

Department of Pharmaceutical Sciences
School of Pharmacy
Health Sciences Facility II, Room 601
University of Maryland, Baltimore
20 Penn St.
Baltimore, MD 21201

jalem...@outerbanks.umaryland.edu | (410) 706-7441

==
--
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: Umbrella sampling question

[Christopher Neale]

Why not do two umbrella sampling simulations: one with initial conformations 
from your faster pulling and one with initial conformations from your slower 
pulling. Then you can run them both as regular US simulations until (a) neither 
US PMF is drifting systematically with increasing simulation time and (b) they 
converge to the same answer. This way, you might also be able to make some 
comment on the relative importance of doing the initial pulling slowly.

Next time, please wait until your post has appeared on the list (it is 
currently awaiting approval for inclusion of large images) before sending me a 
private email asking me to comment on-list (which is, by itself, fine with me).

Also: I can't make heads or tails of your plots. (i) I have no idea which one 
corresponds to which force constant; (ii) you mentioned 4 force constants but 
you posted 8 figures; (iii) I can not read any of the axes or labels.

Chris.

From: surampu...@gmail.com [surampu...@gmail.com]
Sent: 29 July 2013 19:39
To: chris.ne...@utoronto.ca
Subject: Umbrella sampling question

Hi Chris,

I have seen many of your contributions to the Umbrella sampling topic in the 
forum. It would be of immense help to me if you can throw light on a few points.

I am running my first umbrella sampling simulation, and having hard time to 
decide if the PMF plot I am getting is right or wrong. I am pulling one atom 
from a short polymer chain from the center of a micelle and trying to obtain a 
PMF plot along the distance from the center of the micelle to the surface and 
eventually few nanometers away from the micelle. Here is the mdp file for the 
pulling:
title   = Umbrella pulling simulation
define  = -DPOSRES_surfpoly
; Run parameters
integrator  = md
dt  = 0.002 ; timestep (ps)
tinit   = 0
nsteps  = 25;  500 ps= 0.5ns
nstcomm = 10; remove COM every 10 steps
; Output parameters
nstxout = 5000
nstvout = 5000
nstfout = 250
nstxtcout   = 250
nstenergy   = 500
; Bond parameters
constraint_algorithm= lincs
constraints = all-bonds
continuation= yes   ; continuing from NPT
; Single-range cutoff scheme
nstlist = 5
ns_type = grid
rlist   = 1.4
rcoulomb= 1.4
rvdw= 1.4
; PME electrostatics parameters
coulombtype = PME
fourierspacing  = 0.12
fourier_nx  = 0
fourier_ny  = 0
fourier_nz  = 0
pme_order   = 4
ewald_rtol  = 1e-5
optimize_fft= yes
; Berendsen temperature coupling is on in two groups
Tcoupl  = Nose-Hoover
tc_grps = System
tau_t   = 0.5
ref_t   = 300
; Pressure coupling is on
Pcoupl  = Parrinello-Rahman
pcoupltype  = isotropic
tau_p   = 1.0
compressibility = 4.5e-5
ref_p   = 1.0
refcoord_scaling = com
; Generate velocities is off
gen_vel = no
; Periodic boundary conditions are on in all directions
pbc = xyz
; Long-range dispersion correction
DispCorr= EnerPres
; Pull code
pull= umbrella  ; COM pulling using umbrella potential between 
reference group and other groups
;pull_geometry   = distance  ; simple distance increase
pull_geometry   = direction  ; simple distance increase
;pull_dim= Y N N ; pulling in x-direction
pull_vec1   = 1 0 0 ; pulling in x-direction
pull_start  = yes   ; define initial COM distance > 0
pull_ngroups= 1 ; we are only applying a pulling force to one group
pull_group0 = surf   ; reference group for pulling
pull_group1 = poly; group to which pulling force is applied
pull_rate1  = 0.01  ; 0.01 nm per ps = 10 nm per ns
pull_k1 = 300   ; kJ mol^-1 nm^-2

I have repeated pull run using various force constants 
(pull_k1=300,500,1000,2000 kJ/mol/nm^2) to pull over 5 nm distance with 0.1nm 
windows and none of them is a clear pick as in the tutorial as to which one to 
use for umbrella sampling. From my understanding, force constant should neither 
be too low or too high. Is there a simpler way to decide which one is the right 
force constant to use from the plots? Please see the link below for the F vs 
time and  position vs time plots (top to bottom order --- pull_k1=2000, 1000, 
500, 300 kJ/mol/nm^2).

http://gromacs.5086.x6.nabble.com/Umbrella-sampling-force-vs-time-plots-tp5009709p5010097.html

Thanks a lot,
Andy S.

_
Sent from http://gromacs.5086.x6.nabble.com



--
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: problem in g_membed

[pavithrakb]

I would have made a blunder by selecting the POPE membrane.
But, that paper (one which used POPE for human protein) was published in
ACS-Journal of Chemical Information and Modeling. 
I thought following high standard papers are trust worthy. 
Thank you so much sir. I will start learning the basics before continuing
the simulation.




--
View this message in context: 
http://gromacs.5086.x6.nabble.com/problem-in-g-membed-tp5009503p5010184.html
Sent from the GROMACS Users Forum mailing list archive at Nabble.com.
-- 
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] trouble with -DGMX_BUILD_OWN_FFTW, crashing in m4?

[Mark Abraham]

Yes, this is a known problem. A race condition with parallel make
exists between the gmxfftw build target and the things that depend on
it. AFAIK, a second call to make will Just Work. There are known ways
for GROMACS to solve this by controlling the dependency properly, but
the leading candidates either do not work at all with a specific CMake
minor release, or require more invasive restructuring then we will do
in 4.6 series. A long discussion thread exists on gmx-developers for
those with nothing to do!

Do let us know how you go. I guess we should update the install guide
accordingly.

Mark

On Mon, Jul 29, 2013 at 11:59 PM, Jacob Pessin
 wrote:
> Hi all,
>
> I'm trying to compile 4.6.3 on my desktop, but have running into some issues 
> with FFTW.
> Specifically with "-DGMX_BUILD_OWN_FFTW=ON" make seems to crash with M4 (if 
> I'm reading it right)
>
> This is not dpkg install-info anymore, but GNU install-info
> See the man page for ginstall-info for command line arguments
> Making install in tools
>  /usr/bin/install -c fftw-wisdom-to-conf 
> '/home/jacob/Desktop/gromacs-4.6.3/build-cmake/src/contrib/fftw/gmxfftw-prefix/bin'
>   /bin/bash ../libtool   --mode=install /usr/bin/install -c fftwf-wisdom 
> '/home/jacob/Desktop/gromacs-4.6.3/build-cmake/src/contrib/fftw/gmxfftw-prefix/bin'
>  /usr/bin/install -c -m 644 
> /home/jacob/Desktop/gromacs-4.6.3/build-cmake/src/contrib/fftw/gmxfftw-prefix/src/gmxfftw/tools/fftw-wisdom-to-conf.1
>  fftwf-wisdom.1 
> '/home/jacob/Desktop/gromacs-4.6.3/build-cmake/src/contrib/fftw/gmxfftw-prefix/share/man/man1'
> libtool: install: /usr/bin/install -c fftwf-wisdom 
> /home/jacob/Desktop/gromacs-4.6.3/build-cmake/src/contrib/fftw/gmxfftw-prefix/bin/fftwf-wisdom
> Making install in m4
> [ 57%] Completed 'gmxfftw'
> [ 57%] Built target gmxfftw
> make: *** [all] Error 2
>
> I've already have an AVX-compiled installed for other uses, building GMX of 
> of that went fine aside from recommendations against using it in both the 
> doc's and the build itself (upto 20% speed reduction, rather not thanks)
>
> Any suggestions, help or pointers, would be greatly appreciated.
>
> the only thing I can think of is create a separate build of FFTW and then 
> direct cmake to use that one.
> I was able to build a new FFTW (--enable-sse2),  but couldn't figure out how 
> to get cmake to prefer it over the others.
>
> I hope this is clear,
> thanks
> jacob
>
> machine in question
> Dell T3600 e5-1650 32gb ram (ECC) with nvidia quadro-600
> Xubuntu 13.04 (ubuntu, xfce spin)
> M4 ubuntu packaged 1.4.16-5
>
> command variations attempted:
> cmake ..-DGMX_GPU=OFF -DGMX_BUILD_OWN_FFTW=ON 
> -DCMAKE_INSTALL_PREFIX=/opt/gromacs4.6.3 2>&1|tee cmakeinitall.txt
>  cmake .. -DGMX_BUILD_OWN_FFTW=ON -DCMAKE_INSTALL_PREFIX=/opt/gromacs4.6.3 
> 2>&1|tee cmakeinitall.txt
> cmake .. -DGMX_GPU=ON -DCUDA_TOOLKIT_ROOT_DIR=/usr/include/cuda 
> -DGMX_BUILD_OWN_FFTW=ON -DCMAKE_INSTALL_PREFIX=/opt/gromacs4.6.3
>  cmake .. -DGMX_GPU=ON -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda 
> -DGMX_BUILD_OWN_FFTW=ON -DCMAKE_INSTALL_PREFIX=/opt/gromacs4.6.3
>  cmake .. -DGMX_GPU=ON -DCMAKE_INSTALL_PREFIX=/opt/gromacs4.6.3 
> -DGMX_BUILD_OWN_FFTW=ON 2>&1|tee cmakeInitall.txt
>
> All die as above after:
> make -j 12
>  BUT
> cmake .. -DGMX_GPU=OFF -DCMAKE_INSTALL_PREFIX=/opt/gromacs4.6.3avx
> make -j 12
> sudo make install
>
>  Runs fine, a full copy of the terminal text for gpu=off fftw=on can be 
> found at:
>
> https://www.dropbox.com/s/367aji2x42w3ogz/cmakeinitall.txt
> https://www.dropbox.com/s/fmj5nszul3taczj/makej12.txt
>
>
>
>
>
> --
> 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

[gmx-users] trouble with -DGMX_BUILD_OWN_FFTW, crashing in m4?

[Jacob Pessin]

Hi all,

I'm trying to compile 4.6.3 on my desktop, but have running into some issues 
with FFTW.
Specifically with "-DGMX_BUILD_OWN_FFTW=ON" make seems to crash with M4 (if I'm 
reading it right)

This is not dpkg install-info anymore, but GNU install-info
See the man page for ginstall-info for command line arguments
Making install in tools
 /usr/bin/install -c fftw-wisdom-to-conf 
'/home/jacob/Desktop/gromacs-4.6.3/build-cmake/src/contrib/fftw/gmxfftw-prefix/bin'
  /bin/bash ../libtool   --mode=install /usr/bin/install -c fftwf-wisdom 
'/home/jacob/Desktop/gromacs-4.6.3/build-cmake/src/contrib/fftw/gmxfftw-prefix/bin'
 /usr/bin/install -c -m 644 
/home/jacob/Desktop/gromacs-4.6.3/build-cmake/src/contrib/fftw/gmxfftw-prefix/src/gmxfftw/tools/fftw-wisdom-to-conf.1
 fftwf-wisdom.1 
'/home/jacob/Desktop/gromacs-4.6.3/build-cmake/src/contrib/fftw/gmxfftw-prefix/share/man/man1'
libtool: install: /usr/bin/install -c fftwf-wisdom 
/home/jacob/Desktop/gromacs-4.6.3/build-cmake/src/contrib/fftw/gmxfftw-prefix/bin/fftwf-wisdom
Making install in m4
[ 57%] Completed 'gmxfftw'
[ 57%] Built target gmxfftw
make: *** [all] Error 2

I've already have an AVX-compiled installed for other uses, building GMX of of 
that went fine aside from recommendations against using it in both the doc's 
and the build itself (upto 20% speed reduction, rather not thanks)

Any suggestions, help or pointers, would be greatly appreciated.

the only thing I can think of is create a separate build of FFTW and then 
direct cmake to use that one.
I was able to build a new FFTW (--enable-sse2),  but couldn't figure out how to 
get cmake to prefer it over the others.

I hope this is clear,
thanks
jacob

machine in question
Dell T3600 e5-1650 32gb ram (ECC) with nvidia quadro-600
Xubuntu 13.04 (ubuntu, xfce spin)
M4 ubuntu packaged 1.4.16-5

command variations attempted:
cmake ..-DGMX_GPU=OFF -DGMX_BUILD_OWN_FFTW=ON 
-DCMAKE_INSTALL_PREFIX=/opt/gromacs4.6.3 2>&1|tee cmakeinitall.txt
 cmake .. -DGMX_BUILD_OWN_FFTW=ON -DCMAKE_INSTALL_PREFIX=/opt/gromacs4.6.3 
2>&1|tee cmakeinitall.txt
cmake .. -DGMX_GPU=ON -DCUDA_TOOLKIT_ROOT_DIR=/usr/include/cuda 
-DGMX_BUILD_OWN_FFTW=ON -DCMAKE_INSTALL_PREFIX=/opt/gromacs4.6.3
 cmake .. -DGMX_GPU=ON -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda 
-DGMX_BUILD_OWN_FFTW=ON -DCMAKE_INSTALL_PREFIX=/opt/gromacs4.6.3
 cmake .. -DGMX_GPU=ON -DCMAKE_INSTALL_PREFIX=/opt/gromacs4.6.3 
-DGMX_BUILD_OWN_FFTW=ON 2>&1|tee cmakeInitall.txt

All die as above after:
make -j 12
 BUT
cmake .. -DGMX_GPU=OFF -DCMAKE_INSTALL_PREFIX=/opt/gromacs4.6.3avx
make -j 12
sudo make install

 Runs fine, a full copy of the terminal text for gpu=off fftw=on can be 
found at:

https://www.dropbox.com/s/367aji2x42w3ogz/cmakeinitall.txt
https://www.dropbox.com/s/fmj5nszul3taczj/makej12.txt





--
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] constant force pulling

[Justin Lemkul]

On 7/29/13 2:42 PM, kim2811 wrote:

Hi,

I am trying to pull/separate a protein dimer by applying constant force in
my SMD. The dimer has dimension 9 x 8 x 5 nm^3, and I'm trying to pull in
the y-direction so I have set the box as 12 x 40 x 8 nm^3. I have also set
my simulation to run for 5 ns. However, after only 251 ps, I got this fatal
error:

   Distance of pull group 1 (3.958423 nm) is larger than 0.49 times the box
size (16.314939)



This appears to be a minor output bug.  The violation occurs in the z-dimension, 
since 0.49 * 8 = 3.92.



Can somebody please interpret this error? When I checked the trajectory, the
protein seems to be inside the box or at least the COM of the dimer is near
the center of the box, so the protein approaching near the boundary can't be
the reason for this error. If it can help to clarify, here's my pull code:

; Pull code
pull= constant_force
pull_geometry   = direction  ; pull in the direction of pull code
pull_dim= Y Y Y


Note that pull_dim should be ignored here, you only need pull_vec1.  The code 
should interpret the .mdp contents correctly, though.


-Justin


pull_start  = yes   ; define initial COM distance > 0
pull_ngroups= 1
pull_group0 = chain_A  ; C-terminal of Protein 1
pull_group1 = chain_B  ; C-terminal of Protein 2
pull_k1 = -500  ; kJ mol^-1 nm^-1
pull_vec1   = 0 1 0

Thank you.



--
View this message in context: 
http://gromacs.5086.x6.nabble.com/constant-force-pulling-tp5010180.html
Sent from the GROMACS Users Forum mailing list archive at Nabble.com.



--
==

Justin A. Lemkul, Ph.D.
Postdoctoral Fellow

Department of Pharmaceutical Sciences
School of Pharmacy
Health Sciences Facility II, Room 601
University of Maryland, Baltimore
20 Penn St.
Baltimore, MD 21201

jalem...@outerbanks.umaryland.edu | (410) 706-7441

==
--
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] Box dimension size errors in MARTINI soft core simulation

[Justin Lemkul]

On 7/29/13 2:12 PM, Scott Pendley wrote:

Thank you, Justin.  I am using gromacs version 4.5.5 and have attached .mdp
file.  I followed your advise and pointer to trouble shooting the system


The mailing list does not accept attachments.  Please either copy and paste its 
contents or provide a link from which it can be downloaded.



and decomposed the energy to find potential sources for the problem.  The
simulation ran for 978 ps, the total energy changed from approximately
-13000 kj/mol to -15000 kj/mol and plateau'ed out around 900 ps without a
big energy blow-out.  The majority of the change in energy was from the LJ
contribution which is the expected source with the disappearing atoms of my
ligand.  Of more concern is the change in box coordinates/shape.  The
simulation cell starts with dimensions 9.45nm x 9.45nm x 9.45nm and ends at
2.8 x 2.8 x 45.8 nm which does seem to give rise to the error that I
originally noted.  While some change in volume and cell dimensions is
expected, these changes seems to be a focused solely on expanding along the
Z-coordinate.  Is there any way to constrain the ratio of x:y:z coordinates
during npt simulations or do you know of something that I may be missing in
my simulations?



The magnitude of change you're seeing suggests extreme instability and thus 
there is no real "hack" to simply "make it work."  Isotropic pressure coupling 
is normally sufficient for this purpose, but something seems to be going very 
wrong in your system.  The complete .mdp file, and a description of what your 
ligand is (or at least how big) would be helpful.  You've got a very large box 
for what one would normally consider a "ligand."


-Justin


Thank you,

Scott


On Wed, Jul 24, 2013 at 4:59 PM, Justin Lemkul  wrote:




On 7/24/13 4:33 PM, Scott Pendley wrote:


I am fairly new to gromacs and I am trying to run a thermodynamic
integration simulation of a ligand disappearing in a box of octanol at a
single set lambda point.  I have previous successful nvt and npt runs of
this system.  When I have added the free energy portions to the input
file,
I get the following error:

Fatal error:
One of the box vectors has become shorter than twice the cut-off length or
box_yy-|box_zy| or box_zz has become smaller than the cut-off.
For more information and tips for troubleshooting, please check the
GROMACS
website at 
http://www.gromacs.org/**Documentation/Errors

This seems unusual.  The box dimensions are 9.45 nm x 9.45 x 9.45 nm so
that is fairly large even accounting for some shrinkage with a
disappearing
ligand.



The available information suggests the system has become unstable and is
imploding.  See general troubleshooting information at
http://www.gromacs.org/**Documentation/Terminology/**
Blowing_Up#Diagnosing_an_**Unstable_System
.


  Cutoffs in the input file are set as follows: rlist =1.4, rvdw=1.2,

rcoulomb=1.2.  Doubling any of them would still be less than 3 nm which is
significantly smaller than the box size.  Is there anything I am missing
or
any suggestions that others can give me?



I wouldn't mess with the cutoffs; they're an essential part of the force
field.  For further diagnostics, please consider the points above and
provide your .mdp file and Gromacs version.

-Justin

--
==**

Justin A. Lemkul, Ph.D.
Postdoctoral Fellow

Department of Pharmaceutical Sciences
School of Pharmacy
Health Sciences Facility II, Room 601
University of Maryland, Baltimore
20 Penn St.
Baltimore, MD 21201

jalemkul@outerbanks.umaryland.**edu  | (410)
706-7441

==**
--
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/Searchbefore
 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





--
==

Justin A. Lemkul, Ph.D.
Postdoctoral Fellow

Department of Pharmaceutical Sciences
School of Pharmacy
Health Sciences Facility II, Room 601
University of Maryland, Baltimore
20 Penn St.
Baltimore, MD 21201

jalem...@outerbanks.umaryland.edu | (410) 706-7441

==
--
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] constant force pulling

[kim2811]

Hi, 

I am trying to pull/separate a protein dimer by applying constant force in
my SMD. The dimer has dimension 9 x 8 x 5 nm^3, and I'm trying to pull in
the y-direction so I have set the box as 12 x 40 x 8 nm^3. I have also set
my simulation to run for 5 ns. However, after only 251 ps, I got this fatal
error:

  Distance of pull group 1 (3.958423 nm) is larger than 0.49 times the box
size (16.314939)

Can somebody please interpret this error? When I checked the trajectory, the
protein seems to be inside the box or at least the COM of the dimer is near
the center of the box, so the protein approaching near the boundary can't be
the reason for this error. If it can help to clarify, here's my pull code:

; Pull code
pull= constant_force
pull_geometry   = direction  ; pull in the direction of pull code 
pull_dim= Y Y Y
pull_start  = yes   ; define initial COM distance > 0
pull_ngroups= 1
pull_group0 = chain_A  ; C-terminal of Protein 1
pull_group1 = chain_B  ; C-terminal of Protein 2 
pull_k1 = -500  ; kJ mol^-1 nm^-1
pull_vec1   = 0 1 0 

Thank you.



--
View this message in context: 
http://gromacs.5086.x6.nabble.com/constant-force-pulling-tp5010180.html
Sent from the GROMACS Users Forum mailing list archive at Nabble.com.
-- 
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] Running GROMACS on mini GPU cluster

[Szilárd Páll]

The message is perfectly normal. When you do not use all available
cores/hardware threads (seen as "CPUs" by the OS), to avoid potential
clashes, mdrun does not pin threads (i.e. it lets the OS migrate
threads). On NUMA systems (most multi-CPU machines), this will cause
performance degradation as without pinning the OS can move tightly
coupled threads belonging to the same process/MPI rank to different
NUMA regions (e.g. cores on different CPU sockets).

With four physical cores the machines in question are most probably
single-processor and for these pinning will not improve performance by
much (if at all).

Cheers,
--
Szilárd


On Fri, Jul 26, 2013 at 12:09 AM, Tim Moore  wrote:
> I am running GROMACS 4.6.2 on a GPU cluster in our reasearch group. I am 
> trying to bench mark some systems, and I am getting this message:
>
> NOTE: The number of threads is not equal to the number of (logical) cores
>   and the -pin option is set to auto: will not pin thread to cores.
>   This can lead to significant performance degradation.
>   Consider using -pin on (and -pinoffset in case you run multiple jobs).
>
> Each node has 2 GTX 580s and 4 physical cores. So when I submit a job I set 
> -nt 2. But since we have a queuing system, there is no way to know which 
> cores will be available to set -pinoffset. Does anyone have a solution, or 
> should I even be worrying about that at all?
>
> Thanks,
> Tim--
> 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] Box dimension size errors in MARTINI soft core simulation

[Scott Pendley]

Thank you, Justin.  I am using gromacs version 4.5.5 and have attached .mdp
file.  I followed your advise and pointer to trouble shooting the system
and decomposed the energy to find potential sources for the problem.  The
simulation ran for 978 ps, the total energy changed from approximately
-13000 kj/mol to -15000 kj/mol and plateau'ed out around 900 ps without a
big energy blow-out.  The majority of the change in energy was from the LJ
contribution which is the expected source with the disappearing atoms of my
ligand.  Of more concern is the change in box coordinates/shape.  The
simulation cell starts with dimensions 9.45nm x 9.45nm x 9.45nm and ends at
2.8 x 2.8 x 45.8 nm which does seem to give rise to the error that I
originally noted.  While some change in volume and cell dimensions is
expected, these changes seems to be a focused solely on expanding along the
Z-coordinate.  Is there any way to constrain the ratio of x:y:z coordinates
during npt simulations or do you know of something that I may be missing in
my simulations?

Thank you,

Scott


On Wed, Jul 24, 2013 at 4:59 PM, Justin Lemkul  wrote:

>
>
> On 7/24/13 4:33 PM, Scott Pendley wrote:
>
>> I am fairly new to gromacs and I am trying to run a thermodynamic
>> integration simulation of a ligand disappearing in a box of octanol at a
>> single set lambda point.  I have previous successful nvt and npt runs of
>> this system.  When I have added the free energy portions to the input
>> file,
>> I get the following error:
>>
>> Fatal error:
>> One of the box vectors has become shorter than twice the cut-off length or
>> box_yy-|box_zy| or box_zz has become smaller than the cut-off.
>> For more information and tips for troubleshooting, please check the
>> GROMACS
>> website at 
>> http://www.gromacs.org/**Documentation/Errors
>>
>> This seems unusual.  The box dimensions are 9.45 nm x 9.45 x 9.45 nm so
>> that is fairly large even accounting for some shrinkage with a
>> disappearing
>> ligand.
>>
>>
> The available information suggests the system has become unstable and is
> imploding.  See general troubleshooting information at
> http://www.gromacs.org/**Documentation/Terminology/**
> Blowing_Up#Diagnosing_an_**Unstable_System
> .
>
>
>  Cutoffs in the input file are set as follows: rlist =1.4, rvdw=1.2,
>> rcoulomb=1.2.  Doubling any of them would still be less than 3 nm which is
>> significantly smaller than the box size.  Is there anything I am missing
>> or
>> any suggestions that others can give me?
>>
>>
> I wouldn't mess with the cutoffs; they're an essential part of the force
> field.  For further diagnostics, please consider the points above and
> provide your .mdp file and Gromacs version.
>
> -Justin
>
> --
> ==**
>
> Justin A. Lemkul, Ph.D.
> Postdoctoral Fellow
>
> Department of Pharmaceutical Sciences
> School of Pharmacy
> Health Sciences Facility II, Room 601
> University of Maryland, Baltimore
> 20 Penn St.
> Baltimore, MD 21201
>
> jalemkul@outerbanks.umaryland.**edu  | 
> (410)
> 706-7441
>
> ==**
> --
> 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/Searchbefore
>  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] Re: problem in g_membed

[Justin Lemkul]

On 7/29/13 9:10 AM, pavithrakb wrote:

sir,
the reason for selecting POPE doesn't have much valid reason. I mean, I have
referred previous works and in the recent work they have used POPE membrane
for my protein (the exact protein) simulation. I have searched literature on
selecting a membrane for simulation to know/understand why they have
selected the particular membrane. But couldn't find put the reason why?.


The choice of a membrane is nearly as significant as the choice of the force 
field that represents the system.  The chosen lipid model should be 
representative of the membrane environment that the protein will most likely 
experience.  POPE is common for bacterial membranes, while POPC is common for 
eukaryotic systems.  More complex models (rafts, etc) exist in the literature 
and are relevant in some cases.


-Justin

--
==

Justin A. Lemkul, Ph.D.
Postdoctoral Fellow

Department of Pharmaceutical Sciences
School of Pharmacy
Health Sciences Facility II, Room 601
University of Maryland, Baltimore
20 Penn St.
Baltimore, MD 21201

jalem...@outerbanks.umaryland.edu | (410) 706-7441

==
--
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: problem in g_membed

[pavithrakb]

sir,
the reason for selecting POPE doesn't have much valid reason. I mean, I have
referred previous works and in the recent work they have used POPE membrane
for my protein (the exact protein) simulation. I have searched literature on
selecting a membrane for simulation to know/understand why they have
selected the particular membrane. But couldn't find put the reason why?.
And, sorry I have misunderstood what you have mentioned about the protein
out of the box. I get the point now.
I have used editconf and have increased the Z dimension of the box. 
Now the protein fits inside the box and no protruding. Thank you sir.





--
View this message in context: 
http://gromacs.5086.x6.nabble.com/problem-in-g-membed-tp5009503p5010176.html
Sent from the GROMACS Users Forum mailing list archive at Nabble.com.
-- 
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] How do I monitor dynamics of helices and domain rotation?

[Mark Abraham]

There is lots of stuff. Please look in manual 7.4 and 8, which bring
order to the the morass of available tools.

Mark

On Mon, Jul 29, 2013 at 12:29 AM, jayant james  wrote:
> Hi all,
>
> 1) I am looking at see if two adjacent helices are changing their
> conformation in space. I would like to monitor whether they are orthogonal
> to each other or have become parallel to each other during simulations. Is
> it possible in Gromacs to follow such changes, and if so, what command
> would I use to track such changes?
>
> 2a) Also how would I track domain rotations? To check if a domain A is
> rotating with respect to domain B. I am thinking of picking 2 amino acids
> on domains A and B and monitor the dihederal angle to see if there is
> rotation between domains A and B. Is it possible to do such an analysis
> using Gromacs and if so how and what command should I be using? or if there
> is a different way please do share.
>
> 2b) Also I am looking to monitor whether domain A is in the same plane as
> domain B or if it has gone up or down in space with respect to domain B?
> How can I monitor this feature?
> I appreciate your help.
>
> Thank you
>
> James
> --
> 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] Fwd: Fatal error: number of coordinates in coordinate file (trp-b4ion.pdb, 25093) does not match topology (trp.top, 26684)

[Justin Lemkul]

On 7/29/13 6:30 AM, Jonathan Saboury wrote:

Files: http://www.sendspace.com/file/vxcnv3

Commands used: http://pastebin.com/raw.php?i=wPqfuUwc

What I want to do: I just want to run the protein without the ligand in
explicit water. Why is the coordinate file not matching topology?

http://www.gromacs.org/Documentation/Errors#Number_of_coordinates_in_coordinate_file_does_not_match_topologydoesn't
offer much help in this case. I know the problem is the number of
waters however.



The problem is not the waters.  Your topology specifies 3221 protein+CA atoms, 
but the coordinate file you're using only has 1630.  The problem is here:


pdb2gmx -ff amber99sb -f protein2.pdb -o trp.pdb -p trp.top -water tip3p -ignh

editconf -bt octahedron -f protein2.pdb -o trp‐b4solv.pdb -d 1.0

You're using "protein2.pdb" to move forward, after pdb2gmx acted upon it (to 
produce conf.gro) to add hydrogens.


-Justin

--
==

Justin A. Lemkul, Ph.D.
Postdoctoral Fellow

Department of Pharmaceutical Sciences
School of Pharmacy
Health Sciences Facility II, Room 601
University of Maryland, Baltimore
20 Penn St.
Baltimore, MD 21201

jalem...@outerbanks.umaryland.edu | (410) 706-7441

==
--
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] Net charge in implicit solvent simulations

[saber naderi]

Dear gmx-users,

We currently performed simulations to study the effect of repulsive
electrostatic interactions on the stability of a silk-like protein. The
amino acid sequence of our protein is the following: Lys [ (Gly-Ala)_3 Gly
(Gln or Lys)]_3 where (Gln or Lys) means that we alternatively have Lys or
Gln in that position starting with Gln. We start our simulations with three
of these proteins on top of each other (each having a beta-sheet
structure).

We performed two set of Replica exchange simulations with implicit solvent
(see below for an mdp file). In one the lysine residues are positively
charged and in the other they are neutral (LYN). Surprisingly, we see that
the charged protein is more stable than the neutral one, i.e., repulsive
electrostatic interactions are helping the charged protein not to unfold!!!

I suppose this is not a normal behavior. What could go wrong in such
simulations that results in this?

Thanks for your time,

Regards,
Saber


mdp file for one of the replicas:

;  RUN CONTROL PARAMETERS
integrator   = sd
tinit= 0   ; Starting time
dt   = 0.002   ; 2 femtosecond time step for integration
nsteps   = 1000

; OUTPUT CONTROL OPTIONS
nstxout  = 5 ; Writing full precision coordinates every
nanosecond
nstvout  = 5 ; Writing velocities every nanosecond
nstfout  = 0 ; Not writing forces
nstlog   = 500  ; Writing to the log file every step
nstenergy= 500  ; Writing out energy information every step
nstxtcout= 500  ; Writing coordinates every 5 ps
energygrps   = System

; NEIGHBORSEARCHING PARAMETERS
nstlist  = 0
ns-type  = simple
pbc  = no
rlist= 0

; OPTIONS FOR ELECTROSTATICS AND VDW
coulombtype = cut-off
rvdw = 0
rcoulomb = 0


; Temperature coupling
tc-grps  = System
ld_seed = -1
tau_t= 0.1
ref_t= 298.00,
; implicit solvent

implicit_solvent= GBSA
gb_algorithm= OBC
rgbradii= 0
gb_epsilon_solvent = 80

; GENERATE VELOCITIES FOR STARTUP RUN
gen_vel  = yes
gen_temp= 300
comm_mode= Angular

; OPTIONS FOR BONDS
constraints  = all-bonds
constraint-algorithm = Lincs
unconstrained-start  = yes
lincs-order  = 4
lincs-iter   = 1
lincs-warnangle  = 30
-- 
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] Fwd: Fatal error: number of coordinates in coordinate file (trp-b4ion.pdb, 25093) does not match topology (trp.top, 26684)

[Jonathan Saboury]

Files: http://www.sendspace.com/file/vxcnv3

Commands used: http://pastebin.com/raw.php?i=wPqfuUwc

What I want to do: I just want to run the protein without the ligand in
explicit water. Why is the coordinate file not matching topology?

http://www.gromacs.org/Documentation/Errors#Number_of_coordinates_in_coordinate_file_does_not_match_topologydoesn't
offer much help in this case. I know the problem is the number of
waters however.

Thanks :)
-- 
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] Re: problem in g_membed

[Justin Lemkul]

On 7/29/13 4:31 AM, pavithrakb wrote:

Thank you both of you (Justin and Albert) sir.
Initially I was using dppc128 and now I changed to POPE 340 and still my
protein (its a GPCR protein) protrude out of the membrane (the same region;
two amino acids).


Out of curiosity, why have you chosen POPE?


since you (Justin) you have mentioned that the protein must be completely
inside the membrane to avoid any instability, what must I do to avoid this
problem?


I did not say that.  The previous discussion was around the fact that your 
protein crossed a periodic boundary, which is very different from specifying 
that the whole protein must be inside the membrane.  It needs to fit within the 
box to avoid minimum image convention problems.  Whether or not the protein sits 
completely within the membrane is dependent upon the actual biology of the system.



is something wrong with my protein?
The region protruding out is a loop. is it still a problem?


Out of the membrane?  Not necessarily a problem.  Out of the box?  Possibly a 
problem, depending on the overall geometry of the system and its orientation 
within the box.



the protein's box size is 4.49101 4.74797 7.29103 (from protein.gro).


Most membranes of 128 lipids or more are larger in the x-y plane, so that's 
fine.  The z-dimension is usually the limiting factor, and thus your membrane 
box needs to suitably accommodate the protein.


-Justin

--
==

Justin A. Lemkul, Ph.D.
Postdoctoral Fellow

Department of Pharmaceutical Sciences
School of Pharmacy
Health Sciences Facility II, Room 601
University of Maryland, Baltimore
20 Penn St.
Baltimore, MD 21201

jalem...@outerbanks.umaryland.edu | (410) 706-7441

==
--
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] Re: problem in g_membed

[Albert]

superimpose your receptor PDB files with related structure OPM database
center your lipids in 0 by editconf command in gromacs

then you GPCR would be in the center of the lipids.

PS: 340 lipids is too big for a single GPCR, 140~160 would be enough 
before g_membed. You'd better read paper to see how many lipids did 
other people use.



On 07/29/2013 10:31 AM, pavithrakb wrote:

Thank you both of you (Justin and Albert) sir.
Initially I was using dppc128 and now I changed to POPE 340 and still my
protein (its a GPCR protein) protrude out of the membrane (the same region;
two amino acids).
since you (Justin) you have mentioned that the protein must be completely
inside the membrane to avoid any instability, what must I do to avoid this
problem?
is something wrong with my protein?
The region protruding out is a loop. is it still a problem?
the protein's box size is 4.49101 4.74797 7.29103 (from protein.gro).
Kindly help.


--
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: problem in g_membed

[pavithrakb]

Thank you both of you (Justin and Albert) sir.
Initially I was using dppc128 and now I changed to POPE 340 and still my
protein (its a GPCR protein) protrude out of the membrane (the same region;
two amino acids).
since you (Justin) you have mentioned that the protein must be completely
inside the membrane to avoid any instability, what must I do to avoid this
problem?
is something wrong with my protein?
The region protruding out is a loop. is it still a problem?
the protein's box size is 4.49101 4.74797 7.29103 (from protein.gro).
Kindly help.



--
View this message in context: 
http://gromacs.5086.x6.nabble.com/problem-in-g-membed-tp5009503p5010166.html
Sent from the GROMACS Users Forum mailing list archive at Nabble.com.
-- 
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