富岳のセットアップ

• 自作ものは-SSL2であっさりcompileに成功した。
• submit用のpython scriptを作成した。
• src/fujitsuとsrc/intel以下に、それぞれLAMMPS, QE, VASP, 他toolsをcompile
• LAMMPSとQEは、富岳ポータルサイトに従ってcompileした。
• VASPはmake.includeを作成し、spack管理下のfujitsu謹製libfftw3.aを full pathで与えてリンクした。なぜか、最終ステップでlibparser.aのリン クに失敗したので、build/std/parserにて手動でmakeを叩いて libparser.aを作り直した。
• 90原子のglass構造にてVASPとQEで計算を行い、他の計算機と実行速度を比較した。

• 有賀君から、LAMMPSの実行中に異常終了する現象が確認された。

[c26-0113c:00013] *** Process received signal ***
[c26-0113c:00013] Signal: Bus error (7)
[c26-0113c:00013] Signal code: Non-existant physical address (2)
[c26-0113c:00013] Failing at address: 0x40002f927d84
[c26-0113c:00013] [ 0] linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x40000006066c]
[c26-0113c:00013] [ 1] /opt/FJSVxtclanga/tcsds-1.2.29/lib64/libmpi.so.0(+0x37e4f8)[0x40000047e4f8]
[c26-0113c:00013] [ 2] /opt/FJSVxtclanga/tcsds-1.2.29/lib64/libmpi.so.0(opal_progress+0x98)[0x40000052c1e0]
[c26-0113c:00013] [ 3] /opt/FJSVxtclanga/tcsds-1.2.29/lib64/libmpi.so.0(+0x27f720)[0x40000037f720]
[c26-0113c:00013] [ 4] /opt/FJSVxtclanga/tcsds-1.2.29/lib64/libmpi.so.0(mca_pml_ob1_send+0x420)[0x40000037fc98]
[c26-0113c:00013] [ 5] /opt/FJSVxtclanga/tcsds-1.2.29/lib64/libmpi.so.0(MPI_Send+0x84)[0x400000221f74]
[c26-0113c:00013] [ 6] /home//xxxxx/src/fujitsu/lammps/src/lmp_mpi_fugaku[0x4e5d90]
[c26-0113c:00013] [ 7] /home//xxxxx/src/fujitsu/lammps/src/lmp_mpi_fugaku[0xbd2dac]
[c26-0113c:00013] [ 8] /home//xxxxx/src/fujitsu/lammps/src/lmp_mpi_fugaku[0x9f3a6c]
[c26-0113c:00013] [ 9] /home//xxxxx/src/fujitsu/lammps/src/lmp_mpi_fugaku[0x42d418]
[c26-0113c:00013] [10] /home//xxxxx/src/fujitsu/lammps/src/lmp_mpi_fugaku[0x42bc4c]
[c26-0113c:00013] [11] /home//xxxxx/src/fujitsu/lammps/src/lmp_mpi_fugaku[0x407e9c]
[c26-0113c:00013] [12] /lib64/libc.so.6(__libc_start_main+0xe4)[0x4000012c0be4]
[c26-0113c:00013] [13] /home//xxxxx/src/fujitsu/lammps/src/lmp_mpi_fugaku[0x407d68]
[c26-0113c:00013] *** End of error message ***

• vaspを長時間流すとやはり異常終了する。今の所、24h連続で死亡せずに計算が流れたた めしがない。今回はerrファイルにメモリエラーを匂わせる出力をして死亡した。

jwe0019i-u The program was terminated abnormally with signal number SIGBUS.
           signal identifier = BUS_ADRERR, non-existent physical address

