[Wien] Some interesting observation with "runsp_lapw -so -orb"on Mac OSX

[Gavin Abo]

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