[Wien] Some interesting observation with "runsp_lapw -so -orb"on Mac OSX

Peter Blaha pblaha at theochem.tuwien.ac.at
Tue Dec 18 07:55:08 CET 2012


Of course SO breaks cubic symmetry and reduces symmetry. You MUST use symmetso during
initso.
However, it is not necessary to change from F to P symmetry and introduce
4 atoms, unless you want to introduce some possible non-equivalency of the
atoms in your cell.

In any case, this cannot be the reason about your SCRATCH-problem, which seems
to be something completely different now...

Am 17.12.2012 21:15, schrieb Zhu, Jianxin:
> 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
> 
> _______________________________________________
> 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