怪事：Gaussian运行时CPU占不满

Accelerator

近日发现很多Gaussian任务运行起来出奇的慢，查看了一下机器的CPU占用情况，发现是很多情况下Gaussian虽然在gjf文件里指定了并行，但实际上占用的CPU资源远少于通过nprocshared指定的。
类型1
输入文件示例：

1. %nprocshared=8
   
2. %mem=12GB
   
3. # opt gen mn15l scf=xqc
   
4. 
   
5. opt
   
6. 
   
7. -1 8
   
8. Fe                 0.54628098   -0.49170929   -1.64724167
   
9. Fe                 0.20361797    1.61684662    0.96045771
   
10. S                 -1.04332306   -1.05480271    0.85744828
    
11. S                  1.14778115   -1.54791527    1.21906735
    
12. S                 -0.85435704    1.47758065   -1.38973167
    
13. 
    
14. @ma-TZVP.txt
    

复制代码

在一台用了很久的6139*2（128 GB内存）的机子上运行（此前没有发现过类似现象），使用G16，大多数时间l502.exe实际占用的CPU核心数只有4-5核，甚至还有只使用1核的时候。看到这里可能会觉得是否是由于原子数太少；确实这个机子上目前运行的任务都比较小，这段时间机器又非常满，暂时没有做过更大体系的测试。

类型2
在另一台2696v3（单路，32 GB内存，使用G09）的机子上，则更为诡异：这个时候，不论体系有多大（从几个原子到~100原子的DFT单点任务），只要%mem指定的内存数大于10 GB，不论nprocshared指定使用多少核心，l502.exe就会在大多数时间只占用1核，与此同时，即使只是单点，也会占用~10 GB的内存；而当%mem设置为10 GB以下时就没有任何异常了，指定使用18核，用top一看肯定是1800%占得满满的。

这一现象属实诡异，不知大家是否有遇到过。

sobereva

scf=noincore大概率能解决
内存给得较大的时候，自动用incore方式处理电子积分，此时并行效率很低，甚至还不如direct方式快

Accelerator

sobereva 发表于 2020-12-7 17:21
scf=noincore大概率能解决
内存给得较大的时候，自动用incore方式处理电子积分，此时并行效率很低，甚至还 ...

确实如此，学到了。
不过incore方式什么时候会导致该现象的规律十分成谜，不写scf=incore时完全相同的输入文件在一台机子上就只能实际占用1核，放到另一台机子上则能差不多满核运行，不知道是机器的什么因素产生了影响。

sobereva

Accelerator 发表于 2020-12-15 17:50
确实如此，学到了。
不过incore方式什么时候会导致该现象的规律十分成谜，不写scf=incore时完全相同的输 ...

原理上，如果关键词相同，用什么方式处理积分和给的内存量、并行线程数有关。不同版本的规则也可能有所不同。对于大内存机子算不是很大体系的情况，可以总写上scf=noincore或者在default.rou里加上以求保险。

TaylorWu

我也遇到过类似问题，貌似是体系原子数比较少的时候会出现，在输出文件里面可以看到它在计算的中间会说只调用xx个核心，推测是默认的方法对于小计算体系不能调用太多核心。

abin

班级有三十人
班主任拿来五箱苹果
说两个同学负责洗一箱苹果
当然会有部分同学坐着啥也不干了