ORCA计算freq 并行问题和续算问题

是aweia

我最近在计算freq
计算用到的输入如下：
! B3LYP 6-31G  freq
%maxcore 10000
%pal
   nprocs 64
end
%tddft
nroots 5
IROOT 1
end
* xyz 0 1

...
在计算Calculating on displaced geometry时并行计算出现问题
发现问题时计算已经进行了五天左右，我发现计算的速度慢了下来，于是我ssh到对应的计算节点使用top命令查看计算情况
计算共用到两个节点各32核心，
其中一个节点的top显示已经没有ORCA的任务在计算，

   PID      USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND      
17576     root      20   0 3232784  49776  14444 S   6.2  0.0 366:40.09 containerd   
33046     root      20   0       0      0      0 S   6.2  0.0   1594:08 krdma_evthd/0
104873   gc09  20   0  160936   2780   1456 R   6.2  0.0   0:00.03 top          
     1       root      20   0   54320   6404   2536 S   0.0  0.0  30:54.70 systemd      
     2       root      20   0       0      0      0 S   0.0  0.0   0:04.34 kthreadd     
     3       root      20   0       0      0      0 S   0.0  0.0   2:39.03 ksoftirqd/0  
     5       root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H
另一个节点只有一个orca_cis在计算
55632    gc09  20   0 1004676 427644   9868 R 100.0  0.2  18:10.51 orca_cis     
68401     gc09  20   0  162680   2520   1456 R    6.2    0.0    0:00.03 top         
     1 root      20   0   54160   5900   2120 S   0.0  0.0  32:43.48 systemd      
     2 root      20   0       0      0      0 S   0.0  0.0   0:05.50 kthreadd     
     3 root      20   0       0      0      0 S   0.0  0.0   3:11.20 ksoftirqd/0  
     5 root       0 -20       0      0      0 S   0.0  0.0   0:00.09 kworker/0:0H


作为比较，我所有输入输出复制到新目录下重新提交，在计算Calculating on displaced geometry时查看计算节点的状态如下：其中共25个orca任务在进行（但是一共有32个核心）
  5806 gc09  20   0 1004824 419700   1596 R 100.0  0.2  20:49.31 orca_cis      
  5813 gc09  20   0 1004872 419316   1704 R 100.0  0.2  20:49.44 orca_cis      
  9530 gc09  20   0 1004856 423004   1576 R 100.0  0.2  15:31.23 orca_cis      
  9605 gc09  20   0 1004856 419728   1716 R 100.0  0.2  15:17.06 orca_cis      
13383 gc09  20   0 1428864 847104   1452 R 100.0  0.3   9:28.46 orca_cis      
16118 gc09  20   0 1428904 847536   1772 R 100.0  0.3   5:35.91 orca_cis      
16212 gc09  20   0 1428912 844056   2084 R 100.0  0.3   5:24.96 orca_cis      
16282 gc09  20   0 1428940 844628   2468 R 100.0  0.3   5:06.13 orca_cis      
16687 gc09  20   0 1428936 847768   2636 R 100.0  0.3   4:43.07 orca_cis      
16906 gc09  20   0 1428944 847472   3196 R 100.0  0.3   3:55.54 orca_cis      
17875 gc09  20   0 1428940 845164   3620 R 100.0  0.3   3:29.25 orca_cis      
  5818 gc09  20   0 1004844 419180   1716 R  94.1  0.2  20:46.84 orca_cis      
  9155 gc09  20   0 1004848 423204   1576 R  94.1  0.2  15:41.00 orca_cis      
  9388 gc09  20   0 1004872 422660   1596 R  94.1  0.2  15:38.90 orca_cis      
