No, add the line Jacobian=0 before it. Do not delete the line rel1=0.5,
that will lead to chaos.
On Sun, Aug 19, 2018 at 12:10 AM, Dr. K. C. Bhamu
wrote:
> In wien2k_18.1 Line number 24 is " rel1=0.5D0"
> You advised changing " rel1=0.5D0" to "Jacobian=0". Right?
>
>
>
>
> Happy Sunday!!
>
>
>
By choosing a local scratch directory (like /scratch or /tmp or ...,
this depends on your computers, you can then add -scratch /scratch to
all wien2k run or x commands) and using massively k-parallelism (on as
many different nodes as possible, you can distribute these large
case.vector_xx
In wien2k_18.1 Line number 24 is " rel1=0.5D0"
You advised changing " rel1=0.5D0" to "Jacobian=0". Right?
Happy Sunday!!
regards
Bhamu
On Mon, Aug 13, 2018 at 8:34 PM, Laurence Marks
wrote:
> Line 24 of ScaleDiag.F, please change to
> Jacobian=0
>
> (It was a typo, the version
Dear Gavin,
Thank you for your comments. This is what I was afraid.
I can glue output files by myself, no problem, hopefully they don't
change the order of k-points. But one way to solve the disk-space issue
would be to write a script that calculates SOC eigenvalues k-point by
k-point. Then
From WIEN2k 18.2 UG page 126:
WFFIL: standard option, writes wave functions to file case.vector
(needed in lapw2)
SUPWF: suppresses wave function calculation (faster for testing
eigenvalues only)
WFPRI: prints eigenvectors to case.output1 and writes case.vector
(produces long outputs!)
With
Dear All, dear Prof. Blaha,
I used SUPWF in case.in1c to limit the size of output files.
Then I used:
x lapw1 -band -up -p -c
x lapw1 -band -dn -p -c
x lapwso -up -p -c
There are no errors, but lapwso does not seem to calculate eigenvalues.
I use 4 parallel cores, so I have 4 output files.
6 matches
Mail list logo