[gmx-users] Symmetry corrections in FEP

[Dries Van Rompaey]

Dear gmx-users,

I'm analysing set of FEP simulations where a water molecule is decoupled from a 
protein. I’m using the orientational restraints as suggested by Boresch et al 
(doi 10.1021/jp0217839). In my simulations, the water molecule interconverts 
between two equivalent orientations at the weakly constrained lambda stages, 
but as the constraints get stronger, the equivalent orientation is no longer 
sampled. It’s unclear to me how the symmetry correction should be handled in 
this case. In the literature I have only found Mobley et al’s 2006 paper (doi 
10.1063/1.2221683), which mentions that symmetry corrections may need to be 
applied to each pair of neighbouring simulations when equivalent orientations 
are only sampled in some of the simulations. In most papers where water 
molecules are decoupled (for instance Lu et al, doi 10.1021/ja058042g) it seems 
a complete symmetry correction is applied to all water molecules, regardless of 
sampling.

I’d be very grateful if someone could shed some light on this issue. 
Thanks in advance,

Dries
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] -1.8 Equilibration pressure during MD simulation

[Dries Van Rompaey]

Hi,

Pressure can often fluctuate wildly, especially in relatively small
systems. You probably won't be able to achieve a stable pressure of 1 atm,
and that's not a problem. As long as your pressure fluctuates around 1 atm
you should be fine (you can use running average in xmgrace to check for
this out). If it's not close enough yet, try extending your NPT
equilibration until you are satisfied. The density is often a more stable
indicator.

Kind regards

Dries

On 10 May 2017 at 12:25, Quin K  wrote:

> Hi
>
> I used lyzozyme in water tutorial by virginia tech for MD simulation of a
> protein, *pdb id = 2NT7*.
> http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin/gmx
> -tutorials/lysozyme/index.html
> During equilibration step of MD simulation for a protein I got following
> results for pressure.
> Would the minus pressure value be a problem during MD production step?
> What should be done to increase the pressure to 1 atm ?
>
>
> Energy  Average   Err.Est.   RMSD  Tot-Drift
> 
> ---
> Pressure   -1.834252.8124.812  -0.905452  (bar)
>
>
>
> *Other results:*
>
> Energy  Average   Err.Est.   RMSD  Tot-Drift
> 
> ---
> Density 1025.74   0.322.016231.97406
>  (kg/m^3)
>
>
>
> Thanks
> Regards
> --
> Gromacs Users mailing list
>
> * Please search the archive at http://www.gromacs.org/
> Support/Mailing_Lists/GMX-Users_List before posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] protein has broken after 100ns simulation

[Dries Van Rompaey]

Hi,

The mailing list removes attachments. Your best bet is uploading your snapshot 
to an image sharing service.
Sometimes several uses of trjconv are required to fix pbc issues.


> On 02 Jul 2016, at 08:16, Seera Suryanarayana  wrote:
> 
> Dear gromacs users,
> 
> I have simulated protein for 100ns. When I visualized the protein in VMD, I
> have seen the protein into different fragments. Later I came to know that
> there is no breaking phenomena in simulations and that is because of the
> PBC problems. I have executed the trjconv command with following arguments
> to solve the problem, but I couldn't make it successful. I also attached
> the snapshot. Kindly guide me how to resolve problem?
> 
> gmx trjconv -s md_0_1.tpr -f md_0_1.xtc -o md_0_1_noPBC.xtc -center -pbc
> mol -ur compact
> 
> Surya
> Graduate student
> India.
> -- 
> Gromacs Users mailing list
> 
> * Please search the archive at 
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!
> 
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> 
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
> mail to gmx-users-requ...@gromacs.org.

-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Saving trajectory with different output time steps

[Dries Van Rompaey]

Hi,

You can use trjconv with the -skip flag to get your desired output.
On 24 Jun 2016 9:19 a.m., "Sanket Ghawali"  wrote:

> Dear Gromacs user,
>
> I have 100ns trajectory in which the output steps are written every 5ps. I
> would like to save the same trajectory of 100ns with the output steps
> written at every 500ps.
> Is there any options available to do so ?
> Or do i need to perform the production run again making changes to the .mdp
> file i.e making nxtout = 25
>
> Please help.
>
> Thanks & Regards
> Sanket.
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

[gmx-users] Relative FEP with restraints

[Dries Van Rompaey]

Dear gmx-users,

I have performed a relative FEP simulation involving a small mutation to my
ligand. In order to prevent distortions to the protein structure I added
harmonic position restraints to the protein backbone.

Does anyone have a reference article for the correct treatment of the
restraints imposed?

Thanks in advance

Dries
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Suggested settings for using Amber force field in Gromacs

[Dries Van Rompaey]

Hi,

Your first stop should be the article describing the parametrisation of the 
force field. It might also be useful to look for articles that are doing 
something similar to what you want to do. 

> On 05 May 2016, at 14:49, Casalini Tommaso  
> wrote:
> 
> Dear Gromacs users and developers,
> I would like to use Amber force field in Gromacs.
> I have no problem for topology conversion and so on, but I would like to ask 
> which are the best settings which should be used for the simulation.
> Right now I am using Berendsen barostat (which is implemented in Amber), PME 
> for electrostatic interactions and Langevin thermostat. I have also put 
> DispEner = no.
> 
> I would like to ask if you can provide some suggestions for the best settings 
> that, in your experience, should be used for simulations using Amber force 
> field.
> 
> I thank you in advance for your help and collaboration.
> 
> Tommaso Casalini
> Posdoctoral fellow, ETH Zurich
> -- 
> Gromacs Users mailing list
> 
> * Please search the archive at 
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!
> 
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> 
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
> mail to gmx-users-requ...@gromacs.org.

-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] very strange phenomenon for my production MD by gromacs

[Dries Van Rompaey]

Hi,
Sounds like you're experiencing periodic boundary artifacts. Take a look at
the following link:
http://www.gromacs.org/Documentation/Terminology/Periodic_Boundary_Conditions

Dries
On 13 Apr 2016 4:31 p.m., "Brett"  wrote:

> Dear All,
>
>
> After energy minimization and equilibrations, I am now running a 50 ns
> production MD, for a protein of 6 identical subunits, with each subunit
> about 300 residues (from resi 120 to resi 420), and there were no breaks in
> any chain. Every day it runs about 1 ns, and every day I use the command
> trjconv to get a new PDB based on the md_0_1.trr file, for the comparison
> between the new pdb and the initial pdb.
>
>
> Today I got the PDB at 6 ns. However when I checked it my pymol, I find
> there is something very strange. Although the rmsd between the 6 ns md PDB
> and 0ns md PDB was about only 3.7, for chain B, residue 366-367 moved 180
> angstrom away from this residues neighbouring residues, and correspondingly
> make chain B has a break at residue 366-367!
>
>
> Will you please let me know what is wrong with my MD, and why 2 residues
> (resi 366-367) moved 180 angstrom away? Does this phenomenon often occur?
>
>
> I am looking forward to getting a reply from you.
>
>
> Brett
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Script for measurung and exporting distances between residues in VMD or Pymol from a gromacs simulation

[Dries Van Rompaey]

Hi,

You can do this using built-in gromacs tools. You want to make a suitable
index group using gmx make_ndx, after which you can use gmx distance to
measure the distance between your groups.

Dries
On 13 Apr 2016 3:50 p.m., "Faulkner, Matthew" 
wrote:

> Hi all,
>
> Does anybody have a script, or reference where this has been done, for
> measuring distances between two residues in each time step of a simulation
> and exporting this data into a handy format like a text or csv file?
>
> I want to measure the distances over time between the nearest atoms of
> some residues that appear to have a conformation change but at the moment I
> only know how to do this manually.
>
> Regards,
> Matthew Faulkner.
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Preparing dual topology for free energy calculation

[Dries Van Rompaey]

Hi,

You should contact the tool's authors for that issue. I don't have any
experience with it.

Good luck

Dries
Hi Rompaey,
Thanks for your valuable advice. As per your advice I went through the
paper (
https://www.google.be/url?sa=t=web=j=http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2872215/=0ahUKEwjq3I7M-YbMAhXI_w4KHQeeCX8QFggoMAU=AFQjCNHnkqQys4V7UYCURTPZyKQEYrGdWQ=rpmfKD8E07TCQ_XfeUyE3Q
).


They also used dual topology approach. They use pmx to generate those
topology. Unfortunately the same program didn't work for me. It gives the
following error (mentioned at the bottom) which I couldn't solve. I went
through many tutorial and on line material but everywhere people talk about
binding energy with ligand. Also they provide topology file and don't
describe how to generate one. I will be grateful if I can get some other
option to prepare dual topology or calculate free energy without dual
topology.

Error message from pmx:

Traceback (most recent call last):
  File "/home/madhu/pmx/scripts/mutate.py", line 504, in 
main(sys.argv)
  File "/home/madhu/pmx/scripts/mutate.py", line 495, in main
apply_mutation( m, mutation, mtp_file )
  File "/home/madhu/pmx/scripts/mutate.py", line 354, in apply_mutation
apply_aa_mutation(m, residue, new_aa_name, mtp_file)
  File "/home/madhu/pmx/scripts/mutate.py", line 332, in apply_aa_mutation
bb_super(residue, hybrid_res )
  File "/usr/local/lib/python2.7/dist-packages/pmx/geometry.py", line 168,
in bb_super
assert len(atoms1) == len(atoms2), "%s -> %s" % ( '-'.join( map(lambda
a: a.name, atoms1)),'-'.join( map(lambda a: a.name, atoms2)) )

Thanks a lot.

"A society with free knowledge is better than a society with free food"

Tushar Ranjan Moharana
B. Tech, NIT Warangal
Ph D Student, CCMB
--
Gromacs Users mailing list

* Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send
a mail to gmx-users-requ...@gromacs.org.
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] on md of protein-ligand complex

[Dries Van Rompaey]

Hi,

Take a look at acpype or FESetup. Those are automated tools that will do
the conversion to gromacs compatible files.
Dear All,


