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/ --------------------------------------------------------------------------