2022年度スパコン更新内容

(最終更新: 2023/9/19) 2023年2月に運用開始した新システムについての情報です。

一般的な注意点

• Gaussian の formchk が動かない場合は FAQ の内容をご確認ください。
• Cgroup mem limit exceeded のメッセージについては FAQ の内容をご確認ください。
• No space left on device については FAQ の内容をご確認ください。
• CPU コアあたりのメモリ量が減っている点にご注意ください。コア数を前システムの時の倍にしないと同程度のメモリが確保できません。
• core 単位のジョブ(ncpus<64 及び GPU ジョブ)と jobtype=largemem については別途コア数制限が課されます。jobinfo -s で制限値を確認可能です。
• サーバ負荷を減らすため、短期間に大量のジョブを実行されている場合ペナルティが課される可能性があります。
  • 一日に数千ジョブ、のような規模で実行するような場合は、ジョブをまとめるようお願いします。
• Intel oneAPI の setvars.sh を .bashrc 等で読み込んでいる場合、sftp (含 WinSCP 等)での接続ができなくなる場合があります。
  • source ~/intel/oneapi/setvars.sh >& /dev/null のように出力を捨てればひとまず接続はできるはずです。
  • ($PS1 が存在する時だけ setvars.sh を読み込むようにしても大丈夫です。.bash_profile に移動させるだけでも大丈夫かもしれません)
• HPC-X 利用時に Failed to shmget with IPC_PRIVATE, size 20971520, IPC_CREAT; errno 28:No space left on device のようなメッセージでジョブがエラー終了、あるいはハングする
  • sys.c:883  UCX  ERROR   shmget(size=4296704 flags=0x7b0) for mm_recv_desc failed: No space left on device, please check shared memory limits by 'ipcs -l' というメッセージも表示されるようです。
  • cp2k で並列数が大きい時にこの問題が発生することを確認しています。
  • 使用している hcoll というライブラリが共有メモリセグメントを限界まで使ってしまったことが原因だと思われます(現在は最大4096個)
  • mpirun に -mca coll_hcoll_enable 0 オプションを追加して hcoll を無効にすることでひとまず解消できます。
    • 共有メモリセグメントの最大数を増やすことも可能ではありますが、そのような必要がある場合はまず一度ご相談ください。

既知の問題 (最終更新: 9/19)

• (対応完了した項目についてはページ末尾に移動させました。) (3/6)
• Intel MPI を使っている場合でも hcoll の影響でプログラムがフリーズするという報告がありました。(4/26)
  • Intel MPI 2021.8 で確認。他のバージョンでも同様の問題が起こる可能性があります。
  • 問題が発生したケースではログには何も表示されず、単純にプログラムの実行がフリーズしたような状態となっていました。
    • Intel MKL の scalapack から呼ばれた MPI 関連関数で、libhcoll 関連のコードを実行中にフリーズしている様子が確認できています
  • export I_MPI_COLL_EXTERNAL=no を mpirun 実行前に設定しておくことで問題を回避できるようです。
    • マニュアルによると、このパラメータはデフォルトで no となっていますが、指定することでなぜか挙動が変わります。
    • デバッグモード(I_MPI_DEBUG を利用)で実行した場合、デフォルト条件では [0] MPI startup(): detected mlx provider, set device name to "mlx_hcoll" のようなメッセージが表示されますが、上記環境変数を設定した場合には表示されません。
    • hcoll が存在する場合、自動的にそれを読み込むようになっているのかもしれません。
• HPC-X を利用している場合、含まれている hcoll が [LOG_CAT_P2P] や [LOG_CAT_MCAST] で始まる warning(エラー?)を出力する場合があります。(3/1)
  • mpirun に -mca coll_hcoll_enable 0 オプションを追加して hcoll を無効化すれば、メッセージが表示されなくなる場合が多いようです。
  • ただし、上記のようなメッセージが表示される場合には、ノード間通信が遅くなっている場合等あります(例: HPC-X 2.11 でビルドした GAMESS)のでご注意ください。
    • (HPC-X 2.11 でビルドした GAMESS で hcoll を無効化した場合、メッセージが表示されなくなるだけで、ノード間通信の問題に変化はありませんでした。)
  • MCAST だけの問題であれば、mpirun に -x HCOLL_ENABLE_MCAST=0 を追加するだけでメッセージが消える場合があります。こちらで済むケースについては大きな問題ではない可能性が高いと思われます。
    • 有効になっている knem モジュールと関係している可能性がありますが、当センターでは未検証です。
  • /apl/openmpi/3.1.6 には hcoll が組み込まれていないため、このメッセージが表示されることはありません。
