Dear Prof. Gavin,
Thank you so much for your elaborate answer. I really
appreciate it.
Thanks once again.
with best regards,
On Sat, 11 May 2024 at 20:47, Gavin Abo wrote:
> To find the answer to your question, it might help to look at the WIEN2k
> 23.2 source code.
>
>
Hello Peter,
I just use "x_nmr_lapw -p" and the rest is initiated by the nmr script.
The Line "/usr/local/WIEN2k/nmr_mpi -case MS_2M1_Al2 -mode current
-green -scratch /scratch/WIEN2k/ -noco " is just part of the
whole procedure and not initiated by me manually.. (I only copied the
Do you get identical gaps for:
LDA and then MBJ (no SO)
PBE and then MBJ (no SO) ???
If you did everything right, there is no reason why adding SO at the end
should give a different result.
Probably some other mistake ... ?
Am 11.05.2024 um 17:32 schrieb Yakup Boran:
Dear Dr Blaha,
Hallo Michael,
I don't understand the line:
/usr/local/WIEN2k/nmr_mpi -case MS_2M1_Al2 -mode current -green
-scratch /scratch/WIEN2k/ -noco
The mode current should run only k-parallel, not in mpi ??
PS: The repetition of
nmr_integ:localhost is useless.
nmr mode integ runs only
Dear Dr Blaha,
I think I did not write clear enough.
The calculation was done by following:
1. I did regular scf calculation with LDA
2. I added mBJ on it.
3. Then I added SOC.
I repeated the same calculation with PBE.
Thank you
11 May 2024 Cmt, saat 17:08 tarihinde Peter Blaha
şunu yazdı:
To find the answer to your question, it might help to look at the WIEN2k
23.2 source code.
In SRC_lapw2/fermi.F, lines 108 and 109 should have:
IF(myid.EQ.0) write(21,'(//,27h TEMP.-SMEARING WITH
,f10.5,4h Ry )') &
etemp
In x_lapw, line 979 should have:
Please read the UG. This is not a valid question for the mailing list.
Am 11.05.2024 um 10:38 schrieb shamik chakrabarti:
-- Forwarded message -
From: *shamik chakrabarti*
Date: Thu, 9 May 2024 at 19:50
Subject: Re: unit of eval in case.in2
To: A Mailing list for WIEN2k users
Hello Peter,
this is the .machines file content:
granulartity:1
omp_lapw0:8
omp_global:2
1:localhost
1:localhost
1:localhost
1:localhost
1:localhost
1:localhost
1:localhost
1:localhost
nmr_integ:localhost
nmr_integ:localhost
nmr_integ:localhost
nmr_integ:localhost
nmr_integ:localhost
-- Forwarded message -
From: shamik chakrabarti
Date: Thu, 9 May 2024 at 19:50
Subject: Re: unit of eval in case.in2
To: A Mailing list for WIEN2k users
Is it that we have to use either 0 or 0.0018 for room temperature
broadening?
On Thu, 9 May 2024, 17:40 shamik chakrabarti,
No.
These 2 calculations should be exactly the same.
What matters is only: XC_MBJ
Everything in parenthesis is only a comment to give you a few common
options.
Am 11.05.2024 um 16:00 schrieb Yakup Boran:
Dear Dr Blaha,
Thank you for your response.
———
case.in0 for LDA is
TOT
Dear Dr Blaha,
Thank you for your response.
———
case.in0 for LDA is
TOT XC_MBJ ( (XC_PBE,XC_PBESOL,XC_WC,XC_MBJ,XC_SCAN)
R2V IFFT (R2V)
30 30 48 2.00 1 NCON 9 # min IFFT-parameters, enhancement factor, iprint,
NCON n
——-
Case.in0 for PBE
TOT XC_MBJ (
I'm not quite sure I understand what you did.
You are always using mBJ (for VX), but how do you mix in LDA or PBE ?
By default we use LDA for VC, (and anything for EX and EC, since this is
not important).
Usually, the choice of VC has only a small effect (as compared to VX).
Please show
Hmm. ?
Are you using k-parallel AND mpi-parallel ?? This could overload
the machine.
How does the .machines file look like ?
Am 10.05.2024 um 18:15 schrieb Michael Fechtelkord via Wien:
Dear all,
the following problem occurs to me using the NMR part of WIEN2k (23.2)
on a opensuse
13 matches
Mail list logo
