[gmx-developers] some notes on compiling the current gmx cvs sources on cray xt3

Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu
Mon May 29 00:27:37 CEST 2006

On 5/17/06, Axel Kohlmeyer <akohlmey at cmm.upenn.edu> wrote:
> On Wed, 17 May 2006, David van der Spoel wrote:

hi everybody,

please find attached an updated patch for compiling the current
gromacs cvs on the cray xt3. it adds some kind of a hack to the
configure.ac file, that will trigger cross-compilation when trying
to compile on the xt3. the compilation still needs some additional
fine tuning, since you have to compile all tools serially and link
them differently so they run on the fronend node.

> DS> Axel Kohlmeyer wrote:
> DS> I have fixed the // problems. I don't understand the remark about
> DS> compiling serially.
> thanks. to compile serially i need to add the following change
> (extracted from the patch i sent):

note, that this is still not fixed (and included in the attached patch).
the current cvs code does not compile without enabling MPI.

> Index: src/mdlib/pme.c
> ===================================================================
> RCS file: /home/gmx/cvs/gmx/src/mdlib/pme.c,v
> retrieving revision 1.75
> diff -u -r1.75 pme.c
> --- src/mdlib/pme.c     16 May 2006 15:18:08 -0000      1.75
> +++ src/mdlib/pme.c     16 May 2006 23:50:00 -0000
> @@ -1294,7 +1294,9 @@
>      pme->nodeid = cr->nodeid;
>      pme->nnodes = cr->nnodes;
>    }
> +#ifdef GMX_MPI
>    pme->mpi_comm = cr->mpi_comm_mygroup;
> +#endif


> DS> > as already reported by shawn brown elsewhere, the gcc compiled code
> DS> > tends to crash
> DS> > in different places (e.g. segfault in add_gbond(), mpi error in
> DS> > splitter.c).
> DS>
> DS> This is weird, the add_gbond error might depend on the system studied
> DS> however.
> this is the DPPC benchmark. it seems to be quite random. i'll try
> compiling with lower optimization. the gcc compiler is a gcc 3.3.1.

i've made a lot of tests and checks with different combination of flags
and compilers using single/double precision with fortran innerloops and
assemble and so on, and it seems, that the problem is not in this specific
subroutine, but somehow generic and happening all over the place.
even for the cases, where the run succeeds, the resulting trajectories
are bogus. any hints about where something this generic and ubiquitous
could happen to the gromacs code (and not to a lot of others) would
be very much appreciated.



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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gmx-crayxt3-fix.diff.gz
Type: application/x-gzip
Size: 858 bytes
Desc: not available
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20060528/529e95b2/attachment.gz>

More information about the gromacs.org_gmx-developers mailing list