• 導入済の Molpro 2022.3.0, 2022.2.2, 2021.3.1 では Disk option が正常に動作していません。(9/12 更新)
  • (Disk option についてはこちらの公式情報をご確認ください。)
  • molpro 2022.3.0 でも hcoll が有効な場合にハングする可能性がありそうです。現在検証を行っておりますので、もう少しお待ちください。(9/12)
  • Open MPI を使用している場合、一つのノードで複数の並列 molpro ジョブが実行された場合に動作がおかしくなるようです。Open MPI で disk option を使う場合はノードを専有する(ncpus=128)と安全性が上がる可能性があります。(9/12)
    • 参考(公式ページ): https://www.molpro.net/manual/doku.php?id=ga_installation
    • (ただし、これまでのところ実際にこの原因でクラッシュしたジョブは確認できていません。ハングするジョブはいくつか確認できておりますが、上記 hcoll が疑われるケースとの区別がついていません。)
  • 新規に導入している 2022.3.0-mva だけは正常に動作すると期待されます。(5/18 導入)
    • Open MPI を用いたバージョンでも、HPC-X 2.13.1 と hcoll を排除したケース(素の Open MPI 4.1.5 や hcoll を使わない HPC-X 2.11)ではある程度正常な動作が期待できそうです。ただし、この場合も MCSCF(PNO-LCCSD) を使う計算が"ERROR: Error setting an MPI file to atomic mode" というメッセージでクラッシュする場合が確認されています。(9/19)
  • MPI 由来の部分(MPIIO)でエラーが発生していると思われます。
  • これまでに確認できたところでは、Intel MPI 2021.7.1 と HPC-X 2.11 (Open MPI 4.1.4)と HPC-X 2.13.1 (Open MPI 4.1.5)で問題の発生が確認されています。
    • Intel MPI の場合、2021.5.1, 2021.8.0, 2021.9.0 では問題が発生していません。2021.7.1 の実行時ライブラリを使った場合のみハングしています。
    • Open MPI 3.1.6 では問題が発生していません。ただし、計算結果には直接的な影響は無いと思われるものの、計算終了時にエラーが出力されるようです。
    • HPC-X 2.11, 2.13.1 (Open MPI 4.x)の場合には hcoll 原因と思われるハングが起きることがあります。一方で hcoll を無効にしてもハングするケースを確認できています。
      • 同様に hcoll を使う(バージョンは違いますが) Intel MPI では問題が起きていないため、本件については hcoll は直接関係していない可能性があります。
        • HPC-X 2.11: hcoll v4.7.3208 (1512342c)
        • HPC-X 2.13.1: hcoll v4.8.3220 (2e96bc4e)
        • Intel MPI: hcoll v4.8.3221 (b622bfb) (/opt/mellanox/hcoll)
    • MVAPICH 2.3.7 では正常に動作しているようです。
  • Disk option が導入されていないバージョン(2021.1 よりも以前のバージョン)についてはこの問題は影響しません。Disk option は 2021.2 でデフォルト設定となっているため、2021.1 の場合には明示的に使用しない限りは影響を受けません。
  • 上記の問題があるバージョンについても --ga-impl ga を追加して以前のような動作にすれば、正常に動作します。RCCS で用意したサンプルでは適宜設定してあります。

oneAPI 環境の導入と csh で oneAPI 環境を読み込む方法について (3/3 更新)

Intel oneAPI Base Toolkit はこちらからダウンロードできます。コンパイラ、MKL, MPI などが含まれています。Linux 向け Online か Offline 版をご利用ください。
Fortran のコンパイラが必要な場合は HPC Toolkit も導入する必要があります。こちらよりダウンロードしてください。(3/3 更新)

