[Wien] Some interesting observation with "runsp_lapw -so -orb"on Mac OSX
Zhu, Jianxin
jxzhu at lanl.gov
Sat Dec 22 18:51:44 CET 2012
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121222/7dec58bc/attachment.htm>
More information about the Wien
mailing list