• QEのbenchmarkで死亡した16 node計算を再度実行した。同じところ(scf loop14回目)でやはり死亡する。statsを見たがイマイチ見方がわからない。使用メモリらしき MAX MEMORY SIZE (USE)は、2201.7 MiBなので問題なさそう。そもそもメモリ足りないなら、1 node計算とかで死亡するはず。

  ======= Backtrace: =========
  /opt/FJSVxos/mmm/lib64/libmpg.so.1(+0x8044)[0x400000fb8044]
  /opt/FJSVxos/mmm/lib64/libmpg.so.1(+0x849c)[0x400000fb849c]
  /opt/FJSVxos/mmm/lib64/libmpg.so.1(+0xa5dc)[0x400000fba5dc]
  /opt/FJSVxtclanga/tcsds-1.2.29/lib64/libfj90i.so.1(jwe_xdal+0xe8)[0x400000a03720]
  /xxxx/src/fujitsu/qe-6.5/bin/pw.x[0x1079a38]
  /xxxx/src/fujitsu/qe-6.5/bin/pw.x[0x10707a4]
  /opt/FJSVxtclanga/tcsds-1.2.29/lib64/libfjomp.so(+0x765e0)[0x4000008c65e0]
  /opt/FJSVxtclanga/tcsds-1.2.29/lib64/libfjomp.so(__kmp_invoke_microtask+0x9c)[0x4000008e552c]
  ======= Memory map: ========
  00400000-014c0000 r-xp 00000000 7f:4f342 162157806366085170              /xxxx//src/fujitsu/qe-6.5/PW/src/pw.x
  02000000-03200000 rw-p 00000000 00:0f 6804404                            /anon_hugepage (deleted)
  03200000-03400000 rw-p 00000000 00:0f 6804408                            /anon_hugepage (deleted)
  .
  .
  .
  40001b5c0000-40001cdd0000 rw-s 00000000 00:00 0
  fff80ba00000-1000000000000 rw-p 00000000 00:0f 6804407                   /memfd: [stack] by libmpg (deleted)
  [i28-2203c:00116] *** Process received signal ***
  [i28-2203c:00116] Signal: Aborted (6)
  [i28-2203c:00116] Signal code:  (-6)
  [i28-2203c:00116] [ 0] linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x40000006066c]
  [i28-2203c:00116] [ 1] /lib64/libc.so.6(gsignal+0xac)[0x400001282c1c]
  [i28-2203c:00116] [ 2] /lib64/libc.so.6(abort+0x110)[0x4000012707a8]
  [i28-2203c:00116] [ 3] /opt/FJSVxos/mmm/lib64/libmpg.so.1(+0x8048)[0x400000fb8048]
  [i28-2203c:00116] [ 4] /opt/FJSVxos/mmm/lib64/libmpg.so.1(+0x849c)[0x400000fb849c]
  [i28-2203c:00116] [ 5] /opt/FJSVxos/mmm/lib64/libmpg.so.1(+0xa5dc)[0x400000fba5dc]
  [i28-2203c:00116] [ 6] /opt/FJSVxtclanga/tcsds-1.2.29/lib64/libfj90i.so.1(jwe_xdal+0xe8)[0x400000a03720]
  [i28-2203c:00116] [ 7] /xxxx/src/fujitsu/qe-6.5/bin/pw.x[0x1079a38]
  [i28-2203c:00116] [ 8] /xxxx/src/fujitsu/qe-6.5/bin/pw.x[0x10707a4]
  [i28-2203c:00116] [ 9] /opt/FJSVxtclanga/tcsds-1.2.29/lib64/libfjomp.so(+0x765e0)[0x4000008c65e0]
  [i28-2203c:00116] [10] /opt/FJSVxtclanga/tcsds-1.2.29/lib64/libfjomp.so(__kmp_invoke_microtask+0x9c)[0x4000008e552c]
  [i28-2203c:00116] *** End of error message ***
  jwe0019i-u The program was terminated abnormally with signal number SIGBUS.
             signal identifier = BUS_ADRERR, non-existent physical address
  

• fftwが怪しいと思い、 openmpiを外したfftw3を作成してlammpsを実行したが、やはり異常終了した。

• vaspのbenchmark計算で、エネルギーが並列条件によりやや変化する。

  omp1-node01-KPAR1/OUTCAR:  free  energy   TOTEN  =      -697.62942013 eV
  omp1-node01-KPAR4/OUTCAR:  free  energy   TOTEN  =      -697.62942013 eV
  omp1-node02-KPAR4/OUTCAR:  free  energy   TOTEN  =      -697.62942013 eV
  omp1-node04-KPAR4/OUTCAR:  free  energy   TOTEN  =      -697.62944689 eV
  omp1-node04-KPAR8/OUTCAR:  free  energy   TOTEN  =      -697.62942013 eV
  omp1-node08-KPAR8/OUTCAR:  free  energy   TOTEN  =      -697.62942013 eV
  omp1-node16-KPAR8/OUTCAR:  free  energy   TOTEN  =      -697.62944689 eV
  omp1-node32-KPAR8/OUTCAR:  free  energy   TOTEN  =      -697.62942013 eV
  

ちなみのお手製の並列計算機では、次のとおり。siliconは、intel i5の並 列計算機です。九大itoのvaspの結果も載せています。九大itoは自分でコ ンパイルしていません。多数決で-697.62942013 eVが正しそう。九大itoの vaspの結果が0.04 eVも高いのは謎です。okagiriは、研究室設置の36コア Xeonマシンです。

