Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Arik Cohen]

thanks

Arik

Mark James Abraham wrote:


On 01/01/10, *"Justin A. Lemkul" * wrote:



Arik Cohen wrote:
>No, sorry for the confusion. The images are only from a simulation 
of one protein(tmRBP_Unliganded, PDB: 2FN9). The problem seen with 
BPTI was a bit different in a way that only 1 C-alpha was "detached" 
(cell size ?).

>

If there is supposed to be only a single protein in the images you've 
shown (and after having a look at the 2FN9 structure from the PDB), 
it seems pretty clear to me that part of your protein has simply 
crossed a periodic boundary and trjconv -pbc mol (or some such 
command) should fix it.
Indeed. Further, note that the reappearance of a subset of the 
seemingly detached atoms back with the main group is totally normal. 
With domain decomposition in GROMACS 4, such "broken" molecules can be 
written to the trajectory. Judicious use of trjconv fixes the 
appearance of this non-problem.


Mark



>Arik
>
>Justin A. Lemkul wrote:
>>
>>
>>Arik Cohen wrote:
>>>Which two proteins ? I have at least in beginning only one protein 
which some how is divided into two along the calculation.

>>>Any way I'll try both increasing the cell and fix it with trjconv.
>>>
>>
>>Quoting your original message:
>>
>>"While running a simple MD simulation with both a small protein 
such as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb..."

>>
>>I assumed that what I was seeing in the images was a set of two 
proteins.  My concern was that you defined a box relative to the 
larger protein, then inserted the smaller one (BPTI?), leaving 
insufficient space in the box to satisfy the minimum image 
convention.  If that's not what we're looking at, then that'd be 
useful to know :)

>>
>>If you have a single protein, "divided into two" then the problem 
is almost certainly a simple periodicity artifact.  Bonds do not 
break in a normal MD calculation (in fact they can't using the 
standard MM approximations).

>>
>>-Justin
>>
>>>Thanks a lot
>>>
>>>Arik
>>>
>>>Justin A. Lemkul wrote:


Arik Cohen wrote:
>I'm using dodecahedron -d 0.7
>
>

Was that distance specified with respect to both of the protein 
molecules in the unit cell?  You can check for spurious PBC 
interactions with g_mindist -pi. Anyway, I'd be curious to see how 
you do with trjconv.


-Justin

>
>Justin A. Lemkul wrote:
>>
>>
>>Arik Cohen wrote:
>>>Hi,
>>>
>>>I have not tried yet to fix it with trjconv which I will . 
Attached is a picture with 4 snapshots taken from the simulation. The 
C-alphas in question are emphasized with red color.

>>>
>>
>>Is your unit cell sufficiently large?  It looks like the 
C-alphas indicated are simply crossing the periodic boundary on the 
"left" of the frame and interacting with the protein molecule in the 
"right" of the frame, which would indicate to me that the unit cell 
is too small and you're seeing spurious PBC interactions (i.e., 
violation of the minimum image convention).

>>
>>-Justin
>>
>>>Thanks
>>>
>>>Arik
>>>
>>>Justin A. Lemkul wrote:


Arik Cohen wrote:
>Hi,
>
>Sorry to bother you again ,but its not only a periodic 
effect since only *some of the atoms* in the  "Detached" group are 
vanishing from this group and reappearing in the main protein group. 
The rest of the atoms are either always in the detached or the main 
group.
>In addition, the "detached" group includes three segments of 
the protein(8 residues(126-131), 8 residues(157-164) and 4 
residues186-189).

>

From your description, this sounds exactly like a periodicity 
problem - some of the atoms are crossing the periodic boundary and 
are appearing in strange locations.  Have you even tried trjconv to 
fix it?  That would be useful information, as I see that Mark long 
ago also suggested the same sort of fix.


It is hard for me to envision what you are seeing.  It would 
be enormously helpful if you could post images (screenshots, etc) of 
the problematic structures to get a more expedient resolution.


-Justin

>Thanks a lot
>
>Arik
>
>Justin A. Lemkul wrote:
>>
>>
>>Arik Cohen wrote:
>>>Hi,
>>>
>>>With regards to your question I do see some periodicity in 
which for a section of time in the trajectory some of the Calphas in 
the "detached group" are vanishing from it and reappear in the main 
protein.

>>>In addition,
>>>I would appreciate as before any suggestion you might have 
in the matter.

>>>
>>
>>If this is just a periodicity artifact, fix it with trjconv.
>>
>>-Justin
>>
>>>Thanks
>>>
>>>Arik
>>>
>>>Mark Abraham wrote:
Arik Cohen wrote:
>Hi,
>

Re: [gmx-users] gromacs 4.06 binary for linux -redhat

[Mark James Abraham]

