toolchain/scripts/install_fftw.sh の ./configure の直前に
sed -i -e “s/-no-gcc//g” configure
を追加。-no-gccが残っているとエラーが出て、fftw3がコンパイルできない。
今年から導入されるアーキテクチャは基本的に /usr/bin/python は存在しないため、CP2K本体のmake時、/usr/bin/env pythonがエラーになる。pythonをpython2.7に変換する必要がある。特に、隠しフォルダ /exts/dbcsr/.cp2k の中のスクリプトは普通にgrepで検索すると引っかからない。
gfortran.makeに並列化のオプションをつけ足せばコンパイルできる。
intelも試したが、難しいので一旦諦める。普通にやるとmpi_siestaに必要なライブラリが見つからないと言われるので、Objディレクトリをincludeパスに追加。そのエラーは消えたが、今度はMPI_BCastが見つからないと言われる。これはちょっとわからない。
SIEASTA-3.2も試みたが、こちらはconfigure中のa.out実行のところで止まる。全部tssrunに変更すればよいのかもしれないが、ひとまずGNU-compilerで良しとする。
.SUFFIXES:
.SUFFIXES: .f .F .o .c .a .f90 .F90
SIESTA_ARCH = unknown
CC = cc
FPP = $(FC) -E -P -x c
FC = ftn
FC_SERIAL = ftn
FFLAGS = -O2 -fPIC -ftree-vectorize
AR = ar
RANLIB = ranlib
SYS = nag
SP_KIND = 4
DP_KIND = 8
KINDS = $(SP_KIND) $(DP_KIND)
LDFLAGS =
COMP_LIBS = libsiestaLAPACK.a libsiestaBLAS.a
FPPFLAGS = $(DEFS_PREFIX)-DFC_HAVE_ABORT -DMPI -DFC_HAVE_FLUSH
MPI_INTERFACE=libmpi_f90.a
MPI_INCLUDE=.
LIBS =
# Dependency rules ———
FFLAGS_DEBUG = -g -O1 # your appropriate flags here…
# The atom.f code is very vulnerable. Particularly the Intel compiler
# will make an erroneous compilation of atom.f with high optimization
# levels.
atom.o: atom.F
$(FC) -c $(FFLAGS_DEBUG) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_fixed_F) $<
.c.o:
$(CC) -c $(CFLAGS) $(INCFLAGS) $(CPPFLAGS) $<
.F.o:
$(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_fixed_F) $<
.F90.o:
$(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_free_F90) $<
.f.o:
$(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_fixed_f) $<
.f90.o:
$(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_free_f90) $<
あくまでも自分が流す第一原理計算 with CP2K ver5.1 での比較だが、計算時間は
物性研システムB 1728 並列 (72 nodes) ≂ 阪大OCTOPUS 768 並列（32 nodes）x 5.5 < 京大CRAY 544 cores (8 nodes)
物性研がこれまで圧倒的に早かったが、OCTOPUSがちょっとだけ抜いてきて、京大CRAYはこの二つより5.5倍ほど遅く、何もしないよりはマシ、というところ。
物性研は、1728 coresはちょっとやりすぎというか、864→1728は1.15倍速程度にしかならないのだが、F36キュー（最大864並列）はかなり混雑しており、待ち時間が長すぎて使い物にならない。多少ポイントは浪費するが、F144キュー（最大3456並列）の1728並列の方が逆に空いていて、シームレスにjobが入る。
OCTOPUSでは、今のところ32 nodesなら切れ目なく投入でき、物性研並みに使える印象。
京大CRAY 544 coresは96万円で最低限保証されるcore数で、それ以上core数を増やすと、切れ目なく投入されるかどうかは混み具合に依存する。すぐ入るときもあるし、1日以上待つときもある。どちらかというとプロパティの1点計算やその他のプログラムを回すのに主に使い、出張中や、雑務or書き物であまり頻回にjob更新をできない時に第一原理MDを少しでも進めておく感じで使う。ただ、ポイント消費制でなく、空いてさえいればjobがいくらでも投入できるのは大きな魅力。最低544 cores、最大4352 coresあれば、一人で使う分にはストレスなく使えるが、今後もし学生が増えたら予算確保できるだろうか…と思うところはないでもない。
まずGNUコンパイラを準備。
module swap PrgEnv-cray PrgEnv-gnu
module load fftw
ライブラリ類は基本的に
./configure FC=ftn CC=cc CXX=CC –prefix=/somewhere/somepath
make
でビルドできる。
libsmmも、付属のpbs.wlmをオプションだけ変えて使ってバッチジョブでビルドできる。
ちょっとだけ問題だったのはlibint。ビルドの途中でバイナリを実行するのだが、このシステムでは基本的にログインノードで負荷の高いバイナリを実行できない（Illegal Instructionと出て止まる。何か条件はあるんだろうが、具体的には不明で、負荷の高いという表現がよいのかわからない。例えばcp2k.popt等は実行できないが、Hello Worldは動く。今回もbuild～やvrr～の処理が完了し、hrr1～の処理に突入した段階で止まる。makeはsingle coreで実行しているし、serial/parallelの問題というわけでもなさそうだし、ulimit -s unlimitedを実行すればよいというわけでもなかった）。そこで、build_libintが異常終了したタイミングで
cd ~/src/libint-1.1.4/src/lib/libint/src
tssrun /home/b/bxxxxx/src/libint-1.1.4/src/lib/libint/../../../src/bin/libint/build_libint
と会話処理でbuild_libintを実行したのち（要するにMakefileの動きに従って、止まった処理をtssrunで実行）、makeを再開するとビルドできた。
コンパイルを４通りほど試してわかったのは、
・-O3は-O2より30%ほど高速化する
・libsmmとlibxsmmでは速度には違いが無い
ひとまず使おうと思うバイナリのコンパイルオプションは以下のとおり。
CC = cc
CPP =
FC = ftn
LD = ftn
AR = ar -r
LIBINT_DIR = /home/b/bxxxxx/src/libint-1.1.4
LIBSMM_DIR = /home/b/bxxxxx/src/cp2k-5.1/tools/build_libsmm
LIBGRID_DIR = /home/b/bxxxxx/src/cp2k-5.1/tools/autotune_grid
CPPFLAGS =
DFLAGS = -D__FFTW3 -D__parallel -D__SCALAPACK -D__HAS_NO_SHARED_GLIBC -D__LIBINT -D__LIBSMM -D__HAS_LIBGRID
CFLAGS = $(DFLAGS)
FCFLAGS = $(DFLAGS) -O3 \
-mavx -funroll-loops -ffast-math -ftree-vectorize \
-ffree-form -ffree-line-length-512 -fno-omit-frame-pointer
LDFLAGS = $(FCFLAGS)
LIBS = -L$(LIBGRID_DIR) -lgrid \
$(LIBINT_DIR)/lib/libderiv.a $(LIBINT_DIR)/lib/libint.a -lstdc++ \
$(LIBSMM_DIR)/lib/libsmm_dnn_cray.gnu.a \
-lfftw3 -lz -ldl
テストするとCO.inp、multipole_ch_qu.dbg_f_real.inp、UO2-4x4x4-cs-fixd-npt.inpの３つにWRONGが出る。前二つはほぼteleranceに近い値なので良いとして、UO2-4x4x4-cs-fixd-nptは完全に間違っている。同様のエラーは報告があり、そこでは放っておくということになっている…
-O2にすると、前二つはそのままだがUO2-4x4x4-cs-fixd-nptのWRONGは消えるので、NPTを計算することがあれば大事を取って-O2でコンパイルしたバイナリを使うことにする。
ver5.1をビルドするためにはコンパイラのバージョンを変える必要がある。
（. /etc/profile.d/modules.sh）←バッチジョブスクリプトでmoduleコマンドを実行するのに必要
module purge
module load intel/17.0.4.196
module load intel-mpi/5.1.3.258
まずlibint、fftw、libxc-4.0.4、autotune_gridはログインノードでビルド完了。
次にlibsmmは、ログインノードで実行するとデータ集めの最中に切れてしまい不可、またインタラクティブモードでも60分の制限があるため、ジョブを100個自動で生成してビルドするしかない。pbs.wlmを書き換える。
batch_cmd() {
cat <<EOF > ${test_name}.sh
#!/bin/sh
#QSUB -queue F4cpu
#QSUB -node 1
#QSUB -omp 1
#QSUB -place pack
#QSUB -over false
#PBS -l walltime=${wtime}
#PBS -N ${test_name}
cd \$PBS_O_WORKDIR
. /etc/profile.d/modules.sh
module purge
module load intel/17.0.4.196
${aprun_cmd} $@
EOF
}
もとのpbs.wlmではqsubとセットになっているのだが、システムBではワンライナーでqsubができないのでヒアドキュメントを使う。これに実はqsubも組み合わせようとしたのだが、うまくいかなかった。パイプでqsubとか、2段に分けてqsub ${test_name}.shとか試みたが、いずれもEOFが見つからないと怒られる。仕方がないのでqsubは自分で別に実行するようにした。どのみち、システムBにjobは100個しか投入できないので、何か走っていると最後の方が無理だから、様子を見て逐次投入して行くのでちょうどよかったかも。残りのプロセスも同様にして完遂し、libsmmをビルド。
OCTOPUSと同様のarchファイルでコンパイル。
regtestだが、これもシステムBではログインノードでmpijobが実行できず、インタラクティブモードでも時間が足りないので、jobを投げて実行する。do_regtestファイルのmpiexecをmpijobに換えて、-np 2も-mpi 2にする。
テストしたところ、TMCで6件のWRONGが出て、残りはすべてCORRECTだった。
TMC_ana_density.inp 0.711367119328203 WRONG RESULT TEST 39
TMC_ana_G_R.inp 0.711367119328203 WRONG RESULT TEST 39
TMC_ana_dip_cl.inp 0.711367119328203 WRONG RESULT TEST 39
TMC_ana_deviation.inp 0.711367119328203 WRONG RESULT TEST 39
TMC_ana_create_traj_without_ana.inp – OK ( 0.27 sec)
TMC_ana_start_with_exist_traj.inp 5.905896245601220E-003 WRONG RESULT TEST 39
TMC_ana_restart.inp 5.905896245601220E-003 WRONG RESULT TEST 39
シングルコアでテストするとTMCダメと言われているが、そこは2core並列でテストしている。まあシステムBでモンテカルロを計算しなければよいのですね。
阪大サイバーメディアセンターに新しいクラスターOCTOPUSが導入され、Intel Compilerがver2017しかないということで、これを機に最新版のCP2Kを主要なライブラリも全部つけてコンパイルすることにした。こういうビルドの情報って、イギリスとかだと公開してくれるのだが、日本だとあまり共有されない。そこそこ時間を要したので貼ることにする。
OSはRHEL7.3、コンパイラ・ライブラリは
intel compiler & libraries 2017.5.239
のコンパイラ、mkl、intel mpi。これしか選べない。
libint-1.1.4
libxc-2.2.3 or 4.0.4を解凍し、ビルドする。
configure時に FC=ifort、CC=icc、CXX=icpcをつけるのと、prefixを指定する。
またcp2k-5.1/toolsにあるautotune_grid/でlibgrid.aを、build_libsmmでlinux_libsmm.aをそれぞれ指示に従ってビルドする。これらはいずれも１晩くらいかかる。
それでarchファイルはlibxcが2.2.3の場合、
CC = icc
CPP =
FC = mpiifort
LD = mpiifort
AR = ar -r
LIBXC_DIR = /somewhere/somepath/libxc-2.2.3
LIBINT_DIR = /somewhere/somepath/libint-1.1.4
LIBSMM_DIR = /somewhere/somepath/cp2k-5.1/tools/build_libsmm
LIBGRID_DIR = /somewhere/somepath/cp2k-5.1/tools/autotune_grid
CPPFLAGS =
DFLAGS = -D__MKL -D__FFTW3 -D__LIBINT -D__LIBXC -D__parallel \
-D__SCALAPACK -D__HAS_smm_dnn -D__HAS_LIBGRID \
-I$(LIBXC_DIR)/include
CFLAGS = $(DFLAGS)
FCFLAGS = $(DFLAGS) -O2 -g -traceback -fpp -free \
-I$(MKLROOT)/include -I/somewhere/somepath/fftw-3.3.7/include
FCFLAGS2 = $(DFLAGS) -O1 -g -traceback -fpp -free \
-I$(MKLROOT)/include -I//somewhere/somepath/fftw-3.3.7/include
FCFLAGS3 = $(DFLAGS) -O0 -g -traceback -fpp -free \
-I$(MKLROOT)/include -I//somewhere/somepath/fftw-3.3.7/include
LDFLAGS = $(FCFLAGS) -static-intel
LDFLAGS_C = $(FCFLAGS) -static-intel -nofor_main
LIBS = $(MKLROOT)/lib/intel64/libmkl_scalapack_lp64.a \
-Wl,–start-group $(MKLROOT)/lib/intel64/libmkl_intel_lp64.a \
$(MKLROOT)/lib/intel64/libmkl_sequential.a \
$(MKLROOT)/lib/intel64/libmkl_core.a \
$(MKLROOT)/lib/intel64/libmkl_blacs_intelmpi_lp64.a -Wl,–end-group \
-lpthread -lm \
//somewhere/somepath/fftw-3.3.7/lib/libfftw3.a \
$(LIBINT_DIR)/lib/libderiv.a $(LIBINT_DIR)/lib/libint.a -lstdc++ \
-L$(LIBXC_DIR)/lib -lxcf90 -lxc \
$(LIBSMM_DIR)/lib/libsmm_dnn.a $(LIBGRID_DIR)/libgrid.a
# Required due to memory leak that occurs if high optimisations are used
mp2_optimize_ri_basis.o: mp2_optimize_ri_basis.F
../../../tools/build_utils/fypp -n $< $*.F90
$(FC) -c $(FCFLAGS3) -I’$(dir $<)’ $*.F90
libxc-4.0.4の場合は、リンクに記されているようにパッチを当て、libxc-2.2.3→libxc-4.0.4、-lxcf90→-lxcf03と変更。
これで
make ARCH=OCTOPUS VERSION=popt
でビルドしてエラーが出なければ
make ARCH=OCTOPUS VERSION=popt test
を実行するとテストが実行され、すべて成功した！なお、ulimit -s unlimitedをつけておかないとかなりのテストが失敗する。このマシン、デフォルトのスタックサイズが異様に小さい。バッチジョブを投げるときも必要。
Number of FAILED tests 0
Number of WRONG tests 0
Number of CORRECT tests 3011
Number of NEW tests 0
Total number of tests 3011
なお、旧バージョンのCP2Kのリスタートファイルを流すときは、BASIS SET、POTENTIALの詳細情報を消さないと流れない。
また、libxc-3.0.1はコンパイルがうまくいかなかった。
Anacondaでpython3にしたらibus-setupがpythonのエラーを吐いて実行できなくなり、日本語入力ができなくなった。メニューバーのinput methodから行ってもpreferencesが起動せず。
/usr/bin/ibus-setup
の中にあるexec python→exec /usr/bin/pythonと変更したら解決した。
# fdisk -l
Disk /dev/sda: 10000.8 GB, 10000831348736 bytes
255 heads, 63 sectors/track, 1215865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000
Disk /dev/sdc: 10000.8 GB, 10000831348736 bytes
255 heads, 63 sectors/track, 1215865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000
10TBのディスクが二つ認識されていることが確認できた。パーティションを作成するが、fdiskでは2TBまでしかできないのでpartedを用いる。
# parted /dev/sda
(parted) mklabel gpt → Yes
(parted) unit GB
(parted) mkpart primary 0.0GB 10000.8GB
(parted) set 1 lvm on
(parted) print
(parted) quit
/dev/sdcに対しても同様に行う。
・物理ボリューム作成
# pvcreate /dev/sda1
# pvcreate /dev/sdc1
# pvscan
で物理ボリュームがきちんと作成されたか確認。
・ボリュームグループ作成
# vgcreate -s 512m VG01 /dev/sda1 /dev/sdc1
# vgdisplay -v VG01
で表示されるVG Sizeが最大容量なので確認しておく。
・論理ボリューム作成
# lvcreate -L 18.19TiB -n vol01 VG01
# lvscan
で論理ボリュームがきちんと作成されたか確認。
・フォーマット。mkfs.ext4は、どうやら16TBまでしかフォーマットできないらしいので、xfsを用いた。（mke2fsというものあるらしい）
# mkfs -t xfs -f /dev/VG01/vol01
・マウント。xfsフォーマットの場合、特にオプションをつけずにマウントできる。/etc/fstabにも追加しておく。
# mkdir /data
# mount /dev/VG01/vol01 /data
ずっとシステムのアップデートをしていなかったので、まずカーネルをアップデート。
/etc/yum.confの exclude=kernel* をコメントアウトし、
#yum update kernel
ちょっと緊張したが、無事再起動した。
ここで、リポジトリへのリンクが古かったので、更新。
自分の場合は/etc/yum.repos.d/にあるhome:dtufys.repoをリネームして排除する必要もあった。
アップデートと、必要なもののインストール。
#yum -y update
#yum upgrade
#yum install gcc*
#yum install freeglut
#yum install freeglut-devel
#yum install kernel-devel
中を開けた直後の状態。
HDDを増設し、GPUも交換した。GTX 1080 Tiを差し込む際、DVDドライブのSATAケーブルが干渉したので別の場所に移す。
電源から伸びていたPCI-E 8pinをまず差し込む。
あと8pin残っていたのはATX兼EPSケーブルであり、PCI-Eとしては使えなかったので、ペリフェラル4×2→PCI-E 6pin変換ケーブルを用いて6pinを埋めた。
蓋を閉めて起動。
この段階では、CentOSのバーが伸び切った段階で止まる。（startXがうまくいかない。）CUIでログインし、まず/etc/grub.confの末尾に以下を追加することで以前のドライバを無効にする。
nouveau.modeset=0
その後、最新のNVIDIAドライバをインストール。
# sh NVIDIA-Linux-x86_64-*****.run
いろいろと聞かれるが、Accept、yesで答える。
nvidia-smi
コマンドが有効になっていることを確認し、再起動すると、画面が出力された！！
次にCUDAをインストールする。
CUDA9.1は仮想環境を通したTensorFlowでは使えない（ソースコードからビルドすれば可だが、未トライ）ということだったので、まずはCUDA8.0とcuDNN6.0の組み合わせ。run fileからインストールした。
#yum install cuda
では、なぜかjre>=1.7.0を満たしていない(java -versionでは1.7になるにも関わらず)と言われてインストールできなかった。
その後PythonでTensorFlowをimportする。
1.0.0はそのまま（ただしcuDNN5.1）でも動いたが、1.4.0をimportしようとすると高位のglibc、gccが必要だと言われるので、個別に導入した。
glibc-2.17
検索するとCentOS7用のglibcを入れるケースが多かったが、CentOS6用のglibc2.17があったので、これをインストール。
gcc-4.8.4
すでに多くの方々がトライされているように、gccをソースコードからビルドしてlibstdc++.so.6のシンボリックリンクを貼り替える。
これでTensorFlowGPU-1.4.0が動いた。
2017年1月1日にうるう秒が実施された後、qpiddが50%くらいCPUを食うようになった。
ルートで
$ date -s “`LANG=C date`”
とすると負荷がなくなった。
qpidが何をしているのかはあまりよくわかっていないが、ソフトウェア間のデータ通信をしているらしい。