[Wien] Problems with hf and so

[Gavin Abo]

The "error in read_weight: wrong case.weighthfnoso" might be due to a 
bug in SRC_hf/read_weight.f of WIEN2k 18.2.

I think it might be line 126 that needs commented out

!        nk = nkibzall

followed by recompiling the hf module with siteconfig.

It seems like the code was designed such that nk should be set to 
nkibzall on line 15 when "-newklist" is not used, while set instead when 
"-newklist" is used by line 17 in read_weight.f to:

         nk = nkibzoldk

However, you may want to wait for confirmation from the hf module 
developer on that.

On 1/6/2019 2:05 PM, Mikhail Nestoklon wrote:
>
> Dear wien2k community,
> In the new version of WIEN2k the hybrid functionals are compatible 
> with spin-orbit.
> However, using such combination I can not continue calculations after 
> I change the k-mesh.
>
> As a minimal non-working example, to compute the GaAs (the .struct is 
> fine, the band structure with e.g. mBJ is perfect, for completeness it 
> is in attachment) I am trying to
> $ init_lapw -b -vxc 19 -rkmax 8
> $ run_lapw
> $ init_hf_lapw            (choose 32 nband in GaAs.hf, 36 nband in 
> GaAs.in1c number of k =30 )
> $ run_lapw -hf
> $ initso_lapw             (everything default)
> $ run_lapw -hf -so
> This works, but if I then follow UG 4.5.8 and
> $ mv GaAs.klist_fbz GaAs.klist_fbz_old
> $ mv GaAs.klist_ibz GaAs.klist_ibz_old
> $ mv GaAs.outputkgenhf GaAs.outputkgenhf_old
> $ run_kgenhf_lapw  (choose 300)
> $ run_lapw -hf -so -newklist
> The result is
>  LAPW0 END
>  LAPW0 END
>  LAPW1 END
>  LAPW2 END
>  CORE  END
> error in read_weight: wrong case.weighthfnoso
>
> Am I doing something wrong? The error message is strange and I can not 
> understand how it is related with what I am doing.
>
> By the way, doing the same with reduced mesh, it gets worse: there is 
> memory error on a first iteration with spin-orbit,
> something like (this one for ubuntu 16.04 / ifort 15.0.1+mkl / xeon E5420)
> *** Error in `.../WIEN2k_18/hfc': munmap_chunk(): invalid pointer: 
> 0x0000000000d4cc90 ***
> The exact message may be different for different machines/compilers, 
> but I could not find the working combination. .
>
> Thank you in advance.
>
> Sincerely,
> Mikhail Nestoklon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20190106/3c148dda/attachment.html>