On 01/01/10, venkat  wrote:I did installed fftw , not sure it is completed.  while doing make command , got the following error mesage$ configure  -enable-threads --enable-float--prefix=/home/pgm/fftwThis command is hopelessly garbled. Computers are literal, and so must you be when using them. Like most GNU tools, configure commands take double hyphens for options, and a space between options. GROMACS commands take single hyphens for their options, however. Mark$makecp fftw_wisdom.1 fftwf-wisdom.1make  all-am/bin/sh ../libtool --tag=CC   --mode=link gcc -std=gnu99  -O3 -fomit-frame-pointer -fstrict-aliasing -ffast-math -mpentiumpro -pthread  -L/home/vk/pgm/fftw/lib -o fftwf-wisdom fftw-wisdom.o ../tests/bench.o ../tests/fftw-bench.o ../threads/libfftw3f_threads.la ../libfftw3f.la ../libbench2/libbench2.a  -lm libtool: link: gcc -std=gnu99 -O3 -fomit-frame-pointer -fstrict-aliasing -ffast-math -mpentiumpro -pthread -o fftwf-wisdom fftw-wisdom.o ../tests/bench.o ../tests/fftw-bench.o  -L/home/vk/pgm/fftw/lib ../threads/.libs/libfftw3f_threads.a ../.libs/libfftw3f.a ../libbench2/libbench2.a -lm -pthreadMaking all in m4make[2]: Nothing to be done for `all'.any help- Original Message From: Justin A. Lemkul To: Discussion list for GROMACS users Sent: Wed, December 30, 2009 9:54:42 PMSubject: Re: [gmx-users] gromacs 4.06 binary for linux -redhatvenkat wrote:> > > Hi > I am new to GROMACS, like to use it. I would be appreciate if anyone can direct me to the right place where I could> get the linux binary either x32/x64 - redhat.> Binaries for newer versions probably haven't been made yet.  Your subject line points to version 4.0.6, which was a broken release anyway, and was replaced by version 4.0.7.> I could not compile the source cause it is looking for FFTW etc.,. Then you should follow the step-by-step installation instructions.  FFT libraries are a prerequisite for Gromacs.  Please see the following:http://www.gromacs.org/index.php?title=Download_%26_Installation/Installation_Instructions-Justin> thanks> venkat> > >  -- Justin A. LemkulPh.D. CandidateICTAS Doctoral ScholarMILES-IGERT TraineeDepartment of BiochemistryVirginia TechBlacksburg, VAjalemkul[at]vt.edu | (540) 231-9080http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin-- gmx-users mailing list    gmx-users@gromacs.orghttp://lists.gromacs.org/mailman/listinfo/gmx-usersPlease search the archive at http://www.gromacs.org/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/mailing_lists/users.php  -- gmx-users mailing list    gmx-users@gromacs.orghttp://lists.gromacs.org/mailman/listinfo/gmx-usersPlease search the archive at http://www.gromacs.org/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/mailing_lists/users.php
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/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/mailing_lists/users.php

Re: [gmx-users] using mdrun in the supercomputer

[Mark James Abraham]

On 01/01/10, Asmaa Elsheshiny  wrote:Dear gromacs users,I tried to make MD simulation using mdrun in the super computer by using the following script:#!/bin/sh#$  -cwd  –V#$  -l h_rt=1:00:00#$  -pe mx* 4export  DO_PARALLEL=”/usr/local/sge6.0/mpi/myrinet/sge_mpirun”export  gromacs=/apps/gromacs/64/3.3.1-ffamber20080701/bin$ DO_PARALLEL $gromacs/mdrun   “ -s md.tpr  \ -o md.trr  -x md.xtc  –c md.gro  –e  ener.edr”This script appears to work fine, but i stopped suddenly after a short period giving missing output. That is why the structure file .gro is missing. I have tested it locally before submitting it as a job in the supercomputer; I found that it works fine. So, what is the problem with this script?There are various problems. The space after the dollar sign and before DO_PARALLEL breaks its function. That mdrun needs to be compiled with MPI enabled, and the recommended installation guides on the website all recommend using configure options to append _mpi to MPI-enabled mdrun, so that you have a better chance of constructing command lines that do what you intend. Further, GROMACS 3.3.1 is years old, and unless you need scientific continuity with previous work, you will get much better simulation performance from 4.0.7.Mark Kind regards,Asmaa-- gmx-users mailing list    gmx-users@gromacs.orghttp://lists.gromacs.org/mailman/listinfo/gmx-usersPlease search the archive at http://www.gromacs.org/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/mailing_lists/users.php
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/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/mailing_lists/users.php

[gmx-users] Fwd: What could be wrong with rdf plot?

[Lum Nforbi]

-- Forwarded message --
From: Lum Nforbi 
Date: Thu, Dec 31, 2009 at 12:33 PM
Subject: What could be wrong with rdf plot?
To: gmx-users@gromacs.org


Dear all,

 I am currently analyzing a system of 2000 molecules of TIP3P water on
which I performed a NPT simulation. The plot for g(OO) looks very good but
for some reason unknown to me, on the g(OH) plot there is an intense peak
coming before the normal peaks that are characteristic of a g(OH) plot.
Could someone tell me what is going on? I have attached the graphs for gOO
and gOH for viewing.
Also, I have still not been able to figure out how to calculate the Cp
of my system and I have been struggling with this for over a month now.
g_energy for my system gives a wrong Cv (~12). Can someone explain to me or
give me hints on how to calculate the Cp of an NPT simulation of TIP3P
water, please?

Have a wonderful New Year 2010 and Decade (2010-2019)!

Thank you,
Lum


RDF_OWHW1HW2_0_8000PS
Description: Binary data
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/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/mailing_lists/users.php

Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Mark James Abraham]

On 01/01/10, "Justin A. Lemkul"  wrote:Arik Cohen wrote:>No, sorry for the confusion. The images are only from a simulation of one protein(tmRBP_Unliganded, PDB: 2FN9). The problem seen with BPTI was a bit different in a way that only 1 C-alpha was "detached" (cell size ?).>If there is supposed to be only a single protein in the images you've shown (and after having a look at the 2FN9 structure from the PDB), it seems pretty clear to me that part of your protein has simply crossed a periodic boundary and trjconv -pbc mol (or some such command) should fix it.Indeed. Further, note that the reappearance of a subset of the seemingly detached atoms back with the main group is totally normal. With domain decomposition in GROMACS 4, such "broken" molecules can be written to the trajectory. Judicious use of trjconv fixes the appearance of this non-problem.Mark>Arik>>Justin A. Lemkul wrote:>>Arik Cohen wrote:>>>Which two proteins ? I have at least in beginning only one protein which some how is divided into two along the calculation.>>>Any way I'll try both increasing the cell and fix it with trjconv.>>>Quoting your original message:"While running a simple MD simulation with both a small protein such as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb..."I assumed that what I was seeing in the images was a set of two proteins.  My concern was that you defined a box relative to the larger protein, then inserted the smaller one (BPTI?), leaving insufficient space in the box to satisfy the minimum image convention.  If that's not what we're looking at, then that'd be useful to know :)If you have a single protein, "divided into two" then the problem is almost certainly a simple periodicity artifact.  Bonds do not break in a normal MD calculation (in fact they can't using the standard MM approximations).-Justin>Thanks a lot>>Arik>>Justin A. Lemkul wrote:Arik Cohen wrote:>I'm using dodecahedron -d 0.7>>Was that distance specified with respect to both of the protein molecules in the unit cell?  You can check for spurious PBC interactions with g_mindist -pi. Anyway, I'd be curious to see how you do with trjconv.-Justin>>Justin A. Lemkul wrote:>>Arik Cohen wrote:>>>Hi,>>I have not tried yet to fix it with trjconv which I will . Attached is a picture with 4 snapshots taken from the simulation. The C-alphas in question are emphasized with red color.>>>Is your unit cell sufficiently large?  It looks like the C-alphas indicated are simply crossing the periodic boundary on the "left" of the frame and interacting with the protein molecule in the "right" of the frame, which would indicate to me that the unit cell is too small and you're seeing spurious PBC interactions (i.e., violation of the minimum image convention).-Justin>Thanks>>Arik>>Justin A. Lemkul wrote:Arik Cohen wrote:>Hi,>>Sorry to bother you again ,but its not only a periodic effect since only *some of the atoms* in the  "Detached" group are vanishing from this group and reappearing in the main protein group. The rest of the atoms are either always in the detached or the main group.>In addition, the "detached" group includes three segments of the protein(8 residues(126-131), 8 residues(157-164) and 4 residues186-189).>From your description, this sounds exactly like a periodicity problem - some of the atoms are crossing the periodic boundary and are appearing in strange locations.  Have you even tried trjconv to fix it?  That would be useful information, as I see that Mark long ago also suggested the same sort of fix.It is hard for me to envision what you are seeing.  It would be enormously helpful if you could post images (screenshots, etc) of the problematic structures to get a more expedient resolution.-Justin>Thanks a lot>>Arik>>Justin A. Lemkul wrote:>>Arik Cohen wrote:>>>Hi,>>With regards to your question I do see some periodicity in which for a section of time in the trajectory some of the Calphas in the "detached group" are vanishing from it and reappear in the main protein.>>>In addition,>>>I would appreciate as before any suggestion you might have in the matter.>>>If this is just a periodicity artifact, fix it with trjconv.-Justin>Thanks>>Arik>>Mark Abraham wrote:Arik Cohen wrote:>Hi,>>Thanks for answering so quickly !. Apparently whole residues have detached from the protein.So... like I asked last time, are you seeing a periodicity artefact? "Detached" covers a whol

Re: [gmx-users] gromacs 4.06 binary for linux -redhat

[Jussi Lehtola]

On Thu, 2009-12-31 at 08:24 -0800, venkat wrote:
> I think I should be as root to do that.
  
Yes, you must be root to install packages (unless you use rpm switches
to redefine the root directory.)
-- 
--
Jussi Lehtola, FM, Tohtorikoulutettava
Fysiikan laitos, Helsingin Yliopisto
jussi.leht...@helsinki.fi, p. 191 50632
--
Mr. Jussi Lehtola, M. Sc., Doctoral Student
Department of Physics, University of Helsinki, Finland
jussi.leht...@helsinki.fi
--


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

Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Arik Cohen]

Again Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:
No, sorry for the confusion. The images are only from a simulation of 
one protein(tmRBP_Unliganded, PDB: 2FN9). The problem seen with BPTI 
was a bit different in a way that only 1 C-alpha was "detached" (cell 
size ?).




If there is supposed to be only a single protein in the images you've 
shown (and after having a look at the 2FN9 structure from the PDB), it 
seems pretty clear to me that part of your protein has simply crossed 
a periodic boundary and trjconv -pbc mol (or some such command) should 
fix it.


-Justin


Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:
Which two proteins ? I have at least in beginning only one protein 
which some how is divided into two along the calculation.

Any way I'll try both increasing the cell and fix it with trjconv.



Quoting your original message:

"While running a simple MD simulation with both a small protein such 
as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb..."


I assumed that what I was seeing in the images was a set of two 
proteins.  My concern was that you defined a box relative to the 
larger protein, then inserted the smaller one (BPTI?), leaving 
insufficient space in the box to satisfy the minimum image 
convention.  If that's not what we're looking at, then that'd be 
useful to know :)


If you have a single protein, "divided into two" then the problem is 
almost certainly a simple periodicity artifact.  Bonds do not break 
in a normal MD calculation (in fact they can't using the standard MM 
approximations).


-Justin


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

I'm using dodecahedron -d 0.7




Was that distance specified with respect to both of the protein 
molecules in the unit cell?  You can check for spurious PBC 
interactions with g_mindist -pi. Anyway, I'd be curious to see how 
you do with trjconv.


-Justin



Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

I have not tried yet to fix it with trjconv which I will . 
Attached is a picture with 4 snapshots taken from the 
simulation. The C-alphas in question are emphasized with red 
color.




Is your unit cell sufficiently large?  It looks like the 
C-alphas indicated are simply crossing the periodic boundary on 
the "left" of the frame and interacting with the protein 
molecule in the "right" of the frame, which would indicate to me 
that the unit cell is too small and you're seeing spurious PBC 
interactions (i.e., violation of the minimum image convention).


-Justin


Thanks

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

Sorry to bother you again ,but its not only a periodic effect 
since only *some of the atoms* in the  "Detached" group are 
vanishing from this group and reappearing in the main protein 
group. The rest of the atoms are either always in the 
detached or the main group.
In addition, the "detached" group includes three segments of 
the protein(8 residues(126-131), 8 residues(157-164) and 4 
residues186-189).




From your description, this sounds exactly like a periodicity 
problem - some of the atoms are crossing the periodic boundary 
and are appearing in strange locations.  Have you even tried 
trjconv to fix it?  That would be useful information, as I see 
that Mark long ago also suggested the same sort of fix.


It is hard for me to envision what you are seeing.  It would 
be enormously helpful if you could post images (screenshots, 
etc) of the problematic structures to get a more expedient 
resolution.


-Justin


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

With regards to your question I do see some periodicity in 
which for a section of time in the trajectory some of the 
Calphas in the "detached group" are vanishing from it and 
reappear in the main protein.

In addition,
I would appreciate as before any suggestion you might have 
in the matter.




If this is just a periodicity artifact, fix it with trjconv.

-Justin


Thanks

Arik

Mark Abraham wrote:

Arik Cohen wrote:

Hi,

Thanks for answering so quickly !. Apparently whole 
residues have detached from the protein.


So... like I asked last time, are you seeing a periodicity 
artefact? "Detached" covers a whole gamut of possibilities.


Another strange thing that happens in pyMol and VMD is 
that when I select an atom or a residue in the detached 
group the selection appears twice: one in the detached 
group and one in the main part.


If you've got atoms duplicated, then it sounds like 
something's going wrong with how they're interpreting the 
structure file, or how you're manipulating it afterwards. 
Either way, it's not a problem for the GROMACS mailing 
list unless you can demonstrate the atoms are duplicated 
in the structure file (which they aren't!).


Mark


Arik

Mark Abraham wrote:

Arik Cohen wrote:

Dear GROMACS users,

While running a simple MD simulation with both a small 
protein such as BPTI and a larger one such as 
tmRBP_Unliganded_2

Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Justin A. Lemkul]

Arik Cohen wrote:
No, sorry for the confusion. The images are only from a simulation of 
one protein(tmRBP_Unliganded, PDB: 2FN9). The problem seen with BPTI was 
a bit different in a way that only 1 C-alpha was "detached" (cell size ?).




If there is supposed to be only a single protein in the images you've shown (and 
after having a look at the 2FN9 structure from the PDB), it seems pretty clear 
to me that part of your protein has simply crossed a periodic boundary and 
trjconv -pbc mol (or some such command) should fix it.


-Justin


Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:
Which two proteins ? I have at least in beginning only one protein 
which some how is divided into two along the calculation.

Any way I'll try both increasing the cell and fix it with trjconv.



Quoting your original message:

"While running a simple MD simulation with both a small protein such 
as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb..."


I assumed that what I was seeing in the images was a set of two 
proteins.  My concern was that you defined a box relative to the 
larger protein, then inserted the smaller one (BPTI?), leaving 
insufficient space in the box to satisfy the minimum image 
convention.  If that's not what we're looking at, then that'd be 
useful to know :)


If you have a single protein, "divided into two" then the problem is 
almost certainly a simple periodicity artifact.  Bonds do not break in 
a normal MD calculation (in fact they can't using the standard MM 
approximations).


-Justin


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

I'm using dodecahedron -d 0.7




Was that distance specified with respect to both of the protein 
molecules in the unit cell?  You can check for spurious PBC 
interactions with g_mindist -pi. Anyway, I'd be curious to see how 
you do with trjconv.


-Justin



Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

I have not tried yet to fix it with trjconv which I will . 
Attached is a picture with 4 snapshots taken from the simulation. 
The C-alphas in question are emphasized with red color.




Is your unit cell sufficiently large?  It looks like the C-alphas 
indicated are simply crossing the periodic boundary on the "left" 
of the frame and interacting with the protein molecule in the 
"right" of the frame, which would indicate to me that the unit 
cell is too small and you're seeing spurious PBC interactions 
(i.e., violation of the minimum image convention).


-Justin


Thanks

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

Sorry to bother you again ,but its not only a periodic effect 
since only *some of the atoms* in the  "Detached" group are 
vanishing from this group and reappearing in the main protein 
group. The rest of the atoms are either always in the detached 
or the main group.
In addition, the "detached" group includes three segments of 
the protein(8 residues(126-131), 8 residues(157-164) and 4 
residues186-189).




From your description, this sounds exactly like a periodicity 
problem - some of the atoms are crossing the periodic boundary 
and are appearing in strange locations.  Have you even tried 
trjconv to fix it?  That would be useful information, as I see 
that Mark long ago also suggested the same sort of fix.


It is hard for me to envision what you are seeing.  It would be 
enormously helpful if you could post images (screenshots, etc) 
of the problematic structures to get a more expedient resolution.


-Justin


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

With regards to your question I do see some periodicity in 
which for a section of time in the trajectory some of the 
Calphas in the "detached group" are vanishing from it and 
reappear in the main protein.

In addition,
I would appreciate as before any suggestion you might have in 
the matter.




If this is just a periodicity artifact, fix it with trjconv.

-Justin


Thanks

Arik

Mark Abraham wrote:

Arik Cohen wrote:

Hi,

Thanks for answering so quickly !. Apparently whole 
residues have detached from the protein.


So... like I asked last time, are you seeing a periodicity 
artefact? "Detached" covers a whole gamut of possibilities.


Another strange thing that happens in pyMol and VMD is that 
when I select an atom or a residue in the detached group 
the selection appears twice: one in the detached group and 
one in the main part.


If you've got atoms duplicated, then it sounds like 
something's going wrong with how they're interpreting the 
structure file, or how you're manipulating it afterwards. 
Either way, it's not a problem for the GROMACS mailing list 
unless you can demonstrate the atoms are duplicated in the 
structure file (which they aren't!).


Mark


Arik

Mark Abraham wrote:

Arik Cohen wrote:

Dear GROMACS users,

While running a simple MD simulation with both a small 
protein such as BPTI and a larger one such as 
tmRBP_Unliganded_2FN9.pdb, I'm encountering an odd 
situation in which on

Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Arik Cohen]

No, sorry for the confusion. The images are only from a simulation of 
one protein(tmRBP_Unliganded, PDB: 2FN9). The problem seen with BPTI was 
a bit different in a way that only 1 C-alpha was "detached" (cell size ?).


Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:
Which two proteins ? I have at least in beginning only one protein 
which some how is divided into two along the calculation.

Any way I'll try both increasing the cell and fix it with trjconv.



Quoting your original message:

"While running a simple MD simulation with both a small protein such 
as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb..."


I assumed that what I was seeing in the images was a set of two 
proteins.  My concern was that you defined a box relative to the 
larger protein, then inserted the smaller one (BPTI?), leaving 
insufficient space in the box to satisfy the minimum image 
convention.  If that's not what we're looking at, then that'd be 
useful to know :)


If you have a single protein, "divided into two" then the problem is 
almost certainly a simple periodicity artifact.  Bonds do not break in 
a normal MD calculation (in fact they can't using the standard MM 
approximations).


-Justin


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

I'm using dodecahedron -d 0.7




Was that distance specified with respect to both of the protein 
molecules in the unit cell?  You can check for spurious PBC 
interactions with g_mindist -pi. Anyway, I'd be curious to see how 
you do with trjconv.


-Justin



Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

I have not tried yet to fix it with trjconv which I will . 
Attached is a picture with 4 snapshots taken from the simulation. 
The C-alphas in question are emphasized with red color.




Is your unit cell sufficiently large?  It looks like the C-alphas 
indicated are simply crossing the periodic boundary on the "left" 
of the frame and interacting with the protein molecule in the 
"right" of the frame, which would indicate to me that the unit 
cell is too small and you're seeing spurious PBC interactions 
(i.e., violation of the minimum image convention).


-Justin


Thanks

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

Sorry to bother you again ,but its not only a periodic effect 
since only *some of the atoms* in the  "Detached" group are 
vanishing from this group and reappearing in the main protein 
group. The rest of the atoms are either always in the detached 
or the main group.
In addition, the "detached" group includes three segments of 
the protein(8 residues(126-131), 8 residues(157-164) and 4 
residues186-189).




From your description, this sounds exactly like a periodicity 
problem - some of the atoms are crossing the periodic boundary 
and are appearing in strange locations.  Have you even tried 
trjconv to fix it?  That would be useful information, as I see 
that Mark long ago also suggested the same sort of fix.


It is hard for me to envision what you are seeing.  It would be 
enormously helpful if you could post images (screenshots, etc) 
of the problematic structures to get a more expedient resolution.


-Justin


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

With regards to your question I do see some periodicity in 
which for a section of time in the trajectory some of the 
Calphas in the "detached group" are vanishing from it and 
reappear in the main protein.

In addition,
I would appreciate as before any suggestion you might have in 
the matter.




If this is just a periodicity artifact, fix it with trjconv.

-Justin


Thanks

Arik

Mark Abraham wrote:

Arik Cohen wrote:

Hi,

Thanks for answering so quickly !. Apparently whole 
residues have detached from the protein.


So... like I asked last time, are you seeing a periodicity 
artefact? "Detached" covers a whole gamut of possibilities.


Another strange thing that happens in pyMol and VMD is that 
when I select an atom or a residue in the detached group 
the selection appears twice: one in the detached group and 
one in the main part.


If you've got atoms duplicated, then it sounds like 
something's going wrong with how they're interpreting the 
structure file, or how you're manipulating it afterwards. 
Either way, it's not a problem for the GROMACS mailing list 
unless you can demonstrate the atoms are duplicated in the 
structure file (which they aren't!).


Mark


Arik

Mark Abraham wrote:

Arik Cohen wrote:

Dear GROMACS users,

While running a simple MD simulation with both a small 
protein such as BPTI and a larger one such as 
tmRBP_Unliganded_2FN9.pdb, I'm encountering an odd 
situation in which one (in the case of BPTI) or several 
Calphas (in the later case) are "detaching them selfs" 
from the main group.


"main group" of what? Do the atoms bound to them move 
also? Are you seeing a periodicity artefact?


Mark

The problem appeared only after adding salt to the 
simulation(at least in the case of BPTI).
I would app

[gmx-users] pdb file for ammonia

[chris . neale]

Hi Nisha,

Hetero-Atom Navi is a collection of heteroatoms culled from the PDB.
http://hetpdbnavi.nagahama-i-bio.ac.jp/index.php?mode=0

However, having only one heavy-atom, ammonia is unlikely to be  
usefully extracted from this resource for use in atomistic MD.


You can easily make it yourself by taking some protein, running it  
through pdb2gmx -ignh -ter and taking the NH3 terminal group  
coordinates as your ammonia coordinates.


This all assumes that you have some topology for ammonia, else the  
structure will do you little good.


Chris.

-- original message --

Does anyone know where I can get a pdb file for ammonia? I tried
searching but I am not sure if there is a website for the pdb files I
can use in gromac. Any suggestions would be helpful.

Thanks.

Nisha


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

Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Justin A. Lemkul]

Arik Cohen wrote:
Which two proteins ? I have at least in beginning only one protein which 
some how is divided into two along the calculation.

Any way I'll try both increasing the cell and fix it with trjconv.



Quoting your original message:

"While running a simple MD simulation with both a small protein such as BPTI and 
a larger one such as tmRBP_Unliganded_2FN9.pdb..."


I assumed that what I was seeing in the images was a set of two proteins.  My 
concern was that you defined a box relative to the larger protein, then inserted 
the smaller one (BPTI?), leaving insufficient space in the box to satisfy the 
minimum image convention.  If that's not what we're looking at, then that'd be 
useful to know :)


If you have a single protein, "divided into two" then the problem is almost 
certainly a simple periodicity artifact.  Bonds do not break in a normal MD 
calculation (in fact they can't using the standard MM approximations).


-Justin


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

I'm using dodecahedron -d 0.7




Was that distance specified with respect to both of the protein 
molecules in the unit cell?  You can check for spurious PBC 
interactions with g_mindist -pi. Anyway, I'd be curious to see how you 
do with trjconv.


-Justin



Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

I have not tried yet to fix it with trjconv which I will . Attached 
is a picture with 4 snapshots taken from the simulation. The 
C-alphas in question are emphasized with red color.




Is your unit cell sufficiently large?  It looks like the C-alphas 
indicated are simply crossing the periodic boundary on the "left" of 
the frame and interacting with the protein molecule in the "right" 
of the frame, which would indicate to me that the unit cell is too 
small and you're seeing spurious PBC interactions (i.e., violation 
of the minimum image convention).


-Justin


Thanks

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

Sorry to bother you again ,but its not only a periodic effect 
since only *some of the atoms* in the  "Detached" group are 
vanishing from this group and reappearing in the main protein 
group. The rest of the atoms are either always in the detached or 
the main group.
In addition, the "detached" group includes three segments of the 
protein(8 residues(126-131), 8 residues(157-164) and 4 
residues186-189).




From your description, this sounds exactly like a periodicity 
problem - some of the atoms are crossing the periodic boundary and 
are appearing in strange locations.  Have you even tried trjconv 
to fix it?  That would be useful information, as I see that Mark 
long ago also suggested the same sort of fix.


It is hard for me to envision what you are seeing.  It would be 
enormously helpful if you could post images (screenshots, etc) of 
the problematic structures to get a more expedient resolution.


-Justin


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

With regards to your question I do see some periodicity in 
which for a section of time in the trajectory some of the 
Calphas in the "detached group" are vanishing from it and 
reappear in the main protein.

In addition,
I would appreciate as before any suggestion you might have in 
the matter.




If this is just a periodicity artifact, fix it with trjconv.

-Justin


Thanks

Arik

Mark Abraham wrote:

Arik Cohen wrote:

Hi,

Thanks for answering so quickly !. Apparently whole residues 
have detached from the protein.


So... like I asked last time, are you seeing a periodicity 
artefact? "Detached" covers a whole gamut of possibilities.


Another strange thing that happens in pyMol and VMD is that 
when I select an atom or a residue in the detached group the 
selection appears twice: one in the detached group and one in 
the main part.


If you've got atoms duplicated, then it sounds like 
something's going wrong with how they're interpreting the 
structure file, or how you're manipulating it afterwards. 
Either way, it's not a problem for the GROMACS mailing list 
unless you can demonstrate the atoms are duplicated in the 
structure file (which they aren't!).


Mark


Arik

Mark Abraham wrote:

Arik Cohen wrote:

Dear GROMACS users,

While running a simple MD simulation with both a small 
protein such as BPTI and a larger one such as 
tmRBP_Unliganded_2FN9.pdb, I'm encountering an odd 
situation in which one (in the case of BPTI) or several 
Calphas (in the later case) are "detaching them selfs" from 
the main group.


"main group" of what? Do the atoms bound to them move also? 
Are you seeing a periodicity artefact?


Mark

The problem appeared only after adding salt to the 
simulation(at least in the case of BPTI).

I would appreciate any suggestions and comments on the matter.

Thanks

Arik

The run files are:

*em.mdp:*
 
title   =  tmRBP_Unliganded_2FN9 Minimization
integrator  =  steep  ; (steep)using steepest 
descent

nsteps  =  5

RE: [gmx-users] pdb file for ammonia

[Abu Naser]

It is easy to make one yourself. I would use molden to draw  ammonia and save 
as pdb file.  You might need to minimize before using for md.

Abu







 



> Date: Thu, 31 Dec 2009 16:21:29 -0500
> From: nishap.pa...@utoronto.ca
> To: gmx-users@gromacs.org
> Subject: [gmx-users] pdb file for ammonia
> 
> Does anyone know where I can get a pdb file for ammonia? I tried  
> searching but I am not sure if there is a website for the pdb files I  
> can use in gromac. Any suggestions would be helpful.
> 
> Thanks.
> 
> Nisha
> 
> -- 
> gmx-users mailing listgmx-users@gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at http://www.gromacs.org/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/mailing_lists/users.php
  
_
Add your Gmail and Yahoo! Mail email accounts into Hotmail - it's easy
http://clk.atdmt.com/UKM/go/186394592/direct/01/-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/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/mailing_lists/users.php

Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Arik Cohen]

Which two proteins ? I have at least in beginning only one protein which 
some how is divided into two along the calculation.

Any way I'll try both increasing the cell and fix it with trjconv.

Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

I'm using dodecahedron -d 0.7




Was that distance specified with respect to both of the protein 
molecules in the unit cell?  You can check for spurious PBC 
interactions with g_mindist -pi. Anyway, I'd be curious to see how you 
do with trjconv.


-Justin



Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

I have not tried yet to fix it with trjconv which I will . Attached 
is a picture with 4 snapshots taken from the simulation. The 
C-alphas in question are emphasized with red color.




Is your unit cell sufficiently large?  It looks like the C-alphas 
indicated are simply crossing the periodic boundary on the "left" of 
the frame and interacting with the protein molecule in the "right" 
of the frame, which would indicate to me that the unit cell is too 
small and you're seeing spurious PBC interactions (i.e., violation 
of the minimum image convention).


-Justin


Thanks

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

Sorry to bother you again ,but its not only a periodic effect 
since only *some of the atoms* in the  "Detached" group are 
vanishing from this group and reappearing in the main protein 
group. The rest of the atoms are either always in the detached or 
the main group.
In addition, the "detached" group includes three segments of the 
protein(8 residues(126-131), 8 residues(157-164) and 4 
residues186-189).




From your description, this sounds exactly like a periodicity 
problem - some of the atoms are crossing the periodic boundary and 
are appearing in strange locations.  Have you even tried trjconv 
to fix it?  That would be useful information, as I see that Mark 
long ago also suggested the same sort of fix.


It is hard for me to envision what you are seeing.  It would be 
enormously helpful if you could post images (screenshots, etc) of 
the problematic structures to get a more expedient resolution.


-Justin


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

With regards to your question I do see some periodicity in 
which for a section of time in the trajectory some of the 
Calphas in the "detached group" are vanishing from it and 
reappear in the main protein.

In addition,
I would appreciate as before any suggestion you might have in 
the matter.




If this is just a periodicity artifact, fix it with trjconv.

-Justin


Thanks

Arik

Mark Abraham wrote:

Arik Cohen wrote:

Hi,

Thanks for answering so quickly !. Apparently whole residues 
have detached from the protein.


So... like I asked last time, are you seeing a periodicity 
artefact? "Detached" covers a whole gamut of possibilities.


Another strange thing that happens in pyMol and VMD is that 
when I select an atom or a residue in the detached group the 
selection appears twice: one in the detached group and one in 
the main part.


If you've got atoms duplicated, then it sounds like 
something's going wrong with how they're interpreting the 
structure file, or how you're manipulating it afterwards. 
Either way, it's not a problem for the GROMACS mailing list 
unless you can demonstrate the atoms are duplicated in the 
structure file (which they aren't!).


Mark


Arik

Mark Abraham wrote:

Arik Cohen wrote:

Dear GROMACS users,

While running a simple MD simulation with both a small 
protein such as BPTI and a larger one such as 
tmRBP_Unliganded_2FN9.pdb, I'm encountering an odd 
situation in which one (in the case of BPTI) or several 
Calphas (in the later case) are "detaching them selfs" from 
the main group.


"main group" of what? Do the atoms bound to them move also? 
Are you seeing a periodicity artefact?


Mark

The problem appeared only after adding salt to the 
simulation(at least in the case of BPTI).

I would appreciate any suggestions and comments on the matter.

Thanks

Arik

The run files are:

*em.mdp:*
 
title   =  tmRBP_Unliganded_2FN9 Minimization
integrator  =  steep  ; (steep)using steepest 
descent

nsteps  =  5
nstlist =  1
rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
nstenergy   =  10
emtol   =  5.0 ; tolerance kJ/(Mol -1 nm-1) 
instead of 10.0



*pr.mdp
*
title   =  tmRBP_Unliganded_2FN9 PR
integrator  =  md
nsteps  =  5
dt  =  0.002 ;(in ps) doing a 100ps traj.
constraints =  all-bonds
nstlist =  10 ; neighbour list updates every 
number of steps

rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
tcoupl  =  Berendsen
tc-grps =  Protein non-protein
tau-t 

Re: [gmx-users] pdb file for ammonia

[Justin A. Lemkul]

nishap.pa...@utoronto.ca wrote:
Does anyone know where I can get a pdb file for ammonia? I tried 
searching but I am not sure if there is a website for the pdb files I 
can use in gromac. Any suggestions would be helpful.




For something simple like ammonia, you could probably just write the coordinates 
from basic geometry.  Failing that, parse out the coordinates of an 
appropriately-protonated lysine residue in a protein structure.


-Justin


Thanks.

Nisha



--


Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin


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

Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Justin A. Lemkul]

Arik Cohen wrote:

I'm using dodecahedron -d 0.7




Was that distance specified with respect to both of the protein molecules in the 
unit cell?  You can check for spurious PBC interactions with g_mindist -pi. 
Anyway, I'd be curious to see how you do with trjconv.


-Justin



Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

I have not tried yet to fix it with trjconv which I will . Attached 
is a picture with 4 snapshots taken from the simulation. The C-alphas 
in question are emphasized with red color.




Is your unit cell sufficiently large?  It looks like the C-alphas 
indicated are simply crossing the periodic boundary on the "left" of 
the frame and interacting with the protein molecule in the "right" of 
the frame, which would indicate to me that the unit cell is too small 
and you're seeing spurious PBC interactions (i.e., violation of the 
minimum image convention).


-Justin


Thanks

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

Sorry to bother you again ,but its not only a periodic effect since 
only *some of the atoms* in the  "Detached" group are vanishing 
from this group and reappearing in the main protein group. The rest 
of the atoms are either always in the detached or the main group.
In addition, the "detached" group includes three segments of the 
protein(8 residues(126-131), 8 residues(157-164) and 4 
residues186-189).




From your description, this sounds exactly like a periodicity 
problem - some of the atoms are crossing the periodic boundary and 
are appearing in strange locations.  Have you even tried trjconv to 
fix it?  That would be useful information, as I see that Mark long 
ago also suggested the same sort of fix.


It is hard for me to envision what you are seeing.  It would be 
enormously helpful if you could post images (screenshots, etc) of 
the problematic structures to get a more expedient resolution.


-Justin


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

With regards to your question I do see some periodicity in which 
for a section of time in the trajectory some of the Calphas in 
the "detached group" are vanishing from it and reappear in the 
main protein.

In addition,
I would appreciate as before any suggestion you might have in the 
matter.




If this is just a periodicity artifact, fix it with trjconv.

-Justin


Thanks

Arik

Mark Abraham wrote:

Arik Cohen wrote:

Hi,

Thanks for answering so quickly !. Apparently whole residues 
have detached from the protein.


So... like I asked last time, are you seeing a periodicity 
artefact? "Detached" covers a whole gamut of possibilities.


Another strange thing that happens in pyMol and VMD is that 
when I select an atom or a residue in the detached group the 
selection appears twice: one in the detached group and one in 
the main part.


If you've got atoms duplicated, then it sounds like something's 
going wrong with how they're interpreting the structure file, or 
how you're manipulating it afterwards. Either way, it's not a 
problem for the GROMACS mailing list unless you can demonstrate 
the atoms are duplicated in the structure file (which they 
aren't!).


Mark


Arik

Mark Abraham wrote:

Arik Cohen wrote:

Dear GROMACS users,

While running a simple MD simulation with both a small 
protein such as BPTI and a larger one such as 
tmRBP_Unliganded_2FN9.pdb, I'm encountering an odd situation 
in which one (in the case of BPTI) or several Calphas (in the 
later case) are "detaching them selfs" from the main group.


"main group" of what? Do the atoms bound to them move also? 
Are you seeing a periodicity artefact?


Mark

The problem appeared only after adding salt to the 
simulation(at least in the case of BPTI).

I would appreciate any suggestions and comments on the matter.

Thanks

Arik

The run files are:

*em.mdp:*
 
title   =  tmRBP_Unliganded_2FN9 Minimization
integrator  =  steep  ; (steep)using steepest 
descent

nsteps  =  5
nstlist =  1
rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
nstenergy   =  10
emtol   =  5.0 ; tolerance kJ/(Mol -1 nm-1) 
instead of 10.0



*pr.mdp
*
title   =  tmRBP_Unliganded_2FN9 PR
integrator  =  md
nsteps  =  5
dt  =  0.002 ;(in ps) doing a 100ps traj.
constraints =  all-bonds
nstlist =  10 ; neighbour list updates every 
number of steps

rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
tcoupl  =  Berendsen
tc-grps =  Protein non-protein
tau-t   =  0.1 0.1
ref-t   =  298 298
Pcoupl  =  Berendsen
tau-p   =  1.0
compressibility =  5e-5 5e-5 5e-5 0 0 0
ref-p   =  1.0
nstenergy   =  100
define  =  -DPOS

Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Arik Cohen]

I'm using dodecahedron -d 0.7



Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

I have not tried yet to fix it with trjconv which I will . Attached 
is a picture with 4 snapshots taken from the simulation. The C-alphas 
in question are emphasized with red color.




Is your unit cell sufficiently large?  It looks like the C-alphas 
indicated are simply crossing the periodic boundary on the "left" of 
the frame and interacting with the protein molecule in the "right" of 
the frame, which would indicate to me that the unit cell is too small 
and you're seeing spurious PBC interactions (i.e., violation of the 
minimum image convention).


-Justin


Thanks

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

Sorry to bother you again ,but its not only a periodic effect since 
only *some of the atoms* in the  "Detached" group are vanishing 
from this group and reappearing in the main protein group. The rest 
of the atoms are either always in the detached or the main group.
In addition, the "detached" group includes three segments of the 
protein(8 residues(126-131), 8 residues(157-164) and 4 
residues186-189).




From your description, this sounds exactly like a periodicity 
problem - some of the atoms are crossing the periodic boundary and 
are appearing in strange locations.  Have you even tried trjconv to 
fix it?  That would be useful information, as I see that Mark long 
ago also suggested the same sort of fix.


It is hard for me to envision what you are seeing.  It would be 
enormously helpful if you could post images (screenshots, etc) of 
the problematic structures to get a more expedient resolution.


-Justin


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

With regards to your question I do see some periodicity in which 
for a section of time in the trajectory some of the Calphas in 
the "detached group" are vanishing from it and reappear in the 
main protein.

In addition,
I would appreciate as before any suggestion you might have in the 
matter.




If this is just a periodicity artifact, fix it with trjconv.

-Justin


Thanks

Arik

Mark Abraham wrote:

Arik Cohen wrote:

Hi,

Thanks for answering so quickly !. Apparently whole residues 
have detached from the protein.


So... like I asked last time, are you seeing a periodicity 
artefact? "Detached" covers a whole gamut of possibilities.


Another strange thing that happens in pyMol and VMD is that 
when I select an atom or a residue in the detached group the 
selection appears twice: one in the detached group and one in 
the main part.


If you've got atoms duplicated, then it sounds like something's 
going wrong with how they're interpreting the structure file, or 
how you're manipulating it afterwards. Either way, it's not a 
problem for the GROMACS mailing list unless you can demonstrate 
the atoms are duplicated in the structure file (which they 
aren't!).


Mark


Arik

Mark Abraham wrote:

Arik Cohen wrote:

Dear GROMACS users,

While running a simple MD simulation with both a small 
protein such as BPTI and a larger one such as 
tmRBP_Unliganded_2FN9.pdb, I'm encountering an odd situation 
in which one (in the case of BPTI) or several Calphas (in the 
later case) are "detaching them selfs" from the main group.


"main group" of what? Do the atoms bound to them move also? 
Are you seeing a periodicity artefact?


Mark

The problem appeared only after adding salt to the 
simulation(at least in the case of BPTI).

I would appreciate any suggestions and comments on the matter.

Thanks

Arik

The run files are:

*em.mdp:*
 
title   =  tmRBP_Unliganded_2FN9 Minimization
integrator  =  steep  ; (steep)using steepest 
descent

nsteps  =  5
nstlist =  1
rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
nstenergy   =  10
emtol   =  5.0 ; tolerance kJ/(Mol -1 nm-1) 
instead of 10.0



*pr.mdp
*
title   =  tmRBP_Unliganded_2FN9 PR
integrator  =  md
nsteps  =  5
dt  =  0.002 ;(in ps) doing a 100ps traj.
constraints =  all-bonds
nstlist =  10 ; neighbour list updates every 
number of steps

rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
tcoupl  =  Berendsen
tc-grps =  Protein non-protein
tau-t   =  0.1 0.1
ref-t   =  298 298
Pcoupl  =  Berendsen
tau-p   =  1.0
compressibility =  5e-5 5e-5 5e-5 0 0 0
ref-p   =  1.0
nstenergy   =  100
define  =  -DPOSRES ; include posre.itp(position 
restraint) file


*run.md
*title   =  tmRBP_Unliganded_2FN9
integrator  =  md
nsteps  =  30
dt  =  0.001
constraints =  all-bonds
nstlist =  10

[gmx-users] pdb file for ammonia

[nishap . patel]

Does anyone know where I can get a pdb file for ammonia? I tried  
searching but I am not sure if there is a website for the pdb files I  
can use in gromac. Any suggestions would be helpful.


Thanks.

Nisha

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

Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Justin A. Lemkul]

Arik Cohen wrote:

Hi,

I have not tried yet to fix it with trjconv which I will . Attached is a 
picture with 4 snapshots taken from the simulation. The C-alphas in 
question are emphasized with red color.




Is your unit cell sufficiently large?  It looks like the C-alphas indicated are 
simply crossing the periodic boundary on the "left" of the frame and interacting 
with the protein molecule in the "right" of the frame, which would indicate to 
me that the unit cell is too small and you're seeing spurious PBC interactions 
(i.e., violation of the minimum image convention).


-Justin


Thanks

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

Sorry to bother you again ,but its not only a periodic effect since 
only *some of the atoms* in the  "Detached" group are vanishing from 
this group and reappearing in the main protein group. The rest of the 
atoms are either always in the detached or the main group.
In addition, the "detached" group includes three segments of the 
protein(8 residues(126-131), 8 residues(157-164) and 4 residues186-189).




From your description, this sounds exactly like a periodicity problem 
- some of the atoms are crossing the periodic boundary and are 
appearing in strange locations.  Have you even tried trjconv to fix 
it?  That would be useful information, as I see that Mark long ago 
also suggested the same sort of fix.


It is hard for me to envision what you are seeing.  It would be 
enormously helpful if you could post images (screenshots, etc) of the 
problematic structures to get a more expedient resolution.


-Justin


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

With regards to your question I do see some periodicity in which 
for a section of time in the trajectory some of the Calphas in the 
"detached group" are vanishing from it and reappear in the main 
protein.

In addition,
I would appreciate as before any suggestion you might have in the 
matter.




If this is just a periodicity artifact, fix it with trjconv.

-Justin


Thanks

Arik

Mark Abraham wrote:

Arik Cohen wrote:

Hi,

Thanks for answering so quickly !. Apparently whole residues have 
detached from the protein.


So... like I asked last time, are you seeing a periodicity 
artefact? "Detached" covers a whole gamut of possibilities.


Another strange thing that happens in pyMol and VMD is that when 
I select an atom or a residue in the detached group the selection 
appears twice: one in the detached group and one in the main part.


If you've got atoms duplicated, then it sounds like something's 
going wrong with how they're interpreting the structure file, or 
how you're manipulating it afterwards. Either way, it's not a 
problem for the GROMACS mailing list unless you can demonstrate 
the atoms are duplicated in the structure file (which they aren't!).


Mark


Arik

Mark Abraham wrote:

Arik Cohen wrote:

Dear GROMACS users,

While running a simple MD simulation with both a small protein 
such as BPTI and a larger one such as 
tmRBP_Unliganded_2FN9.pdb, I'm encountering an odd situation in 
which one (in the case of BPTI) or several Calphas (in the 
later case) are "detaching them selfs" from the main group.


"main group" of what? Do the atoms bound to them move also? Are 
you seeing a periodicity artefact?


Mark

The problem appeared only after adding salt to the 
simulation(at least in the case of BPTI).

I would appreciate any suggestions and comments on the matter.

Thanks

Arik

The run files are:

*em.mdp:*
 
title   =  tmRBP_Unliganded_2FN9 Minimization

integrator  =  steep  ; (steep)using steepest descent
nsteps  =  5
nstlist =  1
rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
nstenergy   =  10
emtol   =  5.0 ; tolerance kJ/(Mol -1 nm-1) instead 
of 10.0



*pr.mdp
*
title   =  tmRBP_Unliganded_2FN9 PR
integrator  =  md
nsteps  =  5
dt  =  0.002 ;(in ps) doing a 100ps traj.
constraints =  all-bonds
nstlist =  10 ; neighbour list updates every number 
of steps

rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
tcoupl  =  Berendsen
tc-grps =  Protein non-protein
tau-t   =  0.1 0.1
ref-t   =  298 298
Pcoupl  =  Berendsen
tau-p   =  1.0
compressibility =  5e-5 5e-5 5e-5 0 0 0
ref-p   =  1.0
nstenergy   =  100
define  =  -DPOSRES ; include posre.itp(position 
restraint) file


*run.md
*title   =  tmRBP_Unliganded_2FN9
integrator  =  md
nsteps  =  30
dt  =  0.001
constraints =  all-bonds
nstlist =  10
rlist   =  1.0
coulombtype =  PME
rcoulomb

Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Justin A. Lemkul]

Arik Cohen wrote:

Hi,

Sorry to bother you again ,but its not only a periodic effect since only 
*some of the atoms* in the  "Detached" group are vanishing from this 
group and reappearing in the main protein group. The rest of the atoms 
are either always in the detached or the main group.
In addition, the "detached" group includes three segments of the 
protein(8 residues(126-131), 8 residues(157-164) and 4 residues186-189).




From your description, this sounds exactly like a periodicity problem - some of 
the atoms are crossing the periodic boundary and are appearing in strange 
locations.  Have you even tried trjconv to fix it?  That would be useful 
information, as I see that Mark long ago also suggested the same sort of fix.


It is hard for me to envision what you are seeing.  It would be enormously 
helpful if you could post images (screenshots, etc) of the problematic 
structures to get a more expedient resolution.


-Justin


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

With regards to your question I do see some periodicity in which for 
a section of time in the trajectory some of the Calphas in the 
"detached group" are vanishing from it and reappear in the main protein.

In addition,
I would appreciate as before any suggestion you might have in the 
matter.




If this is just a periodicity artifact, fix it with trjconv.

-Justin


Thanks

Arik

Mark Abraham wrote:

Arik Cohen wrote:

Hi,

Thanks for answering so quickly !. Apparently whole residues have 
detached from the protein.


So... like I asked last time, are you seeing a periodicity artefact? 
"Detached" covers a whole gamut of possibilities.


Another strange thing that happens in pyMol and VMD is that when I 
select an atom or a residue in the detached group the selection 
appears twice: one in the detached group and one in the main part.


If you've got atoms duplicated, then it sounds like something's 
going wrong with how they're interpreting the structure file, or how 
you're manipulating it afterwards. Either way, it's not a problem 
for the GROMACS mailing list unless you can demonstrate the atoms 
are duplicated in the structure file (which they aren't!).


Mark


Arik

Mark Abraham wrote:

Arik Cohen wrote:

Dear GROMACS users,

While running a simple MD simulation with both a small protein 
such as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb, 
I'm encountering an odd situation in which one (in the case of 
BPTI) or several Calphas (in the later case) are "detaching them 
selfs" from the main group.


"main group" of what? Do the atoms bound to them move also? Are 
you seeing a periodicity artefact?


Mark

The problem appeared only after adding salt to the simulation(at 
least in the case of BPTI).

I would appreciate any suggestions and comments on the matter.

Thanks

Arik

The run files are:

*em.mdp:*
 
title   =  tmRBP_Unliganded_2FN9 Minimization

integrator  =  steep  ; (steep)using steepest descent
nsteps  =  5
nstlist =  1
rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
nstenergy   =  10
emtol   =  5.0 ; tolerance kJ/(Mol -1 nm-1) instead 
of 10.0



*pr.mdp
*
title   =  tmRBP_Unliganded_2FN9 PR
integrator  =  md
nsteps  =  5
dt  =  0.002 ;(in ps) doing a 100ps traj.
constraints =  all-bonds
nstlist =  10 ; neighbour list updates every number 
of steps

rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
tcoupl  =  Berendsen
tc-grps =  Protein non-protein
tau-t   =  0.1 0.1
ref-t   =  298 298
Pcoupl  =  Berendsen
tau-p   =  1.0
compressibility =  5e-5 5e-5 5e-5 0 0 0
ref-p   =  1.0
nstenergy   =  100
define  =  -DPOSRES ; include posre.itp(position 
restraint) file


*run.md
*title   =  tmRBP_Unliganded_2FN9
integrator  =  md
nsteps  =  30
dt  =  0.001
constraints =  all-bonds
nstlist =  10
rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
tcoupl  =  V-rescale  ;V-rescale
tc-grps =  Protein non-protein
tau-t   =  0.8 0.8
ref-t   =  298 298
nstxout =  1000
nstvout =  1000
nstxtcout   =  1000
nstenergy   =  1000



The runs commands are(integrated inside a C++ code):

SysCommand1 = "echo 6 | pdb2gmx -f " + FileName + " -water tip3p";

 system("editconf -f conf.gro -bt dodecahedron -d 0.7 -o box.gro");

system("genbox -cp box.gro -cs spc216.gro -p topol.top -o 
solvated.gro");



minimization:

 if(Mo

Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Arik Cohen]

Hi,

Sorry to bother you again ,but its not only a periodic effect since only 
*some of the atoms* in the  "Detached" group are vanishing from this 
group and reappearing in the main protein group. The rest of the atoms 
are either always in the detached or the main group.
In addition, the "detached" group includes three segments of the 
protein(8 residues(126-131), 8 residues(157-164) and 4 residues186-189).


Thanks a lot

Arik

Justin A. Lemkul wrote:



Arik Cohen wrote:

Hi,

With regards to your question I do see some periodicity in which for 
a section of time in the trajectory some of the Calphas in the 
"detached group" are vanishing from it and reappear in the main protein.

In addition,
I would appreciate as before any suggestion you might have in the 
matter.




If this is just a periodicity artifact, fix it with trjconv.

-Justin


Thanks

Arik

Mark Abraham wrote:

Arik Cohen wrote:

Hi,

Thanks for answering so quickly !. Apparently whole residues have 
detached from the protein.


So... like I asked last time, are you seeing a periodicity artefact? 
"Detached" covers a whole gamut of possibilities.


Another strange thing that happens in pyMol and VMD is that when I 
select an atom or a residue in the detached group the selection 
appears twice: one in the detached group and one in the main part.


If you've got atoms duplicated, then it sounds like something's 
going wrong with how they're interpreting the structure file, or how 
you're manipulating it afterwards. Either way, it's not a problem 
for the GROMACS mailing list unless you can demonstrate the atoms 
are duplicated in the structure file (which they aren't!).


Mark


Arik

Mark Abraham wrote:

Arik Cohen wrote:

Dear GROMACS users,

While running a simple MD simulation with both a small protein 
such as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb, 
I'm encountering an odd situation in which one (in the case of 
BPTI) or several Calphas (in the later case) are "detaching them 
selfs" from the main group.


"main group" of what? Do the atoms bound to them move also? Are 
you seeing a periodicity artefact?


Mark

The problem appeared only after adding salt to the simulation(at 
least in the case of BPTI).

I would appreciate any suggestions and comments on the matter.

Thanks

Arik

The run files are:

*em.mdp:*
 
title   =  tmRBP_Unliganded_2FN9 Minimization

integrator  =  steep  ; (steep)using steepest descent
nsteps  =  5
nstlist =  1
rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
nstenergy   =  10
emtol   =  5.0 ; tolerance kJ/(Mol -1 nm-1) instead 
of 10.0



*pr.mdp
*
title   =  tmRBP_Unliganded_2FN9 PR
integrator  =  md
nsteps  =  5
dt  =  0.002 ;(in ps) doing a 100ps traj.
constraints =  all-bonds
nstlist =  10 ; neighbour list updates every number 
of steps

rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
tcoupl  =  Berendsen
tc-grps =  Protein non-protein
tau-t   =  0.1 0.1
ref-t   =  298 298
Pcoupl  =  Berendsen
tau-p   =  1.0
compressibility =  5e-5 5e-5 5e-5 0 0 0
ref-p   =  1.0
nstenergy   =  100
define  =  -DPOSRES ; include posre.itp(position 
restraint) file


*run.md
*title   =  tmRBP_Unliganded_2FN9
integrator  =  md
nsteps  =  30
dt  =  0.001
constraints =  all-bonds
nstlist =  10
rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
tcoupl  =  V-rescale  ;V-rescale
tc-grps =  Protein non-protein
tau-t   =  0.8 0.8
ref-t   =  298 298
nstxout =  1000
nstvout =  1000
nstxtcout   =  1000
nstenergy   =  1000



The runs commands are(integrated inside a C++ code):

SysCommand1 = "echo 6 | pdb2gmx -f " + FileName + " -water tip3p";

 system("editconf -f conf.gro -bt dodecahedron -d 0.7 -o box.gro");

system("genbox -cp box.gro -cs spc216.gro -p topol.top -o 
solvated.gro");



minimization:

 if(Mode == "NoSalt")
{
 system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro -o 
em.tpr");
 
 //system("mpirun -np 4 mdrun -v -deffnm em");

}
  if(Mode == "WithSalt")
{
  system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro 
-o em.tpr");

   system("mpirun -np 4 mdrun -v -deffnm em");
}


Salting:

 system("echo 12 | genion -s em.tpr -conc 0.1 -neutral -o 
solvated.gro");
 
pr:


system("grompp -f MDP/prmd.mdp -p topol.top -c em.gro -o pr.tpr");
  /* The actual run*/
  system("mpir

Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Justin A. Lemkul]

Arik Cohen wrote:

Hi,

With regards to your question I do see some periodicity in which for a 
section of time in the trajectory some of the Calphas in the "detached 
group" are vanishing from it and reappear in the main protein.

In addition,
I would appreciate as before any suggestion you might have in the matter.



If this is just a periodicity artifact, fix it with trjconv.

-Justin


Thanks

Arik

Mark Abraham wrote:

Arik Cohen wrote:

Hi,

Thanks for answering so quickly !. Apparently whole residues have 
detached from the protein.


So... like I asked last time, are you seeing a periodicity artefact? 
"Detached" covers a whole gamut of possibilities.


Another strange thing that happens in pyMol and VMD is that when I 
select an atom or a residue in the detached group the selection 
appears twice: one in the detached group and one in the main part.


If you've got atoms duplicated, then it sounds like something's going 
wrong with how they're interpreting the structure file, or how you're 
manipulating it afterwards. Either way, it's not a problem for the 
GROMACS mailing list unless you can demonstrate the atoms are 
duplicated in the structure file (which they aren't!).


Mark


Arik

Mark Abraham wrote:

Arik Cohen wrote:

Dear GROMACS users,

While running a simple MD simulation with both a small protein such 
as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb, I'm 
encountering an odd situation in which one (in the case of BPTI) or 
several Calphas (in the later case) are "detaching them selfs" from 
the main group.


"main group" of what? Do the atoms bound to them move also? Are you 
seeing a periodicity artefact?


Mark

The problem appeared only after adding salt to the simulation(at 
least in the case of BPTI).

I would appreciate any suggestions and comments on the matter.

Thanks

Arik

The run files are:

*em.mdp:*
 
title   =  tmRBP_Unliganded_2FN9 Minimization

integrator  =  steep  ; (steep)using steepest descent
nsteps  =  5
nstlist =  1
rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
nstenergy   =  10
emtol   =  5.0 ; tolerance kJ/(Mol -1 nm-1) instead of 
10.0



*pr.mdp
*
title   =  tmRBP_Unliganded_2FN9 PR
integrator  =  md
nsteps  =  5
dt  =  0.002 ;(in ps) doing a 100ps traj.
constraints =  all-bonds
nstlist =  10 ; neighbour list updates every number of 
steps

rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
tcoupl  =  Berendsen
tc-grps =  Protein non-protein
tau-t   =  0.1 0.1
ref-t   =  298 298
Pcoupl  =  Berendsen
tau-p   =  1.0
compressibility =  5e-5 5e-5 5e-5 0 0 0
ref-p   =  1.0
nstenergy   =  100
define  =  -DPOSRES ; include posre.itp(position 
restraint) file


*run.md
*title   =  tmRBP_Unliganded_2FN9
integrator  =  md
nsteps  =  30
dt  =  0.001
constraints =  all-bonds
nstlist =  10
rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
tcoupl  =  V-rescale  ;V-rescale
tc-grps =  Protein non-protein
tau-t   =  0.8 0.8
ref-t   =  298 298
nstxout =  1000
nstvout =  1000
nstxtcout   =  1000
nstenergy   =  1000



The runs commands are(integrated inside a C++ code):

SysCommand1 = "echo 6 | pdb2gmx -f " + FileName + " -water tip3p";

 system("editconf -f conf.gro -bt dodecahedron -d 0.7 -o box.gro");

system("genbox -cp box.gro -cs spc216.gro -p topol.top -o 
solvated.gro");



minimization:

 if(Mode == "NoSalt")
{
 system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro -o 
em.tpr");
 
 //system("mpirun -np 4 mdrun -v -deffnm em");

}
  if(Mode == "WithSalt")
{
  system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro -o 
em.tpr");

   system("mpirun -np 4 mdrun -v -deffnm em");
}


Salting:

 system("echo 12 | genion -s em.tpr -conc 0.1 -neutral -o 
solvated.gro");
 
pr:


system("grompp -f MDP/prmd.mdp -p topol.top -c em.gro -o pr.tpr");
  /* The actual run*/
  system("mpirun -np 4 mdrun -v -deffnm pr"); 




--


Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin


--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please sea

Re: [Fwd: Re: [gmx-users] A problem with a "detaching Calpha/s"]

[Arik Cohen]

Hi,

With regards to your question I do see some periodicity in which for a 
section of time in the trajectory some of the Calphas in the "detached 
group" are vanishing from it and reappear in the main protein.

In addition,
I would appreciate as before any suggestion you might have in the matter.

Thanks

Arik

Mark Abraham wrote:

Arik Cohen wrote:

Hi,

Thanks for answering so quickly !. Apparently whole residues have 
detached from the protein.


So... like I asked last time, are you seeing a periodicity artefact? 
"Detached" covers a whole gamut of possibilities.


Another strange thing that happens in pyMol and VMD is that when I 
select an atom or a residue in the detached group the selection 
appears twice: one in the detached group and one in the main part.


If you've got atoms duplicated, then it sounds like something's going 
wrong with how they're interpreting the structure file, or how you're 
manipulating it afterwards. Either way, it's not a problem for the 
GROMACS mailing list unless you can demonstrate the atoms are 
duplicated in the structure file (which they aren't!).


Mark


Arik

Mark Abraham wrote:

Arik Cohen wrote:

Dear GROMACS users,

While running a simple MD simulation with both a small protein such 
as BPTI and a larger one such as tmRBP_Unliganded_2FN9.pdb, I'm 
encountering an odd situation in which one (in the case of BPTI) or 
several Calphas (in the later case) are "detaching them selfs" from 
the main group.


"main group" of what? Do the atoms bound to them move also? Are you 
seeing a periodicity artefact?


Mark

The problem appeared only after adding salt to the simulation(at 
least in the case of BPTI).

I would appreciate any suggestions and comments on the matter.

Thanks

Arik

The run files are:

*em.mdp:*
 
title   =  tmRBP_Unliganded_2FN9 Minimization

integrator  =  steep  ; (steep)using steepest descent
nsteps  =  5
nstlist =  1
rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
nstenergy   =  10
emtol   =  5.0 ; tolerance kJ/(Mol -1 nm-1) instead of 
10.0



*pr.mdp
*
title   =  tmRBP_Unliganded_2FN9 PR
integrator  =  md
nsteps  =  5
dt  =  0.002 ;(in ps) doing a 100ps traj.
constraints =  all-bonds
nstlist =  10 ; neighbour list updates every number of 
steps

rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
tcoupl  =  Berendsen
tc-grps =  Protein non-protein
tau-t   =  0.1 0.1
ref-t   =  298 298
Pcoupl  =  Berendsen
tau-p   =  1.0
compressibility =  5e-5 5e-5 5e-5 0 0 0
ref-p   =  1.0
nstenergy   =  100
define  =  -DPOSRES ; include posre.itp(position 
restraint) file


*run.md
*title   =  tmRBP_Unliganded_2FN9
integrator  =  md
nsteps  =  30
dt  =  0.001
constraints =  all-bonds
nstlist =  10
rlist   =  1.0
coulombtype =  PME
rcoulomb=  1.0
vdw-type=  cut-off
rvdw=  1.0
tcoupl  =  V-rescale  ;V-rescale
tc-grps =  Protein non-protein
tau-t   =  0.8 0.8
ref-t   =  298 298
nstxout =  1000
nstvout =  1000
nstxtcout   =  1000
nstenergy   =  1000



The runs commands are(integrated inside a C++ code):

SysCommand1 = "echo 6 | pdb2gmx -f " + FileName + " -water tip3p";

 system("editconf -f conf.gro -bt dodecahedron -d 0.7 -o box.gro");

system("genbox -cp box.gro -cs spc216.gro -p topol.top -o 
solvated.gro");



minimization:

 if(Mode == "NoSalt")
{
 system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro -o 
em.tpr");
 
 //system("mpirun -np 4 mdrun -v -deffnm em");

}
  if(Mode == "WithSalt")
{
  system("grompp -f MDP/em.mdp -p topol.top -c solvated.gro -o 
em.tpr");

   system("mpirun -np 4 mdrun -v -deffnm em");
}


Salting:

 system("echo 12 | genion -s em.tpr -conc 0.1 -neutral -o 
solvated.gro");
 
pr:


system("grompp -f MDP/prmd.mdp -p topol.top -c em.gro -o pr.tpr");
  /* The actual run*/
  system("mpirun -np 4 mdrun -v -deffnm pr"); 



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

Re: [gmx-users] using mdrun in the supercomputer

[Justin A. Lemkul]

Asmaa Elsheshiny wrote:

Dear gromacs users,
I tried to make MD simulation using mdrun in the super computer by using the 
following script:
#!/bin/sh
#$  -cwd  –V
#$  -l h_rt=1:00:00
#$  -pe mx* 4
export  DO_PARALLEL=”/usr/local/sge6.0/mpi/myrinet/sge_mpirun”
export  gromacs=/apps/gromacs/64/3.3.1-ffamber20080701/bin
$ DO_PARALLEL $gromacs/mdrun   “ -s md.tpr  \
 -o md.trr  -x md.xtc  –c md.gro  –e  ener.edr”
This script appears to work fine, but i stopped suddenly after a short period 
giving missing output. That is why the structure file .gro is missing. I have 
tested it locally before submitting it as a job in the supercomputer; I found 
that it works fine. So, what is the problem with this script?


It is very rare that mdrun exits without reporting an error message upon 
abnormal termination.  Is the mdrun executable actually MPI-enabled?  Does the 
log file show anything?


-Justin


Kind regards,
Asmaa



--


Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin


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

[gmx-users] using mdrun in the supercomputer

[Asmaa Elsheshiny]

Dear gromacs users,
I tried to make MD simulation using mdrun in the super computer by using the 
following script:
#!/bin/sh
#$  -cwd  –V
#$  -l h_rt=1:00:00
#$  -pe mx* 4
export  DO_PARALLEL=”/usr/local/sge6.0/mpi/myrinet/sge_mpirun”
export  gromacs=/apps/gromacs/64/3.3.1-ffamber20080701/bin
$ DO_PARALLEL $gromacs/mdrun   “ -s md.tpr  \
 -o md.trr  -x md.xtc  –c md.gro  –e  ener.edr”
This script appears to work fine, but i stopped suddenly after a short period 
giving missing output. That is why the structure file .gro is missing. I have 
tested it locally before submitting it as a job in the supercomputer; I found 
that it works fine. So, what is the problem with this script?
Kind regards,
Asmaa

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

Re: [gmx-users] grompp segmentation error

[Justin A. Lemkul]

ram bio wrote:

Dear Gromacs Users,

Iam following Drug/Enzyme complex solvation tutorial by John E.
Kerrigan, I am unable to execute the grompp step as per the tutorial,
the output of grompp command is as follows:

grompp -f minim.mdp -c trp_b4ion.gro -p trp.top -o trp_b4ion.tpr


   :-)  grompp  (-:

Back Off! I just backed up mdout.mdp to ./#mdout.mdp.11#
checking input for internal consistency...
processing topology...
Opening library file /usr/local/gromacs/share/gromacs/top/ffG53a6.itp
Opening library file /usr/local/gromacs/share/gromacs/top/ffG53a6nb.itp
Opening library file /usr/local/gromacs/share/gromacs/top/ffG53a6bon.itp
Opening library file /usr/local/gromacs/share/gromacs/top/ff_dum.itp
Segmentation fault

what i have done is as per the tutorial, that is
1) generated the drg.itp using prodrug beta
2) executed pdb2gmx using 4 that is ff53a6 ff
3) edit the drg.itp by removing the lines redundant as per trp.top
4) edit trp.gro by adding drg coordinates and chainging the numbers

please help me to overcome this error, for your convenience I have
attached the drg.itp, trp.top, trp.gro and trp_b4ion.gro files.



I doubt any of these files will be useful.  Better information would include:

1. The Gromacs version you are using.
2. The compilers used in installing Gromacs.
3. Options specified during configuration.
4. Specifications of your hardware.

A segmentation fault is a memory error and can have numerous causes.  The above 
information may be useful.


-Justin


Thanks,

Ram
4 attachments —


--


Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin


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

Re: [gmx-users] gromacs 4.06 binary for linux -redhat

[venkat]

I think I should be as root to do that.




- Original Message 
From: Jussi Lehtola 
To: Discussion list for GROMACS users 
Sent: Thu, December 31, 2009 10:17:00 AM
Subject: Re: [gmx-users] gromacs 4.06 binary for linux -redhat

On Thu, 2009-12-31 at 08:09 -0800, venkat wrote:
> I did installed fftw , not sure it is completed. 

I assume you're running Red Hat Enterprise
(or any of its clones such as CentOS).

Just do things the easy way: enable Fedora EPEL
http://www.fedoraproject.org/wiki/EPEL/FAQ#howtouse
on your system and install fftw (system wide) with

# yum -y install fftw-devel

If you're interested, there's a binary package of Gromacs,
too, available in EPEL, that you can install with

# yum -y install gromacs
  

-- 
--
Jussi Lehtola, FM, Tohtorikoulutettava
Fysiikan laitos, Helsingin Yliopisto
jussi.leht...@helsinki.fi, p. 191 50632
--
Mr. Jussi Lehtola, M. Sc., Doctoral Student
Department of Physics, University of Helsinki, Finland
jussi.leht...@helsinki.fi
--


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



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

Re: [gmx-users] gromacs 4.06 binary for linux -redhat

[Jussi Lehtola]

On Thu, 2009-12-31 at 08:09 -0800, venkat wrote:
> I did installed fftw , not sure it is completed. 

I assume you're running Red Hat Enterprise
(or any of its clones such as CentOS).

Just do things the easy way: enable Fedora EPEL
 http://www.fedoraproject.org/wiki/EPEL/FAQ#howtouse
on your system and install fftw (system wide) with

# yum -y install fftw-devel

If you're interested, there's a binary package of Gromacs,
too, available in EPEL, that you can install with

# yum -y install gromacs
   

-- 
--
Jussi Lehtola, FM, Tohtorikoulutettava
Fysiikan laitos, Helsingin Yliopisto
jussi.leht...@helsinki.fi, p. 191 50632
--
Mr. Jussi Lehtola, M. Sc., Doctoral Student
Department of Physics, University of Helsinki, Finland
jussi.leht...@helsinki.fi
--


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

Re: [gmx-users] gromacs 4.06 binary for linux -redhat

[venkat]

I did installed fftw , not sure it is completed. 
 
while doing make command , got the following error mesage

$ configure  -enable-threads --enable-float--prefix=/home/pgm/fftw
$make

cp fftw_wisdom.1 fftwf-wisdom.1
make  all-am
/bin/sh ../libtool --tag=CC   --mode=link gcc -std=gnu99  -O3 
-fomit-frame-pointer -fstrict-aliasing -ffast-math -mpentiumpro -pthread  
-L/home/vk/pgm/fftw/lib -o fftwf-wisdom fftw-wisdom.o ../tests/bench.o 
../tests/fftw-bench.o ../threads/libfftw3f_threads.la ../libfftw3f.la 
../libbench2/libbench2.a  -lm 
libtool: link: gcc -std=gnu99 -O3 -fomit-frame-pointer -fstrict-aliasing 
-ffast-math -mpentiumpro -pthread -o fftwf-wisdom fftw-wisdom.o 
../tests/bench.o ../tests/fftw-bench.o  -L/home/vk/pgm/fftw/lib 
../threads/.libs/libfftw3f_threads.a ../.libs/libfftw3f.a 
../libbench2/libbench2.a -lm -pthread
Making all in m4
make[2]: Nothing to be done for `all'.

