Hi, Thank you for taking the time to fix the issue. I would be very interested in testing out the modified code, but unfortunately I have had some difficulties compiling the Gromacs code obtained straight from GIT. In particular, I encounter the following error:
~/gromacs/src/tools/gmx_ membed.c:1095: error: expected declaration specifiers or ‘...’ before ‘gmx_global_stat_t’ If you are curious to see the log and CMake cache files from the build, I have attached them to this email. I could also just patch the relevant parts of version 4.5.1 and test that out. If this would be feasible, then what specific lines should I modify? -Kevin Date: Thu, 9 Sep 2010 17:19:36 +0200 > From: Berk Hess <[email protected]> > Subject: RE: [gmx-users] Overflow problem with test-particle insertion > To: Discussion list for GROMACS users <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > > Hi, > > I realized now that this is an SSE issue. > Normally you would get NAN (or is it INF?). That is treated correctly in > the GROMACS TPI code. > But in SSE a float "wraps around" when it overflows, which could, in very > few cases, lead to a reasonably > looking energy value (I check for very high and very low values). > I found that you can check for overflows in SSE and committed a fix for > 4.5.2. > I also filled the first 10 points (up to r=0.02 nm) of the potential/force > tables, these used to be zero. > These values are only relevant for energy minimization or TPI with extreme > atomic overlap. > > Berk > > From: [email protected] > To: [email protected] > Subject: RE: [gmx-users] Overflow problem with test-particle insertion > Date: Thu, 9 Sep 2010 09:39:42 +0200 > > > > > > > > > Hi, > > This is an interesting issue. > The chance is quite small that this happens, but maybe not negligible. > In single precision the maximum a float can store is 2^127. > This gives a minimum distance of (2^127)^-1/12 = 6.5e-4 nm. > The chance of inserting a particle within this radius is dens*3e-10, > where dens is the number of particles per nm^3. > A typical density of LJ particles is 30 per nm^3, which leads to a chance > of 1e-8. > Such insertion numbers can be reached, so we probably have to worry about > this. > > However, in your example the distance seems to be around 4e-3, which would > give r^-12 = 6e28. This still fits in a float and should not cause > problems. > So we should make sure we understand what's going on here. > Could you file a bugzilla with the files to reproduce this and which > insertion > is the problematic one? > > I so two possible solutions: > Force tabulated potentials with TPI, this can currently be achieved by > setting > the environment variable GMX_FORCE_TABLES > Or require double precision. > But I think both solutions would lead to about 40% lower performance. > > Berk > > > Date: Wed, 8 Sep 2010 21:16:46 -0400 > From: [email protected] > To: [email protected] > Subject: [gmx-users] Overflow problem with test-particle insertion > > Hello Gromacs users, > > I sent a message to the list in June describing what appeared to be a float > overflow issue with the energy calculation for test-particle insertions: > http://lists.gromacs.org/pipermail/gmx-users/2010-June/052213.html. > > > I have recently tried the test-particle insertion mode in Gromacs-4.5.1, > and it seems the problem is still there. Does anyone know how to work around > or fix this problem without using tabulated potentials? > > -Kevin > >
build_output.tar.gz
Description: GNU Zip compressed data
-- gmx-users mailing list [email protected] http://lists.gromacs.org/mailman/listinfo/gmx-users Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/Search before posting! Please don't post (un)subscribe requests to the list. Use the www interface or send it to [email protected]. Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
