[gmx-users] IMPLICIT SOLVENT IN AMBER

[Yulian Gavrilov]

Dear, all
I just begin to work in gromacs.
I would like to run on a protein with amber99.
Is there someone here that successfully did a protein simulation in
GROMACS with implicit solvent and willing to explain the procedure and
share the parameters used (especially force field).

In mdout.mdp (gromacs 4.0.5) I found this lines. Can I add them to md.mdp?
How to change this parameters correctly?
What changes should be done on the previous steps? I mean, how to start a
simulation with implicit solvent model from the very beginning?
Sorry for primitive question, but I did not found any useful information
about it for the begginers.

; IMPLICIT SOLVENT ALGORITHM
implicit_solvent = No

; GENERALIZED BORN ELECTROSTATICS
; Algorithm for calculating Born radii
gb_algorithm = Still
; Frequency of calculating the Born radii inside rlist
nstgbradii   = 1
; Cutoff for Born radii calculation; the contribution from atoms
; between rlist and rgbradii is updated every nstlist steps
rgbradii = 2
; Dielectric coefficient of the implicit solvent
gb_epsilon_solvent   = 80
; Salt concentration in M for Generalized Born models
gb_saltconc  = 0
; Scaling factors used in the OBC GB model. Default values are OBC(II)
gb_obc_alpha = 1
gb_obc_beta  = 0.8
gb_obc_gamma = 4.85
; Surface tension (kJ/mol/nm^2) for the SA (nonpolar surface) part of GBSA
; The default value (2.092) corresponds to 0.005 kcal/mol/Angstrom^2.
sa_surface_tension   = 2.092

-- 

Sincerely,

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

Re: [gmx-users] IMPLICIT SOLVENT IN AMBER

[Per Larsson]

Hi!

Starting an implicit solvent simulation works just as starting a "normal", 
explicit solvent simulation, except there is no solvent molecules.
You should use version 4.5.3 for this though (4.0.5 will not work). 

Then you specify in the mdp-file implicit_solvent = GBSA and use pdb2gmx, 
grompp, mdrun etc... as you otherwise would do.
The choice of the Born radii model is set by gb_algorithm = {Still,HCT,OBC} and 
the non-polar solvation is calculated using sa_algorithm=Ace-approximation.

Cheers
/Per

10 mar 2011 kl. 10.10 skrev Yulian Gavrilov:

> Dear, all
> I just begin to work in gromacs.
> I would like to run on a protein with amber99. 
> Is there someone here that successfully did a protein simulation in
> GROMACS with implicit solvent and willing to explain the procedure and
> share the parameters used (especially force field). 
> 
> In mdout.mdp (gromacs 4.0.5) I found this lines. Can I add them to md.mdp? 
> How to change this parameters correctly? 
> What changes should be done on the previous steps? I mean, how to start a 
> simulation with implicit solvent model from the very beginning?
> Sorry for primitive question, but I did not found any useful information 
> about it for the begginers.
> 
> ; IMPLICIT SOLVENT ALGORITHM
> implicit_solvent = No
> 
> ; GENERALIZED BORN ELECTROSTATICS
> ; Algorithm for calculating Born radii
> gb_algorithm = Still
> ; Frequency of calculating the Born radii inside rlist
> nstgbradii   = 1
> ; Cutoff for Born radii calculation; the contribution from atoms
> ; between rlist and rgbradii is updated every nstlist steps
> rgbradii = 2
> ; Dielectric coefficient of the implicit solvent
> gb_epsilon_solvent   = 80
> ; Salt concentration in M for Generalized Born models
> gb_saltconc  = 0
> ; Scaling factors used in the OBC GB model. Default values are OBC(II)
> gb_obc_alpha = 1
> gb_obc_beta  = 0.8
> gb_obc_gamma = 4.85
> ; Surface tension (kJ/mol/nm^2) for the SA (nonpolar surface) part of GBSA
> ; The default value (2.092) corresponds to 0.005 kcal/mol/Angstrom^2.
> sa_surface_tension   = 2.092
> 
> -- 
> Sincerely,
> Yulian Gavrilov
> 
> -- 
> gmx-users mailing listgmx-users@gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at 
> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> Please don't post (un)subscribe requests to the list. Use the 
> www interface or send it to gmx-users-requ...@gromacs.org.
> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

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

Re: [gmx-users] IMPLICIT SOLVENT IN AMBER

[Yulian Gavrilov]

Thanks!

If I understand you correctly, I need to do this (?):

   1.

   pdb2gmx
   2.

   Adding ions (if I have no SOL, what is better to choose on this step?)
   3.

   Minimization with mdp file, that includes these lines:

   implicit_solvent = GBSA

   gb_algorithm = {Still,HCT,OBC}

   sa_algorithm=Ace-approximation
   4.

   Equilibration (nvt, npt) and MD also with these lines in mdp files.



2011/3/10 Per Larsson 

> Hi!
>
> Starting an implicit solvent simulation works just as starting a "normal",
> explicit solvent simulation, except there is no solvent molecules.
> You should use version 4.5.3 for this though (4.0.5 will not work).
>
> Then you specify in the mdp-file implicit_solvent = GBSA and use pdb2gmx,
> grompp, mdrun etc... as you otherwise would do.
> The choice of the Born radii model is set by gb_algorithm = {Still,HCT,OBC}
> and the non-polar solvation is calculated using
> sa_algorithm=Ace-approximation.
>
> Cheers
> /Per
>
> 10 mar 2011 kl. 10.10 skrev Yulian Gavrilov:
>
> Dear, all
> I just begin to work in gromacs.
> I would like to run on a protein with amber99.
> Is there someone here that successfully did a protein simulation in
> GROMACS with implicit solvent and willing to explain the procedure and
> share the parameters used (especially force field).
>
> In mdout.mdp (gromacs 4.0.5) I found this lines. Can I add them to md.mdp?
> How to change this parameters correctly?
> What changes should be done on the previous steps? I mean, how to start a
> simulation with implicit solvent model from the very beginning?
> Sorry for primitive question, but I did not found any useful information
> about it for the begginers.
>
> ; IMPLICIT SOLVENT ALGORITHM
> implicit_solvent = No
>
> ; GENERALIZED BORN ELECTROSTATICS
> ; Algorithm for calculating Born radii
> gb_algorithm = Still
> ; Frequency of calculating the Born radii inside rlist
> nstgbradii   = 1
> ; Cutoff for Born radii calculation; the contribution from atoms
> ; between rlist and rgbradii is updated every nstlist steps
> rgbradii = 2
> ; Dielectric coefficient of the implicit solvent
> gb_epsilon_solvent   = 80
> ; Salt concentration in M for Generalized Born models
> gb_saltconc  = 0
> ; Scaling factors used in the OBC GB model. Default values are OBC(II)
> gb_obc_alpha = 1
> gb_obc_beta  = 0.8
> gb_obc_gamma = 4.85
> ; Surface tension (kJ/mol/nm^2) for the SA (nonpolar surface) part of GBSA
> ; The default value (2.092) corresponds to 0.005 kcal/mol/Angstrom^2.
> sa_surface_tension   = 2.092
>
> --
>
> Sincerely,
>
> Yulian Gavrilov
>
>  --
> gmx-users mailing listgmx-users@gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-users-requ...@gromacs.org.
> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
>
>
> --
> gmx-users mailing listgmx-users@gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-users-requ...@gromacs.org.
> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>



-- 

Sincerely,

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

Re: [gmx-users] IMPLICIT SOLVENT IN AMBER

[Yulian Gavrilov]

Thanks again!
Don't you know how to make a total charge = 0 in this case, if implicit salt
concentration is not implemented currently? Or it is not critically?

2011/3/10 Per Larsson 

> Hi!
>
> Yes, except that in point 2, I'm not sure about the effects of explicit
> ions in an implicit solvent.
> Do deal with that properly one should use an implicit salt concentration,
> but that is not implemented currently.
> The choice of water-model with pdb2gmx is not important. You can choose
> 'None' here.
>
> Cheers
> /Per
>
> 10 mar 2011 kl. 10.39 skrev Yulian Gavrilov:
>
> Thanks!
>
> If I understand you correctly, I need to do this (?):
>
>1.
>
>pdb2gmx
>2.
>
>Adding ions (if I have no SOL, what is better to choose on this step?)
>3.
>
>Minimization with mdp file, that includes these lines:
>
>implicit_solvent = GBSA
>
>gb_algorithm = {Still,HCT,OBC}
>
>sa_algorithm=Ace-approximation
>4.
>
>Equilibration (nvt, npt) and MD also with these lines in mdp files.
>
>
>
> 2011/3/10 Per Larsson 
>
>> Hi!
>>
>> Starting an implicit solvent simulation works just as starting a "normal",
>> explicit solvent simulation, except there is no solvent molecules.
>> You should use version 4.5.3 for this though (4.0.5 will not work).
>>
>> Then you specify in the mdp-file implicit_solvent = GBSA and use pdb2gmx,
>> grompp, mdrun etc... as you otherwise would do.
>> The choice of the Born radii model is set by gb_algorithm =
>> {Still,HCT,OBC} and the non-polar solvation is calculated using
>> sa_algorithm=Ace-approximation.
>>
>> Cheers
>> /Per
>>
>> 10 mar 2011 kl. 10.10 skrev Yulian Gavrilov:
>>
>> Dear, all
>> I just begin to work in gromacs.
>> I would like to run on a protein with amber99.
>> Is there someone here that successfully did a protein simulation in
>> GROMACS with implicit solvent and willing to explain the procedure and
>> share the parameters used (especially force field).
>>
>> In mdout.mdp (gromacs 4.0.5) I found this lines. Can I add them to md.mdp?
>> How to change this parameters correctly?
>> What changes should be done on the previous steps? I mean, how to start a
>> simulation with implicit solvent model from the very beginning?
>> Sorry for primitive question, but I did not found any useful information
>> about it for the begginers.
>>
>> ; IMPLICIT SOLVENT ALGORITHM
>> implicit_solvent = No
>>
>> ; GENERALIZED BORN ELECTROSTATICS
>> ; Algorithm for calculating Born radii
>> gb_algorithm = Still
>> ; Frequency of calculating the Born radii inside rlist
>> nstgbradii   = 1
>> ; Cutoff for Born radii calculation; the contribution from atoms
>> ; between rlist and rgbradii is updated every nstlist steps
>> rgbradii = 2
>> ; Dielectric coefficient of the implicit solvent
>> gb_epsilon_solvent   = 80
>> ; Salt concentration in M for Generalized Born models
>> gb_saltconc  = 0
>> ; Scaling factors used in the OBC GB model. Default values are OBC(II)
>> gb_obc_alpha = 1
>> gb_obc_beta  = 0.8
>> gb_obc_gamma = 4.85
>> ; Surface tension (kJ/mol/nm^2) for the SA (nonpolar surface) part of GBSA
>> ; The default value (2.092) corresponds to 0.005 kcal/mol/Angstrom^2.
>> sa_surface_tension   = 2.092
>>
>> --
>>
>> Sincerely,
>>
>> Yulian Gavrilov
>>
>>  --
>> gmx-users mailing listgmx-users@gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-users
>> Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
>> Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-users-requ...@gromacs.org.
>> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>>
>>
>> --
>> gmx-users mailing listgmx-users@gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-users
>> Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
>> Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-users-requ...@gromacs.org.
>> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>
>
>
> --
>
> Sincerely,
>
> Yulian Gavrilov
>
>
>


-- 

Sincerely,

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

Re: [gmx-users] IMPLICIT SOLVENT IN AMBER

[Per Larsson]

Hi!

The answer is that I do not now critical it is.
I have seen some papers that seem to hint at it not being overly critical, but, 
again, life does not come at a net charge.
You'd have to see for yourself in your system, given the observables that are 
important I suppose.
Possibly we can implement this in the future, as there indeed seems to be some 
interest in it, but that is not a task I can deal with currently.

/Per


10 mar 2011 kl. 10.52 skrev Yulian Gavrilov:

> Thanks again!
> Don't you know how to make a total charge = 0 in this case, if implicit salt 
> concentration is not implemented currently? Or it is not critically? 
> 
> 2011/3/10 Per Larsson 
> Hi!
> 
> Yes, except that in point 2, I'm not sure about the effects of explicit ions 
> in an implicit solvent. 
> Do deal with that properly one should use an implicit salt concentration, but 
> that is not implemented currently. 
> The choice of water-model with pdb2gmx is not important. You can choose 
> 'None' here.
> 
> Cheers
> /Per
> 
> 10 mar 2011 kl. 10.39 skrev Yulian Gavrilov:
> 
>> Thanks!
>> If I understand you correctly, I need to do this (?):
>> pdb2gmx
>> Adding ions (if I have no SOL, what is better to choose on this step?)
>> Minimization with mdp file, that includes these lines:
>> implicit_solvent = GBSA
>> gb_algorithm = {Still,HCT,OBC}
>> sa_algorithm=Ace-approximation
>> Equilibration (nvt, npt) and MD also with these lines in mdp files.
>> 
>> 
>> 2011/3/10 Per Larsson 
>> Hi!
>> 
>> Starting an implicit solvent simulation works just as starting a "normal", 
>> explicit solvent simulation, except there is no solvent molecules.
>> You should use version 4.5.3 for this though (4.0.5 will not work). 
>> 
>> Then you specify in the mdp-file implicit_solvent = GBSA and use pdb2gmx, 
>> grompp, mdrun etc... as you otherwise would do.
>> The choice of the Born radii model is set by gb_algorithm = {Still,HCT,OBC} 
>> and the non-polar solvation is calculated using 
>> sa_algorithm=Ace-approximation.
>> 
>> Cheers
>> /Per
>> 
>> 10 mar 2011 kl. 10.10 skrev Yulian Gavrilov:
>> 
>>> Dear, all
>>> I just begin to work in gromacs.
>>> I would like to run on a protein with amber99. 
>>> Is there someone here that successfully did a protein simulation in
>>> GROMACS with implicit solvent and willing to explain the procedure and
>>> share the parameters used (especially force field). 
>>> 
>>> In mdout.mdp (gromacs 4.0.5) I found this lines. Can I add them to md.mdp? 
>>> How to change this parameters correctly? 
>>> What changes should be done on the previous steps? I mean, how to start a 
>>> simulation with implicit solvent model from the very beginning?
>>> Sorry for primitive question, but I did not found any useful information 
>>> about it for the begginers.
>>> 
>>> ; IMPLICIT SOLVENT ALGORITHM
>>> implicit_solvent = No
>>> 
>>> ; GENERALIZED BORN ELECTROSTATICS
>>> ; Algorithm for calculating Born radii
>>> gb_algorithm = Still
>>> ; Frequency of calculating the Born radii inside rlist
>>> nstgbradii   = 1
>>> ; Cutoff for Born radii calculation; the contribution from atoms
>>> ; between rlist and rgbradii is updated every nstlist steps
>>> rgbradii = 2
>>> ; Dielectric coefficient of the implicit solvent
>>> gb_epsilon_solvent   = 80
>>> ; Salt concentration in M for Generalized Born models
>>> gb_saltconc  = 0
>>> ; Scaling factors used in the OBC GB model. Default values are OBC(II)
>>> gb_obc_alpha = 1
>>> gb_obc_beta  = 0.8
>>> gb_obc_gamma = 4.85
>>> ; Surface tension (kJ/mol/nm^2) for the SA (nonpolar surface) part of GBSA
>>> ; The default value (2.092) corresponds to 0.005 kcal/mol/Angstrom^2.
>>> sa_surface_tension   = 2.092
>>> 
>>> -- 
>>> Sincerely,
>>> Yulian Gavrilov
>>> 
>>> -- 
>>> gmx-users mailing listgmx-users@gromacs.org
>>> http://lists.gromacs.org/mailman/listinfo/gmx-users
>>> Please search the archive at 
>>> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
>>> Please don't post (un)subscribe requests to the list. Use the 
>>> www interface or send it to gmx-users-requ...@gromacs.org.
>>> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> 
>> 
>> --
>> gmx-users mailing listgmx-users@gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-users
>> Please search the archive at 
>> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
>> Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-users-requ...@gromacs.org.
>> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> 
>> 
>> 
>> -- 
>> Sincerely,
>> Yulian Gavrilov
>> 
> 
> 
> 
> 
> -- 
> Sincerely,
> Yulian Gavrilov
> 

-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don'

[gmx-users] disulfide bridge broken during EM

[Anna Marabotti]