any help



- Original Message 
From: Justin A. Lemkul 
To: Discussion list for GROMACS users 
Sent: Wed, December 30, 2009 9:54:42 PM
Subject: Re: [gmx-users] gromacs 4.06 binary for linux -redhat



venkat wrote:
> 
> 
> Hi 
> I am new to GROMACS, like to use it. I would be appreciate if anyone can 
> direct me to the right place where I could
> get the linux binary either x32/x64 - redhat.
> 

Binaries for newer versions probably haven't been made yet.  Your subject line 
points to version 4.0.6, which was a broken release anyway, and was replaced by 
version 4.0.7.

> I could not compile the source cause it is looking for FFTW etc.,. 

Then you should follow the step-by-step installation instructions.  FFT 
libraries are a prerequisite for Gromacs.  Please see the following:

http://www.gromacs.org/index.php?title=Download_%26_Installation/Installation_Instructions

-Justin

> thanks
> venkat
> 
> 
>  

-- 

Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin


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



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

[gmx-users] grompp segmentation error

[ram bio]

Dear Gromacs Users,

Iam following Drug/Enzyme complex solvation tutorial by John E.
Kerrigan, I am unable to execute the grompp step as per the tutorial,
the output of grompp command is as follows:

grompp -f minim.mdp -c trp_b4ion.gro -p trp.top -o trp_b4ion.tpr


   :-)  grompp  (-:

Back Off! I just backed up mdout.mdp to ./#mdout.mdp.11#
checking input for internal consistency...
processing topology...
Opening library file /usr/local/gromacs/share/gromacs/top/ffG53a6.itp
Opening library file /usr/local/gromacs/share/gromacs/top/ffG53a6nb.itp
Opening library file /usr/local/gromacs/share/gromacs/top/ffG53a6bon.itp
Opening library file /usr/local/gromacs/share/gromacs/top/ff_dum.itp
Segmentation fault

what i have done is as per the tutorial, that is
1) generated the drg.itp using prodrug beta
2) executed pdb2gmx using 4 that is ff53a6 ff
3) edit the drg.itp by removing the lines redundant as per trp.top
4) edit trp.gro by adding drg coordinates and chainging the numbers

