[Wien] Some interesting observation with "runsp_lapw -so -orb"on Mac OSX
Zhu, Jianxin
jxzhu at lanl.gov
Mon Dec 24 03:38:13 CET 2012
Dear Peter,
In my previous message, I sent you the two files with the changes based on
what you suggested.
For a given case with given values of U and J, "runsp_lapw -so -orb"
converges nicely.
Just now, when I changed to use other values of U and J, the above run
seems to not see the use of new U and J values and just stops at the first
iteration.
Cheers,
Jianxin
-----Original Message-----
From: Jian-Xin Zhu <jxzhu at lanl.gov>
Reply-To: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at>
Date: Mon, 24 Dec 2012 02:01:03 +0000
To: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at>
Subject: Re: [Wien] Some interesting observation with "runsp_lapw -so
-orb"on Mac OSX
>Hi Peter,
>
>The way you suggested is the best.
>Since "iorbpot" is already defined in "MODULE orb", we don't have to make
>any
>change to modules.f.
>
>Attached please find the changed source files lapwso.f and init.f.
>The two variables deffn,errfn (together with redundant fname) have been
>removed from init.f (including their type declaration statement).
>It would be great that a broad spectrum of users can test with these two
>modified files.
>
>I have other comments below on the other two possibilities.
>
>
>
>-----Original Message-----
>From: Peter Blaha <pblaha at theochem.tuwien.ac.at>
>Reply-To: A Mailing list for WIEN2k users
><wien at zeus.theochem.tuwien.ac.at>
>Date: Sun, 23 Dec 2012 09:24:54 +0100
>To: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at>
>Subject: Re: [Wien] Some interesting observation with "runsp_lapw -so
>-orb"on Mac OSX
>
>>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
>
>
>For some reason unknown to me, this possibility does not work well.
>
>>b) uncomment the close 1 statement and put a rewind 1 statement.
>
>
>This possibility works well but the coding style is not elegant.
>
>>
>>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).
>
>
>Yes. It is the cleanest.
>
>Best regards,
>
>
>
>Jianxin
>
>
>>
>>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
>>-----------------------------------------
>>_______________________________________________
>>Wien mailing list
>>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
More information about the Wien
mailing list