Dear all,
I have a PDB file of a protein that is in dimeric form, with an INTERchain
disulphide bridge. However, in their paper the crystallographers are not
sure if this is a true dimeric form or a cyrstallographic artefact (PQS
server suggests it is a true dimeric form, but with low confidence). I'm
preparing this protein to do MD simulations in water, so I used pdb2gmx,
editconf, genbox, genion..and all worked properly (no error messages). Then
I launched grompp+mdrun to do a mild minimization before MD: all worked
properly with no error messages, but when I had a look at the final .gro
file, I saw that the disulphide bridge was broken (before this step, it was
present). Looking at the trajectory, I found that the bridge broke at the
first step of the minimization. However, I did not have any error message,
the minimization worked regularly.
I would like to know if my starting structure is a real dimeric structure,
or not, therefore I would like to know if the disulphide bridge broke
because it is only an artefact, or not. Do I have to add some special
constraints to the topology and/or .mdp file in order to preserve the
disulphide bridge in "normal" simulations, or not? I had a look in the
gmx-users list, but I only see suggestions to introduce a new disulphide
bridge (and the messages seem quite old, probably referred to the Gromacs 3
version, whereas I'm currently using version 4.0.3). In a very old message
(2001) there is the statement "pdb2gmx can *not* make inter-molecular bonds"
however, in this case, the bond is already present in the crystal and is
kept in all phases until the minimization. I tried to use pdb2gmx -ss in
order to set interactively the SS bridge selection, but nothing happened:
the program does not ask me any prompt. Any suggestions?
Many thanks and best regards
Anna Marabotti
 
PS BTW: often when I'm searching in the gmx-users list I see the suggestions
to some links (for example in the message in
http://lists.gromacs.org/pipermail/gmx-users/2008-March/032662.html Mark
Abraham suggests to explore http://wiki.gromacs.org/index.php/specbond.dat
but when I click on the link, I am redirected to the www.gromacs.org
website. Even if I copy the link directly in a new browser window, I cannot
see the original link. Why?
 
__
Anna Marabotti, Ph.D.
Laboratory of Bioinformatics and Computational Biology
Institute of Food Science - CNR
Via Roma, 64
83100 Avellino
Phone: +39 0825 299651
Fax: +39 0825 781585
E-mail: amarabo...@isa.cnr.it
Skype account: annam1972
Web site: http://bioinformatica.isa.cnr.it/anna/anna.htm
 
"When a man with a gun meets a man with a pen, the man with the gun is a
dead man"
 
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

Re: [gmx-users] disulfide bridge broken during EM

[Justin A. Lemkul]

Anna Marabotti wrote:

Dear all,
I have a PDB file of a protein that is in dimeric form, with an 
INTERchain disulphide bridge. However, in their paper the 
crystallographers are not sure if this is a true dimeric form or a 
cyrstallographic artefact (PQS server suggests it is a true dimeric 
form, but with low confidence). I'm preparing this protein to do MD 
simulations in water, so I used pdb2gmx, editconf, genbox, genion..and 
all worked properly (no error messages). Then I launched grompp+mdrun to 
do a mild minimization before MD: all worked properly with no error 
messages, but when I had a look at the final .gro file, I saw that the 
disulphide bridge was broken (before this step, it was present). Looking 
at the trajectory, I found that the bridge broke at the first step of 
the minimization. However, I did not have any error message, the 
minimization worked regularly.
I would like to know if my starting structure is a real dimeric 
structure, or not, therefore I would like to know if the disulphide 
bridge broke because it is only an artefact, or not. Do I have to add 
some special constraints to the topology and/or .mdp file in order to 
preserve the disulphide bridge in "normal" simulations, or not? I had a 
look in the gmx-users list, but I only see suggestions to introduce a 
new disulphide bridge (and the messages seem quite old, probably 
referred to the Gromacs 3 version, whereas I'm currently using version 
4.0.3). In a very old message (2001) there is the statement "pdb2gmx can 
*not* make inter-molecular bonds" however, in this case, the bond is 
already present in the crystal and is kept in all phases until the 
minimization. I tried to use pdb2gmx -ss in order to set interactively 
the SS bridge selection, but nothing happened: the program does not ask 
me any prompt. Any suggestions?


Bonds do not break and form during EM or MD, which must obey classical 
mechanics.  If you saw a "bond" there, it was just an effect of the 
visualization software.  The true answer is if there is a bond written in the 
[bonds] section of your topology.  While true that Gromacs cannot make bonds 
between molecules, you can use pdb2gmx -merge (-chainsep in version 4.5 and up) 
to make multiple molecules part of the same [moleculetype].  If you have 
individual chain topologies from pdb2gmx, then there was never a bond there.  If 
the two atoms fall outside the tolerance range specified in specbond.dat, no 
bond will have been created.



Many thanks and best regards
Anna Marabotti
 
PS BTW: often when I'm searching in the gmx-users list I see the 
suggestions to some links (for example in the message in 
http://lists.gromacs.org/pipermail/gmx-users/2008-March/032662.html Mark 
Abraham suggests to explore 
http://wiki.gromacs.org/index.php/specbond.dat but when I click on the 
link, I am redirected to the www.gromacs.org  
website. Even if I copy the link directly in a new browser window, I 
cannot see the original link. Why?
 


The website has undergone several major overhauls since 2008.  You can search 
the current Gromacs website for specbond.dat and retrieve:


http://www.gromacs.org/Documentation/File_Formats/specbond.dat

-Justin


__
Anna Marabotti, Ph.D.
Laboratory of Bioinformatics and Computational Biology
Institute of Food Science - CNR
Via Roma, 64
83100 Avellino
Phone: +39 0825 299651
Fax: +39 0825 781585
E-mail: amarabo...@isa.cnr.it 
Skype account: annam1972
Web site: http://bioinformatica.isa.cnr.it/anna/anna.htm
 
"When a man with a gun meets a man with a pen, the man with the gun is a 
dead man"
 



--


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/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

[gmx-users] RE: g_energy inconsistent results

[Ehud Schreiber]

Dear Mark Abraham (and anyone else interested),

I have implemented your suggestion, changing in the status.mdp file to
integrator = md and adding continuation = yes (this is the new name of
the unconstrained_start parameter); however, this did not have any
effect - the energy remained as before, different from the one obtained
during the minimization.

I have then encountered another (perhaps related) issue.
I thought that the problem may arise from the combination of the
generalized Born and all-vs-all settings.
I have therefore changed in the minimization to rgbradii = rlist =
rcoulomb = rvdw = 100 (from = 0).
As my system is far smaller than 100 nm, I expected these parameters to
provide also an all-vs-all setting (even if non-optimized).
Nevertheless, the resulting structure differed from the previous
minimized one (rmsd ~ 0.005 nm, delta energy ~ a few kJ/mol). Can this
arise from rounding effects only or does this signify a problem? I'm not
sure what rgbradii does, but the manual states that it must equal rlist.
In addition, changing also status.mdp to have all radii = 100 and
running on the new optimized output again does not yield the same energy
as during the optimization. 

Does all of this make any sense to you?

Thank,
Ehud.


>Message: 6
>Date: Tue, 08 Mar 2011 23:37:12 +1100
>From: Mark Abraham 
>Subject: Re: [gmx-users] g_energy inconsistent results
>To: Discussion list for GROMACS users 
>Message-ID: <4d7622f8.7050...@anu.edu.au>
>Content-Type: text/plain; charset="iso-8859-1"
>
>On 8/03/2011 9:44 PM, Ehud Schreiber wrote:
>>
>> Dear Gromacs users,
>>
>> I am working with version 4.5.3, using the opls-aa forcefield in an
implicit solvent, all-vs-all setting:
>>
>> pdb2gmx -ter -ff oplsaa -water none -f file.pdb
>>
>> I am energy-minimizing structures in 3 stages (steep, cg and l-bfgs).

>> The last stage is the following:
>>
>> grompp -f em3.mdp -p topol.top -c em2.gro -t em2.trr -o em3.tpr -po
em3.mdout.mdp
>> mdrun -nice 0 -v -pd -deffnm em3
>> g_energy -s em3.tpr -f em3.edr -o em3.potential_energy.xvg
>>
>> where the mdp file is:
>>
>> ;;; em3.mdp ;;;
>> integrator   = l-bfgs
>> nsteps   = 5
>> implicit_solvent = GBSA
>> gb_algorithm = Still
>> sa_algorithm = Ace-approximation
>> pbc  = no
>> rgbradii = 0
>> ns_type  = simple
>> nstlist  = 0
>> rlist= 0
>> coulombtype  = cut-off
>> rcoulomb = 0
>> vdwtype  = cut-off
>> rvdw = 0
>> nstcalcenergy= 1
>> nstenergy= 1000
>> emtol= 0
>> ;;;
>>
>> The last line in the em3.potential_energy.xvg file should give the
(potential) energy of the minimized structure em3.gro .
>>
>> I wish also to compute the potential energy of .gro files in general,
not necessarily obtained from a simulation.
>> For that, I prepared a .mdp file for a degenerate energy
minimization, having 0 steps, designed just to give the status of the
file:

> Zero-step EM does not calculate the initial energy because it is not
useful for gradient-based energy minimization.
> I don't recall the details, but perhaps the first EM step is reported
as step zero.
> Instead, you should use zero-step MD (with unconstrained_start = yes),
or (for multiple single points) mdrun -rerun.

> You will not necessarily reproduce the g_energy energies with
anything, because the energy is dependent on the state of the neighbour
lists.
> If nstenergy is a multiple of nstlist, then those energies should be
fairly reproducible.

> I have updated the grompp source to provide a note to the user to warn
against zero-step EM.

> Mark

>> ;;; status.mdp ;;;
>> integrator   = l-bfgs
>> nsteps   = 0
>> implicit_solvent = GBSA
>> gb_algorithm = Still
>> sa_algorithm = Ace-approximation
>> pbc  = no
>> rgbradii = 0
>> ns_type  = simple
>> nstlist  = 0
>> rlist= 0
>> coulombtype  = cut-off
>> rcoulomb = 0
>> vdwtype  = cut-off
>> rvdw = 0
>> nstcalcenergy= 1
>> nstenergy= 1
>> emtol= 0
>> ;;;
>>
>> The only changes from the former .mdp file are in nsteps and
nstenergy.
>>
>> However, when I run this potential energy status run on em3.gro
itself,
>>
>> grompp -f status.mdp -p topol.top -c em3.gro -o status.tpr -po
status.mdout.mdp
>> mdrun -nice 0 -v -pd -deffnm status
>> g_energy -s status.tpr -f status.edr -o status.potential_energy.xvg
>>
>> and look at the (single) energy line in status.potential_energy.xvg I
find that the energy does not agree with the one obtained during
minimization (it's higher by some tens of kJ/mol).
>>
>> What am I doing wrong? How should one reliably find the energy of a
given .gro file?
>>
>> Moreover, when changing in status

[gmx-users] Re: disulfide bridge broken during EM

[Anna Marabotti]

 Dear Justin,
thank you very much. Yes for sure bonds do not "break" during EM (I should
have better said "disappear"), that's why it looked strange to me. In any
case, I will do the check: if this bond will fall outside specifications in
specbond.dat I will conclude that it is only a crystallographic artefact
(and I will be very happy because in that way I can use only the monomer of
the protein to do simulations...)
 
Anna

-Messaggio originale-
Da: gmx-users-boun...@gromacs.org [mailto:gmx-users-boun...@gromacs.org] Per
conto di gmx-users-requ...@gromacs.org
Inviato: giovedì 10 marzo 2011 14.15
A: gmx-users@gromacs.org
Oggetto: gmx-users Digest, Vol 83, Issue 66

Message: 3
Date: Thu, 10 Mar 2011 08:13:06 -0500
From: "Justin A. Lemkul" 
Subject: Re: [gmx-users] disulfide bridge broken during EM
To: Discussion list for GROMACS users 
Message-ID: <4d78ce62.2010...@vt.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed



Anna Marabotti wrote:
> Dear all,
> I have a PDB file of a protein that is in dimeric form, with an 
> INTERchain disulphide bridge. However, in their paper the 
> crystallographers are not sure if this is a true dimeric form or a 
> cyrstallographic artefact (PQS server suggests it is a true dimeric 
> form, but with low confidence). I'm preparing this protein to do MD 
> simulations in water, so I used pdb2gmx, editconf, genbox, genion..and 
> all worked properly (no error messages). Then I launched grompp+mdrun to 
> do a mild minimization before MD: all worked properly with no error 
> messages, but when I had a look at the final .gro file, I saw that the 
> disulphide bridge was broken (before this step, it was present). Looking 
> at the trajectory, I found that the bridge broke at the first step of 
> the minimization. However, I did not have any error message, the 
> minimization worked regularly.
> I would like to know if my starting structure is a real dimeric 
> structure, or not, therefore I would like to know if the disulphide 
> bridge broke because it is only an artefact, or not. Do I have to add 
> some special constraints to the topology and/or .mdp file in order to 
> preserve the disulphide bridge in "normal" simulations, or not? I had a 
> look in the gmx-users list, but I only see suggestions to introduce a 
> new disulphide bridge (and the messages seem quite old, probably 
> referred to the Gromacs 3 version, whereas I'm currently using version 
> 4.0.3). In a very old message (2001) there is the statement "pdb2gmx can 
> *not* make inter-molecular bonds" however, in this case, the bond is 
> already present in the crystal and is kept in all phases until the 
> minimization. I tried to use pdb2gmx -ss in order to set interactively 
> the SS bridge selection, but nothing happened: the program does not ask 
> me any prompt. Any suggestions?

Bonds do not break and form during EM or MD, which must obey classical 
mechanics.  If you saw a "bond" there, it was just an effect of the 
visualization software.  The true answer is if there is a bond written in
the 
[bonds] section of your topology.  While true that Gromacs cannot make bonds

between molecules, you can use pdb2gmx -merge (-chainsep in version 4.5 and
up) 
to make multiple molecules part of the same [moleculetype].  If you have 
individual chain topologies from pdb2gmx, then there was never a bond there.
If 
the two atoms fall outside the tolerance range specified in specbond.dat, no

bond will have been created.

> Many thanks and best regards
> Anna Marabotti
>  
> PS BTW: often when I'm searching in the gmx-users list I see the 
> suggestions to some links (for example in the message in 
> http://lists.gromacs.org/pipermail/gmx-users/2008-March/032662.html Mark 
> Abraham suggests to explore 
> http://wiki.gromacs.org/index.php/specbond.dat but when I click on the 
> link, I am redirected to the www.gromacs.org  
> website. Even if I copy the link directly in a new browser window, I 
> cannot see the original link. Why?
>  

The website has undergone several major overhauls since 2008.  You can
search 
the current Gromacs website for specbond.dat and retrieve:

http://www.gromacs.org/Documentation/File_Formats/specbond.dat

-Justin

> __
> Anna Marabotti, Ph.D.
> Laboratory of Bioinformatics and Computational Biology
> Institute of Food Science - CNR
> Via Roma, 64
> 83100 Avellino
> Phone: +39 0825 299651
> Fax: +39 0825 781585
> E-mail: amarabo...@isa.cnr.it 
> Skype account: annam1972
> Web site: http://bioinformatica.isa.cnr.it/anna/anna.htm
>  
> "When a man with a gun meets a man with a pen, the man with the gun is a 
> dead man"
>  
> 

-- 


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.bevanla

Re: [gmx-users] Re: disulfide bridge broken during EM

[Justin A. Lemkul]

Anna Marabotti wrote:

 Dear Justin,
thank you very much. Yes for sure bonds do not "break" during EM (I should
have better said "disappear"), that's why it looked strange to me. In any
case, I will do the check: if this bond will fall outside specifications in
specbond.dat I will conclude that it is only a crystallographic artefact
(and I will be very happy because in that way I can use only the monomer of
the protein to do simulations...)


I would not consider the parameters in specbond.dat to be definitive proof of a 
non-existent disulfide.  If the distance between the S atoms is considerably 
more than 0.2 nm (with 0.205 nm being "average" for a disulfide), then you may 
have some justification.  But if the rationale is "Gromacs didn't think there 
should be a disulfide, so that's reality," I'd imagine most reviewers would be 
extremely skeptical.


-Justin

 
Anna


-Messaggio originale-
Da: gmx-users-boun...@gromacs.org [mailto:gmx-users-boun...@gromacs.org] Per
conto di gmx-users-requ...@gromacs.org
Inviato: giovedì 10 marzo 2011 14.15
A: gmx-users@gromacs.org
Oggetto: gmx-users Digest, Vol 83, Issue 66

Message: 3
Date: Thu, 10 Mar 2011 08:13:06 -0500
From: "Justin A. Lemkul" 
Subject: Re: [gmx-users] disulfide bridge broken during EM
To: Discussion list for GROMACS users 
Message-ID: <4d78ce62.2010...@vt.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed



Anna Marabotti wrote:

Dear all,
I have a PDB file of a protein that is in dimeric form, with an 
INTERchain disulphide bridge. However, in their paper the 
crystallographers are not sure if this is a true dimeric form or a 
cyrstallographic artefact (PQS server suggests it is a true dimeric 
form, but with low confidence). I'm preparing this protein to do MD 
simulations in water, so I used pdb2gmx, editconf, genbox, genion..and 
all worked properly (no error messages). Then I launched grompp+mdrun to 
do a mild minimization before MD: all worked properly with no error 
messages, but when I had a look at the final .gro file, I saw that the 
disulphide bridge was broken (before this step, it was present). Looking 
at the trajectory, I found that the bridge broke at the first step of 
the minimization. However, I did not have any error message, the 
minimization worked regularly.
I would like to know if my starting structure is a real dimeric 
structure, or not, therefore I would like to know if the disulphide 
bridge broke because it is only an artefact, or not. Do I have to add 
some special constraints to the topology and/or .mdp file in order to 
preserve the disulphide bridge in "normal" simulations, or not? I had a 
look in the gmx-users list, but I only see suggestions to introduce a 
new disulphide bridge (and the messages seem quite old, probably 
referred to the Gromacs 3 version, whereas I'm currently using version 
4.0.3). In a very old message (2001) there is the statement "pdb2gmx can 
*not* make inter-molecular bonds" however, in this case, the bond is 
already present in the crystal and is kept in all phases until the 
minimization. I tried to use pdb2gmx -ss in order to set interactively 
the SS bridge selection, but nothing happened: the program does not ask 
me any prompt. Any suggestions?


Bonds do not break and form during EM or MD, which must obey classical 
mechanics.  If you saw a "bond" there, it was just an effect of the 
visualization software.  The true answer is if there is a bond written in
the 
[bonds] section of your topology.  While true that Gromacs cannot make bonds


between molecules, you can use pdb2gmx -merge (-chainsep in version 4.5 and
up) 
to make multiple molecules part of the same [moleculetype].  If you have 
individual chain topologies from pdb2gmx, then there was never a bond there.
If 
the two atoms fall outside the tolerance range specified in specbond.dat, no


bond will have been created.


Many thanks and best regards
Anna Marabotti
 
PS BTW: often when I'm searching in the gmx-users list I see the 
suggestions to some links (for example in the message in 
http://lists.gromacs.org/pipermail/gmx-users/2008-March/032662.html Mark 
Abraham suggests to explore 
http://wiki.gromacs.org/index.php/specbond.dat but when I click on the 
link, I am redirected to the www.gromacs.org  
website. Even if I copy the link directly in a new browser window, I 
cannot see the original link. Why?
 


The website has undergone several major overhauls since 2008.  You can
search 
the current Gromacs website for specbond.dat and retrieve:


http://www.gromacs.org/Documentation/File_Formats/specbond.dat

-Justin


__
Anna Marabotti, Ph.D.
Laboratory of Bioinformatics and Computational Biology
Institute of Food Science - CNR
Via Roma, 64
83100 Avellino
Phone: +39 0825 299651
Fax: +39 0825 781585
E-mail: amarabo...@isa.cnr.it 
Skype account: annam1972
Web site: http://bioinfo

Re: [gmx-users] RE: g_energy inconsistent results

[Per Larsson]

Hi!

When you are computing your zero-step energies, do you then start from the 
gro-file that you got from em? If so, maybe the energies changes because 
gro-files have a fixed precision format (with three decimals), while the 
em-calculations are done using either full single or double precision.

Your second issue is almost certainly related to rounding errors. The 
all-vs-all and the cutoff-code (even with enormous cut-offs) compute 
interactions in completely order. I would not worry about a 0.005 nm difference 
in RMSD.

/Per

10 mar 2011 kl. 14.27 skrev Ehud Schreiber:

> Dear Mark Abraham (and anyone else interested),
> 
> I have implemented your suggestion, changing in the status.mdp file to
> integrator = md and adding continuation = yes (this is the new name of
> the unconstrained_start parameter); however, this did not have any
> effect - the energy remained as before, different from the one obtained
> during the minimization.
> 
> I have then encountered another (perhaps related) issue.
> I thought that the problem may arise from the combination of the
> generalized Born and all-vs-all settings.
> I have therefore changed in the minimization to rgbradii = rlist =
> rcoulomb = rvdw = 100 (from = 0).
> As my system is far smaller than 100 nm, I expected these parameters to
> provide also an all-vs-all setting (even if non-optimized).
> Nevertheless, the resulting structure differed from the previous
> minimized one (rmsd ~ 0.005 nm, delta energy ~ a few kJ/mol). Can this
> arise from rounding effects only or does this signify a problem? I'm not
> sure what rgbradii does, but the manual states that it must equal rlist.
> In addition, changing also status.mdp to have all radii = 100 and
> running on the new optimized output again does not yield the same energy
> as during the optimization. 
> 
> Does all of this make any sense to you?
> 
> Thank,
> Ehud.
> 
> 
>> Message: 6
>> Date: Tue, 08 Mar 2011 23:37:12 +1100
>> From: Mark Abraham 
>> Subject: Re: [gmx-users] g_energy inconsistent results
>> To: Discussion list for GROMACS users 
>> Message-ID: <4d7622f8.7050...@anu.edu.au>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> On 8/03/2011 9:44 PM, Ehud Schreiber wrote:
>>> 
>>> Dear Gromacs users,
>>> 
>>> I am working with version 4.5.3, using the opls-aa forcefield in an
> implicit solvent, all-vs-all setting:
>>> 
>>> pdb2gmx -ter -ff oplsaa -water none -f file.pdb
>>> 
>>> I am energy-minimizing structures in 3 stages (steep, cg and l-bfgs).
> 
>>> The last stage is the following:
>>> 
>>> grompp -f em3.mdp -p topol.top -c em2.gro -t em2.trr -o em3.tpr -po
> em3.mdout.mdp
>>> mdrun -nice 0 -v -pd -deffnm em3
>>> g_energy -s em3.tpr -f em3.edr -o em3.potential_energy.xvg
>>> 
>>> where the mdp file is:
>>> 
>>> ;;; em3.mdp ;;;
>>> integrator   = l-bfgs
>>> nsteps   = 5
>>> implicit_solvent = GBSA
>>> gb_algorithm = Still
>>> sa_algorithm = Ace-approximation
>>> pbc  = no
>>> rgbradii = 0
>>> ns_type  = simple
>>> nstlist  = 0
>>> rlist= 0
>>> coulombtype  = cut-off
>>> rcoulomb = 0
>>> vdwtype  = cut-off
>>> rvdw = 0
>>> nstcalcenergy= 1
>>> nstenergy= 1000
>>> emtol= 0
>>> ;;;
>>> 
>>> The last line in the em3.potential_energy.xvg file should give the
> (potential) energy of the minimized structure em3.gro .
>>> 
>>> I wish also to compute the potential energy of .gro files in general,
> not necessarily obtained from a simulation.
>>> For that, I prepared a .mdp file for a degenerate energy
> minimization, having 0 steps, designed just to give the status of the
> file:
> 
>> Zero-step EM does not calculate the initial energy because it is not
> useful for gradient-based energy minimization.
>> I don't recall the details, but perhaps the first EM step is reported
> as step zero.
>> Instead, you should use zero-step MD (with unconstrained_start = yes),
> or (for multiple single points) mdrun -rerun.
> 
>> You will not necessarily reproduce the g_energy energies with
> anything, because the energy is dependent on the state of the neighbour
> lists.
>> If nstenergy is a multiple of nstlist, then those energies should be
> fairly reproducible.
> 
>> I have updated the grompp source to provide a note to the user to warn
> against zero-step EM.
> 
>> Mark
> 
>>> ;;; status.mdp ;;;
>>> integrator   = l-bfgs
>>> nsteps   = 0
>>> implicit_solvent = GBSA
>>> gb_algorithm = Still
>>> sa_algorithm = Ace-approximation
>>> pbc  = no
>>> rgbradii = 0
>>> ns_type  = simple
>>> nstlist  = 0
>>> rlist= 0
>>> coulombtype  = cut-off
>>> rcoulomb = 0
>>> vdwtype  = cut-off
>>> rvdw = 0
>>> nstcalcenergy= 1
>>> nstenergy= 

[gmx-users] namd in gromacs

[Francesco Oteri]

Dear gromacs users,
I need to convert namd topology (.psf file) in gromacs format (.top).
Any suggestion?
--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

Re: [gmx-users] namd in gromacs

[Roland Schulz]

Hi,

in most cases the easiest way is to regenerate the topology in
pdb2gmx. If that is not possible for some reason, you can use a
version of psfgen we developed in our lab:
http://www.benlabs.net/psfgen+top/Overview.html

BTW: Please don't cross-post to both gmx-users and gmx-developers.

Roland

On Thu, Mar 10, 2011 at 9:28 AM, Francesco Oteri
 wrote:
> Dear gromacs users,
> I need to convert namd topology (.psf file) in gromacs format (.top).
> Any suggestion?
> --
> gmx-users mailing list    gmx-users@gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> Please don't post (un)subscribe requests to the list. Use the www interface
> or send it to gmx-users-requ...@gromacs.org.
> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
>
>



-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

[gmx-users] Free energy calculation and position restraint

[Da-Wei Li]

Dear all

>From Table 5.6 of Gromacs 4.5.4 manu, position restrain constants can be
interpolated in free energy calculations. However, I cannot find how to set
up this. Can somebody help?

thanks.

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

Re: [gmx-users] Fwd: KALP-15 in DPPC Tutorial Step 0 Segmentation Fault

[Steve Vivian]

On 03/08/2011 10:23 PM, Justin A. Lemkul wrote:



Steve Vivian wrote:


New to Gromacs.

Worked my way through the tutorial with relatively few issues until 
the Equilibration stage.  My system blows up!!


Returned to the Topology stage and rebuilt my system ensuring that I 
followed the procedure correctly for the InflateGro process.  It 
appears to be correct, reasonable lipid area, no water inside my 
bilayer, vmd shows a structure which appears normal (although I am 
new to this).  There are voids between bilayer and water molecules, 
but this is to be expected, correct?


Energy Minimization repeatedly produces results within the expected 
range.


Again system blows up at equilibration, step 0 segmentation fault.  
Regardless of whether I attempt the NVT or Anneal_Npt process (using 
the provided mdp files, including the updates for restraints on the 
protein and the lipid molecules).


I have attempted many variations of the nvt.mdp and anneal_npt.mdp 
files hoping to resolve my issue, but with no success.  I will post 
the log information from the nvt.mdp file included in the tutorial.


Started mdrun on node 0 Tue Mar  8 15:42:35 2011

   Step   Time Lambda
  00.00.0

Grid: 9 x 9 x 9 cells
   Energies (kJ/mol)
   G96AngleProper Dih.  Improper Dih.  
LJ-14 Coulomb-14
8.52380e+016.88116e+012.23939e+01   
-3.03546e+012.71260e+03
LJ (SR)  Disper. corr.   Coulomb (SR)   
Coul. recip. Position Rest.
1.49883e+04   -1.42684e+03   -2.78329e+05   
-1.58540e+052.57100e+00
  PotentialKinetic En.   Total 
Energy  Conserved En.   Temperature
   -4.20446e+05*1.41436e+141.41436e+14
1.41436e+141.23343e+12*

 Pres. DC (bar) Pressure (bar)   Constr. rmsd
   -1.56331e+025.05645e+121.18070e+01


As you can see the Potential Energy is reasonable, but the Kinetic 
Energy and Temperature seem unrealistic.


I am hoping that this is enough information for a more experienced 
Gromacs user to provide guidance. Note:  that I have tried all of the 
suggestions that I read on the mailing list and in the "blowing up" 
section of the manual, specifically:

-reduced time steps in Equilibration Stages
-reduced Fmax during EM stage (down as low as 100kJ which did not help)
-modified neighbours list parameters

Any help is appreciated. I can attach and forward any further 
information as required, please let me know.




Which Gromacs version are you using?  It looks like you're running in 
serial, is that correct?  Otherwise, please provide your mdrun command 
line.  If you're using version 4.5.3 in serial, I have identified a 
very problematic bug that seems to affect a wide variety of systems 
that could be related:



Yes I am currently using Gromacs 4.5.3 in serial.


http://redmine.gromacs.org/issues/715

I have seen even the most robust tutorial systems fail as well, as 
some new lab members experienced the same problem.  The workaround is 
to run in parallel.


If I understand you correctly, the recommended workaround is to 
re-configure gromacs 4.5.3 with mpi enabled and complete the 
Equilibration and Production simulation in parallel.


Do you have a recommendation for which mpi library to install (lam mpi 
seems to be referenced in other articles on the mailing list)?


Are there documented installation procedures for this process (upgrading 
to gromacs with mpi enabled)?


Thanks for your assistance.
Steve.


-Justin



Regards,
Steve Vivian.
sviv...@uwo.ca







--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

Re: [gmx-users] Fwd: KALP-15 in DPPC Tutorial Step 0 Segmentation Fault

[Justin A. Lemkul]

Steve Vivian wrote:

On 03/08/2011 10:23 PM, Justin A. Lemkul wrote:



Steve Vivian wrote:


New to Gromacs.

Worked my way through the tutorial with relatively few issues until 
the Equilibration stage.  My system blows up!!


Returned to the Topology stage and rebuilt my system ensuring that I 
followed the procedure correctly for the InflateGro process.  It 
appears to be correct, reasonable lipid area, no water inside my 
bilayer, vmd shows a structure which appears normal (although I am 
new to this).  There are voids between bilayer and water molecules, 
but this is to be expected, correct?


Energy Minimization repeatedly produces results within the expected 
range.


Again system blows up at equilibration, step 0 segmentation fault.  
Regardless of whether I attempt the NVT or Anneal_Npt process (using 
the provided mdp files, including the updates for restraints on the 
protein and the lipid molecules).


I have attempted many variations of the nvt.mdp and anneal_npt.mdp 
files hoping to resolve my issue, but with no success.  I will post 
the log information from the nvt.mdp file included in the tutorial.


Started mdrun on node 0 Tue Mar  8 15:42:35 2011

   Step   Time Lambda
  00.00.0

Grid: 9 x 9 x 9 cells
   Energies (kJ/mol)
   G96AngleProper Dih.  Improper Dih.  
LJ-14 Coulomb-14
8.52380e+016.88116e+012.23939e+01   
-3.03546e+012.71260e+03
LJ (SR)  Disper. corr.   Coulomb (SR)   
Coul. recip. Position Rest.
1.49883e+04   -1.42684e+03   -2.78329e+05   
-1.58540e+052.57100e+00
  PotentialKinetic En.   Total 
Energy  Conserved En.   Temperature
   -4.20446e+05*1.41436e+141.41436e+14
1.41436e+141.23343e+12*

 Pres. DC (bar) Pressure (bar)   Constr. rmsd
   -1.56331e+025.05645e+121.18070e+01


As you can see the Potential Energy is reasonable, but the Kinetic 
Energy and Temperature seem unrealistic.


I am hoping that this is enough information for a more experienced 
Gromacs user to provide guidance. Note:  that I have tried all of the 
suggestions that I read on the mailing list and in the "blowing up" 
section of the manual, specifically:

-reduced time steps in Equilibration Stages
-reduced Fmax during EM stage (down as low as 100kJ which did not help)
-modified neighbours list parameters

Any help is appreciated. I can attach and forward any further 
information as required, please let me know.




Which Gromacs version are you using?  It looks like you're running in 
serial, is that correct?  Otherwise, please provide your mdrun command 
line.  If you're using version 4.5.3 in serial, I have identified a 
very problematic bug that seems to affect a wide variety of systems 
that could be related:



Yes I am currently using Gromacs 4.5.3 in serial.


http://redmine.gromacs.org/issues/715

I have seen even the most robust tutorial systems fail as well, as 
some new lab members experienced the same problem.  The workaround is 
to run in parallel.


If I understand you correctly, the recommended workaround is to 
re-configure gromacs 4.5.3 with mpi enabled and complete the 
Equilibration and Production simulation in parallel.




Strictly speaking, an external MPI library is no longer required.  Gromacs now 
builds with internal threading support (as long as your hardware and compilers 
support such features).  In fact, thread support builds by default if possible, 
so if your mdrun has an -nt flag, you don't need to do anything else except use 
"mdrun -nt (number of threads)" when running your command.


Do you have a recommendation for which mpi library to install (lam mpi 
seems to be referenced in other articles on the mailing list)?




I've had good luck with OpenMPI in the past, but this is not strictly necessary 
in all cases.


Are there documented installation procedures for this process (upgrading 
to gromacs with mpi enabled)?




http://www.gromacs.org/Downloads/Installation_Instructions#Using_MPI

-Justin


Thanks for your assistance.
Steve.


-Justin



Regards,
Steve Vivian.
sviv...@uwo.ca









--


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/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/Support/Mail

Re: [gmx-users] RMSD truncation Restart simulation problems

[Henri Mone]

Hi Mark,

Thanks for your feedback. The simulations are running now again.
I got one questions, I think it will be also of interest for the
others on the mailinglist.
I used "grompp" with the "-t state0.cpt"  option, are the starting
velocities taken from the cpt files or are the assigned randomly from
a Boltzman distribution.
Meaning are the new simulations starting fresh or are they
acontinuation from the previous ones?

Thanks,
Henri

On Tue, Mar 8, 2011 at 1:54 PM, Mark Abraham  wrote:
> On 8/03/2011 9:41 PM, Henri Mone wrote:
>Ah yes, I remember now. mdrun tries to be smart and
>check that all the files match the state they were in before
>the crash by computing checksums when writing and again
>when reading.
>So the original problem was that the steps recorded in the different
>.cpt are different, unsurprisingly.
>To fix this, get the .mdp used to make the original .tpr, and call
>grompp the same way, plus (e.g.) -t state0.cpt for each of the
>replicas. Now the (matching) state information will be taken by
>grompp from the (matching) checkpoint files, and no checksum
>calculation can fail. Then
>mdrun_mpi -multi 32 -replex 5000 -s new.tpr
>should be fine (and no .cpt should be provided).
>While doing this, I would avoid trying to use mdrun -append,
>by the way. Glue things together later if you need to.
>
>Mark
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

Re: [gmx-users] RMSD truncation Restart simulation problems

[Justin A. Lemkul]

Henri Mone wrote:

Hi Mark,

Thanks for your feedback. The simulations are running now again.
I got one questions, I think it will be also of interest for the
others on the mailinglist.
I used "grompp" with the "-t state0.cpt"  option, are the starting
velocities taken from the cpt files or are the assigned randomly from
a Boltzman distribution.
Meaning are the new simulations starting fresh or are they
acontinuation from the previous ones?



The grompp output should tell you.  In older versions, when using a .trr file 
(with velocities) for a restart, the combination of -t traj.trr and "gen_vel = 
yes" caused the velocities in the .trr to be ignored and new ones generated.  A 
clear message was printed.


Check the screen output, and also compare the velocities in the .cpt with that 
of your new .tpr files using gmxcheck/gmxdump.


-Justin


Thanks,
Henri

On Tue, Mar 8, 2011 at 1:54 PM, Mark Abraham  wrote:

On 8/03/2011 9:41 PM, Henri Mone wrote:
Ah yes, I remember now. mdrun tries to be smart and
check that all the files match the state they were in before
the crash by computing checksums when writing and again
when reading.
So the original problem was that the steps recorded in the different
.cpt are different, unsurprisingly.
To fix this, get the .mdp used to make the original .tpr, and call
grompp the same way, plus (e.g.) -t state0.cpt for each of the
replicas. Now the (matching) state information will be taken by
grompp from the (matching) checkpoint files, and no checksum
calculation can fail. Then
mdrun_mpi -multi 32 -replex 5000 -s new.tpr
should be fine (and no .cpt should be provided).
While doing this, I would avoid trying to use mdrun -append,
by the way. Glue things together later if you need to.

Mark


--


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/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

[gmx-users] Possible free energy bug?

[Justin A. Lemkul]

Hi All,

I've been troubleshooting a problem for some time now and I wanted to report it 
here and solicit some feedback before I submit a bug report to see if there's 
anything else I can try.


Here's the situation: I ran some free energy calculations (thermodynamic 
integration) a long time ago using version 3.3.3 to determine the hydration free 
energy of a series of small molecules.  Results were good and they ended up as 
part of a paper, so I'm trying to reproduce the methodology with 4.5.3 (using 
BAR) to see if I understand the workflow completely.  The problem is my systems 
are crashing.  The runs simply stop randomly (usually within a few hundred ps) 
with lots of LINCS warnings and step*.pdb files being written.


I know the parameters are good, and produce stable trajectories, since I spent 
months on them some years ago. The system prep is steepest descents EM to Fmax < 
100 (always achieved), NVT at 298 K for 100 ps, NPT at 298K/1 bar for 100 ps, 
then 5 ns of data collection under NPT conditions.  Here's the rundown of what 
I'm seeing:


1. All LJ transformations work fine.  The problem only comes when I have a 
molecule with full LJ interaction and I am "charging" it (i.e., introducing 
charges to the partially-interacting species).


2. Simulations at lambda=1 (full interaction) work fine.

3. Simulations with the free energy code off entirely work fine under all 
conditions.


4. I cannot run in serial due to http://redmine.gromacs.org/issues/715.  The bug 
seems to affect other systems and is not specifically related to my free energy 
calculations.


5. Running with DD fails because my system is relatively small (more on this in 
a moment).


6. Running with mdrun -pd 2 works, but mdrun -pd 4 crashes for any value of 
lambda != 1.


7. I created a larger system (instead of a 3x3x3-nm cube of water with my 
molecule, I used 4x4x4) and ran on 4 CPU's with DD (lambda = 0, i.e. full vdW, 
no intermolecular Coulombic interactions - .mdp file is below).  This run also 
crashed with some warnings about DD cell size:


DD  load balancing is limited by minimum cell size in dimension X
DD  step 32  vol min/aver 0.748! load imb.: force 31.5%

...and then the actual crash:

---
Program mdrun_4.5.3_gcc_mpi, VERSION 4.5.3
Source code file: domdec_con.c, line: 693

Fatal error:
DD cell 0 0 0 could only obtain 14 of the 15 atoms that are connected via 
constraints from the neighboring cells. This probably means your constraint 
lengths are too long compared to the domain decomposition cell size. Decrease 
the number of domain decomposition grid cells or lincs-order or use the -rcon 
option of mdrun.

For more information and tips for troubleshooting, please check the GROMACS
website at http://www.gromacs.org/Documentation/Errors
---

Watching the trajectory doesn't seem to give any useful information.  The small 
molecule of interest is at a periodic boundary when the crash happens, but there 
are several crosses prior to the crash without incident, so I don't know if the 
issue is related to PBC or not, but it appears not.


8. I initially thought the problem might be related to the barostat, but 
switching from P-R to Berendsen does not alleviate the problem, nor does 
increasing tau_p (tested 0.5, 1.0, 2.0, and 5.0 - all crash).  Longer tau_p 
simply delays the crash, but does not prevent it.


So after all that, I'm wondering if (1) anyone has seen the same, or (2) if 
there's anything else I can try (environment variables, hidden tricks, etc) that 
I can use to get to the bottom of this before I give up and file a bug report.


If you made it this far, thanks for reading my novel and hopefully someone can 
give me some ideas.  The .mdp file I'm using is below, but it is just one of 
many that I've tried.  In theory, it should work, since the parameters are the 
same as my successful 3.3.3 runs, with the exception of the new free energy 
features in 4.5.3 and obvious keyword changes related to the difference in version.


-Justin

--- .mdp file ---

; Run control
integrator   = sd   ; Langevin dynamics
tinit= 0
dt   = 0.002
nsteps   = 250  ; 5 ns
nstcomm  = 100
; Output control
nstxout  = 500
nstvout  = 500
nstfout  = 0
nstlog   = 500
nstenergy= 500
nstxtcout= 0
xtc-precision= 1000
; Neighborsearching and short-range nonbonded interactions
nstlist  = 5
ns_type  = grid
pbc  = xyz
rlist= 0.9
; Electrostatics
coulombtype  = PME
rcoulomb = 0.9
; van der Waals
vdw-type = cutoff
rvdw = 1.4
; Apply long range dispersion corrections for Energy and Pressure
DispCorr 

[gmx-users] Viscosity calculation problems (periodic perturbation method)

[Xiang Gu]

Hi, all,

I was trying to reproduce the viscosity results of SPC water reported in 
Berk Hess' paper (JCP, vol.116 No.1, 209-217, 2002) by using the 
periodic perturbation method. After reading some old tips on the 
maillist exchanged by Song, David, etc., I tried to set up the NVT 
simulation just according to Hess has done, and sent it to calculation.


Probably because not everything is properly understood, I processed the 
edr file with g_energy_d but found both the columns 2CosZ*Vel-X & 
1/Viscosity always zero. I played with several options of Tcoupl and 
tau_t, still the same happened. Could anybody experienced in this tutor 
me what has been improperly specified in the mdp file (see below; system 
is 3456 SPC water molecules contained in a 3.75*3.75*7.5 nm^3 box--just 
as in Hess' paper Table II, already well equilibrated at 300 K in 
advance; perhaps it is unnecessary to run this double precisely, but I 
was using double precision version (4.5.3.d) just because I forgot to 
switch to the single precision one, however this shouldn't cause the 
problem I had ...)?


Thanks and wish to see your suggestions soon!

Xiang Gu

;Generic mdp file for SPC water equilibration
;Gromacs 4.3.x
;
;T = 300 K
;
;NVT equilibration run, 1.2 ns
;

define   =  ; define here posres etc., e.g. -DPOSRES

integrator  = md
tinit   = 0
dt  = 0.001
nsteps  = 120

; Bond constraints
continuation=  no  ; switch to 'yes' if need to read 
in velocities etc.

constraints =  none; constrain all bond lengths
constraint_algorithm=  lincs   ; default
lincs_order =  4   ; default

; X/V/F/E outputs  change these according to your system 
nstxout = 1000
nstvout = 1000
nstfout = 0
nstlog  = 1000
nstenergy   = 1000
; Output frequency and precision for xtc file
nstxtcout   = 1000
xtc-precision   = 1000
; This selects the subset of atoms for the xtc file. You can
; select multiple groups. By default all atoms will be written.
xtc-grps=
; Selection of energy groups
energygrps  = System

; Neighbor list
ns_type  =  grid; neighlist type
nstlist  =  5   ; Freq. to update neighbour list
rlist=  0.9 ; nm (cutoff for short-range NL)
pbc  =  xyz ; xyz(default), no, full(infinite 
systems)

periodic_molecules   =  no

; Non-equilibrium MD
;acc_grps = SYSTEM
cos_acceleration =  0.025   ; PPM option for viscosity 
calculation (nm/ps²)


coulombtype  = PME
rcoulomb = 0.9
optimize_fft = yes ; affects only PME calculations
  ; if you use PME, set also 
rcoulomb = rlist


; van der Waals interactions
vdwtype  =  Cut-off; Van der Waals interactions
rvdw =  0.9; nm (LJ cut-off)
DispCorr =  EnerPres   ; long-range dispersion 
correction to energy and pressure


Tcoupl  = berendsen
tc-grps = System
tau_t   = 2.5
ref_t   = 300.0

;Pressure coupling
Pcoupl  =  no  ; berendsen, tau_p = 1.0 for 
faster equilibration
;Pcoupltype  =  isotropic   ; semi-isotropic: xy and z 
separately (CNT)

;tau_p   =  1.0 ; ps
;compressibility =  4.5e-5  ; 1/bar (water @ 1 atm, 300 K)
;ref_p   =  1.0 ; bar0  4000 1.034798 0.001949

gen_vel = no
;gen_temp= 300.0
;gen_seed= 173529

--
_
Xiang Gu, PhD, Postdoctoral Research Fellow
Department of Applied Physics
Aalto University School of Science and Technology, Finland
Tel: +358-9-470 23137
Email: xiang...@aalto.fi
http://tfy.tkk.fi/soft/ 


--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

Re: [gmx-users] Viscosity calculation problems (periodic perturbation method)

[Justin A. Lemkul]

There have been several bug fixes related to viscosity calculations since the 
release of version 4.5.3, of which at least one (on 1/10/2011) specifically 
mentions zero viscosity in the .edr and .log files.


I would suggest pulling the latest release-4-5-patches from the git repository 
and try again.


-Justin

Xiang Gu wrote:

Hi, all,

I was trying to reproduce the viscosity results of SPC water reported in 
Berk Hess' paper (JCP, vol.116 No.1, 209-217, 2002) by using the 
periodic perturbation method. After reading some old tips on the 
maillist exchanged by Song, David, etc., I tried to set up the NVT 
simulation just according to Hess has done, and sent it to calculation.


Probably because not everything is properly understood, I processed the 
edr file with g_energy_d but found both the columns 2CosZ*Vel-X & 
1/Viscosity always zero. I played with several options of Tcoupl and 
tau_t, still the same happened. Could anybody experienced in this tutor 
me what has been improperly specified in the mdp file (see below; system 
is 3456 SPC water molecules contained in a 3.75*3.75*7.5 nm^3 box--just 
as in Hess' paper Table II, already well equilibrated at 300 K in 
advance; perhaps it is unnecessary to run this double precisely, but I 
was using double precision version (4.5.3.d) just because I forgot to 
switch to the single precision one, however this shouldn't cause the 
problem I had ...)?


Thanks and wish to see your suggestions soon!

Xiang Gu

;Generic mdp file for SPC water equilibration
;Gromacs 4.3.x
;
;T = 300 K
;
;NVT equilibration run, 1.2 ns
;

define   =  ; define here posres etc., e.g. 
-DPOSRES


integrator  = md
tinit   = 0
dt  = 0.001
nsteps  = 120

; Bond constraints
continuation=  no  ; switch to 'yes' if need to read 
in velocities etc.

constraints =  none; constrain all bond lengths
constraint_algorithm=  lincs   ; default
lincs_order =  4   ; default

; X/V/F/E outputs  change these according to your system 
nstxout = 1000
nstvout = 1000
nstfout = 0
nstlog  = 1000
nstenergy   = 1000
; Output frequency and precision for xtc file
nstxtcout   = 1000
xtc-precision   = 1000
; This selects the subset of atoms for the xtc file. You can
; select multiple groups. By default all atoms will be written.
xtc-grps=
; Selection of energy groups
energygrps  = System

; Neighbor list
ns_type  =  grid; neighlist type
nstlist  =  5   ; Freq. to update neighbour list
rlist=  0.9 ; nm (cutoff for short-range NL)
pbc  =  xyz ; xyz(default), no, full(infinite 
systems)

periodic_molecules   =  no

; Non-equilibrium MD
;acc_grps = SYSTEM
cos_acceleration =  0.025   ; PPM option for viscosity 
calculation (nm/ps²)


coulombtype  = PME
rcoulomb = 0.9
optimize_fft = yes ; affects only PME calculations
  ; if you use PME, set also 
rcoulomb = rlist


; van der Waals interactions
vdwtype  =  Cut-off; Van der Waals interactions
rvdw =  0.9; nm (LJ cut-off)
DispCorr =  EnerPres   ; long-range dispersion 
correction to energy and pressure


Tcoupl  = berendsen
tc-grps = System
tau_t   = 2.5
ref_t   = 300.0

;Pressure coupling
Pcoupl  =  no  ; berendsen, tau_p = 1.0 for 
faster equilibration
;Pcoupltype  =  isotropic   ; semi-isotropic: xy and z 
separately (CNT)

;tau_p   =  1.0 ; ps
;compressibility =  4.5e-5  ; 1/bar (water @ 1 atm, 300 K)
;ref_p   =  1.0 ; bar0  4000 1.034798 0.001949

gen_vel = no
;gen_temp= 300.0
;gen_seed= 173529



--


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/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

[gmx-users] Re: question about gromacs (4.5) installation

[Moeed]

Hi,

Please don't #include "ions.itp" in your topology file if not needed.

moeed

On 10 March 2011 13:22, tao wei  wrote:

> Hi
>
> I saw your post on Gromacs forum about the
>
> Fatal error:
> Atomtype CU2+ not found
>
> http://lists.gromacs.org/pipermail/gmx-users/2010-September/053804.html
>
> I have found that i have the same problem.
> I grompp my file with gromacs-4.0.5. I have no problem.
> But if I change to gromacs-4.5.3
> Gromacs just gave me this error report, like yours
> It looks very strange.
>
> Have you solved the problem?
> Thanks for your information!
>
> tao
>
>
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

[gmx-users] Re: question about gromacs (4.5) installation

[Moeed]

Hello,

If you need to keep ions.top then see the below link:

http://lists.gromacs.org/pipermail/gmx-users/2010-September/054487.html

moeed

On 10 March 2011 14:53, tao wei  wrote:

> Dear Moeed,
>
> Thanks a lot for your quick response!
> That is problem. I do need to include ions.itp.
>
> Is there anything wrong on this file? Does Gromacs mis-understand C* with
> CU2+ ?
> Do you think if i only keep the necessary line for these ions that i need?
> Thanks for your suggestions!
>
> Now temporally grompp with the old version of Gromacs, and put it to run it
> on the cluster
> with new version. But I should find out what is going on for this new
> version.
>
> tao
>
>
> On Thu, Mar 10, 2011 at 1:49 PM, Moeed  wrote:
>
>> Hi,
>>
>> Please don't #include "ions.itp" in your topology file if not needed.
>>
>> moeed
>>
>>
>> On 10 March 2011 13:22, tao wei  wrote:
>>
>>> Hi
>>>
>>> I saw your post on Gromacs forum about the
>>>
>>> Fatal error:
>>> Atomtype CU2+ not found
>>>
>>> http://lists.gromacs.org/pipermail/gmx-users/2010-September/053804.html
>>>
>>>
>>>
>>> I have found that i have the same problem.
>>> I grompp my file with gromacs-4.0.5. I have no problem.
>>> But if I change to gromacs-4.5.3
>>> Gromacs just gave me this error report, like yours
>>> It looks very strange.
>>>
>>>
>>>
>>> Have you solved the problem?
>>> Thanks for your information!
>>>
>>> tao
>>>
>>>
>>
>
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

RE: [gmx-users] QMMM

[Dallas Warren]

Looks what shows up when you search the GROMACS website 
(http://www.gromacs.org/)

http://www.gromacs.org/Special:Search?search=qmmm&ns=main&path=

Top two links provide all the information you require.

Catch ya,

Dr. Dallas Warren
Medicinal Chemistry and Drug Action
Monash Institute of Pharmaceutical Sciences, Monash University
381 Royal Parade, Parkville VIC 3010
dallas.war...@monash.edu
+61 3 9903 9304
-
When the only tool you own is a hammer, every problem begins to resemble a 
nail. 

> -Original Message-
> From: gmx-users-boun...@gromacs.org [mailto:gmx-users-
> boun...@gromacs.org] On Behalf Of Haresh
> Sent: Thursday, 10 March 2011 4:48 PM
> To: gmx-users@gromacs.org
> Subject: [gmx-users] QMMM
> 
> 
> Respected sir,
> 
> I am new user in gromacs.
> I want to run QMMM on gromacs.
> Should I have install all source code like mopac7, guessin,gamess-UK
> for QMMM ?
> 
> Please help me out.
> 
> 
> --
> gmx-users mailing listgmx-users@gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-users-requ...@gromacs.org.
> Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

[gmx-users] 2 Questions

[simon sham]

Hi,
I) I have been trying to figure out where is the source of the following 
warning message coming from:

WARNING: masses and atomic (Van der Waals) radii will be determined
 based on residue and atom names. These numbers can deviate
 from the correct mass and radius of the atom type.

2). I used ngmx to inspect the trajectory of a 20ns MD run, and I noticed that 
the protein is moving around quite a bit in different directions. Is it normal?

Thanks for your insight.

Simon



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

Re: [gmx-users] 2 Questions

[Justin A. Lemkul]

simon sham wrote:

Hi,
I) I have been trying to figure out where is the source of the following 
warning message coming from:


WARNING: masses and atomic (Van der Waals) radii will be determined
 based on residue and atom names. These numbers can deviate
 from the correct mass and radius of the atom type.



It would be useful to know what program is issuing this statement, what your 
command was, what you're doing, etc.  Presumably, whatever program it is needs 
van der Waals radii and is going to make a guess as to what they should be based 
on atom names rather than types.  Using a run input file usually alleviates this 
issue.


2). I used ngmx to inspect the trajectory of a 20ns MD run, and I 
noticed that the protein is moving around quite a bit in different 
directions. Is it normal?




