[Wien] Some interesting observation with "runsp_lapw -so -orb"on Mac OSX
Zhu, Jianxin
jxzhu at lanl.gov
Mon Dec 17 21:15:14 CET 2012
Peter,
Instead of doing change to the source code, I am asking myself a question.
For an original fcc structure in the paramagnetic state, by which I mean
there is only one atom in case.struct,
can it still be used for the "runsp_lapw -so -orb" for a ferromagnetic
state?
The answer seems to be negative.
Because when we have spin-orbit coupling in a magnetic state, the symmetry
can be reduced and the equivalent atoms can be reduced.
However, if the structure file has only one atom (like fcc Fe), there is
no degree of freedom to adjust the number of non-equivalent atoms.
Therefore, I change the structure file to have 4 atoms (the same element,
two non-equivalent types) like
P LATTICE,NONEQUIV.ATOMS: 2221_Pm-3m
MODE OF CALC=RELA unit=bohr
8.140000 8.140000 8.140000 90.000000 90.000000 90.000000
ATOM 1: X=0.00000000 Y=0.00000000 Z=0.00000000
MULT= 1 ISPLIT= 2
Np1 NPT= 781 R0=0.00000500 RMT= 2.50000 Z: 93.0
LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000
0.0000000 1.0000000 0.0000000
0.0000000 0.0000000 1.0000000
ATOM -2: X=0.50000000 Y=0.50000000 Z=0.00000000
MULT= 3 ISPLIT=-2
-2: X=0.00000000 Y=0.50000000 Z=0.50000000
-2: X=0.50000000 Y=0.00000000 Z=0.50000000
Np2 NPT= 781 R0=0.00000500 RMT= 2.50000 Z: 93.0
LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000
0.0000000 1.0000000 0.0000000
0.0000000 0.0000000 1.0000000
48 NUMBER OF SYMMETRY OPERATIONS
-1 0 0 0.00000000
0-1 0 0.00000000
0 0-1 0.00000000
....
During the initso_lapw run, I accept the new structure file from symmetso.
The new structure file then contains
P 3 221
RELA
8.140000 8.140000 8.140000 90.000000 90.000000 90.000000
ATOM -1: X=0.00000000 Y=0.00000000 Z=0.00000000
MULT= 1 ISPLIT=-2
Np1 NPT= 781 R0=.000005000 RMT= 2.50000 Z: 93.00000
LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000
0.0000000 1.0000000 0.0000000
0.0000000 0.0000000 1.0000000
ATOM -2: X=0.50000000 Y=0.50000000 Z=0.00000000
MULT= 1 ISPLIT=-2
Np2 NPT= 781 R0=.000005000 RMT= 2.50000 Z: 93.00000
LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000
0.0000000 1.0000000 0.0000000
0.0000000 0.0000000 1.0000000
ATOM -3: X=0.00000000 Y=0.50000000 Z=0.50000000
MULT= 2 ISPLIT= 8
-3: X=0.50000000 Y=0.00000000 Z=0.50000000
Np3 NPT= 781 R0=.000005000 RMT= 2.50000 Z: 93.00000
LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000
0.0000000 1.0000000 0.0000000
0.0000000 0.0000000 1.0000000
16 NUMBER OF SYMMETRY OPERATIONS
1 0 0 0.00000000
0 1 0 0.00000000
0 0 1 0.00000000
...
Now the code runs properly on my Mac OSX machines.
Please advise whether this adjustment makes sense to you.
Best regards,
Jianxin
-----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: Mon, 17 Dec 2012 17:52:30 +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
>I have another guess, also I'm not sure if it fixes the problem. It
>could be that some long pathnames get truncated:
>
>When reading the filnames which are stored in the def files, some
>"older" programs (like lapwso) have still
>
>character*80 ...,fname,...
>
>while others have changed this to character*180
>
>Change in lapwso.f:
>
> character*80 deffn,errfn,fname
>to
> character*80 deffn,errfn
> character*180 fname
>
>
>Let me know if this fixes the problem.
>
>PS: Is there no other information when lapwso does not write the
>energyso files ? It should complain that it cannot read the vector files.
>
>*error files, *outputso file ???
>
>
>
>On 12/17/2012 04:38 PM, Zhu, Jianxin wrote:
>> Peter,
>>
>>
>>
>> -----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: Mon, 17 Dec 2012 07:59:04 +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
>>
>>> I do not have a Mac, so cannot test it. But:
>>>
>>> does the $SCRATCH directory exist ?
>>>
>>> what gives: ls -alsrp $SCRATCH
>>>
>>> do you see the vectorup/dn file generated by lapw1 ?
>>
>> ...4312510 Dec 17 08:32 nfcc.vectordn
>> ...205826 Dec 17 08:32 nfcc.vectorsodn
>> ...205826 Dec 17 08:32 nfcc.vectorsoup
>> ...4312510 Dec 17 08:32 nfcc.vectorup
>>
>>
>>
>>
>>>
>>> cat uplapw1.def
>>> cat lapwso.def
>>
>> cat uplapw1.def
>> 4,'nfcc.klist', 'unknown','formatted',0
>> 5,'nfcc.in1', 'old', 'formatted',0
>> 6,'nfcc.output1up','unknown','formatted',0
>> 10,'/Volumes/Macintosh_HD2/scratch/wien2k_scratch/nfcc.vectorup',
>> 'unknown','unformatted',9000
>> 11,'nfcc.energyup', 'unknown','formatted',0
>> 18,'nfcc.vspup', 'old', 'formatted',0
>> 19,'nfcc.vnsup', 'unknown','formatted',0
>> 20,'nfcc.struct', 'old', 'formatted',0
>> 21,'nfcc.scf1up', 'unknown','formatted',0
>> 55,'nfcc.vec', 'unknown','formatted',0
>> 71,'nfcc.nshup', 'unknown','formatted',0
>> 200,'/Volumes/Macintosh_HD2/scratch/wien2k_scratch/nfcc.storeHinvup',
>> 'replace','unformatted',9000
>>
>>
>>
>> cat lapwso.def
>> 4 ,'nfcc.in1', 'old', 'formatted',0
>> 5 ,'nfcc.inso', 'old', 'formatted',0
>> 6 ,'nfcc.outputso', 'unknown','formatted',0
>> 8 ,'nfcc.scfso', 'unknown','formatted',0
>> 9 ,'/Volumes/Macintosh_HD2/scratch/wien2k_scratch/nfcc.vectordn',
>> 'old', 'unformatted',9000
>> 10 ,'/Volumes/Macintosh_HD2/scratch/wien2k_scratch/nfcc.vectorup',
>> 'unknown', 'unformatted',9000
>> 18,'nfcc.vspdn', 'old','formatted',0
>> 19,'nfcc.vspup', 'unknown','formatted',0
>> 20 ,'nfcc.struct', 'old', 'formatted',0
>> 22,'nfcc.vnsdn', 'old','formatted',0
>> 23,'nfcc.vnsup', 'unknown','formatted',0
>> 41,'/Volumes/Macintosh_HD2/scratch/wien2k_scratch/nfcc.vectorsodn',
>> 'unknown','unformatted',9000
>> 42,'/Volumes/Macintosh_HD2/scratch/wien2k_scratch/nfcc.vectorsoup',
>> 'unknown','unformatted',9000
>> 44,'nfcc.vect1', 'unknown','unformatted',9000
>> 45,'nfcc.normsodn', 'unknown','formatted',0
>> 46,'nfcc.normsoup', 'unknown','formatted',0
>> 51,'nfcc.energysodn', 'unknown','formatted',9000
>> 52,'nfcc.energysoup', 'unknown','formatted',9000
>> 53,'nfcc.energydum', 'unknown','formatted',9000
>> 54,'nfcc.energydn', 'old','formatted',9000
>> 55 ,'nfcc.energyup', 'unknown', 'formatted',9000
>> 11,'nfcc.vorbdn', 'unknown','formatted',0
>> 12,'nfcc.vorbup', 'unknown','formatted',0
>> 13,'nfcc.vorbdu', 'unknown','formatted',0
>>
>>
>>
>>>
>>> Are the definitions correct ? Do you see the correct path in these def
>>> files
>>> for the vector files ? Or is a "/" missing ???
>>
>> I see the correct path and no "/" is missing.
>>
>>>
>>> Maybe the Mac-filesystem does not allow for a path of arbitrary lenght
>>> (similar as
>>> upper/lower case problems ....) ?
>>
>>
>> If I run other modes like "runsp_lapw -so" or "runsp_lapw -orb", etc.,
>> there is no problem.
>>
>>>
>>> Eventually, set the SCRATCH variable to
>>> /Volumes/Macintosh_HD2/scratch/wien2k_scratch/
>>> (with a "/" at the end). The wien2k-scripts should append this
>>> automatically, but maybe
>>> the sed command behaves differently on the Mac ?
>>
>>
>> As shown above with "cat", the slash "/" is indeed appended
>>automatically.
>>
>>
>> Thanks,
>>
>> Jianxin
>>
>>
>>
>>
>>
>>>
>>> Am 17.12.2012 06:02, schrieb Zhu, Jianxin:
>>>> Dear Peter and Wien2k users,
>>>>
>>>> I think it is much more fruitful to get help from you.
>>>>
>>>> I have always been observing interesting issues with "runsp_lapw so
>>>> orb" (or "runsp_c_lapw so orb") on my Mac OSX machine.
>>>>
>>>> If I define the scratch as something like ---
>>>>
>>>> [] jxzhu% echo $SCRATCH
>>>> /Volumes/Macintosh_HD2/scratch/wien2k_scratch
>>>>
>>>> By running wien2k with the above mentioned mode, I get the error
>>>>
>>>>
>>>> [] jxzhu% runsp_lapw -so -orb -cc 0.001 -NI -i 1
>>>> LAPW0 END
>>>> ORB END
>>>> ORB END
>>>> LAPW1 END
>>>> LAPW1 END
>>>> LAPWSO END
>>>> forrtl: severe (59): list-directed I/O syntax error, unit 30, file
>>>> /Users/jxzhu/nfcc/nfcc.energysoup
>>>> Image PC Routine Line
>>>> Source
>>>> lapw2c 00000001001274AC Unknown Unknown
>>>> Unknown
>>>> lapw2c 0000000100125FD4 Unknown Unknown
>>>> Unknown
>>>> lapw2c 00000001000F852E Unknown Unknown
>>>> Unknown
>>>> lapw2c 00000001000AF83A Unknown Unknown
>>>> Unknown
>>>> lapw2c 00000001000AF009 Unknown Unknown
>>>> Unknown
>>>> lapw2c 00000001000DA81E Unknown Unknown
>>>> Unknown
>>>> lapw2c 000000010003AF56 _fermi_tetra_ 516
>>>> fermi_tmp_.F
>>>> lapw2c 000000010003A476 _fermi_ 111
>>>> fermi_tmp_.F
>>>> lapw2c 000000010006E463 _MAIN__ 278
>>>> lapw2_tmp_.F
>>>> lapw2c 000000010000108C Unknown Unknown
>>>> Unknown
>>>> lapw2c 0000000100001024 Unknown Unknown
>>>> Unknown
>>>>
>>>> > stop error
>>>>
>>>>
>>>> The problem is that the "x lapwso up orb" does not generate
>>>> eigenvalues properly.
>>>>
>>>> However, if I specify the scratch as something below (or with the
>>>> absolute path being not greater than 22 characters in length)
>>>>
>>>> [] jxzhu% echo $SCRATCH
>>>> /Users/jxzhu/scratch
>>>>
>>>> By running wien2k with the above mentioned mode, no error appears
>>>>
>>>> [] jxzhu% runsp_lapw -so -orb -cc 0.001 -NI -i 1
>>>> LAPW0 END
>>>> ORB END
>>>> ORB END
>>>> LAPW1 END
>>>> LAPW1 END
>>>> LAPWSO END
>>>> LAPW2 END
>>>> LAPW2 END
>>>> LAPWDM END
>>>> CORE END
>>>> CORE END
>>>> MIXER END
>>>>
>>>> > charge in SCF NOT CONVERGED
>>>>
>>>> If I look into the file nfcc.energysoup, I see the command "x lapwso
>>>> up orb" does generate eigenvalues properly.
>>>>
>>>> This kind of issues only happen on Mac OSX machines (I am using
>>>>10.6.8,
>>>> and the wien2k is compiled with Intel 11.1/089) but not on linux
>>>> machines.
>>>> In addition, on the same Mac OSX machine, the running modes like
>>>> "runsp_lapw so" and "runsp_lapw orb" simply work fine.
>>>>
>>>> I very much appreciate if you can help reproduce this on your Mac OSX
>>>> machines and share your experience on how to fix it (if it is true).
>>>>
>>>> Sincerely yours,
>>>>
>>>> Jianxin
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>--
>
> P.Blaha
>--------------------------------------------------------------------------
>Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
>Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
>Email: blaha at theochem.tuwien.ac.at WWW:
>http://info.tuwien.ac.at/theochem/
>--------------------------------------------------------------------------
>_______________________________________________
>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