Error in epsilon.cplx.x : a fail in a case of many bands

[加藤洋生]

Dear developers and users of BerkeleyGW,

Hi there, I am new to BerkelyGW 3.0, while having some experiences in older version.

Let me ask some advices for the trouble I met when running epsilon.cplx.x.

The system is 2D hBN.

I'm trying to execute the epsilon.cplx.x with 16x16x1 kpoint grid and 3000 bands.

The job is however terminated with following messages:

 Started calculation of matrix elements with 512 transition(s) at 18:22:08.
 [ 18:22:08 |   0% ] transition   1 / 512.
*** LOG: calling genwf  time = 18:22:08.136
rk =     0.000000    0.000000    0.000000
qq =     0.001000    0.002000    0.000000
 
ERROR: genwf_mpi: No match for rkq point:   0.001   0.002   0.000 in file WFNq
 
forrtl: error (76): Abort trap signal
Image              PC                Routine            Line        Source            
epsilon.cplx.x     0000000003F4FD4B  Unknown               Unknown  Unknown
libpthread-2.28.s  0000148D7F3C2B20  Unknown               Unknown  Unknown
libc-2.28.so       0000148D7CD727FF  gsignal               Unknown  Unknown
libc-2.28.so       0000148D7CD5CC35  abort                 Unknown  Unknown
epsilon.cplx.x     00000000004084D9  Unknown               Unknown  Unknown
epsilon.cplx.x     0000000000505C67  Unknown               Unknown  Unknown
epsilon.cplx.x     0000000000505010  Unknown               Unknown  Unknown
epsilon.cplx.x     00000000004E88EF  Unknown               Unknown  Unknown
epsilon.cplx.x     0000000000405622  Unknown               Unknown  Unknown
libc-2.28.so       0000148D7CD5E7B3  __libc_start_main     Unknown  Unknown
epsilon.cplx.x     000000000040552E  Unknown               Unknown  Unknown
srun: error: c15u01n2: task 0: Aborted (core dumped)
srun: launch/slurm: _step_signal: Terminating StepId=976185.0
slurmstepd: error: *** STEP 976185.0 ON c15u01n2 CANCELLED AT 2022-08-23T18:22:09 ***

and also a Warning appears:

WARNING: checkbz: unfolded BZ from WFN has missing k-points
See file checkbz.log for more information.

I understand a conflict is happening when referring kpoints,  

but a weird point is that the job successfully finishes when the number of bands is 200.
I confirmed all input files and symbolic links are exactly same in the two cases except the number of bands.

Let me attach a zip file of the working directory.
(I eliminated big files, but I am sorry if it is breaking the regulation of this forum.)

I would appreciate if I could have advices.

Best regards,

Hiroki Katow

[加藤洋生]

I got to be able to avoid this problem.

It turned out that epsilon.x is not responsible to it, sorry.

Seemingly pw.x in many-band calculation or pw2bgw.x overwrites some of the input files generated by scf calculation.

First I executed codes in the following orders:

i. scf calculation by pw.x

ii. many-band calculation with 'bands' option by pw.x for WFN

iii. many-band calculation with 'bands' option by pw.x for WFN_inner

iv. conversion of WFN by pw2bgw.x

v. conversion of WFN_inner by pw2bgw.x
(and also for WFNq)

vi. run epsilon.x

I let epsilon.x and  pw2bgw.x write down k points which they actually read, and found that  pw2bgw.x at step iv is reading k point set of WFN_inner.

So I rearranged the order as:

i. scf calculation by pw.x

ii. many-band calculation with 'bands' option by pw.x for WFN

iii. conversion of WFN by pw2bgw.x

iv. scf calculation by pw.x

v. many-band calculation with 'bands' option by pw.x for WFN_inner

vi. conversion of WFN_inner by pw2bgw.x
(and also for WFNq)

vii. run epsilon.x

and it correctly worked.

Perhaps it might be trivial, but I wasn't aware of it.

Thank you so much if someone already considered this question.

Best,

Hiroki Katow 

2022年8月26日金曜日 14:38:33 UTC+9 加藤洋生:

[inagaki ctec]

Hi Prof. Kato,

It's grate to hear someone solving trouble by oneself.

And I feel sorry I didn't reply to this post.

I often fall into same situation.

In such case I am utilizing wfn_rho_vxc_info.x to write out header information of WFN WFnq WFN_co brabra.

Sometimes it's helpful.

Best Reagrds,

Jun Inagaki

2022年9月8日木曜日 17:15:10 UTC+8 hiroki...@gmail.com:

[加藤洋生]

Dear Inagaki-san

Thank you for an informative reply.

I never knew that code of utilities.

Best regards,

Hiroki Katow

2022年9月8日木曜日 21:42:46 UTC+9 ctec.i...@gmail.com: