Pgi64/8.0/1
It seems that using pgi64/8.0/1 causes problems for GMIN, at least when you are using the CHARMM forcefield. CHARMM however is unaffected i.e. if an old version of pgi64 i.e. 7.2/5 is used to compile the GMIN code and 8.0/1 is used for CHARMM - all is well. This problem seems only to affect big systems (i.e. influenza HA fragments of 2.5k atoms) and results in NaNs and Infs appearing everywhere (coordinates, energy etc!)
Essentially - don't use pgi64/8.0/1!
I think this is an incredibly dangerous approach to take. Whilst I have reported 2 bugs in the pgf90 to PGI in the last few months, my first instinct is still to believe my code is incorrect rather than the compiler. If it is indeed not the compiler that's causing the problem, then it means you're ignoring a bug in your program.
You're assuming that a bug was introduced (as opposed to being fixed) in pgi8, without any evidence that this is the case.
Have you got any reason to believe it is the compiler? NaNs and infinities are somewhat worrying. I've seen it before where some compilers hide errors/interpret your code in the way you intend (rather than a more strict approach). Just because the problem doesn't occur with other compilers/versions, doesn't mean it's necessarily the compiler's fault. It's possible that PGI 8 has tightened up some operations. You can't know for sure unless you track down exactly where the NaNs and infinities are coming from.
Can you trust the results generated by other compilers that aren't infinities/NaNs to be correct? In my experience: not necessarily. There is always a reason why something becomes infinite/not defined.
It's perfectly plausible that a change in memory handling has led to a memory leak becoming noticeable, or how variables are initialised (a behaviour which is not defined by the standards: we cannot assume a variable has a value of 0 before it's assigned anything) has changed slightly or... Small (but correct) improvements/changes in the compiler can lead to bugs becoming (more) apparent than they were before.
These issues are why using different compilers is so helpful in improving code quality.
I think my point is that more often than not, it's not the compiler. If you get different results using 2 different compilers and can't explain *exactly* why, then how can you trust either? Just because one result seems sensible, doesn't make it (necessarily) correct. --james 20:20, 17 January 2009 (GMT)