All molecules diffuse.  Otherwise, see FAQ #11, which is a question that gets 
asked weekly, if not more frequently.


http://www.gromacs.org/Documentation/FAQs

-Justin


Thanks for your insight.

Simon




--


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/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.

Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

Re: [gmx-users] Possible free energy bug?

[Matthew Zwier]

Dear Justin,

We recently experienced a similar problem (LINCS errors, step*.pdb
files), and then GROMACS usually segfaulted.  The cause was a
miscompiled copy of GROMACS.  Another member of our group had compiled
GROMACS on an Intel Core2 quad (gcc -march=core2) and tried to run the
copy without modification on an AMD Magny Cours machine.
Recompilation with the correct subarchitecture type (-march=amdfam10)
fixed the problem.  Don't really know why it didn't die with SIGILL or
SIGBUS instead of SIGSEGV, but that's probably a question for the
hardware gurus.

So...are you observing segfaults?  What compiler are you using (and on
what OS)?  What were the compilation parameters for 4.5.3?  Also, are
you really running across nodes with MPI, or running on the same node
with MPI?

Cheers,
Matt Zwier

On Thu, Mar 10, 2011 at 1:55 PM, Justin A. Lemkul  wrote:
>
> Hi All,
>
> I've been troubleshooting a problem for some time now and I wanted to report
> it here and solicit some feedback before I submit a bug report to see if
> there's anything else I can try.
>
> Here's the situation: I ran some free energy calculations (thermodynamic
> integration) a long time ago using version 3.3.3 to determine the hydration
> free energy of a series of small molecules.  Results were good and they
> ended up as part of a paper, so I'm trying to reproduce the methodology with
> 4.5.3 (using BAR) to see if I understand the workflow completely.  The
> problem is my systems are crashing.  The runs simply stop randomly (usually
> within a few hundred ps) with lots of LINCS warnings and step*.pdb files
> being written.
>
> I know the parameters are good, and produce stable trajectories, since I
> spent months on them some years ago. The system prep is steepest descents EM
> to Fmax < 100 (always achieved), NVT at 298 K for 100 ps, NPT at 298K/1 bar
> for 100 ps, then 5 ns of data collection under NPT conditions.  Here's the
> rundown of what I'm seeing:
>
> 1. All LJ transformations work fine.  The problem only comes when I have a
> molecule with full LJ interaction and I am "charging" it (i.e., introducing
> charges to the partially-interacting species).
>
> 2. Simulations at lambda=1 (full interaction) work fine.
>
> 3. Simulations with the free energy code off entirely work fine under all
> conditions.
>
> 4. I cannot run in serial due to http://redmine.gromacs.org/issues/715.  The
> bug seems to affect other systems and is not specifically related to my free
> energy calculations.
>
> 5. Running with DD fails because my system is relatively small (more on this
> in a moment).
>
> 6. Running with mdrun -pd 2 works, but mdrun -pd 4 crashes for any value of
> lambda != 1.
>
> 7. I created a larger system (instead of a 3x3x3-nm cube of water with my
> molecule, I used 4x4x4) and ran on 4 CPU's with DD (lambda = 0, i.e. full
> vdW, no intermolecular Coulombic interactions - .mdp file is below).  This
> run also crashed with some warnings about DD cell size:
>
> DD  load balancing is limited by minimum cell size in dimension X
> DD  step 32  vol min/aver 0.748! load imb.: force 31.5%
>
> ...and then the actual crash:
>
> ---
> Program mdrun_4.5.3_gcc_mpi, VERSION 4.5.3
> Source code file: domdec_con.c, line: 693
>
> Fatal error:
> DD cell 0 0 0 could only obtain 14 of the 15 atoms that are connected via
> constraints from the neighboring cells. This probably means your constraint
> lengths are too long compared to the domain decomposition cell size.
> Decrease the number of domain decomposition grid cells or lincs-order or use
> the -rcon option of mdrun.
> For more information and tips for troubleshooting, please check the GROMACS
> website at http://www.gromacs.org/Documentation/Errors
> ---
>
> Watching the trajectory doesn't seem to give any useful information.  The
> small molecule of interest is at a periodic boundary when the crash happens,
> but there are several crosses prior to the crash without incident, so I
> don't know if the issue is related to PBC or not, but it appears not.
>
> 8. I initially thought the problem might be related to the barostat, but
> switching from P-R to Berendsen does not alleviate the problem, nor does
> increasing tau_p (tested 0.5, 1.0, 2.0, and 5.0 - all crash).  Longer tau_p
> simply delays the crash, but does not prevent it.
>
> So after all that, I'm wondering if (1) anyone has seen the same, or (2) if
> there's anything else I can try (environment variables, hidden tricks, etc)
> that I can use to get to the bottom of this before I give up and file a bug
> report.
>
> If you made it this far, thanks for reading my novel and hopefully someone
> can give me some ideas.  The .mdp file I'm using is below, but it is just
> one of many that I've tried.  In theory, it should work, since the
> parameters are the same as my successful 3.3.3 runs, with the exception of
> the new free energy fea

