Page 1 of 1

Exciton wavefunction vs FFTGvecs

Posted: Sat Dec 23, 2023 10:39 am
by sdwang
Dear developers,
I have plotted the exciton wavefunction in real space using Ypp (version 5.2.0), and I found the default (22586 RL) and reduced (16113 RL) FFTGvecs give the very different results, as attached. Is it normal?
Thanks!

Shudong

Re: Exciton wavefunction vs FFTGvecs

Posted: Sat Dec 23, 2023 11:03 am
by Daniele Varsano
Dear Shudong,

yes, I think it can happen, increasing the FFT grid you are also increasing the real-space grid. Yambo fix the hole in the real space grid in the closest point to the one indicated in the input, so in the two calculations the hole is placed in slightly different points
and this can be the reason of the encountered difference. The position of the hole is reported in the output.

Best,
Daniele

Re: Exciton wavefunction vs FFTGvecs

Posted: Sun Dec 24, 2023 3:27 am
by sdwang
Dear Daniele,
Thanks for your quick reply. I have checked the output files and the situations as you said. Since the real space distribution is totally different, do we need to converge the FFT vs. the wavefunction distribution? I mean, the reduced FFT can not capture the 'real' exciton features.

Thanks!

Merry Christmas and happy new year in advance!

Shudong

Re: Exciton wavefunction vs FFTGvecs

Posted: Mon Jan 08, 2024 11:10 am
by Daniele Varsano
Dear Shudong,

I think that the wfs distribution is so different because the hole is placed in different position.
Try to have an FFT grid fine enough to have the hole near the position you want to place it, possibly in a point presenting some
symmetry.

Best,

Daniele

Re: Exciton wavefunction vs FFTGvecs

Posted: Sat Jan 13, 2024 3:20 am
by sdwang
Dear Daniele,
I have tested the FFT values vs. the exciton distributions, and I found that the reduced FFT grid gives the same positions as I set in the input of ypp.in. However, when increase the FFT, the position is far from the value I set in the input as below from the log:
...
Extended grid : 348 348 128
<03s> P2: Hole position in the DL cell : 0.00000 4.02759 39.41810 [c.c.] (I set in the ypp.in)
<03s> P2: position in the FFT grid : 0.00000 4.02760 39.17786 [c.c.] (reduced FFT from the default value, which is the same as the set value)
<03s> P2: translated position : 48.83200 88.60709 39.17786 [c.c.]
...
If I leave the FFT in the default, it is
...
Extended grid : 522 522 175
<05s> Hole position in the DL cell : 0.00000 4.02759 39.41810 [c.c.] (I set in the ypp.in)
<05s> position in the FFT grid : 0.38756 4.02759 39.61244 [c.c.] (different from the set value)
<05s> translated position : 49.21954 88.60709 39.61244 [c.c.]
...

Thanks!

Shudong

Re: Exciton wavefunction vs FFTGvecs

Posted: Wed Jan 17, 2024 12:41 pm
by Daniele Varsano
Dear Shudong,

this is quite odd.
In the output file of the wfs you have the real space grid, can you check that the hole position in the larger grid case is indeed the point closer to the one in the input file?
To make this test set consider the unit cell only i.e. ncell (1,1,1).

Best,
Daniele

Re: Exciton wavefunction vs FFTGvecs

Posted: Wed Jan 17, 2024 2:02 pm
by sdwang
Dear Daniele,
Below is the log of 1x1x1 cell canculation:
...
<04s> P1: Extended grid : 18 18 175
<04s> P1: Hole position in the DL cell : 0.00000 4.02759 39.41810 [c.c.]
<04s> P1: position in the FFT grid : 0.00000 4.02759 39.61244 [c.c.] (default FFT)
<04s> P1: translated position : 0.00000 4.02759 39.61244 [c.c.]
...
in which the hole position is almost identical. And I tested the number of the cell vs. the hole position, and found when the cell is increased to 25x25x1, the hole position got the problem. The k-point I used in nscf.in is 36x36x1.

Best

Shudong

Re: Exciton wavefunction vs FFTGvecs

Posted: Fri Jan 19, 2024 10:12 am
by Daniele Varsano
Dear Shudong,
that's weird, I would need an example to reproduce the problem and inspect it.
Can you provide a minimal example where the problem arise? Please note that it should be independent of the size of the kernel so you can
try with a kernel using just two bands, x only (so no screening) with very few G vectors.

Mnay thanks,

Daniele