这里会显示出您选择的修订版和当前版本之间的差别。
两侧同时换到之前的修订记录前一修订版后一修订版 | 前一修订版后一修订版两侧同时换到之后的修订记录 | ||
atk:解决quantumatk运行性能和内存消耗问题 [2020/02/29 17:26] – [特定于器件构型] xie.congwei | atk:解决quantumatk运行性能和内存消耗问题 [2023/06/04 09:36] – [想要运行更快?] fermi | ||
---|---|---|---|
行 1: | 行 1: | ||
====== 解决QuantumATK运行性能和内存消耗问题 ====== | ====== 解决QuantumATK运行性能和内存消耗问题 ====== | ||
- | 在本教程中,您将学习用于提高各种系统 **ATK** 性能而需要调整的主要参数。为了获得尽可能高的计算性能,**ATK** 提供了一系列不同的算法,并利用 MPI 和共享内存线程进行并行。正如技术说明 [[https:// | + | ===== 问题概述 ===== |
- | 要获得任何高性能软件的绝对最佳性能,需要对所涉及的计算和使用的硬件有一定的深入了解。因此,对于使用的硬件和并行方法,优化您的 QuantumATK 模拟非常重要。然而,下面章节给出了一些关于 QuantumATK 算法和选项的提示,也可能有助于解决内存或速度问题。 | + | 衡量 QuantumATK 计算运行性能的指标是正确运行计算得到结果的时间长短。计算性能的限制因素主要来自于: |
- | ===== 内存不足? | + | * CPU主频、并行、缓存。这是直接决定计算速度的因素; |
+ | * 内存大小。计算中,特别是DFT计算中有许多大型的中间数据,这些数据在内存中保存可以大大提高计算速度,但是会造成内存过度占用甚至溢出; | ||
+ | * 操作系统与作业队列系统对计算资源的调度。 | ||
+ | * 程序本身的代码和编译质量。由于 QuantumATK 提供给用户的预编译好的二进制代码,因此程序本身的问题只能等待开发组在未来版本中解决。 | ||
+ | |||
+ | 一般情况下,我们总是优先选择将中间结果保存在内存中,这也是计算设置的默认选项。在发生问题时,存在两种情况,一种是 QuantumATK 给出内存溢出错误: | ||
+ | |||
+ | |||
+ | 对于明确的内存溢出错误信息,可以考虑: | ||
+ | * 增加硬件内存; | ||
+ | * 更改控制参数,不保存中间数据,以节约内存,使计算得以完成。 | ||
+ | |||
+ | |||
+ | 另一种是 QuantumATK 未给出错误,但发生异常终止,log文件没有错误信息或者有如下类似的错误信息: | ||
+ | |||
+ | |||
+ | |||
+ | 此时,意外终止的原因并不清楚,可能的原因包括: | ||
+ | * 内存读写错误,可能是计算节点大量的内存泄漏(解决:重启节点) | ||
+ | * MPI与硬件存在不兼容(解决:自行安装测试使用其他版本的 Intel MPI 或 MPICH) | ||
+ | * 内存不足(解决:参考下文降低内存需求) | ||
+ | |||
+ | |||
+ | ===== 软件层面影响计算速度和内存占用的主要因素 ===== | ||
+ | |||
+ | ==== 算法与模型 ==== | ||
+ | |||
+ | 不同的算法、不同的模型、不同的分析等计算性能相差很大: | ||
+ | * 普通列表项目有些计算是单纯的 DFT 自洽,可以通过简单的Calculator参数控制计算的性能; | ||
+ | * 有些计算包含多个 DFT 自洽过程,例如声子动力学矩阵、IVCharacteristics曲线等,此时要综合考虑并行的效果; | ||
+ | * 有些计算还会改变DFT自洽计算的实际模型,例如声子动力学矩阵在实际计算时,采用的是对超胞进行自洽的方法。 | ||
+ | |||
+ | ==== 并行计算 ==== | ||
+ | |||
+ | 要获得任何高性能软件的最佳性能,需要对所涉及的计算和使用的硬件有一定的深入了解。因此,对于使用的硬件和并行方法,优化您的 QuantumATK 模拟非常重要。然而,下面章节给出了一些关于 QuantumATK 算法和选项的提示,也可能有助于解决内存或速度问题。 | ||
+ | |||
+ | |||
+ | ===== 减少内存消耗 | ||
行 10: | 行 47: | ||
* 尝试禁用 **AlgorithmParameters** 中的 **store_grids**,这将稍稍降低内存,轻微减少计算时间。 | * 尝试禁用 **AlgorithmParameters** 中的 **store_grids**,这将稍稍降低内存,轻微减少计算时间。 | ||
+ | |||
* 在 **AlgorithmParameters** 中禁用 **store_basis_on_grid** 将显著减少内存,如果系统的矩阵很小,则会对性能产生负面影响。默认情况下此参数处于关闭状态,如果构型很大,它可能已被禁用。如果是 **并行** 运行,由于内存是分布式的,每个核的内存减少量将更低。 | * 在 **AlgorithmParameters** 中禁用 **store_basis_on_grid** 将显著减少内存,如果系统的矩阵很小,则会对性能产生负面影响。默认情况下此参数处于关闭状态,如果构型很大,它可能已被禁用。如果是 **并行** 运行,由于内存是分布式的,每个核的内存减少量将更低。 | ||
* 如果在 **并行** 有两个以上进程运行,请尝试将 **IterationControlParameters** 中的 **algorithm** 设置为 **ParallelPulayMixer.d**。 | * 如果在 **并行** 有两个以上进程运行,请尝试将 **IterationControlParameters** 中的 **algorithm** 设置为 **ParallelPulayMixer.d**。 | ||
- | ==== 特定于分子和块体构型 ==== | + | ==== 对于分子和块体构型 ==== |
* 如果矩阵非常大,可以考虑将 **AlgorithmParameters** 中的 **density_matrix_method** 设置为 **DiagonalizationSolver(processes_per_kpoint=2)**。这将使每个 mpi 进程的内存使用减少 2 倍。如果问题持续存在,请尝试增大 **processes_per_kpoint**。 | * 如果矩阵非常大,可以考虑将 **AlgorithmParameters** 中的 **density_matrix_method** 设置为 **DiagonalizationSolver(processes_per_kpoint=2)**。这将使每个 mpi 进程的内存使用减少 2 倍。如果问题持续存在,请尝试增大 **processes_per_kpoint**。 | ||
+ | |||
* 如果计算量非常大,且计算是在 **并行** 中的许多节点上运行,那么将 **AlgorithmParameters** 的 **density_matrix_method** 设置为 **ChebyshevExpansionSolver** 是很值得尝试的做法。当大规模并行运行时,内存使用将显著减少,但与普通情况相比还是很慢。 | * 如果计算量非常大,且计算是在 **并行** 中的许多节点上运行,那么将 **AlgorithmParameters** 的 **density_matrix_method** 设置为 **ChebyshevExpansionSolver** 是很值得尝试的做法。当大规模并行运行时,内存使用将显著减少,但与普通情况相比还是很慢。 | ||
- | ==== 特定于器件构型 ==== | + | ==== 对于器件构型 ==== |
* 尝试将 **SelfEnergyCalculator** 中的 **storage_strategy** 设置为 **StoreOnDisk** 或 **NoStorage**。这将显着减少内存,但也会降低之后的性能。如果是 **并行** 运行,由于内存是分布式的,每个核的内存减少量将更低。 | * 尝试将 **SelfEnergyCalculator** 中的 **storage_strategy** 设置为 **StoreOnDisk** 或 **NoStorage**。这将显着减少内存,但也会降低之后的性能。如果是 **并行** 运行,由于内存是分布式的,每个核的内存减少量将更低。 | ||
+ | |||
* 器件的横截面较宽,可以尝试将 **equilibrium_method** 和/或 **non_equilibrium_method** 设置为 **SparseGreensFunction**。 | * 器件的横截面较宽,可以尝试将 **equilibrium_method** 和/或 **non_equilibrium_method** 设置为 **SparseGreensFunction**。 | ||
+ | |||
* 如果是 **并行** 运行,将 **equilibrium_method** 和/ | * 如果是 **并行** 运行,将 **equilibrium_method** 和/ | ||
- | ===== 想要运行更快? | + | ===== 提升运行速度 |
==== 一般情况 ==== | ==== 一般情况 ==== | ||
- | 如果计算需要使用多重网格方法,如存在栅的情况,可能对于 **possion_solver** 要考虑 **DirectSolver**。这样将需要更多的内存,但是开销是内存分配的,因此如果是 **并行** 运行,则值得尝试。 | + | * 如果计算需要使用多重网格方法,如存在栅的情况,可能对于 **possion_solver** 要考虑 **DirectSolver**。这样将需要更多的内存,但是开销是内存分配的,因此如果是 **并行** 运行,则值得尝试。 |
- | 设置 **AlgorithmParameters** 中的 **store_basis_on_grid** 为 **True**。这将使计算运行更快,并具有适度但分布式的内存开销。 | + | * 设置 **AlgorithmParameters** 中的 **store_basis_on_grid** 为 **True**。这将使计算运行更快,并具有适度但分布式的内存开销。 |
- | ==== 特定于分子和块体构型 ==== | + | ==== 对于分子和块体构型 ==== |
在 **ATK 2015** 中为 **AlgorithmParameters** 中的 **density_matrix_method** 引入了两个新增参数:**processes_per_kpoint** 和 **bands_above_fermi_level**。 | 在 **ATK 2015** 中为 **AlgorithmParameters** 中的 **density_matrix_method** 引入了两个新增参数:**processes_per_kpoint** 和 **bands_above_fermi_level**。 | ||
行 72: | 行 113: | ||
</ | </ | ||
- | ==== 特定于器件构型 ==== | + | ==== 对于器件构型 ==== |
- | 实际上,您可以调整许多参数获得器件构型的最佳性能。哪些参数需要调整呢?这其实上取决于您正在研究的系统和所使用的方法。 | + | 实际上,您可以调整许多参数获得器件构型的最佳性能,有些取决于您正在研究的体系和所使用的方法。 |
===== 参考 ===== | ===== 参考 ===== | ||
* 英文原文:https:// | * 英文原文:https:// |