SSCHA
Unable to use more conformations #339
-
|
hello, SSCHA Developers. I have recently been utilizing SSCHA to conduct an NVT simulation on a structure of interest, the pressure is ambient. Under the harmonic approximation, the structure exhibits dynamical stability as there are no imaginary frequencies. However, upon introducing anharmonic corrections, the simulation terminates prematurely during the initial phase. A file named "error_struct.scf" is generated in the directory. Here is the error message:
After adjusting the parameter N_CONFIGS from 800 to 80, the SSCHA calculations were able to run smoothly and eventually outputted the dynamical matrix. Therefore, I am wondering why using a larger N_CONFIGS value leads to the program not functioning properly. I would appreciate any suggestions on how I can improve this issue. Zhongyu |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
|
Hi, the quantum espresso calculation was failing. After 5 failed attempts, the code stopped. The code should also have created the input/output of the failing espresso calculation; you can check it there to better understand the problem. However,if you run again, it has been overwritten. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, mesonepigreco Thank you very much for your response. In the SCF calculation for a single conformation, the QE output file indicates: "Estimated max dynamical RAM per process > 115.67 MB, Estimated total dynamical RAM > 1.81 GB." Given the capabilities of my current machine, it can handle 128 cores and 450GB of RAM. However, the introduction of more conformations seems to exceed the computational limits of the machine. Nevertheless, using more conformations appears necessary as a small number of conformations does not seem to allow the FC gradient to approach zero. Are there any alternative solutions besides upgrading the computational equipment? For instance, could we perform the SCF calculation using only one k-point or utilize a smaller unit cell? Another point of confusion for me is that in some works utilizing SSCHA, such as in Journal of Applied Physics 130.17 (2021) and Physical Review B 103.13 (2021): 134305, it seems they did not test for size effects by using larger unit cells. I understand that larger unit cells can lead to significantly longer computation times. However, is the information provided solely in Fig. 2 of Tutorial-1 sufficient to judge the convergence of the calculations? Is it necessary to check for size effects by varying the size of the unit cell? Especially when considering the inability to perform calculations with larger supercell sizes. Zhongyu |
Beta Was this translation helpful? Give feedback.
-
|
Hi,
Regarding 1, I believe the problem is more related to the fact that you are probably submitting all the calculations in one single node. If you are on a cluster, the best approach should be using the Cluster module, as shown in the second tutorial on the website. This would avoid memory conflicts between different calculations and allow you to exploit the cluster architecture much better. If it is not a cluster, try again with the big number of random configurations and look at the failing QE calculation why it is crashing. It should not. Regarding 2: Yes, you have to converge with the supercell size. Nowadays, this is becoming easier and easier thanks to the availability of machine-learning force fields (tutorial 6). So the solution usually is to study the SCHA on a small cell, then use the data generated during the sscha simulation to train an ML potential (tutorial 6), then run the SSCHA on a bigger cell until converges. |
Beta Was this translation helpful? Give feedback.
-
|
It seems that it's just because some of the supercell calculations failed in Quantum Espresso. |
Beta Was this translation helpful? Give feedback.
-
|
hello, Yue wen Thank you for your advice. As mesonepigreco speculated, it seems that 800 configurations were occupying the memory simultaneously, but I'm curious about the reason behind this occurrence. Although I have resolved the issue using the cluster module, I still want to provide you with a reference. Theoretically, running the Python script from Tutorial-1 in parallel on the machine should not have led to such an issue. The command to invoke QE is command = 'mpirun -np 32 pw.x -i PREFIX.pwi > PREFIX.pwo' within the SSCHA script. And in the script for submitting jobs, I used mpirun -np 4 python sscha-anhamonic.py. This indicates that 128 cores are being utilized simultaneously, with 4 pw.x calculations running, each calling 32 cores. Zhongyu |
Beta Was this translation helpful? Give feedback.
-
|
This could not be optimal, as clusters can map processes into real cores to avoid multiple processes running on the same cores. This binding is usually done by running |
Beta Was this translation helpful? Give feedback.
Hi,
So here there are two distinct problems:
Regarding 1, I believe the problem is more related to the fact that you are probably submitting all the calculations in one single node. If you are on a cluster, the best approach should be using the Cluster module, as shown in the second tutorial on the website. This would avoid memory conflicts between different calculations and allow you to exploit …