bash の場合も以下の方法はそのまま使えますが、素直に ~/intel/oneapi/setvars.sh を読み込んだ方が楽です。
コンパイラや MKL 等の個別パッケージだけを読み込みたい場合は各コンポーネント中の env ディレクトリにあるスクリプトを読み込むこともできます。
(コンパイラーを読み込む場合: source ~/intel/oneapi/compiler/latest/env/vars.sh)

csh での設定読み込みはいくつか方法が考えられますが、ここでは module 化する方法を紹介します。oneAPI は ~/intel 以下に導入済とします。

$ cd ~/intel/oneapi
$ sh modulefiles-setup.sh
$ cd modulefiles/
$ module use .
$ module save

これを実行すると、oneapi の module を作成し、module の検索パスにそのディレクトリを登録する(module use . の箇所)ことになります。
最後に module save でその設定を保存しています。
RCCS ではログイン時に save した module 環境を restore するようになっているため、次回以降のログイン時には自動的に設定されます。
例えばコンパイラを読み込みたいのであれば、module load compiler/latest を実行することになります。
バージョンの詳細等については module avail コマンド等でご確認ください。

module save の前に compiler 等を読み込んでから save すれば、次回ログイン後はすぐにインテルのコンパイラが使えます。

$ cd modulefiles/
$ module use .
$ module load compiler/latest
$ module load mkl/latest
$ module load mpi/latest
$ module save

module save した環境を破棄したい場合は module saverm を実行してください。
なお、環境を保存してしまうと、システム側のデフォルト設定の変更に追随できなくなりますので、そこはお気をつけください。

演算ノード

• ノード貸しは 64 コアの vnode (仮想ノード)単位で割り当てられます。
• グローバルな作業領域(前システムの /work 相当)とは別に、ローカルストレージ上の作業領域が利用できます。

ストレージ

実効容量 14.8 PB (Lustre)
 

インターコネクト

InfiniBand
 

キュー構成とキュー係数(2023年度用)

ノードジョブは 64 コアの vnode (仮想ノード)を利用単位とします。(各ノードは 2 つの vnode に分けられます。)

• ジョブの最大時間は、定期メンテナンスまでとなります。ただし、1週間を越えるジョブが実行できるノードは全体の半分程度とします。
• largemem 以外の jobtype については指定したリソースより判定可能であるため、省略可能です。
• TypeC の 80 ノード(160 vnode)は vnode ジョブと core ジョブ共存領域となります。
• 短期の vnode ジョブが largemem 用の領域で実行される場合があります
• 短期の core ジョブが gpu 用ノードで実行される場合があります。
• (2022年度中のキュー係数は上記とは異なるものとなります。)

ログイン方法とファイルの転送方法

利用申請が許可され、アカウントが有効化されると、ログインノード(ccfep)に接続することができるようになります。
ログインやファイル転送の具体的な方法についてはクイックスタートガイドページの前半部分をご確認ください。
手順は前システムと同じです。
 

ジョブの投入方法について(jsub)

ジョブスクリプトを作成すれば、jsub コマンドでジョブを投入することができます。
ゼロからジョブスクリプトを作成することは、当センター特有の部分もあったりするためそれなりに大変です。
センター側で用意したしたサンプルをベースにして、適宜修正する形にした方が効率的かもしれません。
これらの方法についてはクイックスタートガイドページのジョブ投入ガイドの項目が参考になるかと思います。
Gaussian の場合は g16sub の利用をご検討ください。以下にリソース定義部分の例を示します。
 

例1: 5 ノードまるごと使う場合(640 (128*5) コア, 320 (64*5) MPI)

#PBS -l select=5:ncpus=128:mpiprocs=64:ompthreads=2

例1.5: 64 コアごとに 10 個確保するパターン(640 (64*10)コア, 320(32*10) MPI)

#PBS -l select=10:ncpus=64:mpiprocs=32:ompthreads=2

例2: 16 コアジョブ(16 MPI)

#PBS -l select=1:ncpus=16:mpiprocs=16:ompthreads=1

例3: 16 コア (16 OpenMP), 1 GPU ジョブ