Re: [gmx-users] Possible free energy bug?

[Justin A. Lemkul]

Hi Matt,

Thanks for the reply.  I can't trace the problem to a specific compiler.  We 
have a PowerPC cluster with two partitions - one running Mac OS X 10.3 with 
gcc-3.3, the other running YellowDog Linux with gcc-4.2.2.  The problem happens 
on both partitions.  There are no seg faults, the runs just exit (MPI_ABORT) 
after the fatal error (either "too many LINCS warnings" or the DD-related error 
I posted before).


We are using MPI: mpich-1.2.5 on OSX and OpenMPI-1.2.3 on Linux.  All of the 
above has been the same since my successful 3.3.3 TI calculations (as well as 
all of my simulations with Gromacs, ever).  Our hardware and compilers are 
somewhat (very) outdated so threading is not supported, we always use MPI.


Gromacs was compiled in single precision using standard options through 
autoconf.  The cmake build system still does not work on our cluster due to 
several outstanding bugs.


-Justin

Matthew Zwier wrote:

Dear Justin,

We recently experienced a similar problem (LINCS errors, step*.pdb
files), and then GROMACS usually segfaulted.  The cause was a
miscompiled copy of GROMACS.  Another member of our group had compiled
GROMACS on an Intel Core2 quad (gcc -march=core2) and tried to run the
copy without modification on an AMD Magny Cours machine.
Recompilation with the correct subarchitecture type (-march=amdfam10)
fixed the problem.  Don't really know why it didn't die with SIGILL or
SIGBUS instead of SIGSEGV, but that's probably a question for the
hardware gurus.