(九大ito)                            free  energy   TOTEN  =      -697.58570415 eV
(okagiri)                            free  energy   TOTEN  =      -697.62944689 eV
glass_vasp/OUTCAR.germanium-node04:  free  energy   TOTEN  =      -697.62942013 eV
glass_vasp/OUTCAR.germanium-node08:  free  energy   TOTEN  =      -697.62942013 eV
glass_vasp/OUTCAR.silicon-node04:    free  energy   TOTEN  =      -697.62942013 eV

• 念のためvaspでMD流したが、やはり無言のまま死亡することが再現された。 logのtimestampを見ると、14:41から計算スタートして、20:00に無言になっ ている。job stateはrunのままだが、何も計算していない様子。

• vaspはI/O関係で無言になったりCRASHするようだ。計算結果はintelマシンを再現しているので、問題なさそう。無言になったりCRASHしたらsubmitしなおすようscriptを作って対応することとした。

• lammpsのFFTWは、-DFFT_FFTW_THREADSを指定して富士通謹製fftw3をthread並列付きでリンクしていた。ふとlogを確認するとKISS FFTが使われていて、libfftw3.aが使われていない。

  PPPM initialization ...
    using 12-bit tables for long-range coulomb (../kspace.cpp:340)
    G vector (1/distance) = 0.28677902
    grid = 30 30 30
    stencil order = 5
    estimated absolute RMS force accuracy = 0.0039841386
    estimated relative force accuracy = 1.1998115e-05
    using double precision KISS FFT
    3d grid and FFT values/proc = 17908 7200   
  

  これはおかしいと思い、-DFFT_FFTW3でコンパイルしなおすと、libfftw3.aが正しく使われる様子。

  PPPM initialization ...
    using 12-bit tables for long-range coulomb (../kspace.cpp:340)
    G vector (1/distance) = 0.28677902
    grid = 30 30 30
    stencil order = 5
    estimated absolute RMS force accuracy = 0.0039841386
    estimated relative force accuracy = 1.1998115e-05
    using double precision FFTW3
    3d grid and FFT values/proc = 17908 7200   
  

• lammpsで3000原子の小さい系の計算を大量(2000以上)に実行する必要があったので、1 nodeでのompとmpiの組み合わせの性能評価した。omp06でmpi08が良さそう。threadなしのfftw3を使った方が良さそう。

  omp01-mpi48-DFFT_FFTW3/glass.log:Performance:         21.214 ns/day, 1.131 hours/ns, 245.533 timesteps/s
  omp01-mpi48-DFFT_FFTW3_THREADS/glass.log:Performance: 20.461 ns/day, 1.173 hours/ns, 236.820 timesteps/s
  omp06-mpi08-DFFT_FFTW3/glass.log:Performance:         21.579 ns/day, 1.112 hours/ns, 249.758 timesteps/s
  omp06-mpi08-DFFT_FFTW3_THREADS/glass.log:Performance: 16.550 ns/day, 1.450 hours/ns, 191.547 timesteps/s
  omp12-mpi04-DFFT_FFTW3/glass.log:Performance:         17.972 ns/day, 1.335 hours/ns, 208.005 timesteps/s
  omp12-mpi04-DFFT_FFTW3_THREADS/glass.log:Performance: 12.543 ns/day, 1.913 hours/ns, 145.172 timesteps/s
  

  ちなみにitoの1 nodesで並列条件を変えて計算を行うと次のとおり。 DFFT_MKL_THREADSでコンパイルするとKISS FFTと出力されるが、計算は早くなる。いろいろ矛盾しているが理由は不明。

  omp00-mpi36_DFFT_MKL/glass.log:Performance:         64.131 ns/day, 0.374 hours/ns, 742.261 timesteps/s
  omp00-mpi36_DFFT_MKL_THREADS/glass.log:Performance: 67.599 ns/day, 0.355 hours/ns, 782.400 timesteps/s
  omp01-mpi36_DFFT_MKL/glass.log:Performance:         69.391 ns/day, 0.346 hours/ns, 803.135 timesteps/s
  omp01-mpi36_DFFT_MKL_THREADS/glass.log:Performance: 73.452 ns/day, 0.327 hours/ns, 850.142 timesteps/s
  omp09-mpi04_DFFT_MKL/glass.log:Performance:         44.957 ns/day, 0.534 hours/ns, 520.340 timesteps/s
  omp09-mpi04_DFFT_MKL_THREADS/glass.log:Performance: 35.966 ns/day, 0.667 hours/ns, 416.270 timesteps/s
  omp12-mpi03_DFFT_MKL/glass.log:Performance:         37.538 ns/day, 0.639 hours/ns, 434.473 timesteps/s
  omp12-mpi03_DFFT_MKL_THREADS/glass.log:Performance: 29.047 ns/day, 0.826 hours/ns, 336.188 timesteps/s
  