please help me to overcome this error, for your convenience I have
attached the drg.itp, trp.top, trp.gro and trp_b4ion.gro files.

Thanks,

Ram
4 attachments —
--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/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/mailing_lists/users.php

Re: [gmx-users] PME node

[Justin A. Lemkul]

Vitaly V. Chaban wrote:

Hi,

What conditions could cause the following error?
=
Fatal error:
2 particles communicated to PME node 7 are more than a cell length out 
of the domain decomposition cell of their charge group   
=




Please check the wiki for such things, many errors are explained there:

http://www.gromacs.org/Documentation/Errors#X_particles_communicated_to_PME_node_Y_are_more_than_a_cell_length_out_of_the_domain_decomposition_cell_of_their_charge_group

With the same system, sometimes is appears, but sometimes everything 
goes smoothly (starting from the same start point).




Sounds like there is something unstable about the system, such that you're 
seeing sporadic crashes.


-Justin


--
Vitaly V. Chaban, Ph.D.
http://www-rmn.univer.kharkov.ua/chaban.html



--


Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin


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

Re: [gmx-users] LINCS WARNING max 597108032.000000 (between atoms 366 and 368) ?

[Tsjerk Wassenaar]

Hi,

So many posts and replies on a single issue, and still no exact
command lines, nor grompp output, nor gromacs version. Lin, please be
aware that such errors only make sense in the context of what you did.
You'll have to provide all information that might be related to it.
I'm pretty sure that your command lines will reveal the problem, and
otherwise the grompp output will.

