[gmx-developers] GROMACS 4.0.1 still broken on Bluegene

[Axel Kohlmeyer]

On Sun, 9 Nov 2008, Erik Lindahl wrote:

hi,

just a generic comment about the XLF and GCC-4.x compilers.
i haven't compiled gmx recently, so i don't know whether
this applies or not, but a _lot_ of MD and related codes seem 
to get miscompiled these days by both compiler families, due to 
in complete conformance to ANSI-C aliasing issues.

i saw these popping up in the weirdest places recently while
compiling a lot of software on a new RHEL 5.1(plus patches)
machine. so for general distribution it may be worth considering
adding -fno-strict-aliasing to CFLAGS for safety. for XLF there
is a similar flag (-qansi=none?). for the codes that i was testing
this made all the difference, particularly when using lookup
tables etc. ;)

cheers,
    axel.

EL> Hi,
EL> 
EL> Nope, for BG we currently rely on people like you testing it :-)
EL> 
EL> Please keep sending your patches!
EL> 
EL> You might want to hold off with the 4.0.2 I just put on the website.
EL> Apparently somebody has been committing stuff that disables the water-water
EL> detection & optimization. Trying to debug it now...
EL> 
EL> Cheers,
EL> 
EL> Erik
EL> 
EL> On Nov 9, 2008, at 3:32 PM, Mark Abraham wrote:
EL> 
EL> >Erik Lindahl wrote:
EL> > >Hi,
EL> > >Sorry, me too - I always use the default settings when retrieving my
EL> > >to-do list, so I too missed it.
EL> > >I'll see if I can make an instant 4.0.2 tomorrow, that also has makefiles
EL> > >for windows. Then it's binary time!
EL> >
EL> >Erik's helpfully fixed the earlier issues I've noted with BlueGene, along
EL> >with some more I found today at
EL> >http://bugzilla.gromacs.org/show_bug.cgi?id=250 and
EL> >http://bugzilla.gromacs.org/show_bug.cgi?id=252
EL> >
EL> >There can't have been any kind of real-world testing of this code:
EL> >* Any non-solvent charge groups in a neighbour-list of more than 6 atoms
EL> >would have produced erroneous Coulomb energies and forces for a third of
EL> >the interactions. (In my case, an equilibrated system blew up in under 20
EL> >steps.)
EL> >* I suspect RF and cutoff have a sign error in generating fscal, but
EL> >haven't tested or analysed the code to my satisfaction yet.
EL> >* Any double-precision build would have failed.
EL> >
EL> >However, once I applied some fixes, a no-solvent-loop simulation of 50K
EL> >atoms under PME is running stably on 32 processors under both single and
EL> >double precision.
EL> >
EL> >I haven't gotten around to looking at the water-optimized loops yet, but I
EL> >will, and will test things out with gmxtest.pl as well.
EL> >
EL> >Mark
EL> >_______________________________________________
EL> >gmx-developers mailing list
EL> >gmx-developers at gromacs.org
EL> >http://www.gromacs.org/mailman/listinfo/gmx-developers
EL> >Please don't post (un)subscribe requests to the list. Use the www interface
EL> >or send it to gmx-developers-request at gromacs.org.
EL> 
EL> _______________________________________________
EL> gmx-developers mailing list
EL> gmx-developers at gromacs.org
EL> http://www.gromacs.org/mailman/listinfo/gmx-developers
EL> Please don't post (un)subscribe requests to the list. Use thewww interface
EL> or send it to gmx-developers-request at gromacs.org.
EL> 

-- 
=======================================================================
Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.