Re: [gmx-users] Numerical Stability of Gromacs Implementation
> Date: Fri, 22 Aug 2014 17:05:31 +0200 > From: Mark Abraham > To: Discussion list for GROMACS users > Subject: Re: [gmx-users] Numerical Stability of Gromacs Implementation > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > On Aug 22, 2014 4:49 PM, "Johnny Lu" wrote: >> >> it has many (relatively) power7 cores and aix 6.1.0.0 with no gpu, and I >> compiled single precision gromacs 4.6.6 with open mp on it. >> I tried xlc or mpcc for 30+ times. > > 6.1 was released 7 years ago, but if you have a functional xlc, then you > should be able to build GROMACS. It won't run fast, though. > >>The gcc on it doesn't support openmp, >> and I compiled another one with openmp, and also gnu cmake. >> Linker is aix ld, with -lmass, and -lm flags. I am not sure if the mass >> library helped in compilation of fftw3 library. > > It doesn't. > >> Somehow, gcc can't find affinity support on aix ld, so I specified that in >> the job script of llqueue. A recent version of gcc (~4.7) for aix is available through Gentoo Prefix: <https://www.gentoo.org/proj/en/gentoo-alt/prefix/> Once you have bootstrapped Gentoo Prefix on your AIX machine, you will most likely be able to use the Gromacs package (4.6.6 or 5.0) therein! Cheers, Christoph >> May be next time I would try the mass simd library(-lmass_simdp7) or > vector >> library (-lmassvp4) >> (http://www-01.ibm.com/support/docview.wss?uid=swg27005375) >> >> Somehow, 24 intel xeon cpu (compiled with intel compiler, and mkl library) >> seems 4 times faster than 32 power7, when I run gromacs 4.6.6. > > Not surprising, that Intel hardware has been the target of a lot of > optimization. > > Mark > >> On Thu, Aug 21, 2014 at 7:28 PM, Mark Abraham >> wrote: >> >> > On Thu, Aug 21, 2014 at 7:59 PM, Johnny Lu > wrote: >> > >> > > Sorry for asking this. Is it possible for me to get some references > about >> > > the claims of instability of gromacs simulations, and their debunk? >> > > >> > >> > Not really. You can find a paper from some of the Desmond authors that >> > correctly observes some issues in GROMACS 3.x. People occasionally > refer to >> > it here as if it is current news. These issues are long fixed, but not >> > worth writing about - journal articles should be about delivering > quality >> > science. More commonly, an issue would be handled via private email, > though >> > even these are rare. Overall, the biomolecular MD community is quite > good >> > at finding problems with their own and each other's algorithms and >> > implementations and getting them fixed constructively. People saying >> > "someone said x was bad but gave me no details" need to talk to the >> > someone, not just the authors of x ;-) If people start being evasive or >> > secretive about possible problems with their code... be concerned. >> > >> > From the few papers that I read, I guess algorithms of molecular > dynamics >> > > do not treat all observables equally well. >> > > Some old papers say that the velocity in velocity verlet is not >> > symplectic, >> > > but rather follows some shadow hamiltonian or generalized > equipartition >> > >> > theorem. >> > > >> > >> > This is common to all methods with a finite time step - see >> > http://en.wikipedia.org/wiki/Energy_drift. There are certainly a variety >> > of >> > ways of estimating the velocity with common integrators, and they have >> > different quality attributes. You can read about how GROMACS handles > this >> > in the manual. >> > >> > Then another one mentioned force splitting can reduce the resonance > effect >> > > caused by integrator. >> > > That said, very few papers talk about this. >> > > >> > >> > There are lots of papers that discuss details of multiple time-stepping >> > algorithms that seek to deal with this issue directly. >> > >> > I don't know much about the effect of MD on the observables that I try > to >> > > look at. >> > > >> > >> > It's not an easy topic - generating converged sampling to assess > whether an >> > integration scheme correctly samples a complex observable is still a >> > non-trivial matter. That needs to happen before questions of "how much >> > algorithmic energy drift is acceptable" can be satisfactorily address
Re: [gmx-users] Numerical Stability of Gromacs Implementation
On Aug 22, 2014 4:49 PM, "Johnny Lu" wrote: > > it has many (relatively) power7 cores and aix 6.1.0.0 with no gpu, and I > compiled single precision gromacs 4.6.6 with open mp on it. > I tried xlc or mpcc for 30+ times. 6.1 was released 7 years ago, but if you have a functional xlc, then you should be able to build GROMACS. It won't run fast, though. >The gcc on it doesn't support openmp, > and I compiled another one with openmp, and also gnu cmake. > Linker is aix ld, with -lmass, and -lm flags. I am not sure if the mass > library helped in compilation of fftw3 library. It doesn't. > Somehow, gcc can't find affinity support on aix ld, so I specified that in > the job script of llqueue. > May be next time I would try the mass simd library(-lmass_simdp7) or vector > library (-lmassvp4) > (http://www-01.ibm.com/support/docview.wss?uid=swg27005375) > > Somehow, 24 intel xeon cpu (compiled with intel compiler, and mkl library) > seems 4 times faster than 32 power7, when I run gromacs 4.6.6. Not surprising, that Intel hardware has been the target of a lot of optimization. Mark > On Thu, Aug 21, 2014 at 7:28 PM, Mark Abraham > wrote: > > > On Thu, Aug 21, 2014 at 7:59 PM, Johnny Lu wrote: > > > > > Sorry for asking this. Is it possible for me to get some references about > > > the claims of instability of gromacs simulations, and their debunk? > > > > > > > Not really. You can find a paper from some of the Desmond authors that > > correctly observes some issues in GROMACS 3.x. People occasionally refer to > > it here as if it is current news. These issues are long fixed, but not > > worth writing about - journal articles should be about delivering quality > > science. More commonly, an issue would be handled via private email, though > > even these are rare. Overall, the biomolecular MD community is quite good > > at finding problems with their own and each other's algorithms and > > implementations and getting them fixed constructively. People saying > > "someone said x was bad but gave me no details" need to talk to the > > someone, not just the authors of x ;-) If people start being evasive or > > secretive about possible problems with their code... be concerned. > > > > From the few papers that I read, I guess algorithms of molecular dynamics > > > do not treat all observables equally well. > > > Some old papers say that the velocity in velocity verlet is not > > symplectic, > > > but rather follows some shadow hamiltonian or generalized equipartition > > > > theorem. > > > > > > > This is common to all methods with a finite time step - see > > http://en.wikipedia.org/wiki/Energy_drift. There are certainly a variety > > of > > ways of estimating the velocity with common integrators, and they have > > different quality attributes. You can read about how GROMACS handles this > > in the manual. > > > > Then another one mentioned force splitting can reduce the resonance effect > > > caused by integrator. > > > That said, very few papers talk about this. > > > > > > > There are lots of papers that discuss details of multiple time-stepping > > algorithms that seek to deal with this issue directly. > > > > I don't know much about the effect of MD on the observables that I try to > > > look at. > > > > > > > It's not an easy topic - generating converged sampling to assess whether an > > integration scheme correctly samples a complex observable is still a > > non-trivial matter. That needs to happen before questions of "how much > > algorithmic energy drift is acceptable" can be satisfactorily addressed. > > Until then, claims of "my energy conservation is better than yours" need to > > be considered alongside "my number of independent converged-ensemble > > samples is better than yours." > > > > And, sorry for replying this late, I have been installing gromacs on aix > > > for a week. > > > Compiling gcc took 3 days of computer time. > > > > > > > Seriously, don't bother. I don't think there is any system that would have > > AIX, with no gcc package available, and which GROMACS 5.0 would run > > decently on (which would require SIMD support, which currently means x86 or > > BlueGene/Q). I'd guess your laptop will get equivalent performance. > > > > Mark > > > > > > > > > > On Thu, Aug 14, 2014 at 2:29 PM, Mark Abraham < mark.j.abra...@gmail.com> > > > wrote: > > > > > > > On Wed, Aug 13, 2014 at 1:19 PM, Johnny Lu > > > wrote: > > > > > > > > > Hi again. > > > > > > > > > > Some of my friends said that gromacs had lower numerical stability > > than > > > > > amber, and occasionally has mysterious error in energy. > > > > > > > > > > > > > Show us a result and we'll discuss fixing it ;-) > > > > > > > > > > > > > Is that still true? Does the implementation of Integrator cause more > > > > > resonance effect? > > > > > > > > > > > > > Any numerical software can be used poorly. Any numerical software can > > > have > > > > bugs. Give them the same input to two implementations of the same > > > algorithm >
Re: [gmx-users] Numerical Stability of Gromacs Implementation
it has many (relatively) power7 cores and aix 6.1.0.0 with no gpu, and I compiled single precision gromacs 4.6.6 with open mp on it. I tried xlc or mpcc for 30+ times. The gcc on it doesn't support openmp, and I compiled another one with openmp, and also gnu cmake. Linker is aix ld, with -lmass, and -lm flags. I am not sure if the mass library helped in compilation of fftw3 library. Somehow, gcc can't find affinity support on aix ld, so I specified that in the job script of llqueue. May be next time I would try the mass simd library(-lmass_simdp7) or vector library (-lmassvp4) (http://www-01.ibm.com/support/docview.wss?uid=swg27005375) Somehow, 24 intel xeon cpu (compiled with intel compiler, and mkl library) seems 4 times faster than 32 power7, when I run gromacs 4.6.6. On Thu, Aug 21, 2014 at 7:28 PM, Mark Abraham wrote: > On Thu, Aug 21, 2014 at 7:59 PM, Johnny Lu wrote: > > > Sorry for asking this. Is it possible for me to get some references about > > the claims of instability of gromacs simulations, and their debunk? > > > > Not really. You can find a paper from some of the Desmond authors that > correctly observes some issues in GROMACS 3.x. People occasionally refer to > it here as if it is current news. These issues are long fixed, but not > worth writing about - journal articles should be about delivering quality > science. More commonly, an issue would be handled via private email, though > even these are rare. Overall, the biomolecular MD community is quite good > at finding problems with their own and each other's algorithms and > implementations and getting them fixed constructively. People saying > "someone said x was bad but gave me no details" need to talk to the > someone, not just the authors of x ;-) If people start being evasive or > secretive about possible problems with their code... be concerned. > > From the few papers that I read, I guess algorithms of molecular dynamics > > do not treat all observables equally well. > > Some old papers say that the velocity in velocity verlet is not > symplectic, > > but rather follows some shadow hamiltonian or generalized equipartition > > theorem. > > > > This is common to all methods with a finite time step - see > http://en.wikipedia.org/wiki/Energy_drift. There are certainly a variety > of > ways of estimating the velocity with common integrators, and they have > different quality attributes. You can read about how GROMACS handles this > in the manual. > > Then another one mentioned force splitting can reduce the resonance effect > > caused by integrator. > > That said, very few papers talk about this. > > > > There are lots of papers that discuss details of multiple time-stepping > algorithms that seek to deal with this issue directly. > > I don't know much about the effect of MD on the observables that I try to > > look at. > > > > It's not an easy topic - generating converged sampling to assess whether an > integration scheme correctly samples a complex observable is still a > non-trivial matter. That needs to happen before questions of "how much > algorithmic energy drift is acceptable" can be satisfactorily addressed. > Until then, claims of "my energy conservation is better than yours" need to > be considered alongside "my number of independent converged-ensemble > samples is better than yours." > > And, sorry for replying this late, I have been installing gromacs on aix > > for a week. > > Compiling gcc took 3 days of computer time. > > > > Seriously, don't bother. I don't think there is any system that would have > AIX, with no gcc package available, and which GROMACS 5.0 would run > decently on (which would require SIMD support, which currently means x86 or > BlueGene/Q). I'd guess your laptop will get equivalent performance. > > Mark > > > > > > On Thu, Aug 14, 2014 at 2:29 PM, Mark Abraham > > wrote: > > > > > On Wed, Aug 13, 2014 at 1:19 PM, Johnny Lu > > wrote: > > > > > > > Hi again. > > > > > > > > Some of my friends said that gromacs had lower numerical stability > than > > > > amber, and occasionally has mysterious error in energy. > > > > > > > > > > Show us a result and we'll discuss fixing it ;-) > > > > > > > > > > Is that still true? Does the implementation of Integrator cause more > > > > resonance effect? > > > > > > > > > > Any numerical software can be used poorly. Any numerical software can > > have > > > bugs. Give them the same input to two implementations of the same > > algorithm > > > and they should give results that are similar (whatever that means in > the > > > problem domain). > > > > > > > > > > I am trying to run NVE simulation with the single precision version, > > and > > > so > > > > I guess the implementation of thermostats is not my most immediate > > > concern > > > > at the moment. > > > > > > > > I searched online, and haven't found much about numerical instability > > of > > > > gromacs using amber forcefield (I mean for version 4.6, which > supports > > > the > > > > amber force-fie
Re: [gmx-users] Numerical Stability of Gromacs Implementation
On Thu, Aug 21, 2014 at 7:59 PM, Johnny Lu wrote: > Sorry for asking this. Is it possible for me to get some references about > the claims of instability of gromacs simulations, and their debunk? > Not really. You can find a paper from some of the Desmond authors that correctly observes some issues in GROMACS 3.x. People occasionally refer to it here as if it is current news. These issues are long fixed, but not worth writing about - journal articles should be about delivering quality science. More commonly, an issue would be handled via private email, though even these are rare. Overall, the biomolecular MD community is quite good at finding problems with their own and each other's algorithms and implementations and getting them fixed constructively. People saying "someone said x was bad but gave me no details" need to talk to the someone, not just the authors of x ;-) If people start being evasive or secretive about possible problems with their code... be concerned. >From the few papers that I read, I guess algorithms of molecular dynamics > do not treat all observables equally well. > Some old papers say that the velocity in velocity verlet is not symplectic, > but rather follows some shadow hamiltonian or generalized equipartition theorem. > This is common to all methods with a finite time step - see http://en.wikipedia.org/wiki/Energy_drift. There are certainly a variety of ways of estimating the velocity with common integrators, and they have different quality attributes. You can read about how GROMACS handles this in the manual. Then another one mentioned force splitting can reduce the resonance effect > caused by integrator. > That said, very few papers talk about this. > There are lots of papers that discuss details of multiple time-stepping algorithms that seek to deal with this issue directly. I don't know much about the effect of MD on the observables that I try to > look at. > It's not an easy topic - generating converged sampling to assess whether an integration scheme correctly samples a complex observable is still a non-trivial matter. That needs to happen before questions of "how much algorithmic energy drift is acceptable" can be satisfactorily addressed. Until then, claims of "my energy conservation is better than yours" need to be considered alongside "my number of independent converged-ensemble samples is better than yours." And, sorry for replying this late, I have been installing gromacs on aix > for a week. > Compiling gcc took 3 days of computer time. > Seriously, don't bother. I don't think there is any system that would have AIX, with no gcc package available, and which GROMACS 5.0 would run decently on (which would require SIMD support, which currently means x86 or BlueGene/Q). I'd guess your laptop will get equivalent performance. Mark > > On Thu, Aug 14, 2014 at 2:29 PM, Mark Abraham > wrote: > > > On Wed, Aug 13, 2014 at 1:19 PM, Johnny Lu > wrote: > > > > > Hi again. > > > > > > Some of my friends said that gromacs had lower numerical stability than > > > amber, and occasionally has mysterious error in energy. > > > > > > > Show us a result and we'll discuss fixing it ;-) > > > > > > > Is that still true? Does the implementation of Integrator cause more > > > resonance effect? > > > > > > > Any numerical software can be used poorly. Any numerical software can > have > > bugs. Give them the same input to two implementations of the same > algorithm > > and they should give results that are similar (whatever that means in the > > problem domain). > > > > > > > I am trying to run NVE simulation with the single precision version, > and > > so > > > I guess the implementation of thermostats is not my most immediate > > concern > > > at the moment. > > > > > > I searched online, and haven't found much about numerical instability > of > > > gromacs using amber forcefield (I mean for version 4.6, which supports > > the > > > amber force-fields without modification.) > > > > > > > What do you mean by numerical stability? Should you actually be concerned > > about getting a correct physical observable? People look at energy > > conservation because it is easy to do, but connecting that to the quality > > of the resulting physics is non-trivial. Even if you can (say) deliver > > state-of-the-art energy conservation (and most packages can do this in > some > > mode), you still need to measure the price in simulation throughput > > incurred by running in that mode. The overall objective is to deliver > > science of sufficient quality with minimal time to solution. In some > cases, > > it is right to let some energy leak and let the thermostat fix it, if you > > generate many more samples by so doing. > > > > Why do people still use and paid for amber, when gromacs is free? > > > I look online and the number of papers that use amber is about twice of > > the > > > number of paper that use gromacs. There are very few papers that > > mentioned > > > both gromacs and amber.
Re: [gmx-users] Numerical Stability of Gromacs Implementation
Sorry for asking this. Is it possible for me to get some references about the claims of instability of gromacs simulations, and their debunk? >From the few papers that I read, I guess algorithms of molecular dynamics do not treat all observables equally well. Some old papers say that the velocity in velocity verlet is not symplectic, but rather follows some shadow hamiltonian or generalized equipartition theorem. Then another one mentioned force splitting can reduce the resonance effect caused by integrator. That said, very few papers talk about this. I don't know much about the effect of MD on the observables that I try to look at. And, sorry for replying this late, I have been installing gromacs on aix for a week. Compiling gcc took 3 days of computer time. On Thu, Aug 14, 2014 at 2:29 PM, Mark Abraham wrote: > On Wed, Aug 13, 2014 at 1:19 PM, Johnny Lu wrote: > > > Hi again. > > > > Some of my friends said that gromacs had lower numerical stability than > > amber, and occasionally has mysterious error in energy. > > > > Show us a result and we'll discuss fixing it ;-) > > > > Is that still true? Does the implementation of Integrator cause more > > resonance effect? > > > > Any numerical software can be used poorly. Any numerical software can have > bugs. Give them the same input to two implementations of the same algorithm > and they should give results that are similar (whatever that means in the > problem domain). > > > > I am trying to run NVE simulation with the single precision version, and > so > > I guess the implementation of thermostats is not my most immediate > concern > > at the moment. > > > > I searched online, and haven't found much about numerical instability of > > gromacs using amber forcefield (I mean for version 4.6, which supports > the > > amber force-fields without modification.) > > > > What do you mean by numerical stability? Should you actually be concerned > about getting a correct physical observable? People look at energy > conservation because it is easy to do, but connecting that to the quality > of the resulting physics is non-trivial. Even if you can (say) deliver > state-of-the-art energy conservation (and most packages can do this in some > mode), you still need to measure the price in simulation throughput > incurred by running in that mode. The overall objective is to deliver > science of sufficient quality with minimal time to solution. In some cases, > it is right to let some energy leak and let the thermostat fix it, if you > generate many more samples by so doing. > > Why do people still use and paid for amber, when gromacs is free? > > I look online and the number of papers that use amber is about twice of > the > > number of paper that use gromacs. There are very few papers that > mentioned > > both gromacs and amber. > > > > Inertia is a big effect. You tend to adopt the package used by the local MD > expert so you have a low-latency person of whom to ask questions. They tend > to still use the package they used in their doctoral work, regardless of > current technical merit, because learning to use such software well is > tricky and discarding your old workflows is not a cheap proposition. The > next biggest effect is what functionality is available, and at what > performance. > > Mark > > Thank you. > > -- > > 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. > -- 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] Numerical Stability of Gromacs Implementation
On Wed, Aug 13, 2014 at 1:19 PM, Johnny Lu wrote: > Hi again. > > Some of my friends said that gromacs had lower numerical stability than > amber, and occasionally has mysterious error in energy. > Show us a result and we'll discuss fixing it ;-) > Is that still true? Does the implementation of Integrator cause more > resonance effect? > Any numerical software can be used poorly. Any numerical software can have bugs. Give them the same input to two implementations of the same algorithm and they should give results that are similar (whatever that means in the problem domain). > I am trying to run NVE simulation with the single precision version, and so > I guess the implementation of thermostats is not my most immediate concern > at the moment. > > I searched online, and haven't found much about numerical instability of > gromacs using amber forcefield (I mean for version 4.6, which supports the > amber force-fields without modification.) > What do you mean by numerical stability? Should you actually be concerned about getting a correct physical observable? People look at energy conservation because it is easy to do, but connecting that to the quality of the resulting physics is non-trivial. Even if you can (say) deliver state-of-the-art energy conservation (and most packages can do this in some mode), you still need to measure the price in simulation throughput incurred by running in that mode. The overall objective is to deliver science of sufficient quality with minimal time to solution. In some cases, it is right to let some energy leak and let the thermostat fix it, if you generate many more samples by so doing. Why do people still use and paid for amber, when gromacs is free? > I look online and the number of papers that use amber is about twice of the > number of paper that use gromacs. There are very few papers that mentioned > both gromacs and amber. > Inertia is a big effect. You tend to adopt the package used by the local MD expert so you have a low-latency person of whom to ask questions. They tend to still use the package they used in their doctoral work, regardless of current technical merit, because learning to use such software well is tricky and discarding your old workflows is not a cheap proposition. The next biggest effect is what functionality is available, and at what performance. Mark Thank you. > -- > 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] Numerical Stability of Gromacs Implementation
On 8/13/14, 2:19 PM, Johnny Lu wrote: Hi again. Some of my friends said that gromacs had lower numerical stability than amber, and occasionally has mysterious error in energy. I have never seen convincing evidence to support such a claim. Some people have stated that they have found evidence of problems, but those claims (at least the recent ones that I have seen) have been debunked. Is that still true? Does the implementation of Integrator cause more resonance effect? I am trying to run NVE simulation with the single precision version, and so I guess the implementation of thermostats is not my most immediate concern at the moment. I searched online, and haven't found much about numerical instability of gromacs using amber forcefield (I mean for version 4.6, which supports the amber force-fields without modification.) Why do people still use and paid for amber, when gromacs is free? One reason is that AMBER has many features that Gromacs does not. Another reason might just be tradition; some labs get set in the way they do things and don't change. I look online and the number of papers that use amber is about twice of the number of paper that use gromacs. There are very few papers that mentioned both gromacs and amber. Usually you only need one MD engine. AMBER has also been around for considerably longer than Gromacs. I see more papers that use Gromacs and NAMD than anything else, these days. But that could be just based on what I read :) -Justin -- == Justin A. Lemkul, Ph.D. Ruth L. Kirschstein NRSA Postdoctoral Fellow Department of Pharmaceutical Sciences School of Pharmacy Health Sciences Facility II, Room 601 University of Maryland, Baltimore 20 Penn St. Baltimore, MD 21201 jalem...@outerbanks.umaryland.edu | (410) 706-7441 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.
[gmx-users] Numerical Stability of Gromacs Implementation
Hi again. Some of my friends said that gromacs had lower numerical stability than amber, and occasionally has mysterious error in energy. Is that still true? Does the implementation of Integrator cause more resonance effect? I am trying to run NVE simulation with the single precision version, and so I guess the implementation of thermostats is not my most immediate concern at the moment. I searched online, and haven't found much about numerical instability of gromacs using amber forcefield (I mean for version 4.6, which supports the amber force-fields without modification.) Why do people still use and paid for amber, when gromacs is free? I look online and the number of papers that use amber is about twice of the number of paper that use gromacs. There are very few papers that mentioned both gromacs and amber. Thank you. -- 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.