For a MD of a protein-ligand complex, I intend to use AMBER99SB-ILDN
protein force field for the protein part. If I use the antechamber (for
GAFF force field) to produce the ligand top file and gro file, can GROMCS
accept this kind of antechamber produced ligand files for MD?


Brett
--
Gromacs Users mailing list

* Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send
a mail to gmx-users-requ...@gromacs.org.
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Preparing dual topology for free energy calculation

[Dries Van Rompaey]

Hi,

I'd recommend alchemistry.org as a good place to start. Justin's tutorial
(the one you linked to) is an example of an equilibrium free energy method,
not a slow growth method. As a general rule, equilibrium methods are easier
to use and are recommended for people without extensive experience.

The following paper did something similar to what you're looking to do:
https://www.google.be/url?sa=t=web=j=http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2872215/=0ahUKEwjq3I7M-YbMAhXI_w4KHQeeCX8QFggoMAU=AFQjCNHnkqQys4V7UYCURTPZyKQEYrGdWQ=rpmfKD8E07TCQ_XfeUyE3Q
It might be worth looking into their methodology.

Good luck

Dries
On 11 Apr 2016 5:41 p.m., "Tushar Ranjan Moharana" <
tusharranjanmohar...@gmail.com> wrote:

Hi everyone,
I want to calculate difference in folding free energy due to certain
mutations. I want to follow the slow growth method as mentioned in:
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin/gmx-tutorials/free_energy/02_topology.html
However I don't know how to prepare dual topology (even after reading
manual, section  5.7.4). I want to use gromos 53a6 force field. Can anyone
tell me how to prepare dual topology. Any link to read or tutorial will be
of great help.

Thanks a lot for the help.

"A society with free knowledge is better than a society with free food"

Tushar Ranjan Moharana
B. Tech, NIT Warangal
Ph D Student, CCMB
--
Gromacs Users mailing list

* Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send
a mail to gmx-users-requ...@gromacs.org.
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] save the trajectory

[Dries Van Rompaey]

Hi,

You could use gmx mindist with suitable index groups to find out the
distance between the surface and the polymer as a function of the time.
Then you can use trjconv with the b and e flags to get that part of the
trajectory.

Kind regards

Dries
On 4 Mar 2016 4:11 p.m., "leila salimi"  wrote:

> Dear gmx useres,
>
> I have a question. I am interested to have some part of trajectories that
> is important for me!
> For example only I like to have the trajectory when the polymer close to
> the surface, not when it is in the solution!
>
> Is there any solution to do with gromacs?
>
> Thanks very much.
> Leila
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

[gmx-users] Different results for same protein's simulation in 4.6.5 and 5.0.4

[Dries Van Rompaey]

On 29 February 2016 at 08:48, SAPNA BORAH  wrote:

> hi
> Thanks for the suggestion. I will give this a shot, and remove these
> restraints.
>
> I am unclear about what should I be looking in the log file as you
> mentioned. The conformations are not just close, they are the same as the
> initial conformation.
>
See if you can find "Position rest." in your logfile in the Energies
subsection.


>
> I have some understanding on pbc that serves a problem in visualisation of
> the trajectory. I have applied the all sorts of pbc options, but somehow
> things are not falling into place.


If you could post a screenshot of what it looks like that would be handy.
Currently there's not much else I can tell you.


>
>
However the problem more grave here, for me, is the production run and the
> model stability that is happening throughout the simulations in different
> versions.
>
> The model stability is probably caused by the postion restraints. If
you're telling gromacs to apply a restraint that penalizes movement of your
atoms, it makes sense that you won't be seeing much movement.
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Protein-ligand system simulations with GROMACS

[Dries Van Rompaey]

Hi Guillem,

Generally, it's advised to have a solute-box distance on both sides at
least equal to your longest cutoff. This makes sure that you don't
experience artefacts due to periodic images. In my opinion, it's better to
be on the safe side here - a bigger box allows for slight unfolding events
or box shrinkage due to NPT pressure regulation, where a smaller box might
not. This can lead to unphysical interactions between copies of your
protein. Also, try not to mix 'cutoffs' and 'solute-box-distance', they're
two quite different things.

You're right that the dodecahedron does't appear as such in some
visualisation programs. This will indeed be fixed if you use trjconv with
the -ur compact flag (use your ions tpr file, that's just one extra step).
I'm not sure if you can do this in a more efficient way - I'd be happy to
learn about this myself.

Your protein will move around, that's pretty much a given. However, you
can't describe those motion as going 'outside' of the box, since you're
working in a periodic system. A lot of useful info can be found here:
http://www.gromacs.org/Documentation/Terminology/Periodic_Boundary_Conditions

Kind regards

Dries

On 24 February 2016 at 14:13, Guillem Prats Ejarque <
guillem.prats.ejar...@uab.cat> wrote:

> Dear Dries,
>
> First of all, I performed my trials in basis of the protein-ligand
> tutorial that you say. However, it seemed to me that there was too much
> waters and I tried to reduce the box. I didn't thought with the periodic
> image convention. A cutoff of 0.9 would be ok?
>
> When I try to center (using the -c flag) in a dodecahedron box, it appears
> in a vertex of the "dodecahedron" (it not seems a dodecahedron), as it not
> happens in a cubic box. I have read that this is due I'm  working with a
> triclinic cell, and that I should to arrange it with trjconv -ur, but it
> requests to me a .tpr file that I don't have prior the addition of the ions.
>
> Another strange thing that it happens to my previous simulations is that,
> when I ran a trial of 20 ns, the protein moves a lot (in a cubic box with
> 1.0 nm of cutoff), and, at the final, it goes partially outside the box. I
> know that it has to move a little, but all of this movement is normal?
>
> Guillem
> 
> De: Dries Van Rompaey [dries.vanromp...@gmail.com]
> Enviat el: dimecres, 24 / febrer / 2016 7:41
> Per a: Guillem Prats Ejarque
> Tema: Re:Re: Protein-ligand system simulations with GROMACS
>
> Hi Guillem,
>
> It's best to keep everything on the mailing list, so that other people
> with your problem can find all of the posts by googling.
>
> You could try centering with editconf explicitly, with the -c flag. Your
> distance (-d) to the box should be bigger, though. Your cutoffs will likely
> be around 1 nm, so I'd recommend a -d of at least that much, in order to
> avoid violation of the periodic image convention.
> If you haven't already, I would take a look at Justin Lemkul's Lysozyme
> tutorial. He goes into great detail on how to set up and solvate your box.
>
> As for NVE/NPT/NVT, that again depends on what you want to observe. NPT is
> probably the most commonly used setup if you just want to see dynamics and
> such.
>
> Good luck
> Dries
>
> On 24 Feb 2016 12:54 a.m., "Guillem Prats Ejarque" <
> guillem.prats.ejar...@uab.cat<mailto:guillem.prats.ejar...@uab.cat>>
> wrote:
>
> Dear Dries,
>
> Thanks a lot for your quick response. In the literature I normally saw
> runs about one hundred nanoseconds, as you said, but I also saw some runs
> from fs to μs, so I was a little confused. I will check the paper about the
> field force, as you recommend.
>
> Regarding the dodecahedron box, first I tried to use it, but the protein
> does not center in the box. I do not think that this is very important, due
> to the PBC, but I found it strange, because if I use a cubic box, the
> protein is very well centered. I prepared the box like this:
>
>
> editconf -bt dodecahedron -d 0.2 -f complex2.pdb -o complex_solv.pdb
>
> genbox -cp complex_solv.pdb -cs spc216.gro -o complex_ion.pdb -p
> complex.top
>
>
> Looking the literature, I have doubts about NVE/NVT/NPT conditions. In
> some tutorials that I checked, with similar systems (protein-ligand
> systems) I found that they do the production run in NPT conditions, and the
> equilibration with NVT/NPT. However, in some papers, they do the whole run
> and equilibration in NVE conditions. Are there any rules to decide it, at
> least in protein-ligand systems?
>
>
> Thanks a lot, and sorry for the inconveniences,
>
>
> PS: Should I reply to the mail list instead of replying to you directly? I
> have never used a mail list before.
>

Re: [gmx-users] Protein-ligand system simulations with GROMACS

[Dries Van Rompaey]

Hi,

These questions are quite specific to your problem. There's no way we can
predict what equilibration time will suffice for your system. Your
simulation time also depends on what the aim of your simulations is and
what you hope to observe. That said, current simulations are generally a
couple of hundred nanoseconds in length. Keep in mind that it's probably
best to perform several simulations - one simulation will only tell you so
much. Repeatability of your observations is important.

You might want to consider using a dodecahedron rather than a cubic box -
the cubic box will require more water molecules to fill completely. As for
the parameters, read the literature. A good starting point is the paper
describing the amber99sb ildn parametrisation. It's also a good idea to
check what parameters have been described in the literature by people
performing similar simulations.

Good luck!
On 23 Feb 2016 8:39 p.m., "Guillem Prats Ejarque" <
guillem.prats.ejar...@uab.cat> wrote:

> Dear colleagues,
>
> I'm starting to use GROMACS and I'm simulating a system between an RNA
> binding protein and a small RNA ligand (a dinucleotide, ~60 atoms) in a
> cubic box. I set  AMBER99SB-ILDN protein, nucleic AMBER94 as a forcefield,
> with a tip3p water model.
>
> This was only to put you in context. My question is, which parameters
> should I take into account with my system during the production run? Which
> should be the duration of the run? And what about the equilibration?
>
> Thanks a lot for your attention,
>
> Guillem
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

[gmx-users] Effect of compilers loaded at runtime

[Dries Van Rompaey]

Hi,

I'm wondering if the version of the intel toolchain loaded when calling
mdrun affects results? My gromacs version was compiled with intel/2015b -
would it matter if module intel/2016b was loaded at runtime?

Thanks

Dries
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] cutoff-scheme=Verlet

[Dries Van Rompaey]

Hi,

You might want to read this:
http://www.gromacs.org/Documentation/Cut-off_schemes

Basically, in the past Gromacs kept track of interactions through the group
scheme (which made use of charge groups). The more recent verlet scheme
doesn't use charge groups - that's what that line is telling you.

It's not an error, nor does it mean that your charges are being removed.
The link above (or the gromacs manual) should help clarify things.

