Hello,
I'm trying to pick up a calculation from several years ago and apply it to a series of related systems. Specifically, I want to calculate the energy of bound excitons in a sheet material. The original calculations were done with exciting lithium, and I have downloaded and compiled/tested exciting boron-10 for the purpose of completing the calculations moving forward. However, I am not able to produce the previous results from the same input files: I now find a very strong bound exciton peak at an energy .1 eV different (.4 vs .3 eV total). I understand that there have been changes to both the species files and the way BSE calculations are performed since the lithium version came out.
Can anyone comment on whether what I'm seeing is a result of these changes and whether there are any things I can do moving forward to ensure results compatibility for BSE calculations with old versions?
Thanks,
NikA
Dear NikA,
could you please paste here your input file? We will try to figure out what is going on.
Best regards,
Caterina Cocchi
(exciting team)
The following is my input file for the BSE calculation. The GS calculations that inform the BSE seem to yield the same results («1% difference) and I can start with either a boron-10 or lithium STATE.OUT & EFERMI.OUT and get the same difference in exciton energies.
<input>
<title>BSE for Ge-H bulk</title>
<structure speciespath="/nfs/11/osu5259/EXCITING/exciting/species/">
<crystal scale="1.0">
<basevect>7.655137 0.0 0.0</basevect>
<basevect>-3.82757 6.629544 0.0</basevect>
<basevect>0.0 0.0 19.95477</basevect>
</crystal>
<species speciesfile="H3.xml" rmt="1.0000" >
<atom coord="0.3333344712623417 0.6666659952333239 0.7230181604860801" bfcmt="0.0 0.0 0.0" />
<atom coord="0.6666658947282684 0.3333355642013190 0.2230181376394524" bfcmt="0.0 0.0 0.0" />
<atom coord="-0.0000014047858665 -0.0000014989204292 0.8598346356745361" bfcmt="0.0 0.0 0.0" />
<atom coord="-0.0000010637550153 -0.0000023665415520 0.3598347357323680" bfcmt="0.0 0.0 0.0" />
</species>
<species speciesfile="Ge3.xml" rmt="1.9000" >
<atom coord="0.3333342808495061 0.6666677546212642 0.5752607854771313" bfcmt="0.0 0.0 0.0" />
<atom coord="0.6666676137995474 0.3333344202546681 0.0752607858377154" bfcmt="0.0 0.0 0.0" />
<atom coord="0.0000000779075186 0.0000000503072549 0.0071969085129899" bfcmt="0.0 0.0 0.0" />
<atom coord="0.0000000699936951 0.0000000808441511 0.5071959006397191" bfcmt="0.0 0.0 0.0" />
</species>
</structure>
<groundstate do="skip" ngridk="32 32 1" nempty="30" rgkmax="4" gmaxvr="20"/>
<xs xstype="BSE"
ngridq="4 4 1"
ngridk="4 4 1" vkloff="0.05 0.15 0.25"
nempty="30"
lmaxapwwf="3"
gqmax="2.0"
broad="0.0073499"
scissor="0.0101"
tevout="true" nosym="true">
<energywindow intv="0.0 1.0"
points="1200" />
<screening screentype="full"
nempty="215" />
<BSE bsetype="singlet"
nstlbsemat="1 30 1 30"
nstlbse="1 30 1 30"
aresbse="false"/>
<qpointset>
<qpoint>0.0 0.0 0.0</qpoint>
</qpointset>
</xs>
</input>
Thanks,
NikA
In this input, Ge3.xml and H3.xml are new species files with values swapped for those from exciting lithium, but swapping these values does not significantly change the output. I don't know if this information is helpful or not.
-NikA
Dear NikA,
the differences between BSE spectra calculated with exciting lithium and exciting boron-10 are to be ascribed to different default values for some parameters in the BSE part of the input file. Specifically,these parameters are sciavbd, sciavqbd, and sciavqhd, which were false by default in exciting lithium and are true in exciting boron-10. As documented in the Input Reference, these parameters affect the integration of the screened Coulomb interaction in the vicinity of q=0.
Best regards,
Caterina Cocchi
(exciting team)
Thank you so much for your reply! I have another (I anticipate related) issue with BSE calculations. When running exciting boron-10, my calculation gets to task 430 (mapping screening-specific parameters) and is able to complete this stage of the calculation for some but not all of the k-points, as evidenced by the output files for specific points in this version. However, the calculation seems to be unable to complete all the k-points for certain structures, and hangs until the allotted computation time is elapsed. I do not see this issue with exciting lithium. Is there a possibility this is related to the change in default parameters for BSE in exciting boron-10?
Thanks,
NikA
Sorry, I am looking at this again and it hangs in task 440 (mapping BSE-specific parameters). It will write approximately 1/3 to 1/2 of the GQPOINTS_QXXXXX.OUT and SCREEN_QXXXXX.OUT files before stopping.
-NikA
Dear NikA,
could you please post the input file that gives you problems, together with all the relevant information of the submission file (number of processors, number of nodes, etc.)?
Best regards,
Caterina Cocchi
(exciting team)
This is my input for the calculation that is crashing. The last files written in these calculations are the DIELTENS0_SCR.OUT and DIELTENS0_NOSYM_SCR.OUT (for exciting boron-10). The calculation crashes at the same point in the INFOXS.OUT file for both the lithium and boron-10 compilations, but I think the order in which the output files are written differs for these two versions.
<input>
<title>BSE for Ge-H bulk</title>
<structure speciespath="/nfs/11/osu5259/EXCITING/exciting/species/">
<crystal scale="1.0">
<basevect>7.522550 0.0 0.0</basevect>
<basevect>-3.761275 6.514719 0.0</basevect>
<basevect>0.0 0.0 41.8</basevect>
</crystal>
<species speciesfile="H.xml" rmt="1.0000" >
<atom coord="0.0000000000000000 0.0000000000000000 0.436741" bfcmt="0.0 0.0 0.0" />
<atom coord="0.3333333333333333 0.6666666666666667 0.612543" bfcmt="0.0 0.0 0.0" />
</species>
<species speciesfile="Ge.xml" rmt="1.9000" >
<atom coord="0.0000000000000000 0.0000000000000000 0.507203" bfcmt="0.0 0.0 0.0" />
<atom coord="0.3333333333333333 0.6666666666666667 0.542070" bfcmt="0.0 0.0 0.0" />
</species>
</structure>
<groundstate do="skip" ngridk="32 32 1" nempty="30" rgkmax="4" gmaxvr="20"/>
<xs xstype="BSE"
ngridq="4 4 1"
ngridk="4 4 1" vkloff="0.05 0.15 0.25"
nempty="30"
lmaxapwwf="3"
gqmax="2.0"
broad="0.0073499"
scissor="0.0101"
tevout="true"
nosym="true">
<energywindow intv="0.0 1.0"
points="1200" />
<screening screentype="full"
nempty="215" />
<BSE bsetype="singlet"
nstlbsemat="1 30 1 30"
nstlbse="1 30 1 30"
aresbse="false"
sciavbd="false"/>
<qpointset>
<qpoint>0.0 0.0 0.0</qpoint>
</qpointset>
</xs>
</input>
Thank you for your help,
NikA
Forgot submission details: the machine I work on have 20ppn, and given my q-mesh I have 10 q-points. I have tried 10 nodes with one process per node at various levels of threading (20,16,10) and 5 nodes with 2 processes per node (10 threads). The calculation freezes at the same place in both cases.
-NikA
Dear NikA,
is the job crashing for both exciting lithium and exciting boron-10? At which spot exactly is the calculation freezing in either case?
Best regards,
Caterina Cocchi
(exciting team)
The job crashes with boron-10 and produces NaN results for lithium.
For boron-10, the last task output in INFOXS.OUT is:
| EXCITING BORON-10 started for task 430 =
| MPI version using 10 processor(s) =
| Date (DD-MM-YYYY) : 19-03-2016 =
Info(xsinit): mapping screening-specific parameters
Info(findocclims): system has Kohn-Sham gap
Info(dfq): Gamma q - point: using momentum matrix elements for dielectric function
Info(dfq): number of G + q vectors (local field effects): 297
Info(dfq): lowest (partially) unoccupied state: 16
Info(dfq): highest (partially) occupied state : 15
Info(dfq): band-combination limits nst1, nst2, nst3, nst4: 15 216 216 15
Info(dfq): band-combination limits istl1, istu1, istl2, istu2: 1 15 16 231
Info(dfq): band-combination limits istl3, istu3, istl4, istu4: 16 231 1 15
Info(dfq): number of G + q vectors: 297
Info(df): Kohn Sham response function finished for q - point: 1
As previously noted, the output files stop writing after the DIELTENS0*.OUT are written.
For lithium, the tasks complete, but the EXCITON_SORTED*.OUT files are full of zeros and NaN values.
Thanks,
NikA
Dear NikA,
could you please check in your calculation whether you have partially occupied states? You can notice it by looking at the files EIGVAL_QMTXXX.
Another question: How much memory do your nodes have?
Best regards,
Caterina Cocchi
(exciting team)
No partially occupied states in the EIGVAL_*.OUT files. Nodes have 64 Gb memory but I can tell that unless the program is "protecting" the nodes by stopping before having an OOM problem, the issue is elsewhere: dynamic memory usage is monitored and is low when the code gets stuck.
Thanks,
NikA
Dear NikA,
I could successfully run your input file with exciting boron-10 using 10 processors distributed over 2 nodes.
As a general suggestion, when dealing with low-dimensional systems, it is advisable to converge the amount of vacuum in the non-periodic direction(s) starting from smaller amounts compared to the one shown in you input. On the other hand, a finer k-point mesh is definitely necessary to obtain reliable results.
Best regards,
Caterina Cocchi
(exciting team)
Thank you for your help! I was aware of the k-point convergence issue but wanted to successfully execute the code before getting too involved in using computer time. I will take your advice and investigate the vacuum convergence (this structure input was converged in another DFT code).
Thanks,
NikA