If I have to make a guess, which is all one can do with the
information provided, I'd say the PBC is incorrect. Maybe you
converted to .pdb format at an intermediary step which is known to
remove the PBC in some gromacs versions.

Cheers,

Tsjerk

On Thu, Dec 31, 2009 at 2:47 AM, Mark Abraham  wrote:
> Chih-Ying Lin wrote:
>>
>>  Hi
>> what does the max max 597108032.00 (between atoms 366 and 368) mean?
>> is it the max force or max length of the system?
>> where is the max force listed?
>
> Don't know.
>
>> max 597108032.00 (between atoms 366 and 368) rms 26394490.00
>> bonds that rotated more than 30 degrees:
>> what does previous, current mean?
>> is it previous length and current length?
>
> Yeah probably. You need to understand what LINCS does to make some sense of
> this output.
>
> It doesn't really matter though. A well-behaved simulation will have none of
> these warnings. Atoms 366 and 368 are connected by a constraint and unhappy
> at the start of the simulation. In the output you quote, their distance has
> gone from under 1nm to a ridiculous number. Look at the region of those
> atoms in the starting configuration, and work out why. The most likely
> hypothesis is that some other atom is so close to them that they experienced
> a massive force, and had massive LJ.
>
> Mark
>
>> Thank you
>> Lin
>>    Step 0, time 0 (ps)  LINCS WARNING
>> relative constraint deviation after LINCS:
>> max 597108032.00 (between atoms 366 and 368) rms 26394490.00
>> bonds that rotated more than 30 degrees:
>>  *atom 1 atom 2  angle  previous, current, constraint length
>> *     26     39   52.0    0.1530   0.1699      0.1530     39     40   69.4
>>    0.1230   0.1423      0.1230       39     41   40.7    0.1330   0.1502
>>  0.1330     75     76   36.0    0.1250   0.1252      0.1250        133
>>  134   69.5    0.1530   0.1937      0.1530
>>    134    135   89.8    0.1470   0.2036      0.1470
>>    344    346   42.4    0.1470   0.2090      0.1470
>>    346    347   42.2    0.1530   0.2141      0.1530
>>    346    359   63.9    0.1530 26006.0332      0.1530
>>    359    360   56.9    0.1230 26006.0469      0.1230
>>    359    361   83.2    0.1330 82898.5859      0.1330
>>    361    362   77.5    0.1000 82845.7109      0.1000
>>    361    363   83.8    0.1470 398710.1875      0.1470
>>    363    364   89.3    0.1530 1909291.8750      0.1530
>>    363    369   85.2    0.1530 393002.8125      0.1530
>>    364    365   90.0    0.1508 31146174.      0.1530
>>    365    366   90.2    0.1544 66925512.      0.1530
>>    366    367   92.7    0.1301 73689816.      0.1250
>>    366    368   87.0    0.1305 74638504.      0.1250
>>    369    370   72.1    0.1230 65978.3203      0.1230
>>    369    371   72.6    0.1330 66864.2812      0.1330
>>    371    372   85.7    0.1000 10685.0596      0.1000
>>    371    373   61.0    0.1470 10685.1035      0.1470      373    374
>> 33.3    0.1530   0.1896      0.1530
>>    373    377   33.5    0.1530   0.1933      0.1530
>>    547    548   90.1    0.1089   0.1358      0.1090
>>    898    900   89.9    0.1530   0.4741      0.1530
>>
> --
> gmx-users mailing list    gmx-us...@gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at http://www.gromacs.org/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/mailing_lists/users.php
>