#PBS -l select=1:ncpus=16:mpiprocs=1:ompthreads=16:ngpus=1

注意: ノードあたりの GPU 数は 8 で、GPU あたりの CPU コア数(ncpus/ngpus)は 16 以下である必要があります。

例4: 64 コア、大容量メモリ(約 500 GB)

#PBS -l select=1:ncpus=64:mpiprocs=32:ompthreads=2:jobtype=largemem

このジョブタイプだけは jobtype=largemem の指定が必須です。

前システムからの変更点

• jsub 実行時にキュー指定(-q H)は不要です。
• jobtype の指定についても大規模メモリ(jobtype=largemem)以外の場合は省略できます。
• 演算ノードではローカルディスクが利用できます。(他のノードから直接参照することはできません。)場所は /lwork/users/${USER}/${PBS_JOBID} です。ジョブの終了時に削除されます。
  • 11.9 GB * ncpus の容量が利用できます。ここで ncpus はノードあたりの cpu 数で判断されます。
  • select=2:ncpus=64:mpiprocs=64... の場合は 64 * 11.9 GB はそれぞれのノードで割り当てられます。
• 個々のユーザー向けのグローバルなスクラッチ領域は /gwork/users/${USER} にあります。前システムの /work/users/${USER} 相当になります。こちらは全ノードでシェアされています。

投入したジョブの確認方法について(jobinfo)

投入したジョブの情報は ccfep で jobinfo コマンドを実行することで確認できます。主な実行方法と出力例は以下の通りです。
今回のシステムではキューの名前(H)は省略できます。-q H のようにキューの名前をつけても問題はありません。
その他の点についてはほぼ前システムと同様の動作となっています。
 

jobinfo -c

自身のジョブの最新の情報を取得できます。ただし、GPU数など一部の情報は得られません。
また、他のオプションとの組み合わせも制限されます。

[user@ccfep ~]$ jobinfo -c

--------------------------------------------------------------------------------
Queue   Job ID Name            Status CPUs User/Grp       Elaps Node/(Reason)
--------------------------------------------------------------------------------
H       4008946 sample3.csh    Run      16  uuu/---     1:51:14 ccc001        
H       4008952 sample0.sh     Run      16  uuu/---     1:51:08 ccc001        
H       4010452 sample-gpu.sh  Queue     1  uuu/---     0:02:40 (gpu)         
--------------------------------------------------------------------------------
Job Status at 2023-01-28 14:00:12

jobinfo

最大で数分程度の遅れがありますが、-c をつけた際よりも詳しい情報が得られます。

(-m 等の他のオプションと組み合わせる状況が多いでしょうか。)

[user@ccfep ~]$ jobinfo

--------------------------------------------------------------------------------
Queue   Job ID Name            Status CPUs User/Grp       Elaps Node/(Reason)
--------------------------------------------------------------------------------
H(c)    4008946 sample3.csh    Run      16  uuu/ggg     1:51:14 ccc001        
H(c)    4008952 sample0.sh     Run      16  uuu/ggg     1:51:08 ccc001
H(g)    4010452 sample-gpu.sh  Queue   1+1  uuu/ggg     0:02:40 (gpu)          
--------------------------------------------------------------------------------
Job Status at 2023-01-28 14:00:12
For the latest status, please use '-c' option without '-m', '-w', '-s'.

jobinfo -s

自身やグループが利用しているコアやGPUの数、キューの空き状況を表示します。

[user@ccfep ~]$ jobinfo -s

User/Group Stat:
--------------------------------------------------------------------------------
 queue: H                       | user(qf7)             | group(za0)           
--------------------------------------------------------------------------------
   NJob (Run/Queue/Hold/RunLim) |    0/    0/    0/-    |    0/    0/    0/2560
   CPUs (Run/Queue/Hold/RunLim) |    0/    0/    0/-    |    0/    0/    0/2560
   GPUs (Run/Queue/Hold/RunLim) |    0/    0/    0/-    |    0/    0/    0/48  
   core (Run/Queue/Hold/RunLim) |    0/    0/    0/600  |    0/    0/    0/600 
--------------------------------------------------------------------------------
note: "core" limit is for per-core assignment jobs (jobtype=core/gpu*)