Dries
On 20 Feb 2016 5:29 p.m., "Alexander Alexander" 
wrote:

> Dear Gromacs user,
>
> In my NVT simulation, I user the Verlet as cutoff-scheme, but below note
> comes up in screen while .tpr generation;
>
> "Removing all charge groups because cutoff-scheme=Verlet"
>
> Does it mean that the atoms which I have indicated a charge for them in
> .top file will be removed? or what ..
>
> Also, how serious is this massage?
>
> Thanks.
>
> Cheers,
> Alex
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] pdb2gmx with GROMOS

[Dries Van Rompaey]

That's good to know. Thanks for the clarifications.

On 19 February 2016 at 14:22, Justin Lemkul <jalem...@vt.edu> wrote:

>
> It's because the GROMOS force fields are the only ones that explicitly
> list [angles] in the .rtp file.  All other force fields let these be
> generated automatically by the bonded structure; this is due to some subtle
> ways in which the force field files differ in their organization (use of
> #define for bonded parameters in GROMOS, etc).
>
> So atoms get deleted when merging the .tdb hackblocks with the .rtp
> bondeds, triggering a warning that something has been deleted.  It causes
> no problem. Probably something subtle has changed, because I have never
> seen such warnings with GROMOS until recently, but these do not indicate
> any problem.  The bonded parameters change due to the altered atom types
> when creating termini, so the correct parameters should always be written.
>
> -Justin
>
>
> On 2/19/16 8:14 AM, Dries Van Rompaey wrote:
>
>> Sure. I pasted my original mail at the bottom.
>> I also followed your suggestion of trying the gromacs-master ff files,
>> with
>> identical results. What I'm trying to find out is why the warning is being
>> triggered and if it's affecting the output in any way. My input is the
>> 1AKI
>> pdb file as downloaded from the pdb. I'm converting it to .gro with the
>> command gmx pdb2gmx -f 1AKI.pdb, selecting the gromos54a7 force field with
>> spc waters.
>>
>> Dear gmx-users,
>>
>> I'm experiencing the following warning while running pdb2gmx (gmx pdb2gmx
>> -f 1AKI.pdb), selecting any of the GROMOS force fields; all others work
>> fine. I get the same error with the -ignh flag.
>>
>> WARNING: WARNING: Residue 1 named LYS of a molecule in the input file was
>> mapped
>> to an entry in the topology database, but the atom H used in
>> an interaction of type angle in that entry is not found in the
>> input file. Perhaps your atom and/or residue naming needs to be
>> fixed.
>>
>> WARNING: WARNING: Residue 129 named LEU of a molecule in the input file
>> was
>> mapped
>> to an entry in the topology database, but the atom O used in
>> an interaction of type angle in that entry is not found in the
>> input file. Perhaps your atom and/or residue naming needs to be
>> fixed.
>>
>> I'm using gromacs 5.1.1 on mac os x. I looked at the rtp and
>> aminoacids.c.tbd/aminoacids.n.tbd files in top/gromos54A7, but I couldn't
>> discover any discrepancies. I also checked the angles in the topology, but
>> it looks like everything that should be applied, based on the contents of
>> the aminoacids.c.tbd/aminoacids.n.tbd files, seems to be applied.
>>
>>   The system I'm working on is lysozyme (pdb code 1AKI). I'm assuming the
>> root cause of this warning is located somewhere in the
>> aminoacids.c.tbd/aminoacids.n.tbd files, as both residues are terminal
>> residues.
>>
>> Can anyone replicate these warnings or does anyone know where they come
>> from?
>>
>> Thanks in advance,
>>
>> Dries
>>
>>
>>
>> On 19 February 2016 at 14:06, Justin Lemkul <jalem...@vt.edu> wrote:
>>
>>
>>> Can you remind me of the context here?  You've provided output files that
>>> indicate everything is fine.  If there's a problem with *input* please
>>> provide those files, the exact command and selections, etc.
>>>
>>> I recall there was some terminus issue, but I've replied to a few hundred
>>> posts since then...
>>>
>>> -Justin
>>>
>>> On 2/19/16 3:50 AM, Dries Van Rompaey wrote:
>>>
>>> Hi Justin,
>>>>
>>>> Sorry for the late reply. Haven't had a chance to look at this yet.
>>>> Could
>>>> you post your output files or compare the contents of yours to mine? I
>>>> chose Gromos 54a7 as my forcefield with the SPC water model. (command
>>>> line
>>>> is gmx pdb2gmx -f 1aki.pdb).
>>>> I'd like to know if this is a cosmetic issue or if something else is
>>>> going
>>>> on.
>>>>
>>>> My files can be found here:
>>>>
>>>> https://www.dropbox.com/sh/uapy2vxcprn0uje/AAA1TLME4czf8recVgV7U3koa?dl=0
>>>>
>>>> Thanks
>>>>
>>>> Dries
>>>>
>>>> On 1/20/16 3:48 AM, Dries Van Rompaey wrote:
>>>>
>>>> * Hi Justin and Marco,
>>>>>
>>>>> *>>* Thanks for your reply. I get this behaviour when I specify the

Re: [gmx-users] pdb2gmx with GROMOS

[Dries Van Rompaey]

Sure. I pasted my original mail at the bottom.
I also followed your suggestion of trying the gromacs-master ff files, with
identical results. What I'm trying to find out is why the warning is being
triggered and if it's affecting the output in any way. My input is the 1AKI
pdb file as downloaded from the pdb. I'm converting it to .gro with the
command gmx pdb2gmx -f 1AKI.pdb, selecting the gromos54a7 force field with
spc waters.

Dear gmx-users,

I'm experiencing the following warning while running pdb2gmx (gmx pdb2gmx
-f 1AKI.pdb), selecting any of the GROMOS force fields; all others work
fine. I get the same error with the -ignh flag.

WARNING: WARNING: Residue 1 named LYS of a molecule in the input file was
mapped
to an entry in the topology database, but the atom H used in
an interaction of type angle in that entry is not found in the
input file. Perhaps your atom and/or residue naming needs to be
fixed.

WARNING: WARNING: Residue 129 named LEU of a molecule in the input file was
mapped
to an entry in the topology database, but the atom O used in
an interaction of type angle in that entry is not found in the
input file. Perhaps your atom and/or residue naming needs to be
fixed.

I'm using gromacs 5.1.1 on mac os x. I looked at the rtp and
aminoacids.c.tbd/aminoacids.n.tbd files in top/gromos54A7, but I couldn't
discover any discrepancies. I also checked the angles in the topology, but
it looks like everything that should be applied, based on the contents of
the aminoacids.c.tbd/aminoacids.n.tbd files, seems to be applied.

 The system I'm working on is lysozyme (pdb code 1AKI). I'm assuming the
root cause of this warning is located somewhere in the
aminoacids.c.tbd/aminoacids.n.tbd files, as both residues are terminal
residues.

Can anyone replicate these warnings or does anyone know where they come
from?

Thanks in advance,

Dries



On 19 February 2016 at 14:06, Justin Lemkul <jalem...@vt.edu> wrote:

>
> Can you remind me of the context here?  You've provided output files that
> indicate everything is fine.  If there's a problem with *input* please
> provide those files, the exact command and selections, etc.
>
> I recall there was some terminus issue, but I've replied to a few hundred
> posts since then...
>
> -Justin
>
> On 2/19/16 3:50 AM, Dries Van Rompaey wrote:
>
>> Hi Justin,
>>
>> Sorry for the late reply. Haven't had a chance to look at this yet. Could
>> you post your output files or compare the contents of yours to mine? I
>> chose Gromos 54a7 as my forcefield with the SPC water model. (command line
>> is gmx pdb2gmx -f 1aki.pdb).
>> I'd like to know if this is a cosmetic issue or if something else is going
>> on.
>>
>> My files can be found here:
>> https://www.dropbox.com/sh/uapy2vxcprn0uje/AAA1TLME4czf8recVgV7U3koa?dl=0
>>
>> Thanks
>>
>> Dries
>>
>> On 1/20/16 3:48 AM, Dries Van Rompaey wrote:
>>
>>> * Hi Justin and Marco,
>>>
>> *>>* Thanks for your reply. I get this behaviour when I specify the
>> default NH3+
>> *>* and COO- termini through -ter, as well as when I don't use the -ter
>> flag.
>> *>* Selecting the COOH terminus type removed the warning for the
>> C-terminus,
>> *>* but selecting the NH2 terminus type did't remove the warning for the
>> *>* N-terminus. That's not a very physiological state, however.
>> *>>* Can anyone replicate this error?
>> *>
>> I can't trigger the same with 5.1 or with current git master.  Try from a
>> fresh
>> install and make sure no one has messed with your force field files.
>>
>> -Justin
>>
>> --
>>
>>
> --
> ==
>
> Justin A. Lemkul, Ph.D.
> Ruth L. Kirschstein NRSA Postdoctoral Fellow
>
> Department of Pharmaceutical Sciences
> School of Pharmacy
> Health Sciences Facility II, Room 629
> University of Maryland, Baltimore
> 20 Penn St.
> Baltimore, MD 21201
>
> jalem...@outerbanks.umaryland.edu | (410) 706-7441
> http://mackerell.umaryland.edu/~jalemkul
>
> ==
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] correct rlist and Verlet scheme

[Dries Van Rompaey]

Hi,

You have to take into account that your box-solute distance is applied on
both sides of your solute. This means that your minimum periodic distance
will be 2*box-solute distance.

Regards

Dries
On 19 Feb 2016 1:21 p.m., "Timofey Tyugashev" 
wrote:

> And here my hope for quick and  easy solution hath end.
> All of the points you make ring true. Especially ones about software
> engineering and funding in science (or maybe I'm more familiar with them).
>
> Actually, ne relatively recent paper, "Phosphorylation of PPARγ Affects
> the Collective Motions of the PPARγ-RXRα-DNA Complex" (
> http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0123984#sec008),
> uses AMBER99SB-ILDN with GROMACS 4.6 and Justin Lemkul is listed as the
> first author. And the simulated structure is a protein-DNA complex. So it
> should be very close to my case.
> The one thing that looks strange to me: both rvdw (LJ interacions) and
> box-solute distance set at 1.0 nm. Shouldn't the latter be larger to avoid
> probable periodic image interactions problems?
> Otherwise, looks like my settings are generally the same, except
> forgetting that LINCS allows 2fs step.
>
>
> 17.02.2016 19:45, gromacs.org_gmx-users-requ...@maillist.sys.kth.se пишет:
>
>> Message: 4
>> Date: Wed, 17 Feb 2016 13:45:46 +
>> From: Mark Abraham
>> To:gmx-us...@gromacs.org,gromacs.org_gmx-users@maillist.sys.kth.se
>> Subject: Re: [gmx-users] correct rlist and Verlet scheme
>> Message-ID:
>> <
>> camnumarkusmbzbrvneie35aahdwkpo-mgbejewxzgpueew6...@mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> Hi,
>>
>> Yes, what you say is true, but very much "in short" and AFAIK true of all
>> MD packages.:-)
>>
>> If e.g. AMBER (or anyone else) has a test suite for any force field, then
>> we'll seriously consider implementing it, to e.g. verify before each
>> release.:-)  IMO, defining such a suite is a research topic itself -
>> particularly as the original parameterizations did so in the context of
>> limitations in the methods of the day. If a force field was parameterized
>> with a fixed buffer because nobody then knew how large a buffer was
>> necessary for a given quality of relevant observable, it does not follow
>> that the only possible acceptable practice now is to use that fixed
>> buffer.
>>
>> Similar considerations apply to things like e.g. the use of long-ranged
>> corrections for dispersion interactions. e.g. AMBER99 was parameterized
>> without such corrections, so probably has built into its parameters some
>> compensating errors, and any kind of validation-by-replication should in
>> principle not use such corrections. But these days, I think that nobody
>> would actually recommend parameterizing a force field without something
>> like that, and experience suggests that using one is an improvement, even
>> if though the change is not officially sanctioned anywhere that I know of.
>> IMO showing that some range of force fields shows satisfactory agreement
>> with experiment under certain .mdp setting combinations is useful evidence
>> of an implementation that is valid, and that is what one can see in the
>> literature.
>>
>> The state of the art in software engineering is that nobody much has time
>> to test all the things that they'd like to test. (One large exception is
>> software for control of devices that potentially affect human health.)
>> Scientific software development has additional challenges because the
>> people doing it are often lacking in formal training in best practice, and
>> have to appear to publish science, in order to keep attracting funding,
>> and
>> this directly conflicts with spending time on good software engineering
>> practice that granting and tenure committees will ignore later in their
>> careers...
>>
>> Mark
>>
>> On Wed, Feb 17, 2016 at 1:01 PM Timofey Tyugashev> >
>> wrote:
>>
>> >In short, FFs were tested to some degree when they were added in GROMACS
>>> >to reproduce AMBER results, but there is no certainty if they actually
>>> >do this now and 'correct' mdp settings to run them are unknown. For any
>>> >of the versions that are listed in GROMACS.
>>> >Is that correct, or I'm missing something in translation?
>>> >
>>> >16.02.2016 18:03,gromacs.org_gmx-users-requ...@maillist.sys.kth.se
>>> ?:
>>>
 > >Message: 2
 > >Date: Tue, 16 Feb 2016 11:23:06 +
 > >From: Mark Abraham
 > >To:gmx-us...@gromacs.org,gromacs.org_gmx-users@maillist.sys.kth.se
 > >Subject: Re: [gmx-users] gromacs.org_gmx-users Digest, Vol 142, Issue
 > >   76
 > >Message-ID:
 > >   <

>>> >camnumasutdhr8sot1qt4xdczogsdjsfgo8umiuhrpffxxfa...@mail.gmail.com>
>>>
 > >Content-Type: text/plain; charset=UTF-8
 > >
 > >Hi,
 > >
 > >The ports of all the AMBER force fields were all tested to reproduce

>>> >AMBER
>>>
 > >when when they 

[gmx-users] pdb2gmx with GROMOS

[Dries Van Rompaey]

Hi Justin,

Sorry for the late reply. Haven't had a chance to look at this yet. Could
you post your output files or compare the contents of yours to mine? I
chose Gromos 54a7 as my forcefield with the SPC water model. (command line
is gmx pdb2gmx -f 1aki.pdb).
I'd like to know if this is a cosmetic issue or if something else is going
on.

My files can be found here:
https://www.dropbox.com/sh/uapy2vxcprn0uje/AAA1TLME4czf8recVgV7U3koa?dl=0

Thanks

Dries

On 1/20/16 3:48 AM, Dries Van Rompaey wrote:
>* Hi Justin and Marco,
*>>* Thanks for your reply. I get this behaviour when I specify the default NH3+
*>* and COO- termini through -ter, as well as when I don't use the -ter flag.
*>* Selecting the COOH terminus type removed the warning for the C-terminus,
*>* but selecting the NH2 terminus type did't remove the warning for the
*>* N-terminus. That's not a very physiological state, however.
*>>* Can anyone replicate this error?
*>
I can't trigger the same with 5.1 or with current git master.  Try from a fresh
install and make sure no one has messed with your force field files.

-Justin

--
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Fwd: FW: PME settings in free energy calculations

[Dries Van Rompaey]

Hi Mark,

Thanks for the clarification. I did use the rerun option as described in
the link you provided.
I uploaded my log files here:
https://www.dropbox.com/sh/tcmqhn5fszeis27/AABcYOI6_FrjG7qoYJycf_35a?dl=0

Thanks for your time,
Kind regards

Dries

On 9 February 2016 at 09:20, Mark Abraham <mark.j.abra...@gmail.com> wrote:

> Hi,
>
> On Fri, Feb 5, 2016 at 1:32 PM Dries Van Rompaey <
> dries.vanromp...@gmail.com>
> wrote:
>
> > Hi,
> >
> > The corresponding mdp output section is:
> >
> > ; OPTIONS FOR ELECTROSTATICS AND VDW
> > ; Method for doing electrostatics
> > coulombtype  = PME
> > coulomb-modifier = Potential-shift-Verlet
> > rcoulomb-switch  = 0
> > rcoulomb = 1.0
> > ; Relative dielectric constant for the medium and the reaction field
> > epsilon-r= 1
> > epsilon-rf   = 0
> > ; Method for doing Van der Waals
> > vdwtype  = cutoff
> > vdw-modifier = Potential-switch
> > ; cut-off lengths
> > rvdw-switch  = 0.9
> > rvdw = 1.0
> > ; Apply long range dispersion corrections for Energy and Pressure
> > DispCorr = EnerPres
> > ; Extension of the potential lookup tables beyond the cut-off
> > table-extension  = 1
> > ; Separate tables between energy group pairs
> > energygrp-table  =
> > ; Spacing for the PME/PPPM FFT grid
> > fourierspacing   = 0.08
> > ; FFT grid size, when a value is 0 fourierspacing will be used
> > fourier-nx   = 0
> > fourier-ny   = 0
> > fourier-nz   = 0
> > ; EWALD/PME/PPPM parameters
> > pme_order= 6
> > ewald_rtol   = 1e-06
> > ewald-rtol-lj= 0.001
> > lj-pme-comb-rule = Geometric
> > ewald-geometry   = 3d
> > epsilon_surface  = 0
>
>
> That all seems reasonable.
>
>
> > I evaluated the energy with:
> >
> > Verlet - settings above (with standard verlet-buffer-tolerance)
> > @ s0 legend "Coulomb-14"
> > @ s1 legend "Coulomb (SR)"
> > @ s2 legend "Coul. recip."
> > 0.00  -2221.295898  -546205.25  9271.518555
> > Total - 539155.0273
> >
> > Verlet - settings above - with verlet-buffer-tolerance -1
> > 0.00  -2221.295898  -546205.25  9271.516602
> > Total   -539155.029296
> >
>
> That kind of agreement is expected, but perhaps might agree exactly if you
> were following
> http://www.gromacs.org/Documentation/How-tos/Single-Point_Energy
>
> Group - settings above
> > @ s0 legend "Coulomb-14"
> > @ s1 legend "Coulomb (SR)"
> > @ s2 legend "Coul. recip."
> > 0.00  -2221.296387  -487993.593750  -48931.437500
> > Total -539146.3276
> >
>
> The difference in those components is expected - in PME you have to avoid
> counting contributions in the long-range part from pairs that are excluded
> e.g. from the bonded topology. The two schemes handle this in different
> places. Their sum should match (within the limits of floating-point
> arithmetic), and a relative error under 1e-5 for summing a few million
> numbers is acceptable for judging the equivalence of the implementations.
>
> Verlet - 3 nm cutoffs, 2.9 vdwswitch, coulomb-modifier none
> > @ s0 legend "Coulomb-14"
> > @ s1 legend "Coulomb (SR)"
> > 0.00  -2221.295898  -774817.875000
> > Total -777039.1709
> >
> >
> > Group - 3 nm cutoffs, 2.9 vdwswitch, coulomb-modifier none
> > @ s0 legend "Coulomb-14"
> > @ s1 legend "Coulomb (SR)"
> > 0.00  -2221.296387  -553398.125000
> > Total -555619.4214
> >
>
> That ought to agree much better, but It's hard to speculate on where the
> problem lies without seeing log files. Please upload some to a file sharing
> service and post the links here (list doesn't take attachments)
>
> Mark
>
>
> > Thanks,
> >
> > Dries
> >
> > On 4 February 2016 at 14:48, Michael Shirts <mrshi...@gmail.com> wrote:
> >
> > > Also, can you be more precise about the inconsistency in the outputs
> > > you are seeing (with numerical output from GROMACS and analysis code).
> > >
> > > On Thu, Feb 4, 2016 at 6:17 AM, Michael Shirts <mrshi...@gmail.com>
> > wrote:
> > > > Hi, Dries-
> > > >
> > > > Can you print out what the corresponding section of mdout.md

Re: [gmx-users] Fwd: FW: PME settings in free energy calculations

[Dries Van Rompaey]

Hi Mark,

Thanks for your pointers. The energies obtained with a shifted potential
match up a lot better.

Kind regards

Dries

On 9 February 2016 at 14:30, Mark Abraham <mark.j.abra...@gmail.com> wrote:

> Hi,
>
> On Tue, Feb 9, 2016 at 1:30 PM Dries Van Rompaey <
> dries.vanromp...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I'm not deliberately triggering the generic kernel.
>
>
> OK, well that means its a setup that we have deliberately not tried to make
> fast in the group scheme, because it's too hard to do for the expected
> usefulness.
>
>
> > I unfortunately have no
> > idea what's causing that. I uploaded logfiles for a setup with matching
> > cutoffs as setup3alt and setup2alt (I got quite a lot of warnings for
> this
> > setup, which is why I initially changed the cutoffs slightly).
> >
> > I'm a bit baffled what could cause the large difference between the
> verlet
> > setup with long cutoffs and the verlet setup with shorter cutoffs and
> PME..
> > After all, that's the one that should be fairly close in order to prove
> my
> > electrostatics treatment is appropriate. This difference seems to be a
> lot
> > more pronounced than the difference to the group scheme.
> >
>
> That's the easy one. You're comparing potentials from Verlet PME with a
> short-ranged potential shift with Verlet plain cutoffs with no potential
> shift. The shift is quite small with PME (that's what ewald-rtol is all
> about) but it applies to every single in-range interaction. Your
> long-cutoff calculation has a cutoff that is only ~3 times longer than the
> modified short-ranged form you used with PME. That increase in range is not
> going to get down to 1e-5 relative error from truncation at the cutoff, and
> it also applies to a lot more interactions. I expect that this is
> confounding all your comparisons with Verlet+PME - you need to compare with
> a scheme with a potential shift. (This also leads people astray when they
> are e.g. comparing total energies between GROMACS and codes that don't use
> the potential shift.)
>
> Whether such comparisons as alchemistry.org suggests worked reasonably
> well
> with Group+PME vs Group+long-cutoff (because neither used a potential
> shift) with current or old code, I don't know.
>
> Mark
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Fwd: FW: PME settings in free energy calculations

[Dries Van Rompaey]

Hi,

I'm not deliberately triggering the generic kernel. I unfortunately have no
idea what's causing that. I uploaded logfiles for a setup with matching
cutoffs as setup3alt and setup2alt (I got quite a lot of warnings for this
setup, which is why I initially changed the cutoffs slightly).

I'm a bit baffled what could cause the large difference between the verlet
setup with long cutoffs and the verlet setup with shorter cutoffs and PME..
After all, that's the one that should be fairly close in order to prove my
electrostatics treatment is appropriate. This difference seems to be a lot
more pronounced than the difference to the group scheme.

Thanks,

Dries

On 9 February 2016 at 11:06, Mark Abraham <mark.j.abra...@gmail.com> wrote:

> Hi,
>
> Runs 2 and 3 are using different rvdw and rvdw-switch, which doesn't seem
> like the comparison you should want to make. However that should not affect
> the Coulomb calculation at all - and certainly not to this degree. What do
> you see when it matches? I notice that somehow you are triggering the use
> of the generic nonbonded kernel - is that deliberate by you?
>
> The group scheme plus rvdw != rcoulomb plus a switch could well be a
> combination that got broken at some point. I tried to verify such
> equivalence before we released 5.0, but I could well have missed some. If
> so, the rerun with 4.5.7 would be instructive. (Michael's advice on
> alchemistry.org is largely based on 4.5-era GROMACS).
>
> Mark
>
> On Tue, Feb 9, 2016 at 9:51 AM Dries Van Rompaey <
> dries.vanromp...@gmail.com>
> wrote:
>
> > Hi Mark,
> >
> > Thanks for the clarification. I did use the rerun option as described in
> > the link you provided.
> > I uploaded my log files here:
> >
> https://www.dropbox.com/sh/tcmqhn5fszeis27/AABcYOI6_FrjG7qoYJycf_35a?dl=0
> >
> > Thanks for your time,
> > Kind regards
> >
> > Dries
> >
> > On 9 February 2016 at 09:20, Mark Abraham <mark.j.abra...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > On Fri, Feb 5, 2016 at 1:32 PM Dries Van Rompaey <
> > > dries.vanromp...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > The corresponding mdp output section is:
> > > >
> > > > ; OPTIONS FOR ELECTROSTATICS AND VDW
> > > > ; Method for doing electrostatics
> > > > coulombtype  = PME
> > > > coulomb-modifier = Potential-shift-Verlet
> > > > rcoulomb-switch  = 0
> > > > rcoulomb = 1.0
> > > > ; Relative dielectric constant for the medium and the reaction field
> > > > epsilon-r= 1
> > > > epsilon-rf   = 0
> > > > ; Method for doing Van der Waals
> > > > vdwtype  = cutoff
> > > > vdw-modifier = Potential-switch
> > > > ; cut-off lengths
> > > > rvdw-switch  = 0.9
> > > > rvdw = 1.0
> > > > ; Apply long range dispersion corrections for Energy and Pressure
> > > > DispCorr = EnerPres
> > > > ; Extension of the potential lookup tables beyond the cut-off
> > > > table-extension  = 1
> > > > ; Separate tables between energy group pairs
> > > > energygrp-table  =
> > > > ; Spacing for the PME/PPPM FFT grid
> > > > fourierspacing   = 0.08
> > > > ; FFT grid size, when a value is 0 fourierspacing will be used
> > > > fourier-nx   = 0
> > > > fourier-ny   = 0
> > > > fourier-nz   = 0
> > > > ; EWALD/PME/PPPM parameters
> > > > pme_order= 6
> > > > ewald_rtol   = 1e-06
> > > > ewald-rtol-lj= 0.001
> > > > lj-pme-comb-rule = Geometric
> > > > ewald-geometry   = 3d
> > > > epsilon_surface  = 0
> > >
> > >
> > > That all seems reasonable.
> > >
> > >
> > > > I evaluated the energy with:
> > > >
> > > > Verlet - settings above (with standard verlet-buffer-tolerance)
> > > > @ s0 legend "Coulomb-14"
> > > > @ s1 legend "Coulomb (SR)"
> > > > @ s2 legend "Coul. recip."
> > > > 0.00  -2221.295898  -546205.25  9271.518555
> > > > Total - 539155.0273
> > > >
> > > > Verlet - settings above - with verlet-buffer-tolerance -1
&

Re: [gmx-users] Fwd: FW: PME settings in free energy calculations

[Dries Van Rompaey]

Hi,

The corresponding mdp output section is:

; OPTIONS FOR ELECTROSTATICS AND VDW
; Method for doing electrostatics
coulombtype  = PME
coulomb-modifier = Potential-shift-Verlet
rcoulomb-switch  = 0
rcoulomb = 1.0
; Relative dielectric constant for the medium and the reaction field
epsilon-r= 1
epsilon-rf   = 0
; Method for doing Van der Waals
vdwtype  = cutoff
vdw-modifier = Potential-switch
; cut-off lengths
rvdw-switch  = 0.9
rvdw = 1.0
; Apply long range dispersion corrections for Energy and Pressure
DispCorr = EnerPres
; Extension of the potential lookup tables beyond the cut-off
table-extension  = 1
; Separate tables between energy group pairs
energygrp-table  =
; Spacing for the PME/PPPM FFT grid
fourierspacing   = 0.08
; FFT grid size, when a value is 0 fourierspacing will be used
fourier-nx   = 0
fourier-ny   = 0
fourier-nz   = 0
; EWALD/PME/PPPM parameters
pme_order= 6
ewald_rtol   = 1e-06
ewald-rtol-lj= 0.001
lj-pme-comb-rule = Geometric
ewald-geometry   = 3d
epsilon_surface  = 0


I evaluated the energy with:

Verlet - settings above (with standard verlet-buffer-tolerance)
@ s0 legend "Coulomb-14"
@ s1 legend "Coulomb (SR)"
@ s2 legend "Coul. recip."
0.00  -2221.295898  -546205.25  9271.518555
Total - 539155.0273

Verlet - settings above - with verlet-buffer-tolerance -1
0.00  -2221.295898  -546205.25  9271.516602
Total   -539155.029296


Group - settings above
@ s0 legend "Coulomb-14"
@ s1 legend "Coulomb (SR)"
@ s2 legend "Coul. recip."
0.00  -2221.296387  -487993.593750  -48931.437500
Total -539146.3276


Verlet - 3 nm cutoffs, 2.9 vdwswitch, coulomb-modifier none
@ s0 legend "Coulomb-14"
@ s1 legend "Coulomb (SR)"
0.00  -2221.295898  -774817.875000
Total -777039.1709


Group - 3 nm cutoffs, 2.9 vdwswitch, coulomb-modifier none
@ s0 legend "Coulomb-14"
@ s1 legend "Coulomb (SR)"
0.00  -2221.296387  -553398.125000
Total -555619.4214

Thanks,

Dries

On 4 February 2016 at 14:48, Michael Shirts <mrshi...@gmail.com> wrote:

> Also, can you be more precise about the inconsistency in the outputs
> you are seeing (with numerical output from GROMACS and analysis code).
>
> On Thu, Feb 4, 2016 at 6:17 AM, Michael Shirts <mrshi...@gmail.com> wrote:
> > Hi, Dries-
> >
> > Can you print out what the corresponding section of mdout.mdp look like?
> >
> > Have you  tried using the cutoffs above with group cutoffs, and seen
> > what the difference is?
> >
> > On Thu, Feb 4, 2016 at 4:59 AM, Dries Van Rompaey
> > <dries.vanromp...@gmail.com> wrote:
> >> Hi,
> >>
> >> I'm using PME with the default Potential-Shift-Verlet modifier. If I'm
> >> interpreting the manual and comments on the mailinglist correctly, the
> >> settings for rcoulomb-switch shouldn't affect this and PME-switching
> >> shouldn't be necessary (although there seems to have been some
> discussion
> >> about this, https://gerrit.gromacs.org/#/c/2220/). Has a consensus been
> >> reached elsewhere?
> >>
> >> Current nonbonded settings in my .mdp files are:
> >> ; Electrostatics
> >> coulombtype  = PME
> >> rcoulomb= 1.0
> >>
> >> ; van der Waals
> >> vdwtype= cutoff
> >> vdw-modifier= Potential-switch
> >> rvdw-switch  = 0.9
> >> rvdw = 1.0
> >>
> >> ; Apply long range dispersion corrections for Energy and Pressure
> >> DispCorr  = EnerPres
> >>
> >> ; Spacing for the PME/PPPM FFT grid
> >> fourierspacing   = 0.08
> >>
> >> ; EWALD/PME/PPPM parameters
> >> pme_order= 6
> >> ewald_rtol = 1e-06
> >> epsilon_surface= 0
> >>
> >> Thanks in advance,
> >>
> >> Dries
> >>
> >> On 4 February 2016 at 00:56, Michael Shirts <mrshi...@gmail.com> wrote:
> >>
> >>> Hi, Dries-
> >>>
> >>> Questions like this are probably best answered on the gmx-users list.
> >>> I can't say too much for the Verlet scheme -- I know that it was
> >>> relatively recently adapted for free energies, and there may be some
> >>> combinations of settings that could give unanticipated r

Re: [gmx-users] Fwd: FW: PME settings in free energy calculations

[Dries Van Rompaey]

Hi,

I'm using PME with the default Potential-Shift-Verlet modifier. If I'm
interpreting the manual and comments on the mailinglist correctly, the
settings for rcoulomb-switch shouldn't affect this and PME-switching
shouldn't be necessary (although there seems to have been some discussion
about this, https://gerrit.gromacs.org/#/c/2220/). Has a consensus been
reached elsewhere?

Current nonbonded settings in my .mdp files are:
; Electrostatics
coulombtype  = PME
rcoulomb= 1.0

; van der Waals
vdwtype= cutoff
vdw-modifier= Potential-switch
rvdw-switch  = 0.9
rvdw = 1.0

; Apply long range dispersion corrections for Energy and Pressure
DispCorr  = EnerPres

; Spacing for the PME/PPPM FFT grid
fourierspacing   = 0.08

; EWALD/PME/PPPM parameters
pme_order= 6
ewald_rtol = 1e-06
epsilon_surface= 0

Thanks in advance,

Dries

On 4 February 2016 at 00:56, Michael Shirts  wrote:

> Hi, Dries-
>
> Questions like this are probably best answered on the gmx-users list.
> I can't say too much for the Verlet scheme -- I know that it was
> relatively recently adapted for free energies, and there may be some
> combinations of settings that could give unanticipated results.
>
> Pretty much all of our experience about nonbonded calculations and
> free energies is collected in the following paper:
> http://pubs.acs.org/doi/abs/10.1021/ct4005068. We used the group
> cutoff scheme since that was the only one that was supported in
> GROMACS at the time.
>
> Since you haven't sent any files, it's hard to tell what is actually
> going on. The one thing that has a tendency to happen with the more
> recent update schemes is if you set a potential modifier that is a
> switch, but don't set the distance the switch starts at, then it is
> automatically set to zero.  Check the mdout.mdp to see if this is
> happening.
>
> > From: Van Rompaey Dries 
> Date: Wednesday, February 3, 2016 at 12:34 PM
> To: Michael Shirts 
> Subject: PME settings in free energy calculations
>
> Dear prof. Shirts,
>
> I'm currently trying to figure out the PME settings for a relative
> free binding energy simulation I'm working on. I took the parameters
> from Matteo Aldeghi's
> paper(
> http://pubs.rsc.org/en/content/articlelanding/2015/sc/c5sc02678d#!divAbstract
> )
> as a starting point (adapted for the Verlet scheme by scaling the
> fourierspacing to 0.08 and setting coulomb = rvdw = 1.0). I then tried
> to verify these settings by comparing a single point energy
> calculation with these settings and one with very long coulomb cutoffs
> as recommended on alchemistry.org.
>
> Unfortunately, I can't seem to get this quite right. I'm getting
> differences in the hundreds of kj/mol, leading me to suspect I'm doing
> something wrong. I'm calculating the energy values by extracting
> CoulombSR and Coul-recip from the energy.xvg files. I've tried
> calculating the energy with coulomb cutoffs at 3 nm and 10 nm, but
> agreement with the PME results remains rather poor. David Mobley
> mentioned you performed extensive research on this topic, and I'm
> hoping you could point me in the right direction.
>
> Thanks in advance,
>
> Dries
>
>
>
> 
> Michael Shirts
> Associate Professor
> michael.shi...@colorado.edu
> Phone: (303) 735-7860
> Office: JSCBB D317
> Department of Chemical and Biological Engineering
> University of Colorado Boulder
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Laptop features for MD simulations - recommendations

[Dries Van Rompaey]

Hi Yasser,

Could you give us an idea of the price range you're looking at? I'd
probably try to get a laptop with a decent gpu to accelerate your work as
much as possible. Unfortunately, such laptops are often pricy.

Kind regards

Dries

On 3 February 2016 at 11:17, Yasser Almeida Hernández <
yasser.almeida.hernan...@chemie.uni-hamburg.de> wrote:

> Dear Joao,
>
> I am aware that laptops are not the proper hardware to run MD simulations.
> I do my runs in workstations designed for that purpose. The hardware I want
> to buy is not just for simulations, but for general private/work purpose,
> but I would like to have a device robust enough to run calculations. My
> question was to get some thoughts about an ideal/optimal hardware.
>
> Best
>
> Yasser
>
> 
> Message: 6
> Date: Wed, 3 Feb 2016 10:53:31 +0100
> From: Jo?o Henriques 
> To: Discussion list for GROMACS users 
> Subject: Re: [gmx-users] Laptop features for MD simulations -
> recommendations
> Message-ID:
> <
> calc+hgt7zsmbkwitu11dprvh4m_qyw2btkgnsq2tvb70o71...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Dear Yasser,
>
> I am by no means an expert on hardware, but I would strongly advise against
> buying a laptop for the specific purpose of running (any and all) MD
> simulations. A desktop is much better suited platform for such a task, as
> you should be able to get a much bigger bang for your buck (this is the
> main reason, but there are more cons).
>
> Notice that I am not saying that you cannot run MD simulations on a laptop,
> I'm just advising against it. In fact, you could probably run MD
> simulations on a smartphone if you wanted to, but it doesn't sound like a
> very good investment of your time and money. In my *personal opinion*, the
> same holds true for the laptop.
>
> Best regards,
> /J
>
> On Wed, Feb 3, 2016 at 10:30 AM, Yasser Almeida Hern?ndez <
> yasser.almeida.hernan...@chemie.uni-hamburg.de> wrote:
>
> Hi all,
>>
>> I want to buy a laptop suitable and powerful enough for MD simulations
>> with GROMACS (mostly membrane/protein systems). Could you recommend
>> optimal
>> features for this goal?
>>
>> Thanks
>>
>> Yasser
>>
>> --
>> Yasser Almeida Hern?ndez
>> PhD student
>> Institute of Biochemistry and Molecular Biology
>> Department of Chemistry
>> University of Hamburg
>> Martin-Luther-King-Platz 6
>> 20146 Hamburg
>> Germany
>> +49 40 42838 2845
>> yasser.almeida.hernan...@chemie.uni-hamburg.de
>> office: Grindelallee 117, room 250c
>>
>> --
>> Gromacs Users mailing list
>>
>> * Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
>> posting!
>>
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
>> send a mail to gmx-users-requ...@gromacs.org.
>>
>
>
> --
>
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
> End of gromacs.org_gmx-users Digest, Vol 142, Issue 14
> **
>
>
>
>
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] How to visualizing gro file in pymol