-- 
Tsjerk A. Wassenaar, Ph.D.

Computational Chemist
Medicinal Chemist
Neuropharmacologist
--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/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/mailing_lists/users.php

Re: [gmx-users] fix a group in truncated octahedron

[Mark Abraham]

lammps lammps wrote:

Sorry for this.

Thanks for your kind reply.  That is the answer of my question.

Actually, I only want to make sure whether the command of energygrp_excl 
has the ability not to calculate the force in the group.


The manual about energygrp_excl seems not talk about how to deal with 
the force. Maybe, I do not fully understand this command.



energygrp excl:
Pairs of energy groups for which all non-bonded interactions are 
excluded. An example: if

you have two energy groups Protein and SOL, specifying
energygrp excl = Protein Protein SOL SOL
would give only the non-bonded interactions between the protein and the 
solvent. This is
especially useful for speeding up energy calculations with mdrun -rerun 
and for excluding

interactions within frozen groups.
---


Energies and forces are evaluated very close together in "code execution 
time", since they are often functions of the same quantities and this is 
the most efficient way to calculate both. Thus they are regarded as 
somewhat synonymous in the documentation. Presumably the definition of 
energy groups early in the manual is clear on this point. Thus the use 
of energy group exclusions excludes the calculation of both energies and 
forces as appropriate. I believe it is impossible with GROMACS to 
evaluate a force without evaluating the corresponding energy, for what 
that is worth.