Queue Status (H):
----------------------------------------------------------------------
      job         | free   |     free     | # jobs  |  requested  
      type        | nodes  | cores (gpus) | waiting | cores (gpus)
----------------------------------------------------------------------
week jobs
----------------------------------------------------------------------
1-4 vnodes        |    706 |  90368       |       0 |      0      
5+  vnodes        |    506 |  64768       |       0 |      0      
largemem          |     14 |   1792       |       0 |      0      
core              |    180 |  23040       |       0 |      0      
gpu               |     16 |   2048 (128) |       0 |      0 (0)  
----------------------------------------------------------------------
long jobs
----------------------------------------------------------------------
1-4 vnodes        |    326 |  41728       |       0 |      0      
5+  vnodes        |    226 |  28928       |       0 |      0      
largemem          |      7 |    896       |       0 |      0      
core              |     50 |   6400       |       0 |      0      
gpu               |      8 |   1024 (64)  |       0 |      0 (0)  
----------------------------------------------------------------------

Gaussianジョブの投入について(g16sub/g09sub)

ジョブは通常上記の jsub コマンドで投入しますが、Gaussian だけは g16sub という専用コマンドが用意されています。
Gaussian 09 用の g09sub というコマンドもあります。使い方については g16sub と基本的に同じです。
Gaussian のインプットを直接与えれば、自動でジョブスクリプトを生成、投入します。
デフォルトでは 8 コア(前システムでは 6 コア)使用で制限時間 72 時間(前システムと同じ)となっています。

基本形( 8コア、72 時間)

[user@ccfep somewhere]$ g16sub input.gjf

コア数、制限時間を変える場合(16 コア、168 時間)

[user@ccfep somewhere]$ g16sub -np 16 --walltime 168:00:00 input.gjf

注意点

• largemem を使う場合は -j largemem の指定が必要です。
  • -np 64 や -np 128 を指定した時には自動的に jobtype=vnode になります。

コンパイル環境について

gcc, aocc, NVIDIA HPC SDK を用意しています。
インテル oneAPI については、ライブラリ等は導入していますが、共用領域にコンパイラは用意していません。
インテルコンパイラが必要であれば oneAPI Base Toolkit や oneAPI HPC Toolkit をご自身のホームディレクトリに導入してください。

gcc についてはシステム標準のもの(8.5)に加えて gcc-toolset の新しいバージョン(9.2,10.3,11.2)も導入しています。
module load gcc-toolset/11 のように実行すれば使えるようになります。
 

科学計算ソフトウェアに関して

インストール済ソフトウェアのリストについては、パッケージプログラム一覧ページにてご確認ください。
module avail コマンドでも確認できます。(キーボードの q を押すか、ページの一番下まで動かせば終了できます)

以下、細々とした注意点です。

• csh 用の設定スクリプトが用意されないソフトが増えてきています。module コマンドならば対応できますので、module コマンドの活用をご検討ください。

module コマンド(Environment Modules)

• ログインシェルが csh の場合、ジョブスクリプトでは module コマンドを使う前に source /etc/profile.d/modules.csh を実行してください。
  • ログインシェルが /bin/bash で csh のジョブスクリプト使う場合も source /etc/profile.d/modules.csh が必須です。
  • ログインシェルが /bin/tcsh で sh のジョブスクリプトを使う場合は . /etc/profile.d/modules.sh が必須です。(. は source と同義です)
• スクリプト内で実行する場合は、-s をつけて余計な出力をさせないようにした方が無難です。(例: module -s load openmpi/3.1.6)
• module save コマンドで現在の状況を保存することができます。保存した状況は次にログインした時に自動で読み込まれます。

対応を完了した問題