[Dries Van Rompaey]

Hi,

Your tpr file only has information on the starting configuration (because
it's a file that stores everything you need to start your simulation, not a
file that contains your output). Your end point .gro file can be converted
into a pdb through editconf as well.

However, a better approach would be to visualise your trajectory (.trr or
.xtc) using trjconv (http://manual.gromacs.org/programs/gmx-trjconv.html).


Kind regards

Dries

On 3 February 2016 at 11:33, anu chandra  wrote:

> Hello all,
>
> I just finished a short simulation of a membrane protein system and trying
> to visualize the final gro file generated from the simulation using Pymol.
> Unfortunately, the Pymol failed to visualize the protein in cartoon
> representation. Though VMD can do the job, I just wonder is there a way I
> can visualize the gro file in Pymol. A quick surfing on web suggested to
> use the editconf to convert the .tpr file to .pdb file for visualizing with
> Pymol. Unfortunately, here the .tpr file have structural information from
> the beginning of the simulation rather than at the end of the simulation.
>
>
> Any suggestion would be very much appreciated.
>
>
> Many thanks
> Anu
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-requ...@gromacs.org.
>
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Laptop features for MD simulations - recommendations

[Dries Van Rompaey]

Hi,

Just to expand a bit on Szilárd’s excellent answer, you can find a list of 
benchmarks for mobile cards here:
http://www.notebookcheck.net/Mobile-Graphics-Cards-Benchmark-List.844.0.html

Kind regards

Dries


> On 03 Feb 2016, at 15:14, Szilárd Páll  wrote:
> 
> Hi,
> 
> What exactly do you want from the laptop besides performance?
> Autonomy, weight, size restrictions?
> 
> If you want something with a decent amount of autonomy, just get a
> high-end Skylake laptop and do your runs on your workstation or
> cluster. If you care about battery time, you may as well forget about
> a powerful system (even a standalone GPU may not be worth it unless
> you can get switchable graphics) - or at least plan to put effort into
> avoiding high CPU/GPU load when on battery.
> 
> If you want max performance, get a beast that's often referred to as
> "portable workstation" with a high-performance CPU (not 15W part) and
> a GTX 970M or 980M. AFAIK NVIDIAs site has a section where they
> advertise gaming laptops with these high-end mobile chips.
> 
> Unless you want to suffer with Windows, I'd also recommend looking
> around before buying and making sure that you don't end up with some
> niche hardware that does not run well under GNU/Linux. I can highly
> recommend System76, they have some monsters too - I have even seen
> recently a rave review about a portable workstation they offer with a
> desktop CPU.
> 
> Cheers,
> --
> Szilárd
> 
> 
> 
> On Wed, Feb 3, 2016 at 11:17 AM, Yasser Almeida Hernández
>  wrote:
>> Dear Joao,
>> 
>> I am aware that laptops are not the proper hardware to run MD simulations. I
>> do my runs in workstations designed for that purpose. The hardware I want to
>> buy is not just for simulations, but for general private/work purpose, but I
>> would like to have a device robust enough to run calculations. My question
>> was to get some thoughts about an ideal/optimal hardware.
>> 
>> Best
>> 
>> Yasser
>> 
>> 
>> Message: 6
>> Date: Wed, 3 Feb 2016 10:53:31 +0100
>> From: Jo?o Henriques 
>> To: Discussion list for GROMACS users 
>> Subject: Re: [gmx-users] Laptop features for MD simulations -
>>recommendations
>> Message-ID:
>>
>> Content-Type: text/plain; charset=UTF-8
>> 
>> Dear Yasser,
>> 
>> I am by no means an expert on hardware, but I would strongly advise against
>> buying a laptop for the specific purpose of running (any and all) MD
>> simulations. A desktop is much better suited platform for such a task, as
>> you should be able to get a much bigger bang for your buck (this is the
>> main reason, but there are more cons).
>> 
>> Notice that I am not saying that you cannot run MD simulations on a laptop,
>> I'm just advising against it. In fact, you could probably run MD
>> simulations on a smartphone if you wanted to, but it doesn't sound like a
>> very good investment of your time and money. In my *personal opinion*, the
>> same holds true for the laptop.
>> 
>> Best regards,
>> /J
>> 
>> On Wed, Feb 3, 2016 at 10:30 AM, Yasser Almeida Hern?ndez <
>> yasser.almeida.hernan...@chemie.uni-hamburg.de> wrote:
>> 
>>> Hi all,
>>> 
>>> I want to buy a laptop suitable and powerful enough for MD simulations
>>> with GROMACS (mostly membrane/protein systems). Could you recommend
>>> optimal
>>> features for this goal?
>>> 
>>> Thanks
>>> 
>>> Yasser
>>> 
>>> --
>>> Yasser Almeida Hern?ndez
>>> PhD student
>>> Institute of Biochemistry and Molecular Biology
>>> Department of Chemistry
>>> University of Hamburg
>>> Martin-Luther-King-Platz 6
>>> 20146 Hamburg
>>> Germany
>>> +49 40 42838 2845
>>> yasser.almeida.hernan...@chemie.uni-hamburg.de
>>> office: Grindelallee 117, room 250c
>>> 
>>> --
>>> Gromacs Users mailing list
>>> 
>>> * Please search the archive at
>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
>>> posting!
>>> 
>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>> 
>>> * For (un)subscribe requests visit
>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
>>> send a mail to gmx-users-requ...@gromacs.org.
>> 
>> 
>> 
>> --
>> 
>> --
>> Gromacs Users mailing list
>> 
>> * Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!
>> 
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> 
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a
>> mail to gmx-users-requ...@gromacs.org.
>> 
>> End of gromacs.org_gmx-users Digest, Vol 142, Issue 14
>> **
>> 
>> 
>> 
>> 
>> --
>> Gromacs Users mailing list
>> 
>> * Please search the archive at
>> 

[gmx-users] Verlet scheme and relative free binding energy

[Dries Van Rompaey]

Hi gmx-users,

I have a question regarding the correct treatment of cut-offs for
amber99sb-ildn in relative free binding energy calculations, using the
verlet scheme. Many articles seem to use a 1.2 nm cutoff for coulomb
interactions and a vdw interaction switched off between 0.9 and 1 nm (for
instance: DOI: 10.1039/c5sc02678d). However, this setup is only possible
with the now deprecated group scheme.

I haven't been able to find any papers using amber99sb-ildn for relative
free energy calculations with a setup suitable for verlet scheme. Does
anyone have experience with such a setup for relative free binding energy
calculations?

Thanks in advance,

Dries
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

[gmx-users] Logfile incorrectly (?) has dVbonded/dl terms

[Dries Van Rompaey]

Hi gmx-users,

I'm currently using FEP introduce a small change in my molecule. As a first
step, I'm simply removing the coulomb interactions for the part that's
being transformed into dummies. No other interactions are being modified.

However, in my logfile I find:
Bond  AngleProper Dih.  Improper Dih.  LJ-14
9.44315e+011.50317e+021.02598e+025.65505e+007.01417e+01
Coulomb-14LJ (SR)  Disper. corr.   Coulomb (SR)   Coul. recip.
-2.09477e+031.55917e+04   -5.21597e+02   -1.17294e+059.63595e+02
PotentialKinetic En.   Total EnergyTemperature Pres. DC (bar)
-1.02932e+051.92182e+04   -8.37142e+042.99969e+02   -1.11454e+02
Pressure (bar)   dEkin/dl  dVcoul/dl   dVvdw/dldVbonded/dl
8.26672e-010.0e+00   -4.21612e+010.0e+001.50215e+01
dVrestraint/dl
0.0e+00

My lambda vectors are:
mass_lambdas = 0.00 0.00 0.00 0.00
coul_lambdas = 0.00 0.25 0.75 1.00
vdw_lambdas  = 0.00 0.00 0.00 0.00
bonded_lambdas   = 0.00 0.00 0.00 0.00
restraint_lambdas= 0.00 0.00 0.00 0.00
temperature_lambdas  = 0.00 0.00 0.00 0.00


I'm a bit confused by the dVbonded/dl in the logfile. Seeing as I'm not
doing anything to my bonded interactions, shouldn't that be zero?

Thanks,

Dries
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] pdb2gmx with GROMOS

