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 <pbl...@theochem.tuwien.ac.at> Reply-To: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at> List-Post: wien@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 -------------- next part -------------- A non-text attachment was scrubbed... Name: init.f Type: application/octet-stream Size: 8103 bytes Desc: init.f URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121224/ab006e1b/attachment-0002.dll> -------------- next part -------------- A non-text attachment was scrubbed... Name: lapwso.f Type: application/octet-stream Size: 6490 bytes Desc: lapwso.f URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121224/ab006e1b/attachment-0003.dll>
