ABINIT Discussion Forums

Hi,
I just merged revno 431 of trunk/6.5.1-public into my 6.5.1-private branch, and it now fails to build on both intel and gcc. Specifically, I did:

commit my changes, which build and pass tests;
run clean-source-tree
merge trunk/6.5.1-public
run makemake
run configure
run make

fails with

/usr/local/openmpi/gcc/bin/mpif90 -m64 -DHAVE_CONFIG_H -I. -I../../../src/12_hide_mpi -I../.. -I../../src/incs -I../../../src/incs -ffree-form -J/home/jzwanzig/code/abinit/6.5.1-private/tmp-gcc/src/mods -O2 -mtune=native -march=native -mfpmath=sse -m64 -ffree-line-length-none -c -o m_xmpi.o ../../../src/12_hide_mpi/m_xmpi.F90
../../../src/12_hide_mpi/m_xmpi.F90:1840.88:

E_CREATE_STRUCT(my_ncol+2,block_length,block_depl,block_type,new_type,ierr)
1
Error: There is no specific subroutine for the generic 'mpi_type_create_struct' at (1)
make[3]: *** [m_xmpi.o] Error 1
make[3]: Leaving directory `/home/jzwanzig/code/abinit/6.5.1-private/tmp-gcc/src/12_hide_mpi'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/jzwanzig/code/abinit/6.5.1-private/tmp-gcc/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jzwanzig/code/abinit/6.5.1-private/tmp-gcc'
make: *** [all] Error 2

any suggestions? thanks in advance,
Joe

p.s. How can this even happen? I know the trunk branch is heavily tested on many platforms...

OK, here's what I had to do to get the trunk/6.5.1-public merge to compile:

1) in src/12_hide_mpi/m_xmpi.F90, line 1782:
old: integer,allocatable :: block_depl(:)
new: integer(KIND=MPI_ADDRESS_KIND),allocatable :: block_depl(:) ! this corresponds to the type needed in the call to MPI_TYPE_CREATE_STRUCT

2) in src/62_iowfdenpot/m_io_screening.F90, line 1383:
old: complex(dpc),allocatable :: bufdc(:,:)
new: complex(dpc),allocatable :: bufdc(:,:),bufdc3(:,:,:)

later in this file there were calls to bufdc with 3 array indices, and others with two. Why did this code ever compile?

It was probably not compiled on the test farm, due to a few transient inconsistencies. I'm fixing them right now, since I'm getting this problem as well on my 6.5.2 branch.

Sorry, it's my fault.
I've been working on the MPI-IO part of the code but most of my changes are still in
gmatteo-training in which all the compilation errors you are reporting have been solved.

See pouillon/6.5.2-public/435 for a clean fix of both the MPI and GW_DPC issues. Please wait until tomorrow and check the test farm's results before merging.

What is more preoccupating is that so much bug-infested and untested code manages to make it through the test farm. In particular, it currently means that the enable_gw_dpc=no option is not tested anymore, despite all the efforts Jean-Michel and I are deploying.

thanks, Yann.

After discussing with Matteo, revno 437 provides the actual fix.

Hi Yann,
Unfortunately, pouillon/6.5.2-public/435 did not succeed today...
To which branch are your referring with "revno 437" ? I did not see
any revno 437 in the test farm this night ... Forgot to push ?
Xavier

No, pushed too late for it to be processed on Wednesday. I knew it anyway.

In any case, seeing what happened to revno 437, the support of MPI-IO has now to be declared fully broken until someone fixes it. It might not be much, but I have no time for this. In the meantime, I'll put a lock on it in my branch so that it can safely be merged into trunk. This means that one will have to activate debug mode (--enable-debug > enhanced, see build-config.ac for details) to compile MPI-IO.

The code is stopping in one of the new routines I've added for supporting MPI-IO.
I'm going to investigate the problem.

Update everyone? I still have the problem with mpi_type_create_struct, but it looks like it comes from the fact my (IBM) distribution of MPICH is old and does not have mpi_type_create_struct implemented yet. The latest IBM doc contains it, but the libs have no reference to the symbol, except in one c++ interface, where they state that mpi_type_struct is deprecated and should be replaced by mpi_type_create_struct...

Matthieu