[Dries Van Rompaey]

Hi Justin and Marco,

Thanks for your reply. I get this behaviour when I specify the default NH3+
and COO- termini through -ter, as well as when I don't use the -ter flag.
Selecting the COOH terminus type removed the warning for the C-terminus,
but selecting the NH2 terminus type did't remove the warning for the
N-terminus. That's not a very physiological state, however.

Can anyone replicate this error?

Kind regards

Dries
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

[gmx-users] Constraints in BAR

[Dries Van Rompaey]

Hello everyone,

I've got a question about the current implementation of BAR and
constraints.
Is the issue discussed in the following thread still a problem in current
versions of gromacs?

https://mailman-1.sys.kth.se/pipermail/gromacs.org_gmx-developers/2010-October/004841.html

Thanks in advance,

Dries
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] pdb2gmx error

[Dries Van Rompaey]

I did some more testing, it seems that this only occurs when the PRO
residue is preceded by a glycine. Could this be related to this issue:
http://comments.gmane.org/gmane.science.biology.gromacs.user/72687 ? When I
change the glycine residue to anything else, pdb2gmx works like a charm. I
constructed a simple test system in which I can replicate the error (see
below).


REMARK  99 MOE v2014.09 (Chemical Computing Group Inc.) Thu Oct 15 10:05:39
2015
ATOM  1  N   ALA 1   0.268  -1.146  -1.547  1.00  0.00
  N1+
ATOM  2  CA  ALA 1   0.506   0.327  -1.714  1.00  0.00
  C
ATOM  3  CB  ALA 1  -0.837   1.004  -1.931  1.00  0.00
  C
ATOM  4  C   ALA 1   1.226   0.877  -0.480  1.00  0.00
  C
ATOM  5  O   ALA 1   1.399   0.165   0.509  1.00  0.00
  O
ATOM  6  H1  ALA 1  -0.272  -1.324  -0.688  1.00  0.00
  H
ATOM  7  H2  ALA 1  -0.224  -1.571  -2.343  1.00  0.00
  H
ATOM  8  H3  ALA 1   1.161  -1.641  -1.413  1.00  0.00
  H
ATOM  9  HA  ALA 1   1.151   0.435  -2.592  1.00  0.00
  H
ATOM 10  HB1 ALA 1  -1.364   0.570  -2.788  1.00  0.00
  H
ATOM 11  HB2 ALA 1  -1.480   0.906  -1.049  1.00  0.00
  H
ATOM 12  HB3 ALA 1  -0.710   2.074  -2.125  1.00  0.00
  H
ATOM 13  N   GLY 2   1.667   2.171  -0.583  1.00  0.00
  N
ATOM 14  CA  GLY 2   2.390   2.835   0.493  1.00  0.00
  C
ATOM 15  C   GLY 2   2.792   4.221   0.005  1.00  0.00
  C
ATOM 16  O   GLY 2   2.258   4.706  -0.997  1.00  0.00
  O
ATOM 17  H   GLY 2   1.519   2.744  -1.415  1.00  0.00
  H
ATOM 18  HA1 GLY 2   1.730   2.918   1.361  1.00  0.00
  H
ATOM 19  HA2 GLY 2   3.269   2.234   0.743  1.00  0.00
  H
ATOM 20  N   PRO 3   3.764   4.872   0.730  1.00  0.00
  N
ATOM 21  CD  PRO 3   4.331   4.472   2.006  1.00  0.00
  C
ATOM 22  CG  PRO 3   4.793   5.786   2.610  1.00  0.00
  C
ATOM 23  CB  PRO 3   5.270   6.581   1.399  1.00  0.00
  C
ATOM 24  CA  PRO 3   4.347   6.129   0.260  1.00  0.00
  C
ATOM 25  C   PRO 3   5.168   5.908  -1.021  1.00  0.00
  C
ATOM 26  O   PRO 3   5.520   4.796  -1.412  1.00  0.00
  O
ATOM 27  HA  PRO 3   3.538   6.843   0.069  1.00  0.00
  H
ATOM 28  HB1 PRO 3   6.318   6.337   1.188  1.00  0.00
  H
ATOM 29  HB2 PRO 3   5.212   7.661   1.568  1.00  0.00
  H
ATOM 30  HG1 PRO 3   5.571   5.654   3.367  1.00  0.00
  H
ATOM 31  HG2 PRO 3   3.945   6.303   3.076  1.00  0.00
  H
ATOM 32  HD1 PRO 3   5.175   3.804   1.803  1.00  0.00
  H
