So I am super new, although I have gotten the hang of using DFT in Quantum Espresso. I am having a problem with running the calculation for 1.6 nm ZnSe quantum dot. I haven't even gotten to calculating bands and optical properties, my laptop did six iterations, and then windows crashed for geometrical optimization. So how do I know how much power is required and how much I have.
Plus, any suggestions for how I can do DFT calculations using my computer because the professor I am working with does not have access to a cluster(which he had, but he doesn't anymore due to some university politics).
So the best configuration I have is a gaming laptop(predator) Thankss
$\begingroup$
$\endgroup$
1
asked Jun 5, 2021 at 9:42
-
4$\begingroup$ +1 I can't directly answer the question, but I think you can get a sense of the CPU power required by running much smaller calculations with smaller basis sets (like try methane with B3LYP/6-31+G*). Additionally some codes output the time required for every SCF or optimization iteration and that will also be helpful. If your program crashed that might also be a sign of memory shortage (apart from processor overheating) $\endgroup$– S R MaitiCommented Jun 5, 2021 at 9:53
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
2
Computational power is a relatively vague term, and can include at least three dimensions: computational time, memory consumption, and disk usage. Under this definition, it's trivial to find out how much computational power you have. The following discusses how to find out how much computational power you need.
- Computational time
The computational time of a method usually scales as a certain power of the system size (measured in the number of atoms, or better, the number of basis functions, $N$). For plane wave-based DFT single-point calculations, the computational time scales as roughly $N^3$. For atomic orbital-based DFT single-point calculations using pure functionals, the time scales as about $N^3$ for systems within a few tens of atoms, $N^2$ for systems with a few tens to a few hundreds of atoms or so, and $N^3$ for systems with thousands of atoms. For hybrid functionals, the scaling for small systems increases to $N^4$, while the remaining conclusions are unchanged. For programs that explicitly use linear-scaling techniques, the time scales as $N$ to $N \log N$ for systems with at least thousands of atoms. Note that these are quite general statements and may only approximately hold for a given software.
The above properties can be used to estimate the run time of a given DFT calculation. To do this, you perform a calculation with a small system that is sufficiently similar to the actual system you intend to study, and use the same computational settings. The system must be small enough so that you can finish the computation without much cost, yet large enough (close enough to the size of the actual system) so that the scaling exponent can still be considered as a constant. Then you extrapolate your timing to your actual system size to estimate your expected computational time.
Some caveats:
(1) When your calculation involves iterations, the number of iterations required to reach convergence usually increases with system size, often linearly. For example, we have recently shown (https://arxiv.org/abs/2105.00205) that at least for some systems, the number of SCF iterations increases linearly with system size, so while a single SCF iteration scales as $N^3$, the total SCF time may scale as $N^{3.5}$ (it's not $N^4$ because the linear scaling of SCF iteration number has a non-zero intercept). With geometry optimization the number of iterations similarly scales approximately linearly with system size, at least for some systems (see, e.g., https://aip.scitation.org/doi/10.1063/1.4952956). So, for geometry optimizations please be prepared for a $N^4$-ish dependence.
(2) The computational time also scales as the -1st power with the number of CPU cores, until the number of cores approaches a certain number when the computational time is hardly dependent on the number of cores (https://en.wikipedia.org/wiki/Amdahl%27s_law). The threshold number of the number of cores varies greatly from program to program, ranging from a few tens of cores to millions.
(3) If your computation eats up all of your physical memory, and you instead rely on virtual memory, the scaling will skyrocket at that point, since virtual memory is much slower than physical memory. Beyond that point, the above estimation method fails.
- Memory and disk
Memory and disk usage also scale polynomially with respect to system size, at least for DFT calculations. In DFT calculations, both memory and disk usage scale quadratically with system size. You can then use exactly the same method to estimate how much memory and disk your actual calculation will use.
Besides, since you are able to run your calculation till the point it crashes, it may be beneficial to analyze why it crashed, by analyzing the output file, monitoring CPU, memory and disk usage, etc.
-
$\begingroup$ "When your calculation involves iterations, the number of iterations required to reach convergence usually increases with system size, often linearly." The linear dependence is fascinating, and not often discussed. I wonder how this changes depending on optimization algorithm used. $\endgroup$ Commented Jun 10, 2021 at 18:12
-
1$\begingroup$ @MattHorton This does change to some extent with the optimization algorithm. For example, in my arXiv paper that I mentioned, we developed a method (iOI) that solves the SCF problem in small domains of the molecule, then gradually merge and enlarge the domains; each time we merge and enlarge them, the converged orbitals of the previous set of domains are used as initial guesses. By this way we can reduce the number of iterations to almost constant. Exactly in what cases are the number of iterations linear, and in what cases constant, is an interesting question that we will look deeper into. $\endgroup$– wzkchem5Commented Jun 11, 2021 at 6:30