Mark


2009/12/28 mailto:chris.ne...@utoronto.ca>>

Hi Wende, please do not double post. If you are unsure if your post
got through, you can easily see the list at
http://lists.gromacs.org/pipermail/gmx-users/2009-December/date.html.

You did not put units beside 40, so I suppose that you mean 40 A,
whereas gromacs uses nm.

1. Make a box with one sodium ion and then editconf -c -d 4 -bt
dodecahedron. This will give you your box, then you can put your
lattice inside it. With properly selected atom in an index file, you
could easily do this in one step based on the commands above (plus
the index group with a single central atom).

2. This is clearly laid out in the manual under energygrp_excl. You
should familiarize yourself with the online .mdp file options at
http://manual.gromacs.org/current/online/mdp_opt.html which will
help you find such things.

Chris.

-- original message --

Hi GMX users,

I want to fix a group in a truncate octahedron. How can I dealt with the
questions below,

1. I hope the box corresponds to an inscribed circle of cubic of size
40*40*40, how to calculate the box vectors?

2. One spherical rigid body consists of  face-center cubic lattices
is fixed
in the center of the box. I do not want to calculate the force and
energy
between the paritcles of this rigid body, so that no matter how
large force
between them shoud not blow up the rigid body.   How can I do this?

Thanks in advance.
-- 
wende


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


