RE: [gmx-users] multiple time step

2010-06-30 Thread Berk Hess
Hi, Our philosophy up till now is that with bond constraints and hydrogens replaced by virtual sites one can reach a time step of 4 or 5 femtoseconds. This is roughly equal to the largest time step, used for the PME mesh part, in multiple time stepping. But we then do less work on the non-bonded

RE: [gmx-users] multiple time step algorithm

2008-05-13 Thread Cristina GRECO
Dear Berk Hess, I am Cristina Greco. When I first wondered why there were no multiple or adaptive timestep methods implemented I suspected that the reasons had to do with compatibility with other options.I was just interested because I want to set up a simulation to study problems connected wi

RE: [gmx-users] multiple time step algorithm

2008-05-13 Thread Berk Hess
Date: Tue, 13 May 2008 12:51:57 +0200 From: [EMAIL PROTECTED] To: gmx-users@gromacs.org Subject: Re: [gmx-users] multiple time step algorithm Berk Hess wrote: It would also make the code more complicated than it already is. Berk. It may be useful to incorporate these

Re: [gmx-users] multiple time step algorithm

2008-05-13 Thread Ran Friedman
David van der Spoel wrote: > Ran Friedman wrote: >> Berk Hess wrote: >>> It would also make the code more complicated than it already is. >>> >>> Berk. >> It may be useful to incorporate these things as part of the source >> but to compile them only if requested by the user, as done e.g. in >> so

Re: [gmx-users] multiple time step algorithm

2008-05-13 Thread David van der Spoel
Ran Friedman wrote: Berk Hess wrote: It would also make the code more complicated than it already is. Berk. It may be useful to incorporate these things as part of the source but to compile them only if requested by the user, as done e.g. in some features of charmm. This will make the main

Re: [gmx-users] multiple time step algorithm

2008-05-13 Thread Ran Friedman
Berk Hess wrote: > It would also make the code more complicated than it already is. > > Berk. It may be useful to incorporate these things as part of the source but to compile them only if requested by the user, as done e.g. in some features of charmm. This will make the main code only minimally mo

Re: [gmx-users] multiple time step algorithm

2008-05-13 Thread Erik Marklund
. > From: [EMAIL PROTECTED] > Date: Tue, 13 May 2008 12:16:04 +0200 > To: gmx-users@gromacs.org > Subject: Re: [gmx-users] multiple time step algorithm > > Dear David av der Spoel > > Thanks for answering. I

RE: [gmx-users] multiple time step algorithm

2008-05-13 Thread Berk Hess
parallelization. It would also make the code more complicated than it already is. Berk. > From: [EMAIL PROTECTED] > Date: Tue, 13 May 2008 12:16:04 +0200 > To: gmx-users@gromacs.org > Subject: Re: [gmx-users] multiple time step algorithm > > Dear David av der Spoel > >

Re: [gmx-users] multiple time step algorithm

2008-05-13 Thread Cristina GRECO
Dear David av der Spoel Thanks for answering. I was just curious to know why you chose not to implement them. Have a nice day On Tue, 13 May 2008 12:00:43 +0200, David van der Spoel said: > > Cristina GRECO wrote: > > Dear Gromacs users and developers, > > > > it seems to me that Gromacs does

Re: [gmx-users] multiple time step algorithm

2008-05-13 Thread David van der Spoel
Cristina GRECO wrote: Dear Gromacs users and developers, it seems to me that Gromacs does not allow for multiple time step nor adaptive timestep MD. Is that correct or did I miss something? If that's true what's the reason ? For example, would there be problems in running such algorithm in p