12992 gc09  20   0 1428932 847220   1508 R  94.1  0.3   9:49.19 orca_cis      
13016 gc09  20   0 1428916 843012   1304 R  94.1  0.3   9:46.43 orca_cis      
16077 gc09  20   0 1428924 844128   1864 R  94.1  0.3   5:41.70 orca_cis      
16116 gc09  20   0 1428944 847224   1680 R  94.1  0.3   5:35.83 orca_cis      
16162 gc09  20   0 1428920 844212   1980 R  94.1  0.3   5:30.26 orca_cis      
16170 gc09  20   0 1428912 846492   2080 R  94.1  0.3   5:29.72 orca_cis      
16283 gc09  20   0 1428952 844208   2476 R  94.1  0.3   5:05.92 orca_cis      
16453 gc09  20   0 1428924 847484   2528 R  94.1  0.3   4:52.64 orca_cis      
16697 gc09  20   0 1428920 844700   2632 R  94.1  0.3   4:41.73 orca_cis      
16817 gc09  20   0 1428916 844812   2904 R  94.1  0.3   4:15.73 orca_cis      
17472 gc09  20   0 1428852 845056   3284 R  94.1  0.3   3:51.46 orca_cis       
20672 zdwlgc09  20   0  162812   2780   1456 R  11.8  0.0   0:00.04 top            
33373 root      20   0       0      0      0 S   5.9  0.0   2:09.18 fence_topo_relo
     1 root      20   0   54048   6224   2536 S   0.0  0.0  24:31.18 systemd        

我想了解一下出现这个情况的原因是什么  是否是我的作业提交方式或输入文件有问题,或者是这个服务器的问题？


我现在把所有输入输出复制到新目录下并在.inp中加入
%freq
Restart true
end
重新提交计算 这样是正确的续算方式么

zjxitcc

老铁，6-31G做实际计算没啥用啊，算freq就更不用考虑了。看Sob老师博文《谈谈量子化学中基组的选择》http://sobereva.com/336

是aweia

zjxitcc 发表于 2022-2-23 11:15
老铁，6-31G做实际计算没啥用啊，算freq就更不用考虑了。看Sob老师博文《谈谈量子化学中基组的选择》http:/ ...

您好 我有读过sob老师的这个文章 在很多地方也见过老师有类似的说法 但是我导喜欢用这个 我无法反驳

zjxitcc

是aweia 发表于 2022-2-23 12:13
您好 我有读过sob老师的这个文章 在很多地方也见过老师有类似的说法 但是我导喜欢用这个 我无法反驳:shut ...

做实际应用型计算，不能用这基组。万一碰到计算类别审稿人，大概率拒稿；即使不拒稿，以后也容易被人拿出来当反例教材。不值当。

abin

看描述，用到了两个节点。
那么问题是，
这套集群或者平台，
采用什么I/O设备？
采用什么网络设备？

盲目使用太多核心，和采用128核心，跑g09一样糟糕。

ORCA做计算, I/O需求很高的.
我也跑ORCA/TD/freq计算, 某一个节点, 2周内, 读写高达36.5 TiB.
这套机器就我在用, 所以还凑合了.

如果你的机器是公用的, I/O或者网络不行, 那么很多时候, 程序都是在等待I/O, 出现你描述的情形, 是很“正常”的.

是aweia

zjxitcc 发表于 2022-2-23 13:10
做实际应用型计算，不能用这基组。万一碰到计算类别审稿人，大概率拒稿；即使不拒稿，以后也容易被人拿出 ...

嗯嗯 好的 我也怕到时候出现这样的问题   我和老师请教一下吧 看他怎么说 谢谢您的建议

wzkchem5

是aweia 发表于 2022-2-23 05:13
您好 我有读过sob老师的这个文章 在很多地方也见过老师有类似的说法 但是我导喜欢用这个 我无法反驳:shut ...

你有没有和你导师确认过，你导师要用的就是6-31G本身，而不是6-31G*、6-31G**？
有的人口头上喜欢用6-31G泛指所有6-31G系列的基组，比如6-31G*，6-31+G*等等，就好比很多人喜欢把CCSD(T)叫做CCSDT而不把括号说出来一样。这种情况下你按你导师字面意思理解就理解错了。

是aweia

wzkchem5 发表于 2022-2-23 16:29
你有没有和你导师确认过，你导师要用的就是6-31G本身，而不是6-31G*、6-31G**？
有的人口头上喜欢用6-31 ...

对 有可能是我的理解有问题

是aweia

abin 发表于 2022-2-23 13:32
看描述，用到了两个节点。
那么问题是，
这套集群或者平台，

嗯嗯 好的 谢谢您的帮助  我下午去了解了一下 也没搞清楚这个的I/O和网络是什么设备  不过很可能是您说的情况 非常感谢