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でモンテカルロを計算しなければよいのですね。