So...are you observing segfaults?  What compiler are you using (and on
what OS)?  What were the compilation parameters for 4.5.3?  Also, are
you really running across nodes with MPI, or running on the same node
with MPI?

Cheers,
Matt Zwier

On Thu, Mar 10, 2011 at 1:55 PM, Justin A. Lemkul  wrote:

Hi All,

I've been troubleshooting a problem for some time now and I wanted to report
it here and solicit some feedback before I submit a bug report to see if
there's anything else I can try.

Here's the situation: I ran some free energy calculations (thermodynamic
integration) a long time ago using version 3.3.3 to determine the hydration
free energy of a series of small molecules.  Results were good and they
ended up as part of a paper, so I'm trying to reproduce the methodology with
4.5.3 (using BAR) to see if I understand the workflow completely.  The
problem is my systems are crashing.  The runs simply stop randomly (usually
within a few hundred ps) with lots of LINCS warnings and step*.pdb files
being written.

I know the parameters are good, and produce stable trajectories, since I
spent months on them some years ago. The system prep is steepest descents EM
to Fmax < 100 (always achieved), NVT at 298 K for 100 ps, NPT at 298K/1 bar
for 100 ps, then 5 ns of data collection under NPT conditions.  Here's the
rundown of what I'm seeing:

1. All LJ transformations work fine.  The problem only comes when I have a
molecule with full LJ interaction and I am "charging" it (i.e., introducing
charges to the partially-interacting species).