ATOM 33  HD2 PRO 3   3.599   3.952   2.629  1.00  0.00
  H
ATOM 34  N   ALA 4   5.499   7.083  -1.656  1.00  0.00
  N
ATOM 35  CA  ALA 4   6.262   7.165  -2.905  1.00  0.00
  C
ATOM 36  CB  ALA 4   5.416   6.725  -4.094  1.00  0.00
  C
ATOM 37  C   ALA 4   6.738   8.618  -3.177  1.00  0.00
  C
ATOM 38  OXT ALA 4   7.513   8.768  -4.161  1.00  0.00
  O1-
ATOM 39  O   ALA 4   6.290   9.477  -2.354  1.00  0.00
  O
ATOM 40  H   ALA 4   5.250   8.002  -1.288  1.00  0.00
  H
ATOM 41  HA  ALA 4   7.137   6.512  -2.806  1.00  0.00
  H
ATOM 42  HB1 ALA 4   4.539   7.372  -4.215  1.00  0.00
  H
ATOM 43  HB2 ALA 4   5.988   6.759  -5.027  1.00  0.00
  H
ATOM 44  HB3 ALA 4   5.053   5.700  -3.965  1.00  0.00
  H
TER  45  ALA 4
END


On 8 October 2015 at 14:15, Dries Van Rompaey <dries.vanromp...@gmail.com>
wrote:

> I definitely agree that it's odd that the warning only occurs with this
> specific residue. I ran a diff against the freshly downloaded AMBER03
> files, but they were identical. I also tried running it again with freshly
> downloaded amber03 files in the directory.
>
> About the error: pdb2gmx never crashed. It always runs to completion and
> mentions that the topology was successfully generated. I only get a warning
> during the execution of pdb2gmx.
>
> Thanks for all your help,
>
> Dries
>
>
>
> On 8 October 2015 at 13:33, Justin Lemkul <jalem...@vt.edu> wrote:
>
>>
>>
>> On 10/8/15 1:54 AM, Dries Van Rompaey wrote:
>>
>>> Thanks for the reply Justin. I unfortunately cannot currently disclose
>>> the
>>> files that I'm working on. Based on the info presented, would you say
>>> that
>>> it's an issue with the force field definition or with the actual protein
>>> topology? I am not planning on using amber03 in my simulations at the
>>> moment, so this specific warning is not that important, but I can't help
>>> but wonder if this warning means something is off in the topology.
>>>
>>>
>> Give

Re: [gmx-users] pdb2gmx error

[Dries Van Rompaey]

Thanks Justin, that makes sense! I'm wondering why none of the other
proline residues triggered that warning though? The same procedure works
like a charm with other proteins.
On 7 Oct 2015 10:59 pm, "Justin Lemkul" <jalem...@vt.edu> wrote:

>
>
> On 10/7/15 3:01 PM, Dries Van Rompaey wrote:
>
>> Hi Mark,
>>
>> This is Gromacs 5.0.4. This is a non-terminal residue.
>> The command line used is:
>> gmx pdb2gmx -f complex.pdb -o complex.gro (-ignh)
>> I tried this procedure with and without ignh flag.
>> As far as I know, specbonds is not in play.
>>
>>
> Non-terminal proline does not have an amide H.  If your force field .rtp
> file claims to use such an atom used in a dihedral (which is what the error
> message tells you is happening), find out who altered the file and
> reprimand them :)
>
> -Justin
>
> Kind regards,
>> Dries
>>
>>
>> On 7 October 2015 at 20:56, Mark Abraham <mark.j.abra...@gmail.com>
>> wrote:
>>
>> Hi,
>>>
>>> Is it terminal? Are there specbonds in play? What's the GROMACS version?
>>> What's your pdb2gmx command line? :-)
>>>
>>> Mark
>>>
>>> On Wed, Oct 7, 2015 at 8:43 PM Dries Van Rompaey <
>>> dries.vanromp...@gmail.com>
>>> wrote:
>>>
>>> Hi everyone,
>>>>
>>>> I'm getting the following warning when I try to run pdb2gmx on my
>>>> protein
>>>> structure:
>>>>
>>>> WARNING: WARNING: Residue 168 named PRO of a molecule in the input file
>>>>
>>> was
>>>
>>>> mapped to an entry in the topology database, but the atom H used in an
>>>> interaction of type dihedral in that entry is not found in the input
>>>>
>>> file.
>>>
>>>> Perhaps your atom and/or residue naming needs to be fixed.
>>>>
>>>> This warning is only present when I use the AMBER03 forcefield, all
>>>> other
>>>> forcefields seem to work fine. I have tried this with both a structure
>>>> without hydrogens as well as a structure with hydrogens added, both with
>>>> and without the -ignh flag. I tried looking at the amber03 database
>>>> files
>>>> as well as the amber99sb-ildn database files (amber99sb-ildn works just
>>>> fine), but I could not find any reason why this particular residue would
>>>>
>>> be
>>>
>>>> problematic. pdb2gmx does not find any problems with the other proline
>>>> residues in the protein (which look identical), so I am puzzled as to
>>>> what's causing this.
>>>>
>>>> The proline residue is:
>>>> ATOM   1384  N   PRO A 168 274.650  45.241  24.167  1.00180.63
>>>>N
>>>> ATOM   1385  CA  PRO A 168 273.508  44.823  23.370  1.00180.63
>>>>C
>>>> ATOM   1386  CD  PRO A 168 275.844  45.381  23.346  1.00180.63
>>>>C
>>>> ATOM   1387  CB  PRO A 168 274.071  44.405  22.014  1.00180.63
>>>>C
>>>> ATOM   1388  CG  PRO A 168 275.381  45.194  21.892  1.00180.63
>>>>C
>>>> ATOM   1389  C   PRO A 168 272.551  43.776  23.888  1.00180.63
>>>>C
>>>> ATOM   1390  O   PRO A 168 271.478  43.646  23.304  1.00180.63
>>>>O
>>>>
>>>> Does anyone know what's going on here?
>>>>
>>>> Thanks in advance!
>>>> --
>>>> Gromacs Users mailing list
>>>>
>>>> * Please search the archive at
>>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
>>>> posting!
>>>>
>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>>
>>>> * For (un)subscribe requests visit
>>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
>>>> send a mail to gmx-users-requ...@gromacs.org.
>>>>
>>>> --
>>> Gromacs Users mailing list
>>>
>>> * Please search the archive at
>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
>>> posting!
>>>
>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>
>>> * For (un)subscribe requests visit
>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
>>> send a mail to gmx-users-requ...@gromacs.org.
>>>
>>>
> --
> =

[gmx-users] pdb2gmx error

[Dries Van Rompaey]

Hi everyone,

I'm getting the following warning when I try to run pdb2gmx on my protein
structure:

WARNING: WARNING: Residue 168 named PRO of a molecule in the input file was
mapped to an entry in the topology database, but the atom H used in an
interaction of type dihedral in that entry is not found in the input file.
Perhaps your atom and/or residue naming needs to be fixed.

This warning is only present when I use the AMBER03 forcefield, all other
forcefields seem to work fine. I have tried this with both a structure
without hydrogens as well as a structure with hydrogens added, both with
and without the -ignh flag. I tried looking at the amber03 database files
as well as the amber99sb-ildn database files (amber99sb-ildn works just
fine), but I could not find any reason why this particular residue would be
problematic. pdb2gmx does not find any problems with the other proline
residues in the protein (which look identical), so I am puzzled as to
what's causing this.

The proline residue is:
ATOM   1384  N   PRO A 168 274.650  45.241  24.167  1.00180.63
  N
ATOM   1385  CA  PRO A 168 273.508  44.823  23.370  1.00180.63
  C
ATOM   1386  CD  PRO A 168 275.844  45.381  23.346  1.00180.63
  C
ATOM   1387  CB  PRO A 168 274.071  44.405  22.014  1.00180.63
  C
ATOM   1388  CG  PRO A 168 275.381  45.194  21.892  1.00180.63
  C
ATOM   1389  C   PRO A 168 272.551  43.776  23.888  1.00180.63
  C
ATOM   1390  O   PRO A 168 271.478  43.646  23.304  1.00180.63
  O

Does anyone know what's going on here?

Thanks in advance!
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

Re: [gmx-users] Grompp checkpoint bug?

[Dries Van Rompaey]

Dear Mark,

Thanks for the reply. I filed a redmine bug report at
http://redmine.gromacs.org/issues/1775. Let me know if there’s any other
data you guys need to get this issue fixed.

Kind regards

Dries
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.

[gmx-users] Effect of hardware threads mismatch on simulation

[Dries Van Rompaey]

Dear gmx-users,

When running a simulation of a protein in solution on my university’s
cluster I get the two following notifications:

Number of hardware threads detected (20) does not match the number
reported by OpenMP (1).
Consider setting the launch configuration manually!

Non-default thread affinity set probably by the OpenMP library,
disabling internal thread affinity.

My PBS file is:
#!/bin/bash
#PBS -l nodes=2:ppn=20,pmem=2gb
#PBS -l walltime=55:00:00
#PBS -N GromacsmTSLP
module load hopper/2015a
module load GROMACS/5.0.4-intel-2015a-hybrid

cd $PBS_O_WORKDIR
mpirun gmx_mpi mdrun -s md_calcua.tpr -o $VSC_DATA/MD.trr -cpo
$VSC_DATA/MD.cpt -c $VSC_DATA/MD.gro -e $VSC_DATA/MD.edr -g
$VSC_DATA/MD.log

The performance of the system seems to be allright (120 ns/day on 2
Xeon E5-2680 v2 @ 2.80GHz), 20 000 atoms).
The number of processes launched seems to be correct as well (40).
I tried looking through the mailing list, and from what I can gather
these notifications should only have an effect on the system
performance (which seems to be okay in my case)?

Could anyone tell me if this has an effect on the reliability of my
simulations or not?


Thanks in advance

Dries
-- 
Gromacs Users mailing list

* Please search the archive at 
http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting!

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

* For (un)subscribe requests visit
https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a 
mail to gmx-users-requ...@gromacs.org.