Ultralong computational time in The Real Time Collisions calculations

Questions and doubts about features of non linear optic in Yambo (yamb_nl)

Moderators: Davide Sangalli, claudio, myrta gruning

User avatar
Davide Sangalli
Posts: 605
Joined: Tue May 29, 2012 4:49 pm
Location: Via Salaria Km 29.3, CP 10, 00016, Monterotondo Stazione, Italy
Contact:

Re: Ultralong computational time in The Real Time Collisions calculations

Post by Davide Sangalli » Mon Jun 26, 2023 8:35 am

Dear Dean,
few suggestion.

Energy cutoff:

Code: Select all

HARRLvcs= 25000      mHa      # [HA] Hartree     RL components
EXXRLvcs=   5000       mHa     # [XX] Exchange    RL components
CORRLvcs=  5000       mHa      # [GW] Correlation RL components
this should be converted into

Code: Select all

BSENGexx= 25000      mHa    # [BSK] Exchange components
BSENGBlk=    5000     mHa    # [BSK] Screened interaction block size [if -1 uses all the G-vectors of W(q,G,Gp)]
Number of bands:

Code: Select all

% COLLBands
  31 | 36 |                     # [COLL] Bands for the collisions
%
this should be converted into

Code: Select all

% BSEBands
  31 | 36 |                         # [BSK] Bands range
%
The RIM-W is not yet coded in the real-time collisions.

Last, you can also first try to reproduce the linear response with the yambo_rt executable. The collisions are the same (although if you generate them with yambo_nl they will be in double precision, so you may consider to generate them with yambo_rt, same input file).
After the collisions have been generated you would have two different input files for the real time dynamics. Please check the tutorials on the yambo wiki.

Best,
D.
Davide Sangalli, PhD
CNR-ISM, Division of Ultrafast Processes in Materials (FLASHit) and MaX Centre
https://sites.google.com/view/davidesangalli
http://www.max-centre.eu/

Dean
Posts: 98
Joined: Thu Oct 10, 2019 7:03 am

Re: Ultralong computational time in The Real Time Collisions calculations

Post by Dean » Thu Jun 29, 2023 1:03 am

Dear Davide,
Thanks for your reply.
I find that the RIM-W is the origin of this difference.
Without RIM_W, the peak of linear response is as ths same as the RT-BSE. You said, "The RIM-W is not yet coded in the real-time collisions".
I am confused should I use RIM_W method in linear response?
Best,
Dr. Yimin Ding
Soochow University, China.

User avatar
Davide Sangalli
Posts: 605
Joined: Tue May 29, 2012 4:49 pm
Location: Via Salaria Km 29.3, CP 10, 00016, Monterotondo Stazione, Italy
Contact:

Re: Ultralong computational time in The Real Time Collisions calculations

Post by Davide Sangalli » Fri Jun 30, 2023 9:46 am

RIM_W is a convergence accelerator.
It is designed to speed up the convergence of momentum integrals involving the screened interaction W.

Thus, if available it can help to speed up convergence.
It is implemented in BSE, not in the real-time collisions.

Also please notice that RIM_W was designed for GW calculations. The BSE dependence on the k-grid does not come only from momentum integrals involving the screened interaction W, but also from the convergence of the excitonic wave-function in k space.

Best,
D.
Davide Sangalli, PhD
CNR-ISM, Division of Ultrafast Processes in Materials (FLASHit) and MaX Centre
https://sites.google.com/view/davidesangalli
http://www.max-centre.eu/

Dean
Posts: 98
Joined: Thu Oct 10, 2019 7:03 am

Re: Ultralong computational time in The Real Time Collisions calculations

Post by Dean » Tue Jul 11, 2023 7:23 am

Dear Davide,
Thanks for your reply.
I met another question about SHG calculations.
When the QP date from GPU-version of yambo without BG terminator is used (GfnQPdb= "E < ./ndb.QP_merged_1_gw_ppa"), the calculated polarization and SHG coefficient is large abnormally.
But, when the QP date from CPU-version of yambo with BG terminator is used, the calculated polarization and SHG coefficient is normal.
The input and some output files are attached.
Any Suggestions are greatly appreciated.
Best,
You do not have the required permissions to view the files attached to this post.
Dr. Yimin Ding
Soochow University, China.

User avatar
Davide Sangalli
Posts: 605
Joined: Tue May 29, 2012 4:49 pm
Location: Via Salaria Km 29.3, CP 10, 00016, Monterotondo Stazione, Italy
Contact:

Re: Ultralong computational time in The Real Time Collisions calculations

Post by Davide Sangalli » Tue Jul 11, 2023 8:36 am

Can you send the report files of the two runs?

Also please compare the content of the two ndb.QP databases to see how they differ.
You can use ncdump.

Code: Select all

ncdump ndb.QP > ndb.QP.dat
Best,
D
Davide Sangalli, PhD
CNR-ISM, Division of Ultrafast Processes in Materials (FLASHit) and MaX Centre
https://sites.google.com/view/davidesangalli
http://www.max-centre.eu/

Dean
Posts: 98
Joined: Thu Oct 10, 2019 7:03 am

Re: Ultralong computational time in The Real Time Collisions calculations

Post by Dean » Wed Jul 12, 2023 3:00 am

Dear Davide,
Thanks for your reply.
The report files and QP databases of the two runs are attached. Please refer them.
After the operation "ncdump ....", there is no output.

Best,
You do not have the required permissions to view the files attached to this post.
Dr. Yimin Ding
Soochow University, China.

User avatar
Davide Sangalli
Posts: 605
Joined: Tue May 29, 2012 4:49 pm
Location: Via Salaria Km 29.3, CP 10, 00016, Monterotondo Stazione, Italy
Contact:

Re: Ultralong computational time in The Real Time Collisions calculations

Post by Davide Sangalli » Wed Jul 12, 2023 11:52 am

Code: Select all

ncdump ndb.QP > ndb.QP.dat
After the operation "ncdump ....", there is no output.
The output would be contained in the file ndb.QP.dat, but of course ndb.QP must be the name of the file with the QP corrections, in your case ndb.QP_merged_1_gw_ppa ...

Anyway, looking at the two reports, in both cases yambo is compiled for runing on CPUs only (no CUDA support).
Also there is a number of differences. For example in one case the terminator is used, in the other it is not.
Moreover the databases loaded come from merging done in different ways.

Finally the ndb.QP inside the folder QP_without_BG_from_GPU seems to be corrupted

D.
Davide Sangalli, PhD
CNR-ISM, Division of Ultrafast Processes in Materials (FLASHit) and MaX Centre
https://sites.google.com/view/davidesangalli
http://www.max-centre.eu/

Post Reply