[Wien] Compilation problems on Red Hat 4 with gfortran and gotolib

[Peter Blaha]

a) Please note: when you do not use ifort you probably loose half of the speed of the
calculations.
b) when using "-lblas_lapw -llapack_lapw"  you are using probably another factor of ~5,
so in total your calculations on a fancy new machine will run at the speed of a 10 year
old processor.

In any case, start out the installation   WITHOUT mpi first (do you have a cluster with infiniband
or only a single machine where mpi is not useful anyway??).

Does the sequential compilation work ? It can always happen that there are some small
incompatibilities between WIEN2k   and   gfortran; in particular gfortran supports by
default only rather "short" lines  (check previous postings on the mailing list about
gfortran).

If there are errors, do not
attach a list of all (identical) error (this will exhaust us) nor include
all compile.msg  files, but you have to READ them yourself and if the
messages do not help, provide the essential details. Just a list of "ERROR" lines
is NOT enough like:
 > SRC_lapw0/compile.msg:make[1]: *** [lapw0_mpi] Error 1
 > SRC_trig/compile.msg:Error: Attribute at (1) is not allowed in a TYPE definition

but in the compile.msg files there is more info (which line,....)

----------------------
Some specific comments follow below, where you have given enough info:

If you want to link a library, which is NOT in any of the default pathes, you have to
provide the directories where these libraries are located. This can be done using eg.
-L/opt/GotoBLAS2/  and of course it should not be -lgoto but either -lgoto2 or -lgoto2_nehalemp-r1.13
and similar you need to specify the directories for your mpi (-lpblas) compilation.

> Fortran Compiler: gfortran
> C Compiler: CC
> goto Libraries: /opt/GotoBLAS2/libgoto2.so
>                       /opt/GotoBLAS2/libgoto2.a
>                       /opt/GotoBLAS2/libgoto2_nehalemp-r1.13.so
> NOTE: recommended for R_LIB is -llapack_lapw -lgoto -llapack_lapw but lgoto doesn't exist in SRC_lib like lapack does and I assumed that blas, which is located in SRC_lib, is what you are looking for since blas is called gotoblas.


> Then when examining the individual compile.msg files I found the pertinent information to be:
> In SRC_lapw0:
> mpif90 -o lapw0_mpi cputim.o modules.o reallocate.o ainv.o am05_xscss.o b88.o blyp.o brj.o charg2.o  charg3.o charge.o chfac.o chslv.o corgga.o corpbe_revtpss.o corpbe_tpss.o cub_xc_back.o corlsd.o dfxhpbe.o dfxrevtpss.o dfxtpss.o drho.o dylm.o efg.o energy.o epot1.o eramps.o errclr.o errflg.o ev92.o ev92ex.o exch.o exch17.o fftw_para.o fithi.o fxhpbe.o fx_revtpss.o fx_tpss.o gbass.o gcor.o gea.o geaex.o  getff1.o getfft.o gpoint.o gpointm.o grans.o gtfnam.o hcth.o htbs.o ifflim.o kcis.o lapw0.o latgen.o multfc.o multsu.o outerr.o pbea.o pbem.o pbe1.o pbe2.o pbesol.o poissn.o potfac.o pwxad4.o pwxad5.o qranf.o readstruct.o rean0.o rean1.o rean3.o rean4.o rhopw.o rotate.o rotdef.o rpbe.o setff0.o setff1.o setfft.o setff2.o seval.o sevald.o sevaldd.o sevali.o sevalin.o sicpbe.o sicpbe_revtpss.o sicpbe_tpss.o sogga.o sphbes.o spline.o srolyl.o stern.o sumfac.o suml.o SymmRot.o th1.o th2.o vpw91.o vresp.o vs98.o vxc15.o vxc16.o vxc17.o vxc24.o vxc26.o vxclm2.o vxcpw2.o vxi35.o 
vx
>   i35a.o wc05.o workf1.o xcener.o xcpot.o xcpot1.o xcpot3.o ykav.o  ylm.o zfft3d.o  W2kutils.o W2kinit.o fftw_seq.o -ffree-form -O2 -L../SRC_lib -lpthread -static  -L/usr/lib -L/usr/lib64 -lpblas -lredist -ltools -lscalapack -lfblacs -lblacs -lmpi -L/opt/local/fftw/lib/ -lfftw_mpi -lfftw
> /usr/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread                 NOTE: This did not appear before I changed RP_LIB
> /usr/bin/ld: cannot find -lpblas                                                                                            NOTE: This DID appear before I changed it and it made no difference

Rather clear after the explanations at the beginning. Errors of that sort are related
to your system.



> In SRC_lapw2: Errors like the following, may on them.
> In file qdmft_tmp_.F:433
>
>      chd=chd+REAL(dmftdm(ikk)%mat(i,i), KIND=8)*vnorm
>                                 1
> Error: 'mat' at (1) is not a member of the 'den_mat' structure

Rather unclear to me (though I'm not the author of this subroutine).
Maybe there is some previous error which explains this one ??
mat is a member of the den_mat structure (see line 20), but
maybe gfortran does not like the allocatable in the definition of a structure ?


> In SRC_mixer: Not even a clue what the error is here:
> Fprojmsec.o: In function `fprojmsec_':
> Fprojmsec.f:(.text+0x231): undefined reference to `dposvx_'

dposvx is part o lapack. So you did not link with a lapack library ...


> In SRC_telnes3: (NOTE: entire file text provided)
> gfortran  -ffree-form -O2  -c describetask.f
>   In file describetask.f:67
>
> 000),' mrad.
>      1
> Error: Unterminated character constant beginning at (1)

Most likely the lines are too long for gfortran (see previous postings).


>
> In SRC_trig: {Nothing more elaborate in here except for specific lines}
> I am guessing that the errors that appear in trig are a result of the failure earlier in the compilation but I do not know for certain.

No, errors in SRC_trig cannot come from errors in other directories.
-- 

                                       P.Blaha
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-15671             FAX: +43-1-58801-15698
Email: blaha at theochem.tuwien.ac.at    WWW: http://info.tuwien.ac.at/theochem/
--------------------------------------------------------------------------