• waitest を再整備しました(9/4)
• Intel MPI の問題はキューイングシステムの設定を見直したことで解消しました。(2/3)
  • export I_MPI_HYDRA_BOOTSTRAP=pdsh の設定は必要ですが、これは自動的に入るようになりました。ご自身で設定する必要はありません。(2/3)
  • GRRM17 の MPI 実行が正常に動作していません。現在検証中です。MPI を使わない実行については問題ありません。
  • Intel MPI を使うと実行開始時にエラーが発生するケースがあります。現時点では、避けられるのであれば Intel MPI は避けた方が無難かもしれません。
    • ご自身のディレクトリにインストールした Intel MPI を使う場合、I_MPI_HYDRA_BOOTSTRAP 環境変数を ssh という値に設定すれば問題が解消するかもしれません。
    • export I_MPI_HYDRA_BOOTSTRAP=pdsh (bash の場合)の方が少し良さそうです。ただ、これでも改善しない場合もすでに確認されています。(2/1)

• jobinfo -s, jobinfo -n, jobinfo 等のコマンドを実行した時にエラーが出るケースがあります。(2/15) 修正により解消したはずです(2/16)
  • jobinfo -c は影響を受けません。
  • 通常は再度実行すれば正しい情報が返ってきます。近日中の修正を予定しています。(2/15) 修正完了(2/16)

• jobtype=core で ompthreads > 1 の場合のコア割り当て方法を変更しました。(2/20)
  • OpenMPI の場合 mpirun --map-by slot:pe=${OMP_NUM_THREADS} あるいは mpirun --map-by numa:pe=${OMP_NUM_THREADS} で個々の mpi プロセスと配下の OpenMP スレッドが一つの numa node に収まるようになります。
    • (上記設定は jobtype=vnode (ncpus=64 or ncpus=128) 時にも有効であるはずです。slot と numa では割り当て方法が違うため、速度に違いが出る場合があります。)
  • ncpus=20:mpiprocs=5:ompthreads=4 の場合、5 つの NUMA ノード (16 コア) から 4 コアずつ切り出したような形になります。
  • (mpiprocs の数によって取り扱いが変わります。うまく動作しない場合はお問いあわせください。)
  • gpu 利用時は ompthreads > 1 で ncpus/ngpus が 8 以下、gpu 数が 2 以下の時は --map-by slot:pe=${OMP_NUM_THREADS} が正常に動作すると期待されます。(2/22)
    • ご自身の条件で効率が思ったように上がらない場合には一度ご相談ください。(2/22)

• openmolcas についてはひとまず現状のまま据え置きとしました(2/13)
  • 908 のテストで 16 MPI 並列までは問題無いものの、32 並列になると安定して結果がおかしくなります。純粋に並列数で決まるようで、ノード内でもノード間でも変化は無し。(2/13)
  • --with-openib でビルドした GlobalArrays の影響が考えられます。現在調査中です。(2/10)
    • --with-openib を --with-mpi-pr 等に変えると動作せず。デフォルト(--with-mpi)では動作するものの、上記エラーは変わらない。(2/13)
    • OpenMPI や IntelMPI でバージョンを変えてみても状況が変わらず。何らかの仕様？OpenMP については動作に問題は見られない。(2/13)
• siesta MPI 版は Open MPI + MKL の条件では時々計算が非常に遅くなるケースがありますが、今のところ効果的な対処法が見つからないため、保留とします。(2/13)
  • Intel MPI を使った場合は今のところ正常に動作していません。(2/13)
  • MKL と Intel MPI を両方避けると若干安定になるようにも見えますが、確実性に欠けます。(2/13)
  • インテルコンパイラを使って MKL を避けようとした場合は scalapack のテストが通らなかったため回避しています。(2/13)

• gamess の並列計算全般に問題があるため、現在調査中です。(2/9)
  • gamess で並列計算を行う場合は当面 /apl/gamess/2022R2-openmpi もしくは /apl/gamess/2021R1-openmpi をご利用ください。(2/10)
  • 3/6 メンテ時にこれらを新たに /apl/gamess/2022R2 と /apl/gamess/2021R1 とします。(2/10)
    • ただし、ノード間通信の最適化はできていません(ucx のエラーメッセージは無視してください)。それらは次のバージョン導入時に MPI 側の設定も合わせて再調整する予定です。(2/10)
  • 3/6 メンテ時には新たに openmpi3 でビルドしたものを /apl/gamess/2022R2, /apl/gamess/2021R1 とします。(2/24)
    • こちらのバージョンではノード間通信も問題無く動作します。上記のような ucx のエラーもありません。
    • ncpus=32:mpiprocs=64 のようにして oversubscribe しても速度は向上しません。演算に関わるコア数は半分になりますが、ncpus=32:mpiprocs=32 のような設定でご利用ください。(setenv OMPI_MCA_mpi_yield_when_idle 1 は行っていますが、それでもダメです。)
