[Wien] Some interesting observation with "runsp_lapw -so -orb"on Mac OSX
Peter Blaha
pblaha at theochem.tuwien.ac.at
Sun Dec 23 09:24:54 CET 2012
The structure of lapwso is clear:
lapwso.f :
call gtfname (deffn,errfn)
open(1, deffn)
....
close 1
....
call init (deffn, errfn,..)
init.f:
...
call gtfname (deffn,errfn) !you may comment out this line, as it is completely redundant
open(1, deffn)
....
I cannot see anything wrong with this in principle.
However, I agree, I do not really see why a second call to gtfname in init.f is necessary.
Then there are two possibilities:
a) keep the close 1 statement in lapwso and also the open statement in init.f
b) uncomment the close 1 statement and put a rewind 1 statement.
In any case, the cleanest solution is to put the determination of iorbpot into lapwso.f (right after
the determination of "complex"), and it is then passed automatically (via module orb) into init.f
(and remove deffn,errfn in the init call).
Peter
Am 22.12.2012 18:51, schrieb Zhu, Jianxin:
> Peter and All,
>
> The change suggested in my previous message has a loop hole.
>
> I made a further correction to init.f (under SRC_lapwso) as follows:
>
> …
> iorbpot=0
> CALL GTFNAM(DEFFN,ERRFN)
> OPEN (1,FILE=DEFFN,STATUS='OLD',ERR=920)
> 10 CONTINUE
> READ (1,*,END=920,ERR=920) IUNIT
> if(iunit.eq.12)then
> iorbpot=1
> endif
> goto 10
> 920 continue
> …
> ---> yesterday
> …
> iorbpot=0
> !CALL GTFNAM(DEFFN,ERRFN)
> OPEN (1,FILE=DEFFN,STATUS='OLD',ERR=920)
> 10 CONTINUE
> READ (1,*,END=920,ERR=920) IUNIT
> if(iunit.eq.12)then
> iorbpot=1
> endif
> goto 10
> 920 continue
> close(1)
> …
>
> ---> now
> …
> iorbpot=0
> !CALL GTFNAM(DEFFN,ERRFN)
> !OPEN (1,FILE=DEFFN,STATUS='OLD',ERR=920)
> rewind(1)
> 10 CONTINUE
> READ (1,*,END=920,ERR=920) IUNIT
> if(iunit.eq.12)then
> iorbpot=1
> endif
> goto 10
> 920 continue
> close(1)
> …
>
> In the above further correction, I commented out the line
>
> OPEN (1,FILE=DEFFN,STATUS='OLD',ERR=920)
>
> and added a line immediately below
>
> rewind(1)
>
> The results are then fully consistent with those obtained without fix but with very short-length absolute path of SCRATCH.
>
> Thanks,
>
> Jianxin
>
>
>
>
> From: Jian-Xin Zhu <jxzhu at lanl.gov <mailto:jxzhu at lanl.gov>>
> Reply-To: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at <mailto:wien at zeus.theochem.tuwien.ac.at>>
> Date: Sat, 22 Dec 2012 07:57:15 +0000
> To: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at <mailto:wien at zeus.theochem.tuwien.ac.at>>
> Subject: Re: [Wien] Some interesting observation with "runsp_lapw -so -orb"on Mac OSX
>
> Dear Peter, Lawrence, and Gavin,
>
> It seems I finally got a solution to this issue.
> In the lapwso.f (under SRC_lapwso), I comment out the line 55
>
> …
> ' FORM:',FORM
> STOP 'OPEN FAILED'
> 8001 CONTINUE
> CLOSE (1)
> …
> --->
> …
> ' FORM:',FORM
> STOP 'OPEN FAILED'
> 8001 CONTINUE
> !CLOSE (1)
> …
>
>
> In the init.f (under SRC_lapwso), I comment the line 208 and put in the close(1) statement after line 216
>
> …
> iorbpot=0
> CALL GTFNAM(DEFFN,ERRFN)
> OPEN (1,FILE=DEFFN,STATUS='OLD',ERR=920)
> 10 CONTINUE
> READ (1,*,END=920,ERR=920) IUNIT
> if(iunit.eq.12)then
> iorbpot=1
> endif
> goto 10
> 920 continue
> …
> --->
> …
> iorbpot=0
> !CALL GTFNAM(DEFFN,ERRFN)
> OPEN (1,FILE=DEFFN,STATUS='OLD',ERR=920)
> 10 CONTINUE
> READ (1,*,END=920,ERR=920) IUNIT
> if(iunit.eq.12)then
> iorbpot=1
> endif
> goto 10
> 920 continue
> close(1)
> …
>
>
> The logics is: In the call statement, lines 96&97, in lapwso.f (under SRC_lapwso)
>
> call init(deffn,errfn,e,vru,emm,fl, &
> jspin,kpot,ipr,theta,phi,irlotot)
>
> I can interpret "deffn" and "errfn" as input variables.
>
> With this change, the problem with the performance depending on the length of the absolute SCRATCH path simply disappears.
> The new observation is: After the new fix, I got a few more eigenvalues from "lapwso", compared with the result from the successful "lapwso lapwo.def" run with a short
> length of SCRATCH path.
>
> For example, with the new fix, I got
>
> 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 1 82 30 1.0
> 1 -2.08090625254879
> 2 -2.03240701021303
> 3 -0.567246937574254
> 4 -0.539993339231611
> 5 0.231678304598749
> 6 0.250627531191759
> 7 0.252411966096012
> 8 0.279337686785437
> 9 0.926000679053928
> 10 0.930488199201178
> 11 1.14434220481735
> 12 1.16171520948171
> 13 1.23017831627502
> 14 1.23542826718575
> 15 1.24859931113056
> 16 1.26205576152643
> 17 1.28894610954967
> 18 1.29668691364255
> 19 1.37815121548287
> 20 1.38408143682758
> 21 1.39761816280017
> 22 1.40244451996550
> 23 1.40731069271633
> 24 1.41409848573386
> 25 1.42741835193314
> 26 1.44972058483728
> 27 1.45216131164329
> 28 1.46140020134674
> 29 1.46715280186968
> 30 1.48011952623831
>
> while the run with a short SCRATCH path but without fix spat out
>
> 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 1 82 26 1.0
> 1 -2.08090625254879
> 2 -2.03240701021303
> 3 -0.567210435437646
> 4 -0.539969939829431
> 5 0.231819653581942
> 6 0.250863233409108
> 7 0.252546650177783
> 8 0.279490391323386
> 9 0.926000679053927
> 10 0.930488199201178
> 11 1.15814779202316
> 12 1.20173218566071
> 13 1.24120493358655
> 14 1.30958379557833
> 15 1.32646347983887
> 16 1.33447988036269
> 17 1.37537123982317
> 18 1.38073681883232
> 19 1.38082472280697
> 20 1.40244451996550
> 21 1.40731069271633
> 22 1.41343387884413
> 23 1.41409848573386
> 24 1.42741835193313
> 25 1.45216131164328
> 26 1.46140020134674
>
> Please advise me on whether my change does make sense to you. This is important because if this change is correct, I should redo the calculations based on "runsp_lapw
> –so –orb" on all other cases and on other platforms (including linux cluster).
>
> Please let me know.
>
> Thanks,
>
> Jianxin
>
>
> From: Laurence Marks <L-marks at northwestern.edu <mailto:L-marks at northwestern.edu>>
> Reply-To: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at <mailto:wien at zeus.theochem.tuwien.ac.at>>
> Date: Thu, 20 Dec 2012 16:05:13 -0600
> To: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at <mailto:wien at zeus.theochem.tuwien.ac.at>>
> Subject: Re: [Wien] Some interesting observation with "runsp_lapw -so -orb"on Mac OSX
>
> I suggest adding an inquire statement to see what are the properties of the files, e.g. record length etc. this may lead nowhere but might if OSX had some unusual
> file defaults in fortran. Maybe also search the ifort/OSX lists for hints. I suspect a compiler/OS bug which may have no better fix than what you have done.
>
> On Dec 20, 2012 9:35 PM, "Zhu, Jianxin" <jxzhu at lanl.gov <mailto:jxzhu at lanl.gov>> wrote:
>
> Gavin,
>
> I did that and the problem remains.
> So at the moment, I will stay with by adding a simple writing statement in the lapwso.f file.
>
> Thanks,
>
> Jianxin
>
>
> From: Gavin Abo <gsabo at crimson.ua.edu <mailto:gsabo at crimson.ua.edu>>
> Reply-To: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at <mailto:wien at zeus.theochem.tuwien.ac.at>>
> Date: Thu, 20 Dec 2012 11:54:37 -0700
> To: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at <mailto:wien at zeus.theochem.tuwien.ac.at>>
> Subject: Re: [Wien] Some interesting observation with "runsp_lapw -so -orb"on Mac OSX
>
> Yes, FPOPT is for mpi parallel not serial.
>
> For serial, you need for fftw3:
>
> O Compiler options: -free -mp1 -prec-div -pc80 -pad -align -traceback -DFFTW3
> R R_LIB (LAPACK+BLAS): -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -L/opt/local/fftw3/lib/ -lfftw3
>
> This requires that you download ( http://fftw.org/download.html) and install fftw3.3.3 at /opt/local/fftw3/. Alternatively, you could use the mkl-fftw3
> library. For that, refer to the Wien2k user guide "11.1.1 Installation tips for mpich and fftw (either version 2.1.5 or 3.3".
>
> On 12/20/2012 11:41 AM, Zhu, Jianxin wrote:
>> Gavin,
>>
>> Yes. I am using serial mode for my Mac machines.
>>
>> This is what I have in the siteconfig_lapw procedure ---
>>
>>
>>
>> ....
>> Recommended options for system linuxif111 are:
>> Compiler options: -FR -mp1 -w -prec_div -pc80 -pad -ip
>> -DINTEL_VML -traceback
>> Linker Flags: $(FOPT)
>> -L/opt/intel/Compiler/11.1/046/mkl/lib/em64t -pthread
>> Preprocessor flags: '-DParallel'
>> R_LIB (LAPACK+BLAS): -lmkl_lapack -lmkl_intel_lp64
>> -lmkl_intel_thread -lmkl_core -openmp -lpthread -lguide
>>
>> Current settings:
>> O Compiler options: -free -mp1 -prec-div -pc80 -pad -align
>> -traceback
>> L Linker Flags: $(FOPT) -L/opt/intel/Composer/mkl/lib
>> P Preprocessor flags '-DParallel'
>> R R_LIB (LAPACK+BLAS): -lmkl_intel_lp64 -lmkl_intel_thread
>> -lmkl_core -liomp5 -lpthread
>>
>> S Save and Quit
>> Q Quit abandon changes
>>
>> To change an item select option.
>>
>> Selection:
>>
>>
>>
>>
>>
>> Do you mean I have to put in -DFFTW3 explicitly?
>>
>> In the OPTIONS file, I do see
>>
>> current:FPOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
>> -DFFTW3
>>
>> But that's for MPI running, right?
>>
>>
>>
>> If I look at the recommended options (as copied/pasted above), there is no
>> -DFFTW3 there.
>>
>> Maybe I haven't understand your point correctly?
>>
>> Do you want me to put -DFFTW3 explicitly behind the option FOPT lineso
>> that it changes from
>>
>>
>> -free -mp1 -prec-div -pc80 -pad -align -traceback
>>
>>
>> to
>>
>> -free -mp1 -prec-div -pc80 -pad -align -traceback -DFFTW3
>>
>>
>> ?
>>
>>
>> Thanks,
>>
>> Jianxin
>
> _______________________________________________ Wien mailing list Wien at zeus.theochem.tuwien.ac.at <mailto:Wien at zeus.theochem.tuwien.ac.at>
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
> _______________________________________________ Wien mailing list Wien at zeus.theochem.tuwien.ac.at <mailto:Wien at zeus.theochem.tuwien.ac.at>
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
> _______________________________________________ Wien mailing list Wien at zeus.theochem.tuwien.ac.at <mailto:Wien at zeus.theochem.tuwien.ac.at>
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
--
-----------------------------------------
Peter Blaha
Inst. Materials Chemistry, TU Vienna
Getreidemarkt 9, A-1060 Vienna, Austria
Tel: +43-1-5880115671
Fax: +43-1-5880115698
email: pblaha at theochem.tuwien.ac.at
-----------------------------------------
More information about the Wien
mailing list