2. Simulations at lambda=1 (full interaction) work fine.

3. Simulations with the free energy code off entirely work fine under all
conditions.

4. I cannot run in serial due to http://redmine.gromacs.org/issues/715.  The
bug seems to affect other systems and is not specifically related to my free
energy calculations.

5. Running with DD fails because my system is relatively small (more on this
in a moment).

6. Running with mdrun -pd 2 works, but mdrun -pd 4 crashes for any value of
lambda != 1.

7. I created a larger system (instead of a 3x3x3-nm cube of water with my
molecule, I used 4x4x4) and ran on 4 CPU's with DD (lambda = 0, i.e. full
vdW, no intermolecular Coulombic interactions - .mdp file is below).  This
run also crashed with some warnings about DD cell size:

DD  load balancing is limited by minimum cell size in dimension X
DD  step 32  vol min/aver 0.748! load imb.: force 31.5%

...and then the actual crash:

---
Program mdrun_4.5.3_gcc_mpi, VERSION 4.5.3
Source code file: domdec_con.c, line: 693

Fatal error:
DD cell 0 0 0 could only obtain 14 of the 15 atoms that are connected via
constraints from the neighboring cells. This probably means your constraint
lengths are too long compared to the domain decomposition cell size.
Decrease the number of domain decomposition grid cells or lincs-order or use
the -rcon option of mdrun.
For more information and tips for troubleshooting, please check the GROMACS
website at http://www.gromacs.org/Documentation/Errors
---

Watching the trajectory doesn't seem to give any useful information.  The
small molecule of interest is at a periodic boundary when the crash happens,
but there are several crosses prior to the crash without incident, so I
don't know if the issue is related to PBC or not, but it appears not.

8. I initially thought the pr

Re: [gmx-users] Possible free energy bug?

[Matthew Zwier]

Hi Justin,

I should have specified that the segfault happened for us after we got
similar warnings and errors (DD and/or LINCS), so the segfault may
have been tangential.  Given that everything about your system worked
before GROMACS 4.5, it's possible that your older compilers are
generating code that's incompatible with the GROMACS assembly loops
(which you are likely running with, as they are the default option on
most mainstream processors).  The bug you mentioned in your original
post also has my antennae twitching about bad machine code.

If that's indeed happening, it's almost certainly some bizarre
alignment issue, something like half of a float is getting overwritten
on the way into or out of the assembly code, which corruption would
trigger the results you describe.  It's also distantly possible that
GROMACS is working fine, but your copy of FFTW or BLAS/LAPACK (more
likely the latter) has alignment problems.  One final possibility
(which would explain the failure on YellowDog but unfortunately not
the failure on OS X) is that GCC is generating badly-aligned code for
auto-vectorized Altivec loops, which is still a problem for Intel's
SIMD instructions on 32-bit x86 architectures even with GCC 4.4.  I've
also observed MPI gather/reduce operations to foul up alignment (or
rigidly enforce it where badly compiled code is relying on broken
alignment) under exceedingly rare circumstances, usually involving
different libraries compiled with different compilers (which is
generally a bad idea for scientific code anyway).

Okay...so all of that said, there are a few things to try:

1) Recompile GROMACS using -O2 instead of -O3; that'll turn off the
automatic vectorizer (on Yellow Dog) and various other relatively
risky optimizations (on both platforms).  CFLAGS="-O2 -march=powerpc"
in the environment AND on the configure command line would do that.
Check your build logs to make sure it took, though, because if you
don't do it exactly right, configure will ignore your directives and
merrily set up GROMACS to compile with -O3, which is the most likely
culprit for badly-aligned code.

2) Recompile GROMACS specifying a forced alignment flag.  I have no
experience with PowerPC, but -malign-natural and -malign-power look
like good initial guesses.  That's probably going to cause more
problems than it solves, but if you have a screwy BLAS/LAPACK or MPI,
it might help. I only suggest it because if you've already tried #1,
it will only take another half hour or hour of your time to recompile
GROMACS again.  Other than that, tinkering with alignment flags is a
really easy way to REALLY break code, so you might consider skipping
this and moving straight on to #3.

3) Snag GCC 4.4.4 or 4.4.5 and compile it, and use that to compile
GROMACS, again with -O2.  GCC takes forever to compile, but beyond
that, it's not as difficult as it could be.  Nothing preventing you
from installing it in your home directory, either, assuming you set
PATH and LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on OS X) properly.  You
might need to snag a new copy of binutils as well, if gcc refuses to
compile with the system ld.  This option would also probably get you
threading, since you certainly have hardware support for it.

4) Rebuild your entire GROMACS stack, including FFTW, BLAS/LAPACK,
MPI, and GROMACS itself with the same compiler (preferably GCC from
#3) and the same compiler options (which again should be -O2, and
definitely NOT any sort of alignment flag).  Put them in their own
tree (like "/opt/sci"), and definitely not in /usr (which is generally
managed by the system) or /usr/local (which tends to accumulate
cruft).  ATLAS is a good choice for BLAS, and there are directions on
the ATLAS website for building a complete and optimized LAPACK based
on BLAS.

In practice, I've found I've had to do #4 for every piece of
scientific software our group uses, because pretty much nothing works
right with OS-installed versions of compilers, BLAS/LAPACK, and MPI.
It takes forever, and it pretty much defines the phrase "learning
experience," but it also essentially *never* breaks once it works
(because OS updates never overwrite anything you've hand-tuned to run
correctly).  But...with luck option #1 will fix things quickly enough
to get you running without devoting two days to rebuilding your
software stack from scratch.

Hope that helps,
Matt Z.


On Thu, Mar 10, 2011 at 8:54 PM, Justin A. Lemkul  wrote:
>
> Hi Matt,
>
> Thanks for the reply.  I can't trace the problem to a specific compiler.  We
> have a PowerPC cluster with two partitions - one running Mac OS X 10.3 with
> gcc-3.3, the other running YellowDog Linux with gcc-4.2.2.  The problem
> happens on both partitions.  There are no seg faults, the runs just exit
> (MPI_ABORT) after the fatal error (either "too many LINCS warnings" or the
> DD-related error I posted before).
>
> We are using MPI: mpich-1.2.5 on OSX and OpenMPI-1.2.3 on Linux.  All of the
> above has been the same since my s

Re: [gmx-users] Possible free energy bug?

[Justin A. Lemkul]

Hi Matt,

Thanks for the extensive explanation and tips.  I'll work through things and 
report back.  It will take a while to get things going through (unless one of 
the early solutions works!) since I have no admin access to install new 
compilers, libraries, etc. and for some reason the only thing I can ever get to 
work in my home directory is Gromacs itself.  The joys of an aging cluster.


We recently got access to gcc-4.4.5 on Linux, but we're stuck with 3.3 on OS X, 
so there's at least a bit of hope for one partition.


Thanks again.

-Justin

Matthew Zwier wrote:

Hi Justin,

I should have specified that the segfault happened for us after we got
similar warnings and errors (DD and/or LINCS), so the segfault may
have been tangential.  Given that everything about your system worked
before GROMACS 4.5, it's possible that your older compilers are
generating code that's incompatible with the GROMACS assembly loops
(which you are likely running with, as they are the default option on
most mainstream processors).  The bug you mentioned in your original
post also has my antennae twitching about bad machine code.

If that's indeed happening, it's almost certainly some bizarre
alignment issue, something like half of a float is getting overwritten
on the way into or out of the assembly code, which corruption would
trigger the results you describe.  It's also distantly possible that
GROMACS is working fine, but your copy of FFTW or BLAS/LAPACK (more
likely the latter) has alignment problems.  One final possibility
(which would explain the failure on YellowDog but unfortunately not
the failure on OS X) is that GCC is generating badly-aligned code for
auto-vectorized Altivec loops, which is still a problem for Intel's
SIMD instructions on 32-bit x86 architectures even with GCC 4.4.  I've
also observed MPI gather/reduce operations to foul up alignment (or
rigidly enforce it where badly compiled code is relying on broken
alignment) under exceedingly rare circumstances, usually involving
different libraries compiled with different compilers (which is
generally a bad idea for scientific code anyway).

Okay...so all of that said, there are a few things to try:

1) Recompile GROMACS using -O2 instead of -O3; that'll turn off the
automatic vectorizer (on Yellow Dog) and various other relatively
risky optimizations (on both platforms).  CFLAGS="-O2 -march=powerpc"
in the environment AND on the configure command line would do that.
Check your build logs to make sure it took, though, because if you
don't do it exactly right, configure will ignore your directives and
merrily set up GROMACS to compile with -O3, which is the most likely
culprit for badly-aligned code.

2) Recompile GROMACS specifying a forced alignment flag.  I have no
experience with PowerPC, but -malign-natural and -malign-power look
like good initial guesses.  That's probably going to cause more
problems than it solves, but if you have a screwy BLAS/LAPACK or MPI,
it might help. I only suggest it because if you've already tried #1,
it will only take another half hour or hour of your time to recompile
GROMACS again.  Other than that, tinkering with alignment flags is a
really easy way to REALLY break code, so you might consider skipping
this and moving straight on to #3.

3) Snag GCC 4.4.4 or 4.4.5 and compile it, and use that to compile
GROMACS, again with -O2.  GCC takes forever to compile, but beyond
that, it's not as difficult as it could be.  Nothing preventing you
from installing it in your home directory, either, assuming you set
PATH and LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on OS X) properly.  You
might need to snag a new copy of binutils as well, if gcc refuses to
compile with the system ld.  This option would also probably get you
threading, since you certainly have hardware support for it.

4) Rebuild your entire GROMACS stack, including FFTW, BLAS/LAPACK,
MPI, and GROMACS itself with the same compiler (preferably GCC from
#3) and the same compiler options (which again should be -O2, and
definitely NOT any sort of alignment flag).  Put them in their own
tree (like "/opt/sci"), and definitely not in /usr (which is generally
managed by the system) or /usr/local (which tends to accumulate
cruft).  ATLAS is a good choice for BLAS, and there are directions on
the ATLAS website for building a complete and optimized LAPACK based
on BLAS.

In practice, I've found I've had to do #4 for every piece of
scientific software our group uses, because pretty much nothing works
right with OS-installed versions of compilers, BLAS/LAPACK, and MPI.
It takes forever, and it pretty much defines the phrase "learning
experience," but it also essentially *never* breaks once it works
(because OS updates never overwrite anything you've hand-tuned to run
correctly).  But...with luck option #1 will fix things quickly enough
to get you running without devoting two days to rebuilding your
software stack from scratch.