• nwchem は HPC-X 2.13.1 が無関係なところでマルチノードでの計算(現在確認した限りでは TDDFT)がおかしくなる場合があります。(2/9)
  • nwchem-7.0.2 を使う場合は /apl/nwchem/7.0.2-mpipr をご利用ください。(2/13)
  • reactionplus の利用時は /apl/reactionplus/1.0/nwchem-6.8-mpipr をご利用ください。(2/13)
    • sample や module についても新しいもの(-mpipr) を使うように修正しています。(2/13)
  • 3/6 メンテ時にそれぞれ /apl/nwchem/7.0.2 と /apl/reactionplus/1.0/nwchem-6.8 としてインストールします。(2/13)
  • ARMCI_NETWORK に OPENIB を指定したことが原因である可能性があります。別途調査と検証を継続します。(2/9)
    • ARMCI_NETWORK を MPI-PR に変更したことで問題が解消しました。(2/13)
• HPC-X 2.13.1 は複数ケースで問題が起きているため、安全ではない可能性が高いです。HPC-X 2.13.1 を使っているソフトについては順次見直していく計画です。(2/7)
  • 一通りの調査が完了しました。(2/13)
  • cp2k-9.1, genesis (CPU 版), lammps (CPU 版), molpro, namd (CPU版), nwchem, openmolcas, siesta については HPC-X 2.13.1 による問題は確認できていません。(2/25)
    • (エラーになる例をご存知の方がおられましたらご連絡ください。症状と回避策についてこちらで検証を行います。)
    • (namd GPU 版は MPI を使っていないため、無関係でした…)
    • molpro についても hpc-x 2.13.1 の疑わしい挙動が確認されました(9/15)
  • namd-2.14 (CPU版) で大規模並列を行うと計算がエラー終了する例が確認されました。問題は解消しています。(2/22)
    • 実行時ライブラリを HPC-X 2.11 (OpenMPI-4.1.4)に切り替えることで解消しています。
    • サンプルとモジュールについても置き換えておりますので、こちらをご利用ください。
  • genesis (CPU版) で大規模並列を行うと計算がエラー終了する例が確認されました。問題は解消しています。(2/25)
    • 実行時ライブラリを HPC-X 2.11 (OpenMPI-4.1.4)に切り替えることで解消しています。
    • サンプルとモジュールについても置き換えておりますので、こちらをご利用ください。
  • gcc と HPC-X 2.13.1 (OpenMPI-4.1.5)を組み合わせて Gromacs (2021.4, 2021.6, 2022.4)で複数ノード並列計算を行った際に、計算は最後まで終了しているように見えるものの、プロセスが終了しないケースがありました。(1/x)解消しました(1/x)
    • HPC-X 2.11 (OpenMPI-4.1.4)を使うことで解消しています(1/x)
  • gcc+HPC-X 2.13.1 を使う AMBER (pmemd GPU 版)の並列時にエラーが確認されました。解消しました(2/1)
    • 実行時ライブラリを HPC-X 2.11 にすることで状況が改善しています (2/1)
    • module の定義も変更しました。新規に amber の module を読み込むと HPC-X 2.11 が読み込まれます(2/1)
  • intelコンパイラ+HPC-X 2.13.1 を使う QE-6.8 でもマルチノード時にほぼ確実にエラーが発生するとの報告がありました。(2/7)解消しました(2/7)
    • こちらも実行時ライブラリを HPC-X 2.11 にすることで状況が改善しています。GPU 版についても変更しています。(2/7)
  • lammps-2022-Jun23 GPU 版で並列時に問題が発生しました。(2/8)解消しました(2/10)
    • amber と同様に実行時ライブラリを HPC-X 2.11 にすることで問題は解消しています。(2/10)
    • ついでに、同一ノードで複数 GPU を使うための wrapper を用意しました。(2/10)
  • genesis 2.0.3-cuda has problem with parallel GPU run. (2/10) 解消しました(2/10)
    • amber と同様に実行時ライブラリを HPC-X 2.11 にすることで問題は解消しています。(2/10)