http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before
posting!
Please don't post (un)subscribe requests to the list. Use thewww
interface or send it to gmx-users-requ...@gromacs.org
.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php




--
wende


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

[gmx-users] PME node

[Vitaly V. Chaban]

Hi,

What conditions could cause the following error?
=
Fatal error:
2 particles communicated to PME node 7 are more than a cell length out of
the domain decomposition cell of their charge group
=

With the same system, sometimes is appears, but sometimes everything goes
smoothly (starting from the same start point).

-- 
Vitaly V. Chaban, Ph.D.
http://www-rmn.univer.kharkov.ua/chaban.html
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/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/mailing_lists/users.php

Re: [gmx-users] fix a group in truncated octahedron

[lammps lammps]

Sorry for this.

Thanks for your kind reply.  That is the answer of my question.

Actually, I only want to make sure whether the command of energygrp_excl has
the ability not to calculate the force in the group.

The manual about energygrp_excl seems not talk about how to deal with the
force. Maybe, I do not fully understand this command.


energygrp excl:
Pairs of energy groups for which all non-bonded interactions are excluded.
An example: if
you have two energy groups Protein and SOL, specifying
energygrp excl = Protein Protein SOL SOL
would give only the non-bonded interactions between the protein and the
solvent. This is
especially useful for speeding up energy calculations with mdrun -rerun and
for excluding
interactions within frozen groups.
---

Happy new year.


2009/12/28 

> Hi Wende, please do not double post. If you are unsure if your post got
> through, you can easily see the list at
> http://lists.gromacs.org/pipermail/gmx-users/2009-December/date.html.
>
> You did not put units beside 40, so I suppose that you mean 40 A, whereas
> gromacs uses nm.
>
> 1. Make a box with one sodium ion and then editconf -c -d 4 -bt
> dodecahedron. This will give you your box, then you can put your lattice
> inside it. With properly selected atom in an index file, you could easily do
> this in one step based on the commands above (plus the index group with a
> single central atom).
>
> 2. This is clearly laid out in the manual under energygrp_excl. You should
> familiarize yourself with the online .mdp file options at
> http://manual.gromacs.org/current/online/mdp_opt.html which will help you
> find such things.
>
> Chris.
>
> -- original message --
>
> Hi GMX users,
>
> I want to fix a group in a truncate octahedron. How can I dealt with the
> questions below,
>
> 1. I hope the box corresponds to an inscribed circle of cubic of size
> 40*40*40, how to calculate the box vectors?
>
> 2. One spherical rigid body consists of  face-center cubic lattices is
> fixed
> in the center of the box. I do not want to calculate the force and energy
> between the paritcles of this rigid body, so that no matter how large force
> between them shoud not blow up the rigid body.   How can I do this?
>
> Thanks in advance.
> --
> wende
>
> --
> gmx-users mailing listgmx-users@gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at http://www.gromacs.org/search before posting!
> Please don't post (un)subscribe requests to the list. Use thewww interface
> or send it to gmx-users-requ...@gromacs.org.
> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
>



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