vaspでMDを実行しているとメモリ不足で終了する。scfは回るが、mdを実行 しているうちに、メモリがあふれるようだ。vasp wikiにしたがって、 KPAR=1、scaLAPACKのもので実行してもダメ。またメモリ節約のため、以下 の環境変数をセットしている。

export XOS_MMM_L_HPAGE_TYPE=none

解決法として、ppnを減らして対処するしかない。なおscaLAPACKを使うよ うにしていると、ppn減らしてもメモリ節約にならないようなので注意する。

lammpsで前ステップで1 Gbyteくらいのtrajectoryを出力しようとすると、 なぜかメモリが溢れて異常終了する。MD計算自体は、数10Mbyteしかメモリ を使わないのに、dumpを続けているとメモリが溢れて終了する。ompとmpi の組み合わせを変えたが、結果はかわらず。

lammpsでしばらく流すと異常終了する件は、コンパイラのversionとjob scriptでloadしたmoduleのversionが一致していないことが原因であった。 versionが違うと、一見、計算が進むがメモリが開放されず異常終了するよ うだ。どのversionでコンパイルしたか記憶しておいて、正しいmoduleを loadする必要がある。

module load lang/tcsds-1.2.31

lammpsで正しいmoduleのversionをloadしたにも関わらず、同じように異常 終了する事例が発生した。計算スタートから、間違ったversionのmoduleを loadした時と同じようなエラーで1.5day後に異常終了する。

[e31-1103c:00012] *** Process received signal ***
[e31-1103c:00012] Signal: Bus error (7)
[e31-1103c:00012] Signal code: Non-existant physical address (2)
[e31-1103c:00012] Failing at address: 0x400006a8d3e4
[e31-1103c:00012] [ 0] linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x40000006066c]
[e31-1103c:00012] [ 1] /opt/FJSVxtclanga/tcsds-1.2.31/lib64/libmpi.so.0(+0x37e738)[0x40000057e738]
[e31-1103c:00012] [ 2] /opt/FJSVxtclanga/tcsds-1.2.31/lib64/libmpi.so.0(opal_progress+0x98)[0x40000062c6c8]

omp=6でlammpsを実行するとが異常終了する件は、以下の変数をセットすると解決した。スタックメモリが溢れていたようだ。

export OMP_STACKSIZE=1G
export FLIB_BARRIER=HARD

job script中からpython+numpyを呼び出す場合、計算ノードでspackで管理 されているpython+numpyを呼び出す必要がある。numpyは富士通謹製の数値 計算ライブラリとリンクしているものもあるらしいが、使用範囲では、重い 処理はないので、openblasをリンクしたversionを利用することとした。job scriptでspackのpythonを次のように呼び出す。

source /vol0004/apps/oss/spack/share/spack/setup-env.sh
spack load /v5kgevs
export LD_LIBRARY_PATH=/lib64:$LD_LIBRARY_PATH

LD_LIBRARY_PATHの追加はwarning抑制のため。また、/v5kgevsは python+numpyに割り当てられたhashで、次のようにして調べる。

spack find -lx | grep numpy

lammpsのjobが流れてもfileに出力されないので不審に思っていたが、48h経過して、jobが終了してもやはり出力されなかった。errorは次のように出力されていたが、何が起こっているか原因は不明。

<file transfer error information>
<summary>
total num: 2
total size: 13706917
error: E1
<detail>
E1 /vol0004/data/applog/20210915/7812086_7812086/app_nm_7812086_7812086_b487d903002cbf058d28f48b04550b8a.log
E1 /vol0004/data/applog/20210915/7812086_7812086/app_strings_7812086_7812086_b487d903002cbf058d28f48b04550b8a.log

ELAPSE TIME過ぎてabortすると、stadoutやstderrに何も吐き出されない場合がある。この場合、計算条件がまずかったのか、富岳の使い方が悪かったのか判断つかず、ハマりがち。

• VASP、QEとLAMMPSのbenchmark用のinputとoutputファイル一式。
• 並列条件で、ディレクトリを整理している。

• fujitsu以下にある実行ファイルを、$HOME/binにコピーする等して参照す る。

• intel以下にある実行ファイルは、loginノードで試計算するためのもの。 計算ノードでは実行できないので注意する。なおintelでコ ンパイルした実行ファイルをログインノードで利用する場合、intelのライブラリを参照す るよう以下のコマンドを投入する。

  source /opt/intel/bin/compilervars.sh intel64
  

• gitで配布するのは、実行ファイルだけ。src/以下にあるsource等は含めないので自分でcompileしたい場合は、各自で準備する。