• /usr/bin/python3 は現在 python 3.9 となっていますが、3/6(月)メンテ時に python 3.6.8 に置き換えられます。(2/7)
  • パッケージの状態や各種問題の解消のためです。
  • python 3.9 に依存しているアプリ(現在確認できている範囲では OpenMolcas と NWChem-7.0.2)については3/6メンテ時に差し替えを予定しています。(2/9)
• /usr/bin/perl は現在バージョン 5.32 となっていますが、3/6(月) メンテ時にバージョン 5.26 に置き換えられます。(3/3)
• ジョブ実行中に他の演算ノードに scp でファイルを送ることが現在できていません。現在対応中です。(2/2)(2/3 対応完了)
• g16sub/g09sub はデフォルトで高速なローカルディスク(/lwork)をスクラッチ領域として使いますが、-N オプションを指定することで共有ディスク /gwork/users/$(USER) (大容量だが速度は劣る)をスクラッチ領域にすることができるようになりました。(2/1)
• AlphaFold 2.3.1 が利用可能です。(2/6)
• remsh が利用できるようになりました (/usr/local/bin/remsh)。(2/6)
• joblog を導入しました(/usr/local/bin/joblog)。(2/6)
  • 2月のジョブでも点数が表示されますが、これは表示のみで実際には点数は消費されません。
• nbo 7.0.10 を導入しました。Gaussian 16 c.01, c.02 からも呼び出せます。(2/14)
• python 3.10 環境(miniforge)を /apl/conda/20230214 以下に用意しました。/apl/conda/20230214/conda_init.sh か /apl/conda/20230214/conda_init.csh を読み込めば利用できます。(2/14)
• jobtype=largemem には 3/6(月) メンテナンスにて追加の制限を設けます。(2/24)
  • 現時点ではグループあたり 896 コア(7 ノード)の制限となる見込みです。
• 計算中に演算サーバのローカルディスク(/lwork)や ramdisk (/ramd/users/${USER}/${PBS_JOBID})のデータを確認するためのソフト、remsh はまだ準備中です。(done)
• joblog は現在準備中です。(done)
• ジョブの実行ディレクトリパスに非ASCII文字が入っている場合、jobinfo -w で作業ディレクトリが正しく表示されません。(2/21)
  • 2/17-18 頃、この理由が原因で jobinfo がエラーを出力していましたが、そのエラーについては解消しています。(2/21)
  • 特定の非ASCII文字が入った場合、現在も jobinfo コマンドが失敗することが確認されました。(4/4)
  • 対応が完了しました(4/7)
• 以下のソフトの導入は完了しました(5/8)
  • DIRAC 22(23 を導入), DIRAC 23(完了), CP2K 2023.1(完了), Quantum ESPRESSO 7.1(かわりに7.2を導入します), Quantum ESPRESSO 7.2(完了), Julia 1.8.5(完了)
• システム側のトラブルに巻き込まれたジョブが意図せず Hold 状態になり、jobinfo では (error) と表示される場合があります。(2/15)システム側の修正でこの問題は解決しています。
  • この事象そのものは前システムでも起こっていましたが、ジョブの再実行で解消できていました。しかし、現在はこの方法がうまくいかず、ジョブが正常に終了しません。(2/15)
    • (ジョブの再実行自体は実行できるのですが、終了後に再び hold 状態に戻ってしまうようです。)
    • そもそもシステムによるジョブの再実行を望まない場合は #PBS -r n をジョブスクリプトに追加してください。(利用の手引きにも記述有)
  • ジョブの削除が失敗する例も複数確認されています。削除したいジョブが削除できない場合は、お手数ですが、ジョブIDをお知らせください。管理者権限で強制的に削除します。(2/15)
    • (残っていても気にならないのであれば放置しても害はありません。その場合も 3/6(月)メンテナンス時には削除されます。)
  • 現在も調査継続中です。(2/15)
  • 3/2 のキューイングシステム障害後、(error) の表記はなくなっていますが、状況は特に変化していません。(3/3)