Hope that helps,
Matt Z.


On Thu, Mar 10, 2011 at 8:5

[gmx-users] Regarding Gromacs Application in more than 10 node cluster

[Kannan Govindarajan]

Hi,

I am trying to running the Gromacs application in more than 10 node beowulf
cluster if i run the gromacs application in 5 node cluster it is not

showing any error. If i increase the number of nodes it throws the
communication error in mpich and program ends abruptly. Is it possible to
run the gromacs application in more than 10 node cluster.


-- 
G.Kannan,
Research Associate,
CARE,MIT,
Anna University Chennai.
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

Re: [gmx-users] Possible free energy bug?

[Michael Shirts]

Hi, all-

Have you tried running

constraints = hbonds?

That might eliminate some of the constraint issues.  Much less likely
for LINCS to break or have DD issues if only the hbonds are
constrained.  2 fs is not that big a deal for the heteroatom bonds.

Best,
Michael

On Thu, Mar 10, 2011 at 8:04 PM, Justin A. Lemkul  wrote:
>
> Hi Matt,
>
> Thanks for the extensive explanation and tips.  I'll work through things and
> report back.  It will take a while to get things going through (unless one
> of the early solutions works!) since I have no admin access to install new
> compilers, libraries, etc. and for some reason the only thing I can ever get
> to work in my home directory is Gromacs itself.  The joys of an aging
> cluster.
>
> We recently got access to gcc-4.4.5 on Linux, but we're stuck with 3.3 on OS
> X, so there's at least a bit of hope for one partition.
>
> Thanks again.
>
> -Justin
>
> Matthew Zwier wrote:
>>
>> Hi Justin,
>>
>> I should have specified that the segfault happened for us after we got
>> similar warnings and errors (DD and/or LINCS), so the segfault may
>> have been tangential.  Given that everything about your system worked
>> before GROMACS 4.5, it's possible that your older compilers are
>> generating code that's incompatible with the GROMACS assembly loops
>> (which you are likely running with, as they are the default option on
>> most mainstream processors).  The bug you mentioned in your original
>> post also has my antennae twitching about bad machine code.
>>
>> If that's indeed happening, it's almost certainly some bizarre
>> alignment issue, something like half of a float is getting overwritten
>> on the way into or out of the assembly code, which corruption would
>> trigger the results you describe.  It's also distantly possible that
>> GROMACS is working fine, but your copy of FFTW or BLAS/LAPACK (more
>> likely the latter) has alignment problems.  One final possibility
>> (which would explain the failure on YellowDog but unfortunately not
>> the failure on OS X) is that GCC is generating badly-aligned code for
>> auto-vectorized Altivec loops, which is still a problem for Intel's
>> SIMD instructions on 32-bit x86 architectures even with GCC 4.4.  I've
>> also observed MPI gather/reduce operations to foul up alignment (or
>> rigidly enforce it where badly compiled code is relying on broken
>> alignment) under exceedingly rare circumstances, usually involving
>> different libraries compiled with different compilers (which is
>> generally a bad idea for scientific code anyway).
>>
>> Okay...so all of that said, there are a few things to try:
>>
>> 1) Recompile GROMACS using -O2 instead of -O3; that'll turn off the
>> automatic vectorizer (on Yellow Dog) and various other relatively
>> risky optimizations (on both platforms).  CFLAGS="-O2 -march=powerpc"
>> in the environment AND on the configure command line would do that.
>> Check your build logs to make sure it took, though, because if you
>> don't do it exactly right, configure will ignore your directives and
>> merrily set up GROMACS to compile with -O3, which is the most likely
>> culprit for badly-aligned code.
>>
>> 2) Recompile GROMACS specifying a forced alignment flag.  I have no
>> experience with PowerPC, but -malign-natural and -malign-power look
>> like good initial guesses.  That's probably going to cause more
>> problems than it solves, but if you have a screwy BLAS/LAPACK or MPI,
>> it might help. I only suggest it because if you've already tried #1,
>> it will only take another half hour or hour of your time to recompile
>> GROMACS again.  Other than that, tinkering with alignment flags is a
>> really easy way to REALLY break code, so you might consider skipping
>> this and moving straight on to #3.
>>
>> 3) Snag GCC 4.4.4 or 4.4.5 and compile it, and use that to compile
>> GROMACS, again with -O2.  GCC takes forever to compile, but beyond
>> that, it's not as difficult as it could be.  Nothing preventing you
>> from installing it in your home directory, either, assuming you set
>> PATH and LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on OS X) properly.  You
>> might need to snag a new copy of binutils as well, if gcc refuses to
>> compile with the system ld.  This option would also probably get you
>> threading, since you certainly have hardware support for it.
>>
>> 4) Rebuild your entire GROMACS stack, including FFTW, BLAS/LAPACK,
>> MPI, and GROMACS itself with the same compiler (preferably GCC from
>> #3) and the same compiler options (which again should be -O2, and
>> definitely NOT any sort of alignment flag).  Put them in their own
>> tree (like "/opt/sci"), and definitely not in /usr (which is generally
>> managed by the system) or /usr/local (which tends to accumulate
>> cruft).  ATLAS is a good choice for BLAS, and there are directions on
>> the ATLAS website for building a complete and optimized LAPACK based
>> on BLAS.
>>
>> In practice, I've found I've had to do #4 for every piece of
>> scienti

Re: [gmx-users] Possible free energy bug?

[Justin A. Lemkul]

Michael Shirts wrote:

Hi, all-

Have you tried running

constraints = hbonds?

That might eliminate some of the constraint issues.  Much less likely
for LINCS to break or have DD issues if only the hbonds are
constrained.  2 fs is not that big a deal for the heteroatom bonds.



I haven't yet, but I'll add it to my to-do list.  I was trying to keep as many 
things consistent between my 3.3.3 and 4.5.3 input files as possible, so I could 
diagnose any issues, but at this point, anything is worth a shot.


Thanks!

-Justin


Best,
Michael

On Thu, Mar 10, 2011 at 8:04 PM, Justin A. Lemkul  wrote:

Hi Matt,

Thanks for the extensive explanation and tips.  I'll work through things and
report back.  It will take a while to get things going through (unless one
of the early solutions works!) since I have no admin access to install new
compilers, libraries, etc. and for some reason the only thing I can ever get
to work in my home directory is Gromacs itself.  The joys of an aging
cluster.

We recently got access to gcc-4.4.5 on Linux, but we're stuck with 3.3 on OS
X, so there's at least a bit of hope for one partition.

Thanks again.

-Justin

Matthew Zwier wrote:

Hi Justin,

I should have specified that the segfault happened for us after we got
similar warnings and errors (DD and/or LINCS), so the segfault may
have been tangential.  Given that everything about your system worked
before GROMACS 4.5, it's possible that your older compilers are
generating code that's incompatible with the GROMACS assembly loops
(which you are likely running with, as they are the default option on
most mainstream processors).  The bug you mentioned in your original
post also has my antennae twitching about bad machine code.

If that's indeed happening, it's almost certainly some bizarre
alignment issue, something like half of a float is getting overwritten
on the way into or out of the assembly code, which corruption would
trigger the results you describe.  It's also distantly possible that
GROMACS is working fine, but your copy of FFTW or BLAS/LAPACK (more
likely the latter) has alignment problems.  One final possibility
(which would explain the failure on YellowDog but unfortunately not
the failure on OS X) is that GCC is generating badly-aligned code for
auto-vectorized Altivec loops, which is still a problem for Intel's
SIMD instructions on 32-bit x86 architectures even with GCC 4.4.  I've
also observed MPI gather/reduce operations to foul up alignment (or
rigidly enforce it where badly compiled code is relying on broken
alignment) under exceedingly rare circumstances, usually involving
different libraries compiled with different compilers (which is
generally a bad idea for scientific code anyway).

Okay...so all of that said, there are a few things to try:

1) Recompile GROMACS using -O2 instead of -O3; that'll turn off the
automatic vectorizer (on Yellow Dog) and various other relatively
risky optimizations (on both platforms).  CFLAGS="-O2 -march=powerpc"
in the environment AND on the configure command line would do that.
Check your build logs to make sure it took, though, because if you
don't do it exactly right, configure will ignore your directives and
merrily set up GROMACS to compile with -O3, which is the most likely
culprit for badly-aligned code.

2) Recompile GROMACS specifying a forced alignment flag.  I have no
experience with PowerPC, but -malign-natural and -malign-power look
like good initial guesses.  That's probably going to cause more
problems than it solves, but if you have a screwy BLAS/LAPACK or MPI,
it might help. I only suggest it because if you've already tried #1,
it will only take another half hour or hour of your time to recompile
GROMACS again.  Other than that, tinkering with alignment flags is a
really easy way to REALLY break code, so you might consider skipping
this and moving straight on to #3.

3) Snag GCC 4.4.4 or 4.4.5 and compile it, and use that to compile
GROMACS, again with -O2.  GCC takes forever to compile, but beyond
that, it's not as difficult as it could be.  Nothing preventing you
from installing it in your home directory, either, assuming you set
PATH and LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on OS X) properly.  You
might need to snag a new copy of binutils as well, if gcc refuses to
compile with the system ld.  This option would also probably get you
threading, since you certainly have hardware support for it.

4) Rebuild your entire GROMACS stack, including FFTW, BLAS/LAPACK,
MPI, and GROMACS itself with the same compiler (preferably GCC from
#3) and the same compiler options (which again should be -O2, and
definitely NOT any sort of alignment flag).  Put them in their own
tree (like "/opt/sci"), and definitely not in /usr (which is generally
managed by the system) or /usr/local (which tends to accumulate
cruft).  ATLAS is a good choice for BLAS, and there are directions on
the ATLAS website for building a complete and optimized LAPACK based
on BLAS.

In practice, I've foun

Re: [gmx-users] Regarding Gromacs Application in more than 10 node cluster

[Mark Abraham]

On 11/03/11, Kannan Govindarajan   wrote:
> Hi,
> 
> I am trying to running the Gromacs application in more than 10 node beowulf 
> cluster if i run the gromacs application in 5 node cluster it is not
> 
> showing any error. If i increase the number of nodes it throws the 
> communication error in mpich and program ends abruptly. Is it possible to run 
> the gromacs application in more than 10 node cluster.
> 

Yes. (Do be sure that MPICH is crashing GROMACS, not GROMACS crashing and 
provoking an MPICH message. See end of GROMACS .log, stdout and stderr.) Some 
versions of MPICH have known problems. I would install and recompile GROMACS 
with latest OpenMPI as my first move.

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

[gmx-users] autocorrelation time of dVpot/dlambda?

[Shun Zhu]

Hi All:

I am doing free energy calculation in Gromacs and want to get an error
estimate of my results. Is it possible to compute the autocorrelation time
of dVpot/dlambda in Gromacs using a certain length of trajectory such as 10
ns? Thanks a lot

Steve Zhu
Biochem@UI
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists

[gmx-users] modified atomtypes.atp and grompp

[Rausch, Felix]

 
Dear Gromacs users,
 
I would like so simulate a protein with phosphorylated amino acids with Gromacs 
4.5.3. To do so, I got the "ffG43a1p" forcefield available from the user 
contributions section (subsection force fields) and adapted the parameters 
given there to Gromos53a6. 
The problem now is that they introduced a new atom type called "OP", which I 
have to add to the atomtypes.atp of my modified force field. I already read 
about problems of a modified atomtypes.atp here in the mailing list, but I 
assumed the problems were sorted out with version 4.5.3.
But if I add OP to the atom list, pdb2gmx works fine, but grompp is raising the 
error
 
Program grompp, VERSION 4.5.3.
Source code file: toppush.c, line: 629
 
Fatal error:
Unknown atomtype CMET
 
which is quite strange because  "CMET" isn't appearing in any file I'm using. 
When I remove OP from the atom list, pdb2gmx is of course raising an error, so 
I'm a bit stuck here...
 
To cut a long story short: Is there any way to introduce a new atom type to 
atomtypes.atp or do I have to parameterize the phosphorylated residues with 
already presend atom types?  
 
Thank you in advance,
Felix Rausch

 

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

[gmx-users] heat capacity etc.

[Thomas Koller]

Hello,

i) I use a NPT ensemble to get the heat capacity c(p). But I always get c(V) 
when I use option -vis where some properties are listed. What is the standard 
way to extract the isobaric heat capacity? Which tool should I use?

ii) The thermal compressibility is never listed when I use g_energy. I use a 
NPT ensemble, same as in i). How can I get the thermal compressibility with 
g_energy exactly?

Regards,
Thomas
-- 
Schon gehört? GMX hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://www.gmx.net/de/go/toolbar
-- 
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the 
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists