[gmx-users] compiling gromacs on powerpc64

[Martin Siegert]

On Thu, Aug 04, 2005 at 09:43:24AM +0200, David van der Spoel wrote:
> On Wed, 2005-08-03 at 19:54 -0700, Martin Siegert wrote:
> > On Wed, Aug 03, 2005 at 06:30:47AM -0500, Nathan Moore wrote:
> 
> > 
> > Nathan: this turned out to be very helpful:
> > 
> > compiling with "-O2" works, i.e., the resulting grompp generates a
> > topol.tpr file that works with mdrun.
> > 
> > compiling with "-q64 -O2" does not work, i.e., the problem is with
> > the 64bit compilation.
> > 
> > Could there be some variable conversion in the code that fails in 64bit
> > mode?
> We'd be delighted to hear of any 64-bit incompatibilities, we're not
> aware of any. Have you tried double precision in 64 bit? Most likely it
> is a compiler thing anyway.

I (currently) doubt that this is a compiler problem:

* xlc -q64 compiles gromacs fine on AIX
* gcc -m64 does not compile gromacs on powerpc either

Thus, if it is a compiler problem it would mean that both gcc and xlc
are broken.

Instead, I suspect a bug in some system include file on the powerpc
platform. I actually suspect that the problem is not with float/double
but with int/long or size_t. The reason is the following: the incorrect
topol.tpr file starts with

00000000  00 00 00 00 00 00 00 00 56 45 52 53 49 4F 4E 20 ........VERSION
00000010  33 2E 32 2E 31 00 00 00 00 00 00 00 00 00 00 00 3.2.1...........
00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Attempting to read this file with mdrun results in

Fatal error: Can not read file topol.tpr,
             this file is from a Gromacs version which is older than 2.0
             Make a new one with grompp or use a gro or pdb file, if possible

When I then use a binary editor and change the 4th and 8th byte so that
the file starts the same as the correct version, i.e.,

00000000  00 00 00 0E 00 00 00 0D 56 45 52 53 49 4F 4E 20 ........VERSION
00000010  33 2E 32 2E 31 00 00 00 00 00 00 00 00 00 00 00 3.2.1...........
00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

then mdrun's error changes to

Fatal error: Unknown precision in file topol.tpr: real is 0 bytes instead of 4 or 8

Since I do not think that there are any floats or doubles written to
topol.tpr BEFORE the "VERSION 3.2.1" string and the last error message
does not really point to a float/double problem either, I suspect a
problem with long to int conversion (long and int being the same on
32 bit, but long being 8 bytes on 64 bit). Another possibility would
be a problem with the size_t declaration ...

Do you know which piece of the code actually writes these variables at the
beginning of topol.tpr?

write_tpx_state calls either write_xml or do_tpx. I quickly get lost in the
write_xml code. do_tpx calls do_string(GromacsVersion()); and then
do_int(precision); thus the problem ought to be visible already within
these two routines.
do_string is equivalent to
do_write((void *)(item),1,eioSTRING,(#item),__FILE__,__LINE__))
The actual routine seems to be determined in fio_select(int fio)
where it is set to (and here I get lost) do_xdr or do_binwrite.
If this actually is do_binwrite then this would first write an integer
namely the size of the string, in this case 14 = 0E. In this correct??

> > Also: is it possible to use a 32bit grompp together with a 64bit mdrun,
> > particularly for problems that require 64bit due to the size of the
> > problem? In other words: if the size of the problem is such that mdrun
> > requires more than 2GB of memory, can I still use a 32bit grompp to
> > generate the topol.tpr file?
> 
>      I. It is no problem, tpr files are portable, you can make them on
>         your desktop computer as well. The only difference is between
>         single and double precision.

Thanks, that is good to know.

Cheers,
Martin