A comment that may or may not be related to the problem: It looks like you are using serial mode with the fftpack. Did you try the Wien2k 12.1 patches to fft_modules.F and vresp.F on the mailing list (http://zeus.theochem.tuwien.ac.at/pipermail/wien/2012-November/017911.html)? If not, I do not see the fftw3 (or fftw2) libraries being used instead in the serial compile settings such as -DFFTW3 in FOPT and -L/opt/local/fftw3/lib/ -lfftw3 in R_LIBS.
On 12/20/2012 8:57 AM, Zhu, Jianxin wrote: > Dear Peter, > > I pull the discussion back to the mailing list. > > For the observations I made these days, they were collected on the machine > under Mac OSX 10.6.8 installed with Intel Compiler 11.1/089. > Therefore, the program listed only the error --- > > forrtl: severe (24): end-of-file during read, unit 30, file > /Users/jxzhu/Research/lapw_dta/fcc-Np/fcc-Np.energysoup > > > I just tested the case on another machine under Mac OSX 10.7.4 installed > with Intel Composer 2013.1.119. > There is more information given in addition to error --- > > forrtl: severe (24): end-of-file during read, unit 30, file > /Users/jxzhu/Research/lapw_dta/fcc-Np/fcc-Np.energysoup > > Image PC Routine Line Source > > > Stack trace terminated abnormally. > cp: .in.tmp: No such file or directory > >> stop error > > > The OPTIONS for all wien2k.12.1 compilations on these machines is the same > and has the following > > current:FOPT:-free -mp1 -prec-div -pc80 -pad -align -traceback > current:FPOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback > -DFFTW3 > current:LDFLAGS:$(FOPT) -L/opt/intel/Composer/mkl/lib > current:DPARALLEL:'-DParallel' > current:R_LIBS:-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 > -lpthread > current:RP_LIBS:-lmkl_scalapack_lp64 -lmkl_solver_lp64 -lmkl_blacs_lp64 > -L/opt/local/fftw3/lib/ -lfftw3_mpi -lfftw3 $(R_LIBS) > current:MPIRUN:mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_ > > > > Do you have a suggestion on the change with compiler option to get a > simple fix? > > Thanks, > > Jianxin > > > > > > > > > -----Original Message----- > From: Peter Blaha <pblaha at theochem.tuwien.ac.at> > Date: Thu, 20 Dec 2012 10:11:06 +0100 > To: Jian-Xin Zhu <jxzhu at lanl.gov> > Subject: Re: [Wien] Some interesting observation with "runsp_lapw -so > -orb"on Mac OSX > >> Seems to be some compiler bug. Always possible (and of course of >> interest for other mac users as well !) >> >> Am 20.12.2012 05:42, schrieb Zhu, Jianxin: >>> Dear Peter, >>> >>> I take this discussion off the mailing list. Since the issue is so >>> specific, >>> I am afraid it will offend other users if I post it to the mailing list. >>> >>> I have done a few more tests. The issue becomes even more interesting. >>> >>> When I simply insert the following >>> >>> !BGN JXZ >>> write(*,*) 'Finish initialization of structure parameter in >>> lapwso!' >>> !END JXZ >>> >>> between line 57 and line 58 in the original lapwso.f file, that is, >>> >>> >>> ... >>> CALL init_struct >>> !BGN JXZ >>> write(*,*) 'Finish initialization of structure parameter in >>> lapwso!' >>> !END JXZ >>> CALL init_ams >>> ... >>> >>> the code then runs just fine regardless of how long the absolute path of >>> SCRATCH. >>> By this, I mean that the command line script "runsp_lapw -so -orb -cc >>> 0.0001 -NI -i 10", runs successfully. >>> >>> But I don't understand why it works this way. >>> >>> Best regards, >>> >>> Jianxin