2014년 분자동역학 분야 계산가속기 이식성 및 성능테스트 ......기술 보고서 2014년 분자동역학 분야 계산가속기 이식성 및 성능테스트 보고서

기술 보고서

2014년 분자동역학 분야 계산가속기

이식성 및 성능테스트 보고서

2014.11

슈퍼컴퓨팅사용자지원실

목 차

개요 및 목록 ······················································································································1

1. AMBER ································································································································2

2. GROMACS ····························································································································17

3. LAMMPS ·························································································································61

- 1 -

2014년도 분자동역학 분야 계산가속기 이식성 및 성능테스트 보고서◦ 개요

∙ 슈퍼컴퓨터 4호기에서 빈번하게 사용되는 분자동역한 분야 응용코드인

AMBER, GROMACS, LAMMPS에 대해서 계산가속기 기반의 초고성능시스템

에서 설치방법, 이식성 및 성능테스트를 수행

순

위

프로그램

명분야 비고 가속기 지원 테스트

3 AMBER 분야동역학 상용NVIDIA GPU/Xeon Phi 지원

(GPU: CUDA, Xeon Phi: 14버전부터 Offload지원)

4GROMA

CS분야동역학

오픈

소스

NVIDIA GPU/Xeon Phi 지원

(GPU:CUDA, Xeon Phi: 5.0-rc1버전부터 Native지원)

5 LAMMPS 분야동역학오픈

소스

NVIDIA GPU/Xeon Phi 지원

(GPU:CUDA, Xeon Phi: 15 Aug. 2014버전부터

Offload)

∙ 55.734Tflops 급의 가속기 기반 계산환경 테스트베드에서 테스트: Intel Xeon Phi

7120p 18개(1.238Tflops/1ea*18ea=22.28Tflops)와 Tesla K40m 15개(1.43

Tflops/1ea*15ea=21.45Tflops)

구분 사양제조사/시스템명 IBM Nextscale nx360M4

노드수 30구분 프로세서 가속기

모델명 Intel Xeon E5-2670 v2 Intel Xeon Phi 7120PNVIDIA Tesla

K40m클럭(GHz) 2.5 1.238 1.43

CPU

Core수

(개)

소켓 당 10 61 2,880노드 당 20 61 2,880

전체 600

이론성능

(GFlops)

노드 당 400 1,208(15노드) 1,430(15노드)

시스템 전체 12,000

22,284(3노드는

카드2개, 12노드는

카드1개)

21,450

55,734노드 당 소켓/가속기

수 (개)2 1 1

메모리DDR3 1,866MHz 128GB

(16GBx8ea)

GDDR5 5.5GHz

16GBGDDR5 12GB

내장디스크 SSD 256GB x 1eaInterconnection

네트워크IB 4x FDR(56Gbps)

기반 계산환경 테스트베드 사양

- 2 -

1. AMBER

∙ 개요

- 1970년대 말부터 만들어진 분자동력학 시뮬레이션을 위한 상용 소프트웨어 패

키지. 처음에는 AMBER(Assisted Model Building with Energy Refinement)를

수행하기 위해 시작된 프로젝트

- 현재는 계산화학을 수행하기 위한 많은 도구들을 포함하고. 특히 단백질, 핵산

(nucleic acids), 탄수화물에 대한 자유 에너지 및 분자동역학 계산에 사용

- 병렬계산시 PMEMD 모듈이 활용되며 CPU로 MPI 수행시 일반적으로 16개

프로세서까지 좋은 병렬확장성을 보여줌

- NVIDIA GPU는 PMEMD 모듈(explicit solvent PME와 implicit solvent GB)

에 대해서 CUDA로 포팅(pmemd.cuda)되어 있으며 계산시 CPU는 활용하지

않고 GPU만 이용함 (CPU와 PCI-express는 입출력시에만 사용됨, 저사양의

CPU에서 GPU카드만으로 성능향상이 가능함)

- Xeon Phi 지원은 PMEMD 모듈에 대해서 14버전(2014년 8월 6일)부터 Native와

Offload 방식제공

※ 본 테스트는 라이센스 문제로 Amber 12버전에 대해서 NVIDIA GPU만 수행

∙ 수행 내용

- NVIDIA GPU 벤치마크 수행 시스템 (Amber 12버전)

* 단백질 접힘 시뮬레이션 (villin headpiece (HP-36), 원자 20,677개)

* 단백질-단백질 상호작용 시뮬레이션 (Barnase-Barstar 상호작용, 원자

151,992개, 145,170개, 175,404개, 161,841개)

- 단백질 접힘 시뮬레이션 (HP-36 단백질 접힘)

* 단백질 접힘은 아미노산 서열로 되어있는 폴리펩타이드가 특정한 기능을

가지는 삼차원 구조로 접히는 과정

단백질 접힘 (HP-36)

- 3 -

* 단백질 접힘과정을 연구하는데에 중요한 세가지 문제

․첫째 아미노산 서열인 일차구조에서 단백질의 삼차구조로 접히게 하는 원

동력

․둘째 아미노산 서열로 이루어진 일차구조가 삼차구조로 접히는 folding

time이 빠른 이유

․마지막으로 아미노산 서열이 주어지면 삼차원 단백질 구조를 예측할 수

있는가

* 최근 컴퓨터 기술의 발전과 분자동력학 모의실험 방법의 획기적인 진보가

이루어지면서 단백질 접힘 문제는 이론적 계산화학적 연구방법을 통해 많

은 진보

* 해당 계산은 villin headpiece (HP-36)라는 단백질에 대해 단백질 접힘 과

정에 대한 분자동력학 모의실험

* HP-36 단백질은 크기가 비교적 작고, folding time 이 매우 빠르며 helix

세개로 이루어진 단순한 구도를 갖기 때문에 단백질 접힘 연구에 아주 좋

은 대상 단백질

- 단백질-단백질 상호작용 시뮬레이션 (Barnase-Barstar 상호작용)

* 단백질-단백질 상호작용은 현대 분자생물학에서 세포의 신호전달에 의한

생노병사를 이해하는데 가장 기본이 되는 현상

* 단백질 상호작용이 일어나면서 수반되는 상호작용의 원동력, 상호작용 메

커니즘, 상호작용의 구조적 특이성 (specificity) 등에 대한 이해는 세포의

기능을 이해하고 조절하는데 필수적

* 세포의 기능이상으로 야기되는 여러 가지 질병을 이해하고 세포의 기능을

조절하기 위한 신약을 개발하는 데에 있어서도 단백질 상호작용에 대한 이

해는 필수적

단백질-단백질 상호작용 시뮬레이션

- 4 -

* 해당 계산은 단백질 상호작용 연구에 가장 많이 연구되어 온 시스템 중

하나인 barnase-barstar 단백질 상호작용에 대해 분자동력학 모의실험을

수행

* barnase-barstar 단백질 시스템은 실험적 방법으로도 가장 많이 연구된 시

스템 중 하나인데, 단백질이 서로 상호작용하며 complex를 이루는 과정 동

안 그 구조가 비교적 안정하고, 그 크기가 비교적 작아 많은 실험적, 계산

적 연구결과가 보고되고 있음

* 그럼에도 불구하고 아직 이 단백질 상호작용 과정에 대해 그 원동력과 구

조적 특이성 등에 대한 원자 수준의 연구는 보고되어 있지 않음

∙ 설치 및 실행 방법

- MPI를 활용한 CPU 버전

* AMBERHOME 환경변수를 소스를 푼 위치로 설정

* PMEMD의 MPI버전(pmemd.mpi)을 Intel 컴파일러로 설치하기 위해서 다

음 명령어를 통해서 컴파일

./configure –oX11 –pi intelmake install

- GPU 버전

* CUDA_HOME을 CUDA(5.0이상 필요)가 설치된 디렉토리로 설정

* PMEMD의 CUDA버전(pmemd.cuda)을 설치하기 위해서 다음 명령어를 통

해서 컴파일

./configure –oX11 –uda intelmake install

- ECC 설정 및 GPU 카드 클락 설정

* ECC (Error Correcting Code) 설정은 기본적으로 켜져 있는데, GPU 실행

시 특히 AMBER 성능에 영향을 미치는 것으로 알려져있음

* K40카드는 온도 관련해서 문제가 없으면 클락(Clock) 향상에 대해서 허용

하고 있음

nvidia-smi – <device number> --ecc-config=0nvidia-smi – <device number> -ac 3004,875

- 5 -

∙ 결과

- NVIDIA GPU 테스트

테스트에 대한 Labeling

K40

(ECC off)

K40

(ECC on)

CPU(1node: 20

cores)

CPU(4nodes: 80

cores)

CPU(6nodes: 120

cores)

HP-36 단백질접힘 83.1 70.2 20.4 50.5 54.7

상호작용

(151,992개)9.8 8.1 1.8 6.9 9.3

상호작용

(145,170개)10.2 8.3 2.2 7.0 9.7

상호작용

(175,404개)8.7 7.2 1.5 5.7 8.1

상호작용

(161,841개)8.9 7.5 1.9 6.5 8.7

NVIDIA GPU와 CPU의 AMBER 테스트 결과 (단위: ns/day 높을수록 좋음)

* 단백질 접힘의 경우에 NVIDIA Tesla K40에서 ECC를 켜는 경우(기본 설

정)는 카드 한 장이 120 CPU cores 대비 1.22배, 끄는 경우는 120 CPU

cores 대비 1.34배 성능 향상을 보여줌

* 단백질-단백질 상호작용인 경우에 ECC를 켜는 경우(기본 설정)는 카드 한

장이 100 CPU cores 정도, ECC를 끄는 경우는 120 코어를 약간 상위하는

수준을 보여줌

※ NVIDIA 보고서에 따르면 PME 계산(Cellulose production NPT benchmark)

은 멀티노드에서 병렬확장성은 좋지 않으며, GB 계산(nucleosome test)은 8노

드까지 병렬확장성을 보여줌

- 6 -

* 단백질 접힘 시뮬레이션 (HP-36 단백질 접힘)

단백질 접힘 시뮬레이션 결과

* 단백질-단백질 상호작용 시뮬레이션 (Barnase-Barstar 상호작용)

모사에 사용된 barnase-bastar

단백질의 초기 구조

- 7 -

․각 시뮬레이선 시스템의 총 원자수는 초기 Barstar 위치/방향에 따라 다름

․단백질과 box edge사이에 적어도 15 Å water buffer가 존재하기 때문에

시뮬레이션 box 크기가 결정됨

Type1 초기 조건인 경우 원자의 수

단백질-단백질 상호작용 시뮬레이션 (Barnase-Barstar 상호작용: type1)


- 8 -



- 9 -

<부록1-1: AMBER14에 대해서 NVIDIA에서 직접 수행한 벤치마크>

※AMBER14에 대해서 NVIDIA사에서 직접 수행한 내용으로 Benchmark Suite은 다음

URL에서 다운받을 수 있음

http://ambermd.org/gpus/Amber14_GPU_Benchmark_Suite.tar.bz2

※벤치마크는 far-field 계산(long range interaction)을 위한 PME method를 사용하였으

며, Cellulose production을 모델화 하였음

∙ 벤치마크 수행 방법

- AMBER14 benchmark suite를 다운받아 압축을 품

- 해당 디렉토리로 이동

cd PME/Cellulose_production_NPT - 시리얼 코드에 대해서 다음을 실행

$AMBERHOME/bin/pmemd.cuda –i mdin.GPU –O –o mdout -inf mdinfo -x mdcrd -r restrt - MPI 버전은 다음을 실행

mpirun –np 2 $AMBERHOME/bin/pmemd.cuda.MPI –i mdin.GPU –O –o mdout –inf mdinfo –x mdcrd –r restrt ※output 파일은 "-o <filename>"옵션을 통해서 설정가능

※성능 향상을 위해서 ECC는 끄고 클락(Clock)은 다음과 같이 제일 높게 설정해야

함

nvidia-smi –i <device number> -ac 3004,875 ※MPI실행시 최적의 성능을 위해서는 같은 노드내의 GPU카드간에

Peer-to-Peer(P2P) 지원과 같은 PCI-express root complex내에 장착되어야 함 필

요함 (GPU사이의 전송시 CPU를 거치지 않게 함)

- CUDA 6.0 툴킷내의 “p2pBandwidthLatencyTest” sample를 수행함으로서 P2P 지원

여부와 같은 PCI-express에 장착되어 있는지 판단 가능함

- MPI 실행시(mdout)에 "GPU PEER-TO-PEER INFO"와 "Peer to Peer Support:

ENABLED"에서 확인 가능

∙ 수행 환경

- 2 K40 GPUs

- Intel IvyBridge E5-2690 v2 @ 3.00GHz, dual socket, 10 CPU cores per socket

- FDR Infiniband

- 128GB of memory

- 10 -

∙ 성능 결과

※ECC는 끄고 실행하였으며 값은 “ns/day"로 나오며 높을수록 성능이 높음

# GPUs ns/day

1 8.70

2 12.82

단일 노드에서 테스트

# nodes ns/day

1 8.70

2 8.07

4 9.34

6 9.23

멀티 노드에서 테스트

- 멀티 노드(노드당 K40 카드 한장)에서 GPU 테스트시 4노드에서 성능 이점이 있음

- 노드당 K40 카드 두장인 경우에는 멀티 노드에서 병렬확장성이 없음

# nodes Total CPU Cores ns/day

1 20 1.30

2 40 2.27

4 80 3.38

15 300 4.26

CPU에서 멀티 노드에서 테스트

(CPU: dual-socket Ivy Bridge E5-2690 @

3.00GHz)

- CPU에서 15노드 사용하더라도 GPU카드 한 장보다 2배 느림

- 11 -

※ nucleosome 테스트 (GB method)

# nodes 1x K40 / node (ns/day) 2x K40 / node (ns/day)

1 4.04 7.72

2 6.46 11.38

4 11.53 17.71

6 14.93 23.97

8 18.10 28.30

12 24.39 33.36

멀티 노드에서 테스트

(nucleosome 테스트)

- 12 -

<부록1-2: AMBER14에 대해서 Intel에서 직접 수행한 벤치마크>

모델 버전 노드 성능향상

PME Cellulose

NPT

AMBER 14(현재 버

전)단일노드 2배 향상

PME Cellulose

NPT

AMBER 14

(2014.12.15버전)단일노드 2.2배 향상

PME Cellulose

NPT

AMBER 14

(2014.12.15버전)멀티노드

단일노드 대비 4노

드에서 2.8배 향상

※NVIDIA GPU

K40대비 3노드 사

용시 1.19배 향상

PME Tobacco

Virus

AMBER 14

(2014.12.15버전)단일노드 2.41배 향상

GB NucleosomeAMBER 14

(2014.12.15버전)단일노드 2.2배 향상

GB RubiscoAMBER 14

(2014.12.15버전)단일노드 5배 향상

* CPU 수행 대비 2배 향상 (Particle Mesh Ewald (PME) Cellulose NPT)

․버전: AMBER 14 (현재 출시된 버전)

․Particle Mesh Ewald (PME) Cellulose NPT

․사용모델: Offload 모델(CPU, Xeon Phi 둘다 사용), Double Precision

․결과: Xeon E5-2697-v2대비 최적화 CPU코드는 1.7배, Xeon Phi에서 Offload모드

로 2배 향상됨

- 13 -

* CPU 수행 대비 2배 향상 (Particle Mesh Ewald (PME) Cellulose NPT)

․버전: AMBER 14 (현재 출시되지 않은 2014년 12월 15일 예정 버전)


․사용모델: Offload 모델(CPU, Xeon Phi 둘다 사용), Double Precision

․결과: Xeon E5-2697-v2대비 최적화 CPU코드는 1.7배, Xeon Phi에서 Offload모드

로 2.2배 향상됨

- 14 -

* CPU 수행 대비 2.41배 향상 (Particle Mesh Ewald (PME) Tobacco Virus)


․Particle Mesh Ewald (PME) Tobacco Virus:

http://www.ks.uiuc.edu/Research/STMV/

․사용모델: Offload 모델(CPU:50%, Xeon Phi:50% 둘다 사용), Double Precision

․결과: Xeon E5-2697-v2대비 Xeon Phi에서 Offload모드로 2.41배 향상됨

※ NVIDIA K40 대비 1.07배 향상됨

- 15 -

* CPU 수행 대비 2.2배 향상 (Generalized Born (GB) Nucleosome)


․Generalized Born (GB) Nucleosome


․결과: Xeon E5-2697-v2대비 Xeon Phi에서 Offload모드로 2.2배 향상됨

* CPU 수행 대비 5배 향상 (Generalized Born (GB) Rubisco)


․Generalized Born (GB) Rubisco


․결과: Xeon E5-2697-v2대비 Xeon Phi에서 Offload모드로 5배 향상됨

- 16 -

* 단일 노드 수행 대비 4노드에서 Xeon Phi 사용시 2.8배 향상 (Particle Mesh

Ewald (PME) Cellulose NPT)




․결과: Xeon E5-2697-v2 단일 노드 대비 4노드에서 Xeon Phi 사용시 Offload모드

로 2.8배 향상됨

※ NVIDIA GPU K40대비 3노드 사용시 1.19배 향상

- 17 -

2. GROMACS

∙ 개요

- 수백에서 수백만 개의 원자들로 이루어진 시스템의 분자동역학 시뮬레이션을

수행하는 오픈소스 프로그램 패키지로 개별 원자 간의 뉴턴 방정식 풀이를 통

해 원자계의 시간 의존 궤적을 계산

- 단백질, 핵산, 지질 등의 생체 분자 시뮬레이션 뿐만 아니라 폴리머, 이오닉 액

체 등의 화학, 공업 부문 시뮬레이션에도 이용되고 있으며 빠른 속도와 편리한

인터페이스, 다양한 힘 파라미터 지원 등의 이유로 세계적으로 널리 이용되고

있는 분자동역학 패키지 중 하나

- GROMACS는 AMBER, CHARMM, NAMD, LAMMPS 등 다른 분자동역학

패키지들과 비교하여 빠른 계산 속도를 보이고, 다양한 힘 파라미터를 지원하

며, 계산에 편리한 인터페이스를 제공함

- 버전 4.6부터는 NVIDIA GPU를 지원하며, GPU는 GROMACS내에 핫스팟인

힘(Force)계산을 CPU는 PME와 나머지 계산부분을 수행 (힘계산과 PME는 상

호 독립적이고, 로드밸런싱에 대해서 수치로서 조절가능)

- 버전 5.0 rc1부터 Xeon Phi는 Native 지원(벡터화/FMA를 위한 수정)하며,

Offload 방식은 개발중

∙ GROMACS 소개

- GROMACS의 장점

* 타 패키지에 비해 우월한 속도

․ GROMACS는 다른 분자동역학 패키지들과 비교하여 2~10배의 빠른 계

산 속도

․ 알고리즘은 빠른 계산 속도를 위하여 정교하게 디자인되었으며, 내부

루프에 어셈블리 언어를 적용하여 계산속도를 한 단계 끌어올렸음

․ 특히 4.6버전이후부터는 GPU 코드에 최적화된 Verlet scheme을 도입하

여 이전의 버전보다도 더욱 향상된 GPU 지원 속도 제공

- 18 -

․ 약 25000개의 원자로 이루어진 시스템의 분자동역학 시뮬레이션 속도를

각각 GROMACS, Desmond, NAMD 패키지에서 실행한 동일 코어 수

CPU 계산 벤치마크 결과로 GROMACS 가 다른 시뮬레이션 패키지와

비교하여 코어 개수가 적을 시에는 2~3배, 많은 수의 코어에서는 10배

가까이 성능 향상

* 다양한 힘 파라미터 지원

․ GROMACS는 생체 시뮬레이션에 쓰이는 OPLS, AMBER, CHARMM,

GAFF(General Amber Force Field), GROMOS 파라미터를 모두 지원

․ 시뮬레이션 목적에 맞는 파라미터를 유연하게 선택할 수 있으며 여러

파라미터를 이용한 계산 결과 비교 또한 쉽게 수행 가능

* 편리한 인터페이스

․ 생체분자들은 펩타이드, 핵산과 같은 다양한 종류의 하부구조들의 결합

으로 이루어짐. 따라서 수천/수만 개의 원자 수와 그 원자들 각각의 복

잡한 결합구조를 가지고 있으므로 원활한 분자동역학 시뮬레이션을 위

해서는 복잡한 거대 분자의 토폴로지를 다룰 수 있는 적합한 유틸리티

와 인터페이스의 제공이 필수

․ PDB (Protein DataBank)와 연동하며 패키지 내부에 내장되어 있는 파

라미터를 이용해 간단한 몇 개의 명령어만으로 생체시스템의 토폴로지

구조파일을 만들어낼 수 있는 기능 제공

․ 시뮬레이션 완료 후 후처리(post-processing) 과정에서 유용하게 응용될

수 있는 수십개의 유틸리티를 내부적으로 제공해 줌으로써 상대적으로

빠른 데이터 후처리 가능

- GROMACS의 단점

* 퍼텐셜 선택의 자유도가 부족

․내부적으로 제공되는 화학 비결합 퍼텐셜은 Lennard-Jones (LJ) 퍼텐셜,

Buckingham 퍼텐셜 두 가지 뿐으로 수십가지의 퍼텐셜을 제공하는

LAMMPS와 같은 패키지에 비교하면 굉장히 제한적인 개수이며, 이외의

퍼텐셜은 tabulated potential과 같은 방법을 이용해 한정적으로 이용가

능. 이로인해 액체-바이오시스템이 아닌 다른 고체, 혹은 기체 시스템의

시뮬레이션에 있어서 GROMACS를 이용하는 데에는 어려움이 있음.

- Use Case: GROMACS를 이용한 ion specificity 연구

* 고전 전자기학에 따르면 유전체 매질 내부에 존재하는 이온간의 힘은 매

질의 유전상수와 이온의 전하량과만 연관

․예를 들어 수용액 내에 용해된 F-, Cl-, Br-, I- 이온은 다른 분자량을

가지지만 고전 전자기학 계산에서는 같은 전하량을 가진 같은 이온으로

취급

* 그러나 실제 실험에서는 같은 전하량을 가진 이온의 분자량이 달라지면

- 19 -

반응성이 바뀌는 현상이 보이며 German University의 Franz Hofmeister

가 이 현상을 최초로 발견

* Franz Hofmeister는 이온 용액에 용해된 양이온과 음이온의 종류를 각

각 바꾸어가며 egg-white lysozyme 단백질의 응고 수준을 측정했으며

이온 용액이 단백질 응고에 미치는 긍정적-부정적 영향에 따라 이온을

순서대로 배열

* 배열은 Hofmeister series로 불리며 전하량이 같은 이온들이 각각 다른

반응성을 보이는 현상을 ion specificity 라고 부름

* Franz Hofmeister 가 단백질 응고에서 관찰한 ion specifity는 최근들어

다양한 화학, 생물현상에서 관측되고 있음

* Hofmeister series의 특성을 따르는 대표적인 물리적 현상으로는 효소

발현, 단백질 안정, 단백질-단백질 반응, 단백질 결정화, 박테리아 성장 ,

아미노산과 설탕 분자들의 광회전 현상 등의 생물현상 뿐만 아니라 전

해질 현상, 제타 퍼텐셜, 액체상의 표면 장력, 거품 합일등 으로 다양한

거대분자 시스템-이온 사이의 생물, 화학적 반응을 조절하는데

Hofmeister 효과가 응용되고 있음

* 벌크 물 내에 이온 분자가 추가되면 이온 분자의 주변으로 물 분자의 수

소결합 네트워크가 변형됨. 이 수소결합 네트워크의 변형 개념을 따라서

고전적인 Hofmeister series에서 이온은 크게 Cl- 음이온을 기준으로 두

가지 종류로 분류됨

․Cl-의 왼쪽의 이온은 kosmotropes라 불리며 이온 주변에 강력한 수화층

을 형성하고 물 구조를 형성하며 단백질 분자를 안정화시키는

‘salting-out’현상을 보임

․반대로 Cl-의 오른쪽의 이온은 chaotropes라 불리며 이온 주변의 수화층

이 상대적으로 약하고 이온 주변의 물의 수소결합 구조를 파괴하며 단

백질 분자를 불안정화시키는 ‘salting-in’ 현상을 보임

* 고체 표면-물 분자, 기체-물 분자, 또는 기름과 같은 비극성 액체-물 분

자 등의 표면에서 Hofmeister 현상은 벌크 물에 비해 강화되는 동시에

- 20 -

고전 Hofmeister series로 설명되지 않는 다른 순서를 보임

* 다른 상의 물질과 물 분자가 만나는 접점 근처에서 물 분자는 벌크 물에

서 보이는 3차원 방향의 등방적 운동이 아닌 표면과의 상호작용을 통하

여 고유의 성질을 가지는 표면 수화층을 형성

* 표면수화층 근처에서의 이온의 성질은 이온-표면 간의 상호작용 뿐만

아니라 이온 수화층 - 표면 수화층간의 상호작용또한 고려해야 하므로

표면의 성질에 따라서 ion specifity가 다르게, 혹은 기존에 알려진

Hofmeister series와 완전히 반대의 순서를 보일 수 있음

․일례로 뮌헨 대학의 R. R. Netz 교수 연구진은 분자동역학 시뮬레이션과

Mesoscale 접근법을 이용하여 소수성 표면과 F-, Cl-, Br-, I- 사이의

ion specificity와 친수성 표면에서의 반응은 특정 조건에서 고전

Hofmeister series 와 정반대의 specifity를 보인다는 사실을 밝혀냈음

* 등방성을 가진 고체나 기체 표면 뿐만 아니라 표면이방성을 가진 단백질

과 같은 생체 분자와 이온같의 반응에 관한 연구 또한 풍부한 물리, 화

학, 생물학적 함의를 제공

* 폴리펩타이드구조를 가진 단백질은 크게 공통구조인 뼈대(backbone)와

펩타이드간의 특성을 강하게 지닌 곁사슬(side chain) 구조로 나뉘어지며

이 두 구조는 서로 다른 ion speficity를 가지고 있는 것이 알려져 있음

* 뼈대는 탄소원자가 주를 차지하며 뼈대 구조와 가장 강력한 반응성을 보

이는 음이온은 I-, SCN-, ClO4-와 같이 약한 수화층을 가지는

chaotropes들로 이 결과는 고전 Hofmeister series와 일치

- 21 -

* 뼈대는 단백질 구조에서 대부분을 차지하며 뼈대와 이온간의 ion

speficity가 기존의 Hofmeister series와 일치한다는 사실은 Franz

Hofmeister 의 단백질 응고 실험에서 보여준 ion specificity 를 분자적

관점에서 설명해 줌.

* 그러나 곁사슬 구조 중 전하를 띠는 아미노산 사슬은 뼈대와 비교하여

전혀 다른 이온 반응성을 보임. 이는 뼈대 구조의 안정성이 중요한 단백

질 안정화 실험에서는 기존의 Hofmeister series가 유용하지만 아미노산

사슬 간의 전기력이 중요한 일련의 현상에서는 계가 전혀 다른 ion

specificity를 보일 수 있음을 의미

* Hofmeister series 에 대한 기존의 연구가 열역학적, 통계역학적인 집단

이온군에 대한 연구가 주를 이루었던 것과 달리, 최근의 연구는 단일 거

대 생체분자 - 단일 이온 간의 상호작용을 분자 스케일 단위에서 접근하

고자 하는 시도가 이루어지고 있고 이에 따라 분자동역학 시뮬레이션이

연구를 위한 필수적인 툴

- NVIDIA GPU 구현

* 밑의 흐름도와 같이 전체 계산 중 non-bonded interaction에 대한 부분

을 GPU가 맡음으로써 계산속도의 개선

- 22 -

CPU 노드 한개만 사용했을 때 프로파일링

* CPU 1노드만을 사용했을 경우 7,959초 걸리던 계산이 가속기(GPU) 1개

를 추가했을 경우 1,798초로 짧아진다. 이로 인해 GPU 가속기를 사용하

면 전체적인 계산 성능이 4.4배 성능 개선

* 가속기가 전체 계산 중 non-bonded interaction을 계산할 때만 사용되므

로 (전체 1,798초 중 1,257초로 전체의 약 70% 수준) 노드 수와 가속기

수가 증가함에 따라 전체 성능이 크게 증가를 보이겠지만, 시스템의 종

류나 non-bonded interaction 계산 분량에 따라서 성능차이는 보일 것으

로 예상

* 부분적인 계산영역에 대해서만 GPU를 사용하여 가속화를 했기 때문에

전체 이론 성능에는 미치지 못 함

- 23 -

CPU 노드 한 개 + GPU 카드 한장을 사용했을 때 프로파일링

- 24 -


- NVIDIA GPU 설치 방법

* 1. CMake를 설치

4.6 버전 이후부터는 CMake를 이용한 빌드가 기본이자 유일한 방법이므

로 www.cmake.org 에서 다운로드 받아 설치. 기존에 CMake가 설치되

지 않으면 bootstrap 스크립트를 실행

$ ./bootstrap$ make$ make install

* 2. GROMACS 소스를 다운받아서 압축 해제

※ 현재 공식 5.0 버전은 GPU acceleration시 자잘한 버그, 계산속도 저하

등의 단점이 속속 보고되고 있으므로 버그가 고쳐진 후속버전을 기다리

거나 아직 출시되지 않았으면 4.6.x 버전을 다운로드 받는 것을 추천

※ 현재 4.6.x 버전은 multi GPU를 원활히 지원하고 GPU acceleration에

최적화 된 verlet scheme을 이용하여 빠른 속도의 계산이 가능

$ tar xfz gromacs-(version).tar.gz

* 3. PATH, LD_LIBRARY_PATH를 컴파일러에 맞게 재설정

※ gcc 4.4.7 + openmpi 1.8.1 로 설정. Intel mpi는 make시 에러 발생함

$ module purge$ export PATH=/usr/bin:/applic/test_only/mpi/cuda/openmpi-1.8.1/gcc-4.4.7/bin:$PATH

$ export LD_LIBRARY_PATH=/applic/test_only/mpi/openmpi-1.8.1/gcc-4.4.7/lib:$PATH

* 4. 빌드를 위한 cmake script를 준비

․ cmake 캐쉬를 저장할 수 있는 폴더를 하나 만들고 (여기서는

GROMACS 폴더 내에 exec라는 폴더를 생성) 내부에 빌드용 스크립트

gpu.sh를 생성

“gpu.sh”CMAKEDIR=/home01/pop09/cmake/binGROMACS_INSTALL_DIR=/home01/pop09/gromacs export CC=mpiccexport CXX=mpiCC ${CMAKEDIR}/cmake .. \

- 25 -

-DBUILD_SHARED_LIBS=OFF \ -DGMX_PREFER_STATIC_LIBS=ON \ -DGMX_BUILD_MDRUN_ONLY=ON \ -DGMX_FFT_LIBRARY=fftpack \ -DCMAKE_INSTALL_PREFIX=${GROMACS_INSTALL_DIR} \ -DGMX_MPI=ON \ -DGMX_OPENMP=ON \ -DGMX_GPU=ON \ -DGMX_XML=OFF

* 5. GROMACS를 빌드하고 설치

$ chmod +x gpu.sh$ ./gpu.sh$ make$ make install

* 6. 단일 노드에서 계산 수행 방법

(1) CPU 계산

예제) 20개의 프로세스를 1스레드로 CPU 실행

$ mpirun -np 20 -bind-to core ${path-to-binary}/mdrun_mpi -nb cpu

(2) GPU 계산

예제) 1개의 프로세스를 20스레드로 GPU 실행

$ OMP_NUM_THREADS=20 mpirun -np 1 -bind-to none ${path-to-binary}/mdrun_mpi -nb gpu

* 7. 멀티 노드에서 계산 수행 방법

(1) CPU 계산

예제) 120개의 프로세스를 6노드 1스레드로 CPU 실행한다.

$ OMP_NUM_THREADS=1 mpirun -np 120 -bind-to core ${path-to-binary}/mdrun_mpi -nb cpu

(2) GPU 계산

예제) 6개의 프로세스를 6노드 20스레드로 GPU 실행한다.

$ OMP_NUM_THREADS=20 mpirun -np 6 -bind-to none —map-by ppr:1:node ${path-to-binary}/mdrun_mpi -nb gpu

* 8. mdrun 옵션

-resethway: 시뮬레이션을 시작할때 GROMACS는 domain decomposition

- 26 -

을 조절하고 CPU-GPU, 혹은 CPU-MIC 사이의 워크로드를 조절. 이로

인해 초반 몇백, 혹은 몇천 스텝까지도 속도가 원래 퍼포먼스보다 느리

게 나타남. 실제 시뮬레이션은 충분히 길기 때문에 이런 초반의 속도저

하를 무시할 수 있지만 벤치마크 중에는 퍼포먼스 테스팅에 artifact를

부여할 수 있음. -resethway 옵션은 이런 artifact를 최소화 하고 더욱

신뢰도 있는 벤치마크 결과를 부여

-maxh <wall clock time>: 이 옵션은 시뮬레이션이 설정한 시간 이후에

자동 종료 시킴. 벤치마크 시뮬레이션은 긴 시간이 걸리는 시뮬레이션을

모두 수행할 필요가 없기 때문에 충분한 시간, 예를 들어서 5-10분 후

자동으로 종료시킬 필요가 있는데 이 옵션이 그 명령을 수행. 5분

=0.08333 에 대응한다. 시뮬레이션 시간이 설정 시간보다 짧을 경우에는

설정 시간은 무시

-noconfout : 모든 시뮬레이션이 끝난 후에는 .gro 파일 생성. 이 옵션은

벤치마킹 시뮬레이션에는 필요없는 .gro 파일이 생성되지 않도록 함

․GROMACS는 병렬실행시 MPI와 OpenMP 모두 지원하며 OpenMP 수행

시에 쓰레드 수 조정을 위해서 OMP_NUM_THREADS를 통해서 설정

하거나, mdrun 명령어 옵션에서 –ntomp를 통해서 설정이 가능함

- Intel Xeon Phi 설치 방법

* 1. CMake를 설치

․4.6 버전 이후부터는 CMake를 이용한 빌드가 기본이자 유일한 방법이므

로 www.cmake.org 에서 다운로드 받아 설치. 기존에 CMake가 설치되

지 않으면 bootstrap 스크립트를 실행

$ ./bootstrap$ make$ make install

* 2. GROMACS 소스를 다운받아서 압축을 해제

※ Intel MIC SIMD 지원은 5.0.x 버전부터 지원하기 때문에 5.0 이상의 버

전을 다운로드 필요. 현재 공식 5.0 버전은 자잘한 버그, 계산속도 저하

등의 단점이 속속 보고되고 있으므로 후속버전을 기다리거나 아직 출시

되지 않았으면 5.0 pre-release 버전을 다운로드 받는 것을 추천

․다운로드를 받은 뒤 압축을 해제

$ tar xfz gromacs-(version).tar.gz

* 3. 빌드를 위한 cmake script를 준비

․cmake 캐쉬를 저장할 수 있는 폴더를 생성후 (여기서는 gromacs폴더

- 27 -

내에 exec라는 폴더를 만들었다) 내부에 빌드용 스크립트를 작성. 설치

는 intel compiler + intel mpi 라이브러리를 이용

※ 현재 GROMACS는 MIC offload acceleration을 지원하지 않는다 (5.x

버전에서 지원 예정)

․symmetric mode로 실행하기 위해 일반적인 CPU host 설치와 MIC 설

치를 두번 수행해야 하고 이에 대응하는 cmake script를 두 개 작성 필

요. 여기에서는 CPU host용 설치파일을 intel.sh, MIC용 설치파일을

intel_mic.sh라고 명명

(1) intel.sh

module purgemodule add intel_cluster_studio-2013_beta CMAKEDIR=/home01/pop09/cmake/binGROMACS_INSTALL_DIR=/home01/pop09/gromacsMPICCDIR=/applic/compilers/intel/2013sp1/impi/4.1.3.048/intel64/bin

export CXX=mpiicpcexport CC=mpiicc ${CMAKEDIR}/cmake .. \ -DBUILD_SHARED_LIBS=OFF \ -DGMX_PREFER_STATIC_LIBS=ON \ -DGMX_BUILD_MDRUN_ONLY=ON \ -DGMX_FFT_LIBRARY=mkl \ -DCMAKE_INSTALL_PREFIX=${GROMACS_INSTALL_DIR} \ -DGMX_MPI=ON \ -DGMX_OPENMP=ON \ -DGMX_GPU=OFF \ -DGMX_XML=OFF \ -DCMAKE_C_COMPILER=${MPICCDIR}/mpiicc \ -DCMAKE_CXX_COMPILER=${MPICCDIR}/mpiicpc

(2) intel_mic.sh

module purgemodule add intel_cluster_studio-2013_beta

- 28 -

CMAKEDIR=/home01/pop09/cmake/binGROMACS_INSTALL_DIR=/home01/pop09/gromacs_micMPICCDIR=/applic/compilers/intel/2013sp1/impi/4.1.3.048/mic/bin

export CXX=mpiicpcexport CC=mpiicc ${CMAKEDIR}/cmake .. \ -DBUILD_SHARED_LIBS=OFF \ -DGMX_PREFER_STATIC_LIBS=ON \ -DGMX_BUILD_MDRUN_ONLY=ON \ -DGMX_FFT_LIBRARY=mkl \ -DCMAKE_INSTALL_PREFIX=${GROMACS_INSTALL_DIR} \ -DGMX_MPI=ON \ -DGMX_OPENMP=ON \ -DGMX_GPU=OFF \ -DGMX_XML=OFF \ -DCMAKE_C_COMPILER=${MPICCDIR}/mpiicc \ -DCMAKE_CXX_COMPILER=${MPICCDIR}/mpiicpc \ -DCMAKE_C_FLAGS=“-O3 -mmic -vec-report1” \ -DCMAKE_CXX_FLAGS= “-O3 -mmic -vec-report1”

․intel_mic.sh 파일은 intel.sh 파일과 비교하여

GROMACS_INSTALL_DIR, MPICCDIR이 바뀌었고 Intel MIC를 위한

-mmic 컴파일러 옵션을 C_FLAGS와 CXX_FLAGS에 추가하였음

․GMX_FFT_LIBRARY로 여기에서는 Intel MKL을 이용했으나 fftw를 이

용해도 유사한 계산속도 가능함. 다만 phi에서는 BUILD_OWN_FFTW

자동 설치 옵션을 사용할 수 없으므로 www.fftw.org 에서 직접 다운받

아서 설치해야 함

* 4. GROMACS를 빌드하고 설치

$ chmod +x intel.sh ; chmod +x intel_mic.sh$ ./intel.sh; ./intel_mic.sh$ make; make$ make install; make install

* 5. 설치 후에 MIC 라이브러리와 컴파일러 환경변수를 각각 .bashrc 와

- 29 -

.bash_profile 파일 끝에 추가

(1) .bashrc

if [ ̀ uname -m` = ‘x86_86’ ]thenmodule purgemodule add intel_cluster_studio-2013_betaelseexport PATH=${PATH}:/applic/compilers/intel/2013sp1/impi/4.1.3.048/mic/bin

export LD_LIBRARY_PATH=:/applic/compilers/intel/2013sp1/impi/4.1.3.048/mic/lib:/applic/compilers/intel/2013sp1/composer_xe_2013_sp1.2.144/compiler/lib/mic:/applic/compilers/intel/2013sp1/composer_xe_2013_sp1.2.144/mkl/lib/intel64/

fi

(2) .bash_profile

source /applic/compilers/intel/2013sp1/composerxe/mkl/bin/mklvars.sh mic

* 6. host only 실행 방법

예제) 20개의 프로세스를 1스레드로 host only 실행

$ mpirun -np 20 -host phi01 ${path-to-host-binary}/mdrun_mpi

* 7. Native MIC 실행 방법

(1) 실행 전에 MIC에 접근 가능하게 환경변수를 설정

$ export I_MPI_MIC=enable

(2) 예제) 4개의 프로세스를 30스레드로 MIC native로 실행

$ export OMP_NUM_THREADS=30$ mpirun -np 4 -host phi01-mic0 ${path-to-mic-binary}/mdrun_mpi

* 8. Symmetric host + MIC 실행 방법

(1) 6과 동일

(2) 예제) 4개의 프로세스를 30스레드 MIC native, 20개의 프로세스를 1스

레드로 host로 symmetric 실행

- 30 -

$ mpirun -np 4 -host phi01-mic0 ./mdrun_mic.sh : -np 20 -host phi01 ./mdrun.sh

두 스크립트 mdrun_mic.sh, mdrun.sh는 각각 다음과 같다.

-mdrun.sh export OMP_NUM_THREADS=1${path-to-host-binary}/mdrun_mpi-mdrun_mic.sh export OMP_NUM_THREADS=30${path-to-mic-binary}/mdrun_mpi

* 9. mdrun 옵션

NVIDIA GPU와 동일함

- 31 -

∙ 수행 내용

- NVIDIA GPU와 Xeon Phi(Native/Symmetric모델)에 대해서 다음 네 가지 시

스템을 이용하여 GROMACS 버전 5.0에 대해서 벤치마크 테스트 수행

* PMF(Potential of Mean Force) 중 하나의 구성(configuration) (11187개

원자)

․계산을 통하여 얻은 깁스 자유 에너지(Gibbs free energy)를 통해 이온

분자의 고체 표면에 대한 상대적인 선호도, 즉 ion specificity를 연구하

는 시뮬레이션을 수행

․umbrella sampling (US) 방법을 이용하여 reaction coordinate에 대한 깁

스 자유 에너지 값 얻음

* Lysozyme 단백질 (55778개 원자): 이온 수용액 내부에서 그 반응을 연

구하는 작업

* GKAI(Geobacillus Kaustophilus Arabinose Isomerase) 반응촉매단백질 효

소체 (332,879개 원자)

․Hexamer로 구성되어 있으며 계산 시스템은 단백질체와 전이금속 Mn2+,

물 분자, Na+ 이온으로 구성

․단백질을 구성하는 아미노산의 수는 2,958개, 원자수는 46,614개, 단백질

주변에는 95,388개의 물분자가 존재하며, 단백질 사이에는 6개의 Mn 이

온이, 단백질 주변에는 95개의 Na 이온이 존재

▸단백질 아미노산 수 : 2,958

▸단백질 원자 수 : 46,614

▸물 분자 수 : 95,388

▸물 원자 수 : 286,164

▸이온 수 : 101

▸총 원자 수 : 332,879

GAKI 구조

* 512000(512k)개의 물분자 (1536000개 원자)

- 32 -

∙ 결과

- CPU 테스트

환경

노드

GROMACS v5.0

CPU Host

GROMACS v5.0-rc1

CPU Host

1 1.686 2.899

2 2.565 4.561

6 5.512 12.884

8 6.952 16.839

12 10.169 22.413

※ GKAI에 대해서 테스트


PMF 단백질 GAKI 512k 물분자단일 노드

(Single-Node)

1.73배

향상1.86배 향상 1.84배 향상 2.15배 향상

멀티 노드

(Multi-Node)-

1.75배 향상@12

노드

1.58배 향상@12

노드

1.75배 향상@12

노드

※ 각 노드는 Host CPU의 경우 16프로세스 x 1쓰레드, GPU의 경우 1프로세스

x 20쓰레드로 수행

※ MPI 작업제출시 MPS 모드에서 단일 및 멀티노드에서 1.1배에서 1.4배까지

성능향상 기대(NVIDIA에서 virus capsid를 테스트한 자료 참고)

※ GROMACS v5.0-rc1는 GPU성능이 v4.6.6에 비해서 2배 이상 느림 (5.0버전

은 기능추가에 초점)

※ GROMACS 의 경우 -nb 옵션으로 GPU acceleration 뿐만 아니라 CPU-GPU

acceleration을 주는 것도 가능한데 GPU 결과와 크게 차이 나지 않음

* 단일 노드 테스트

․CPU acceleration, GPU acceleration 시뮬레이션을 단일 노드에서 수행

후 그 결과를 비교

․ PMF, 단백질, 512K 물문자 시뮬레이션 모두 GPU를 이용하였을 때 퍼

포먼스가 빨라지는 것을 확인할 수 있음. 특이할 만한 점으로 시뮬레이

션 셀의 크기가 증가할 수록 GPU-CPU 상대 퍼포먼스가 더 좋아지는

것을 볼 수 있다. PMF 시뮬레이션에서는 약 1.8배의 성능 향상이 있는

반면에 512k 물분자 시뮬레이션에서는 2.2배의 성능향상

- 33 -

* 멀티 노드 테스트

․CPU acceleration, GPU acceleration 시뮬레이션을 단일 노드에서 수행

후 그 결과를 비교

․두 시뮬레이션 모두 GPU가 CPU 에 비해 2배 정도의 성능 향상을 모든

노드 수에서 보임. 또한 CPU 시뮬레이션이 보이는 병렬확장성이 GPU

시뮬레이션에서 보장되는 것을 확인할 수 있음

․상대적으로 큰 시뮬레이션 사이즈를 가진 512k water 시뮬레이션의 경우

에 CPU, GPU 모두 병렬확장성이 잘 보장되는 것을 확인할 수 있음

노드에서의 NVIDIA GPU 성능 비교

(왼쪽: 단백질, 오른쪽: 512k 물분자)

․GAKI 시뮬레이션 결과

※ GROMACS v4.6.6의 경우 GPU를 사용했을 경우 뛰어난 성능을 보임

※ GROMACS v5.0의 경우 다수의 노드를 사용하여 GPU 사용한다면,

그 성능이 CPU만 사용했을 때보다 떨어짐

- 34 -

0

5

10

15

20

25

30

35

Performance

ns/day

1 2 4 6 8 12

Number of node

v4.6.6 CPU

v5.0 CPU

v4.6.6 CPU+GPU

V5.0 CPU+GPU

CPU & GPU 벤치마킹 결과

GROMACS 4.6.6버전과 5.0버전의 병렬확장성 비교

- 35 -

- Xeon Phi 테스트

PMF 단백질 GAKI 512k 물분자

단일노드

(Single-N

ode)

Native1.71배

성능감소 1.51배 성능감소 성능차이없음 1.29배 성능감소

Symme

tric

1.92배 성능감소 1.92배 성능감소 - 1.2배 성능향상

멀티노드

(Multi-No

de)

Native -

모든 경우

CPU보다

성능느림

(병렬확장성

없음)

모든 경우

CPU보다

성능느림

(병렬확장성

없음)

모든 경우

CPU보다

성능느림

(병렬확장성

없음)

Symme

tric-

모든 경우

CPU보다

성능느림

(2노드까지

병렬확장성

보장)

-

1노드 사용시만

CPU보다 성능

(4노드까지

병렬확장성

보장)

※ 각 노드는 Host CPU의 경우 16프로세스 x 1쓰레드, MIC의 경우 30프로세스

x 8쓰레드로 수행

※ MIC의 프로세스-쓰레드 배분은 512k 물분자 시뮬레이션을 1노드에서 프로세

스-쓰레드 배분을 변형시켜 가면서 가장 빠른 속도를 보여주는 배분치를 사용

* 단일 노드 테스트

․Host only, MIC only native mode, Host + 1 MIC symmetric mode 시

뮬레이션을 수행후 그 퍼포먼스를 비교

․모든 시스템에서 native mode 는 host only 보다 더 낮은 속도를 보임.

이는 MIC 의 낮은 메모리 등의 이유에서 기인한 것으로 보임.

Symmetric mode 는 특이한 경향을 보이는데, PMF 혹은 단백질 시뮬레

이션과 같은 작은 사이즈의 시뮬레이션에서는 native mode 보다도 느린

속도를 보이지만, 512k 물 분자 시뮬레이션과 같이 큰 사이즈의 시뮬레

이션에서는 가장 빠른 속도, Host only 보다 1.3 배 정도의 속도 향상을

보임

․작은 시뮬레이션 사이즈에서는 Host - MIC 간의 느린 통신 속도가 큰

알고리즘 bottleneck으로 작용하는 반면에, 거대 시뮬레이션, 즉 1개의

노드 - 16개의 코어에 domain decomposition을 적절히 분배해주기 어려

운 크기의 시뮬레이션 셀에서는 MIC 가 추가되면서 작아지는 domain

decomposition 크기에 의한 속도 향상 효과가 느린 Host - MIC 통신

속도에 의한 속도 저하를 뛰어넘어 전체적인 속도를 증가시키는 것으로

보임

- 36 -

* 단일 노드 + # MIC 시뮬레이션

․단백질, 512k 물분자 시뮬레이션을 Host only, Host + 1 MIC symmetric

mode, Host + 2 MIC symmetric mode에서 수행 후 그 퍼포먼스를 비

교

․단백질 시뮬레이션의 경우 1에서 설명한 것과 같이 symmetric mode 에

서 급격한 퍼포먼스 저하를 보임. 512k 물분자 시뮬레이션의 경우 2

MIC 에서는 Host only보다는 빠르지만 1 MIC 보다는 느려진 결과를

볼 수 있는데 이 역시 앞에서 설명한 것과 같이 1 MIC 와 달리 2 MIC

에서 domain decomposition 효과가 감소하는 것으로 판단. 더욱 큰 사

이즈의 시뮬레이션을 수행할 경우는 2 MIC 가 1 MIC 에 비해 성능의

향상을 볼 수 있을 것으로 기대

․Phi 테스트베드의 경우에 phi03, 04, 05 노드는 mic0, 1 두 개의 MIC 를

갖는다. Host + 2MIC 시뮬레이션을 같은 노드에 장착된 mic0, 1 과 각

기 다른 노드에 장착된 mic0, mic0으로 수행한 결과는 큰 차이를 보이

지 않음

- 37 -

* 멀티 노드 시뮬레이션

․단백질, 512k 물분자 시뮬레이션을 멀티 노드에서 Host only, native

mode, symmetric mode 에서 수행 후 그 퍼포먼스를 비교

․native, symmetric mode 의 경우 시뮬레이션의 셀 크기 한계로 인한

domain decomposition 개수 한계로 사용할 수 있는 노드의 한계가 12

개 보다 작은 경우가 있음

․단백질 시뮬레이션 결과는 Host mode가 scaling property를 보이는 반

면에 MIC가 추가되면서 scaling이 전혀 적용되지 않는 사실을 확인할

수 있음. Native 와 symmetric mode 를 비교하면 2 노드 이상에서

symmetric mode 가 native mode 를 역전하는 현상이 보이지만

symmetric mode 역시 4 노드에서는 속도가 오히려 감소하는 것을 확인

할 수 있음

․512k 물분자 시뮬레이션은 Host mode가 보이는 병렬확장성에 대해서

MIC가 추가되면서 사라지는 것을 볼 수 있음. 마찬가지로 native mode

는 노드 수가 증가하면서 퍼포먼스가 감소하며 symmetric mode 의 경

우는 4노드까지는 퍼포먼스가 미세하게나마 증가하나 그 이후에는 퍼포

먼스가 감소. MIC를 이용한 성능 향상은 1노드 + symmetic mode 에서

만 관측할 수 있음

노드에서의 Xeon Phi 성능 비교

(왼쪽: 단백질, 오른쪽: 512k 물분자)

- 38 -

․GAKI 시뮬레이션

환경

노드수

v4.6.6

CPU

v5.0

CPU

v5.0

Host

v5.0-rc1

Host

v4.6.6

CPU+GPU

v5.0

CPU+GPU

v5.0-rc1

Xeon Phi

1 2.171 2.211 1.686 2.899 9.611 5.345 2.897

2 3.997 4.083 2.565 4.561 11.449 4.451 2.205

6 10.436 10.520 5.512 12.884 20.364 7.596 0.899

8 13.525 13.280 6.952 16.839 25.023 9.561 0.467

12 18.630 18.444 10.169 22.413 29.509 12.962 0.465

0

5

10

15

20

25

Performance

ns/day

1 2 6 8 12

Number of node

v5.0 Host

v5.0-rc1 Host

v5.0-rc1 Xeon-phi

0

5

10

15

20

25

30

35Performance

ns/day

1 2 6 8 12

Number of node

v4.6.6 CPU

v5.0 CPU

v5.0 Host

v5.0-rc1Host

v4.6.6 CPU+GPU

v5.0 CPU+GPU

v5.0-rc1 Xeon Phi

- 39 -

<부록2-1: GROMACS NVIDIA GPU 튜닝>

* 상위레벨의 수준에서 보면 GROMACS는 다음과 같은 세가지 테스크(task)로 구

성되어 있음

- Force: 짧은 영역의 none-bonded forces에 대해서 계산 (계산 로드가 많음)

- PME: 긴 영역의 none-bonded forces의 긴 영역 부분에 대해서 계산 (멀티 노드

수행에서 계산 로드가 많음)

- 나머지: advance atom positions, handle bonded constraints 등

․Force는 GPU에서 수행하고, PME와 나머지는 CPU에서 수행

․Force와 PME는 독립적인 작업이며 동시에 수행됨. 나머지는 두 계산이 끝나고

나서 수행될 수 있음

․cutoff를 조절함으로서 CPU에서 GPU로 일에 대한 로드밸런싱을 조정할 수 있음

(자동으로 기능은 켜져 있으며, –notunepme 코맨드 라인 스위치를 통해서 끌수

있음)

․위의 그림처럼 GPU가 빨리 수행된 경우에 CPU에서 GPU로 일을 다음 그림과

같이 조정함

* 실행 설정

․GROMACS는 병렬실행시 MPI와 OpenMP 모두 지원하며 OpenMP 수행시에 쓰

레드 수 조정을 위해서 OMP_NUM_THREADS를 통해서 설정하거나, mdrun 명

령어 옵션에서 –ntomp를 통해서 설정이 가능함

* PME 노드 설정

․PME에서 none bonded interactions을 다루는것은 통신에 부하가 많음. Force와

PME에 대한 태스크는 독립적이므로, PME 노드수를 독립적으로 조정하게 해서

네트워크 통신 부하를 줄이는 것이 가능함

․기본적으로 PME 노드수는 자동적으로 결정되지만 -npme 파라메터를 통해서 조

절이 가능

- 40 -

․GPU 가속시 PME 노드들은 PP 노드들과 교차 실행이 가능함 (PP노드는 Force

태스크를 실행하는 노드)

* 쓰레드/프로세스 pinning

․쓰레드/프로세스에 대해서 각 코어에 대해서 pinning이 되면 성능향상에 도움이

될 수 있음

․각 mpi라이브러리에서 실행시 pinning을 조절가능하며 mdrun의 -pin 옵션을 통

해서도 동작시킬 수 있음

* SMT/Hyperthreading

․CPU의 하이퍼쓰레딩 기능이 성능 향상에 도움이 될 수 있음

* GPUBoost

․GPU 카드의 응용프로그램 클락(Clock)을 향상시키면 성능향상이 됨

* MPS

․한 노드내에서 하나의 GPU카드로 MPI 실행시 MPS 동작시 실행향상이 됨

․현재 한 노드내에서 멀티 GPU카드에 대해서 MPS를 지원하지 않지만 다음 URL

과 같은 트릭으로 사용은 가능함

http://cudamusing.blogspot.de/2013/07/enabling-cuda-multi-process-service-mps.ht

ml

- 41 -

<부록2-2: GROMACS에 대해서 NVIDIA에서 직접 수행한 벤치마크>

* CRESTA Benchmarks으로부터 virus_capsid를 수행: 1.19M 원자의 virus capsid

시스템

※ Benchmarks from the CRESTA Project: ftp://ftp.gromacs.org/pub/CRESTA

* hydrogens에 대해서 virtual interaction sites와 PME electrostatics에 대해서 4fs 타

입 스텝을 사용

※ 다음 테스트베드에서 테스트

․Dual socket Ivy Bridge CPUs (Intel Xeon E5-2690 v2 @ 3.00GHz - Hyper

threading disabled)

․각 노드마다 K40 카드 한 장 혹은 두 장 장착

* 설치 순서

1. Setup environment: $ source <GROMACS-Install-Dir>/bin/GMXRC.bash

2. Enable GPU-Boost on all GPUs (example for OpenMPI): $ mpirun -npernode 1 -np <num-nodes> nvidia-smi -ac 3004,875 This should produce a output like Applications clocks set to "(MEM 3004, SM 875)" for GPU 0000:04:0

0.0 […] All done. Remark: The –npernode 1 option is important to start only one ins

tance of nvidia-smi per node.

3. Download and extract the CRESTA Benchmark $ wget ftp://ftp.gromacs.org/pub/CRESTA/CRESTA_Gromacs_benchmark

s_v2.tgz $ tar –xzvf CRESTA_Gromacs_benchmarks_v2.tgz

4. Prepare the input (run grompp) $ cd CRESTA_Gromacs_benchmarks_v2/virus_capsid.bench $ mpirun –np 1 grompp_mpi –f grompp.mdp

* 단일 노드 벤치마크

․단일 노드에서 CUP만 벤치마크 수행시 다음 명령어 수행

$ mpirun -np 20 -bind-to core mdrun_mpi -maxh 0.08333 -resethway -noconfout -v -testverlet -s topol.tpr -nb cpu

- 42 -

․단일 노드에서 CUP+1GPU 벤치마크 수행시 다음 명령어 수행

$ OMP_NUM_THREADS=20 mpirun -np 1 -bind-to none mdrun_mpi -maxh 0.08333 -resethway -noconfout -v -testverlet -s topol.tpr -nb gpu

․단일 노드에서 CUP+2GPUs 벤치마크 수행시 다음 명령어 수행

$ OMP_NUM_THREADS=10 mpirun -np 2 -bind-to socket mdrun_mpi -maxh 0.08333 -resethway -noconfout -v -testverlet -s topol.tpr -nb gpu

* 멀티 노드 벤치마크

․6개 노드에서 CPU만 테스트시 다음 명령어 수행

$ OMP_NUM_THREADS=1 mpirun -np 120 -bind-to core mdrun_mpi -maxh 0.08333 -resethway -noconfout -v -testverlet -s topol.tpr -nb cpu

․15개 노드에서 CPU만 테스트시 다음 명령어 수행

$ OMP_NUM_THREADS=1 mpirun -np 300 -bind-to core mdrun_mpi -maxh 0.08333 -resethway -noconfout -v -testverlet -s topol.tpr -nb cpu

․6개 노드에서 각 노드별 CPU+1GPU 수행시 다음 명령어 수행

$ OMP_NUM_THREADS=20 mpirun -np 6 -bind-to none –npernode 1 mdrun_mpi -maxh 0.08333 -resethway -noconfout -v -testverlet -s topol.tpr -nb gpu

․15개 노드에서 각 노드별 CPU+1GPU 수행시 다음 명령어 수행

$ OMP_NUM_THREADS=20 mpirun -np 15 -bind-to none -npernode 1 mdrun_mpi -maxh 0.08333 -resethway -noconfout -v -testverlet -s topol.tpr -nb gpu

․6개 노드에서 각 노드별 CPU+2GPUs 수행시 다음 명령어 수행

$ OMP_NUM_THREADS=10 mpirun -np 12 -bind-to socket –npersocket 1 mdrun_mpi -maxh 0.08333 -resethway -noconfout -v -testverlet -s topol.tpr -nb gpu

․15개 노드에서 각 노드별 CPU+2GPUs 수행시 다음 명령어 수행

$ OMP_NUM_THREADS=10 mpirun -np 30 -bind-to socket –npersocket 1 mdrun_mpi -maxh 0.08333 -resethway -noconfout -v -testverlet -s topol.tpr –npme 0 -nb gpu

- 43 -

* 테스트 결과

PERFORMANCE 1

NODE (NS/DAY)

PERFORMANCE 6

NODES (NS/DAY)

PERFORMANCE 15

NODES (NS/DAY)

CPU ONLY 1.608 8.203 18.439

CPU + 1 GPU 3.889 14.173 24.740

CPU + 2 GPUS 5.166 19.845 33.092

CPU + 1 GPU

with MPS4.432 18.709 35.841

CPU + 2 GPUS

with MPS5.767 22.440 37.192

* CRESTA Benchmarks 수행 방법

※ Benchmarks from the CRESTA Project: ftp://ftp.gromacs.org/pub/CRESTA

1. Set GMX_MPIRUN to contain the MPI launcher command including command

line arguments. 예) to run on a 8 node cluster and start 2 processes per node

with OpenMPI do

$ export GMX_MPIRUN="mpirun -np 16 -npernode 2"

2. Set OMP_NUM_THREADS to number of cores available per process. 예)

given a dual socket node with dual 10 core CPUs and 2 GPUs and 2 MPI

ranks per node

$ export OMP_NUM_THREADS=10 #10 core available per processes

3. Add “-testverlet” to mdrun_extra_params (line 78 of gmxbench.sh), 예)

mdrun_extra_params="-testverlet" ※ GPU 가속시 필요한 cut-off을 동작시키기 위해 필요함

4. 수행 시작

$ ./gmxbench.sh -m -b ̀ which mdrun_mpi`

- 44 -

<부록2-3: GROMACS에 대해서 Intel에서 직접 수행한 벤치마크>

* CPU 수행 대비 2배 향상 (512K H2O with RF, Symmetric)

․버전: GROMACS 5.0-RC1

․GROMACS* 512K H2O

․사용모델: Native, Symmetric

․결과: Xeon E5-2697-v2대비 Xeon Phi 2장에서 Symmetric모드로 1.79배 향상됨

- 45 -

<부록2-4: GROMACS Protein 테스트 방법>

※ GROMACS가 5.0버전으로 업데이트 되면서 몇몇 유틸리티가 4.6.x 버전과 이름

이 바뀌었음. 5.0 버전을 기준으로 작성됨

※ 단백질은 수 개 혹은 수십 개 이상의 아미노산의 연결로 이루어진 거대 생체분

자. 수천 개 이상의 원자들이 복잡한 구조로 결합 퍼텐셜, 각도 퍼텐셜, 이면 각

퍼텐셜, 1-4 LJ 퍼텐셜에 의해 연결되어 있는 단백질 분자를 일일이 모델링 하

기에는 어려움이 있기 때문에 시뮬레이션의 편의를 위해 특별히 준비된 유틸리

티가 필요함

※ GROMACS는 Protein Data Bank(PDB) 와 결합하여 단백질 분자를 손쉽게 모

델링할 수 있는 툴을 제공함. 본 시뮬레이션에서는 이온 수용액에 용해된

lysozyme 단백질 시뮬레이션을 수행하고 ion-protein 상호작용을 분석함

* 1. Protein Data Bank(PDB)를 통하여 lysozyme 구조 파일을 다운로드

※Protein Data Bank(PDB)는 단백질, 핵산과 같은 거대 생체분자의 3D 구조를 저

장해 놓은 인터넷 저장소. x-ray, NMR 분광학등을 이용해 생체 분자의 구조를

밝히고 3차원 좌표 파일을 PDB, PDBML(XML) 포맷을 가진 파일로

www.pdb.org 홈페이지에 저장해 놓았으며 얼마든지 무료로 열람이 가능.

․PDB에서 2LYM id를 가진 hen egg-white lysozyme 단백질 pdb 파일을 다운로

드

※(주의) 본 시뮬레이션에는 해당하지 않지만 간혹 특정 생체분자의 PDB 파일 내

부에는 생체분자의 크리스탈 구조에 포함되지 않는 다른 분자들이 포함되는 경

우가 있음. 이는 실험 상의 한계 때문으로 이 분자들은 PDB 파일 설명에 포함

되어 있으므로 꼼꼼히 확인하고 제거할 필요가 있을 때에는 파일 가공 전에 제

거해야 함

예) 1J4N id aquaporin-1 막 단백질의 경우에 PDB 파일 내부에 단백질 분자와는

상관없이 B-NONLYGLUCOSIDE 리간드가 포함되어 있음. 따라서 시뮬레이션

전에 다음과 같이 제거

$ grep -v BNG 1J4N.pdb > 1j4n.pdb위의 명령어는 BNG residue를 가진 원자들을 모두 제거하고 결과를 1j4n.pdb 로

내보냄

* 2. pdb2gmx 유틸리티를 이용해서 목적에 맞게 pdb 파일을 가공

․토폴로지 파일을 pdb2gmx 유틸리티를 이용해서 생성

$ gmx pdb2gmx -f 2LYM.pdb -o 2LYM_processed.gro -water spce․유틸리티를 실행하면 다음과 같은 선택창을 볼 수 있음

Select the Force Field:From '/gfs/karys/gromacs/share/gromacs/top':

- 46 -

1: AMBER03 protein, nucleic AMBER94 (Duan et al., J. Comp. Chem. 24, 1999-2012, 2003)

2: AMBER94 force field (Cornell et al., JACS 117, 5179-5197, 1995)

3: AMBER96 protein, nucleic AMBER94 (Kollman et al., Acc. Chem. Res. 29, 461-469, 1996)

4: AMBER99 protein, nucleic AMBER94 (Wang et al., J. Comp. Chem. 21, 1049-1074, 2000)

5: AMBER99SB protein, nucleic AMBER94 (Hornak et al., Proteins 65, 712-725, 2006)

6: AMBER99SB-ILDN protein, nucleic AMBER94 (Lindorff-Larsen et al., Proteins 78, 1950-58, 2010)

7: AMBERGS force field (Garcia & Sanbonmatsu, PNAS 99, 2782-2787, 2002)

8: CHARMM27 all-atom force field (with CMAP) - version 2.0 9: GROMOS96 43a1 force field10: GROMOS96 43a2 force field (improved alkane dihedrals)11: GROMOS96 45a3 force field (Schuler JCC 2001 22 1205)12: GROMOS96 53a5 force field (JCC 2004 vol 25 pag 1656)13: GROMOS96 53a6 force field (JCC 2004 vol 25 pag 1656)14: GROMOS96 54a7 force field (Eur. Biophys. J. (2011), 40,, 843-8

56, DOI: 10.1007/s00249-011-0700-9)15: OPLS-AA/L all-atom force field (2001 aminoacid dihedrals)16: [DEPRECATED] Encad all-atom force field, using full solvent c

harges17: [DEPRECATED] Encad all-atom force field, using scaled-down va

cuum charges18: [DEPRECATED] Gromacs force field (see manual)19: [DEPRECATED] Gromacs force field with hydrogens for NMR

․GROMACS가 내부에서 지원하는 힘 파라미터가 나열됨. 생체 분자 시뮬레이션에

서 자주 이용되는 AMBER, CHARMM, GROMOS, OPLS 등의 힘 파라미터들이

지원되며 간단히 숫자를 선택하는 것 만으로 힘 파라미터를 적용할 수 있음. 여

기에서는 8을 선택해서 CHARMM 힘 파라미터를 선택

․pdb2gmx 유틸리티 통하여 토폴로지 파일(topol.top), 위치 고정 파라미터 파일

(posre.itp), 후처리 좌표 파일(2LYM_processed.gro) 총 세 개의 파일이 생성

- 47 -

* 3. 시뮬레이션 셀 설정

․2LYM_processed.gro 좌표 파일의 셀 크기는 7.917x7.917x3.796(nm)로 periodic

image 간에 상호작용이 존재. editconf 유틸리티를 이용하여 셀 크기를 시뮬레이

션에 적절하게 크게 설정

$ gmx editconf -f 2LYM_processed.gro -o 2LYM_newbox.gro -c -d 1.5 -bt cubic

․-c 옵션은 단백질을 셀의 중간에 위치

․-d 1.5 옵션은 단백질 분자와 셀의 거리를 1.5nm 만큼 유지시키는 셀의 위치를

설정. -d 옵션에 따라 단백질 분자는 periodic image 와 최소 3nm 의 거리를 가

지며 이 거리는 periodic image 간의 반 데르 발스 상호작용을 완전히 차단하는

거리.

․-bt cubic 옵션은 셀의 모양을 정육면체 모양

․ 2LYM_newbox.gro의 셀의 크기가 8.262x8.262x8.262nm로 커진 걸 확인 가능

(구형 단백질의 경우 -bt dodecahedron 혹은 octahedron 옵션을 주어서 셀의 크

기를 줄여 계산속도 증가 가능)

* 4. 물 속에 단백질을 용해

$ gmx solvate -cp 2LYM_newbox.gro -cs spc216.gro -o 2LYM_solv.gro -p topol.top

․여기에서 물 모델로 SPC/E 모델을 이용. SPC/E 말고도 물 계산에 대중적으로

쓰이는 모델들은 SPC, TIP3P, TIP4P, TIP5P 등이 있으며 GROMACS에서는 이

다섯 모델 모두를 포함한 다양한 모델들을 지원하며 상황에 맞게 유동적으로 활

용할 수 있음. SPC, SPC/E, TIP3P 모델은 3-site 모델이므로 -cs spc216.gro 옵

션으로 생성 가능하지만 4-site 모델인 TIP4P나 5-site 모델인 TIP5P의 경우에

는 각각 -cs tip4p.gro 혹은 -cs tip5p.gro 옵션을 주어야 함. 또한 물 뿐만 아니

라 다른 용액들도 기본적으로 gmx solvate 명령어와 -cs 옵션을 이용하여 용해

시킬 수 있음

* 5. 이온을 용해

․2LYM lysozyme는 총 +8e의 net charge를 포함. 실험목적에 맞게 0.25M의 이온

을 용해시키되 charge balance를 위하여 음이온을 8개 더 넣음. 이온을 용해시키

는 gmx genion 유틸리티는 .tpr 파일을 입력파일로 받기 때문에 gmx grompp를

통해서 .tpr 파일을 먼저 생성. 이때 .mdp 파라미터 파일의 파라미터는 아무렇게

나 설정해도 무방함

$ gmx grompp -f ions.mdp -c 2LYM_sol.gro -p topol.top -o ions.tpr$ cp topol.top nacl.top$ gmx genion -s ions.tpr -o 2LYM_solv_nacl.gro -p nacl.top -pname

- 48 -

NA -nname CL -conc 0.25 -neutral․그룹선택창에서 13. SOL을 선택. 12. Water는 에러 생성될 수 있음

* 6. 에너지 minimization 시뮬레이션을 수행

․파라미터 파일 minim.mdp

integrator = steep emtol = 1000.0 emstep = 0.01 nsteps = 50000 nstlist = 1 ns_type = grid rlist = 1.0 coulombtype = PME rcoulomb = 1.0 rvdw = 1.0 pbc = xyz․대중적으로 가장 많이 쓰이는 minimization integrator는 steep. solvation free

energy 계산시 가끔 이용하는 l-bfgs integrator를 제외하고는 대부분의 계산해

서 steep integrator가 가장 빠르고 만족할 만한 결과물을 도출

$ gmx grompp -f minim.mdp -c 2LYM_solv_nacl.gro -p nacl.top -o em_nacl.tpr

$ gmx mdrun -v -deffnm em_nacl

* 7. equilibriation 시뮬레이션을 수행

․최종적으로 NPT ensemble 속에서 단백질 수용액의 시뮬레이션을 수행예정. 하지

만 그 전에 시스템이 충분히 Equilibrium 상태로 안정화될 수 있도록 준비 시뮬

레이션을 수행. 일반적으로 NPT ensemble 준비 시뮬레이션은 NVT

equilibriation, NPT equilibriation step을 수행. 각각 파라미터 파일 nvt.mdp,

npt.mdp를 이용

(1) nvt.mdptitle = CHARMM Lysozyme NVT equilibrationdefine = -DPOSRESintegrator = mdnsteps = 50000dt = 0.002; Output controlnstxout = 100

- 49 -

nstvout = 100 nstenergy = 100 nstlog = 100 ; Bond parameterscontinuation = no constraint_algorithm = lincsconstraints = all-bonds lincs_iter = 1 lincs_order = 4 ; Neighborsearchingns_type = grid nstlist = 5 rlist = 1.0 rcoulomb = 1.0 rvdw = 1.0 ; Electrostaticscoulombtype = PME pme_order = 4 fourierspacing = 0.16 ; Temperature coupling is ontcoupl = V-rescale tc-grps = Protein Non-Protein tau_t = 0.1 0.1 ref_t = 300 300 ; Pressure coupling is offpcoupl = no ; Periodic boundary conditionspbc = xyz ; Dispersion correctionDispCorr = EnerPres; Velocity generationgen_vel = yesgen_temp = 300gen_seed = -1 (2) npt.mdpnvt.mdp에 pcoupl=Parrinello-Rahman으로 바뀌고

- 50 -

pcoupltype = isotropictau_p = 2.0ref_p = 1.0compressibility = 4.5e-5refcoord_scaling=com이 추가

․ temperature coupling group 지정 시 Solute-Non Solute 그룹을 따로 지정하는

게 더 정확한 결과를 내고 “Cold Water, Hot Protein” 현상을 막을 수 있음

$ gmx grompp -f nvt.mdp -c em_nacl.gro -p nacl.top -o nvt_nacl.tpr$ gmx mdrun -v -deffnm nvt_nacl$ gmx grompp -f npt.mdp -c nvt_nacl.gro -p nacl.top -o npt_nacl.tpr$ gmx mdrun -v -deffnm npt_nacl

* 8. Production simulation을 수행

․ equilibriation이 끝나면 데이터 수집을 위한 Production simulation을 수행.

md.mdp 파일은 npt.mdp 파일과 동일하며 수행시간만 50ns로 변경

$ gmx grompp -f md.mdp -c npt_nacl.gro -p nacl.top -o md_nacl.tpr$ gmx mdrun -v -deffnm md_nacl․ 상당한 시간이 걸린 후 계산이 완료

* 9. 뼈대-이온, 곁사슬-이온 간의 Radial Distribution Function (RDF) 계산

․RDF를 통하여 우리는 기준 시스템에 대한 다른 시스템의 통계적 분포를 두 시스

템의 상대적 거리에 대하여 구할 수 있음

․뼈대-이온 사이의 RDF는 다음과 같이 계산

$ gmx rdf -f md_nacl.xtc -s md_nacl.tpr -b 10000 -o rdf_backbone_na.xvg

․그룹 선택창이 나오면 그룹을 두 번 선택. 4 (BackBone)와 16 (Na)를 선택

․곁사슬 - 이온 사이의 RDF는 다음과 같이 계산

$ gmx rdf -f md_nacl.xtc -s md_nacl.tpr -b 10000 -o rdf_side_na.xvg

․그룹은 각각 8 (SideChain) 과 16 (Na)를 선택

․계산시간이 너무 오래 걸리면 -dt 옵션을 이용해 계산에 사용되는 프레임 수 조

절 가능

* 다음 그림은 양이온과 단백질 분자 간의 RDF. Ion specificity를 명확히 확인하기

위해 KCl 수용액 시뮬레이션을 따로 수행하여 Na, K 양이온과 단백질 분자 간

의 상호작용을 계산. RDF를 통하여 두 가지 특징을 알아낼 수 있음

- 51 -

․첫째로 Na 양이온이 K 양이온과 비교하여 단백질 분자 더 가까이에 분포

․둘째로 뼈대 주변보다 곁사슬 주변에 양이온들이 더욱 조밀하게 분포하는 것을

알 수 있음.

* 특히 Na 양이온의 경우는 곁사슬 구조 0.2nm 부근에 뚜렷한 피크를 확인할 수

있음. 이러한 뚜렷한 분포 차이는 고전 전자기학에서 말하는 전하간의 전기력으

로만은 설명할 수 없으며 이온 분자량에 따라 달라지는 이온 주변의 수화층이

유도하는 이온-단백질 분자 간의 상호작용 또한 ion specificity 에 영향을 크게

미친다는 사실을 보여줌

* 다음으로는 양이온, 음이온의 반응성 차이를 보기 위해 Na 양이온과 Cl 음이온의

RDF를 계산 수행). 뼈대 주변에는 Na 양이온이 Cl 음이온에 비해 더 집속되어

있는 반면에, 곁가지 구조 주변에는 미세하게 Cl 음이온이 더 가까이 분포해 있

는 것을 확인할 수 있음. 뼈대구조는 대부분 탄소원자로 이루어진 소수성 구조인

데 비해, 결가지 구조는 전하를 띤 친수성 표면을 포함하고 있음. 이러한 두 구

조의 표면 차이가 서로 반대되는 양이온, 음이온 간의 ion specficity를 보인다는

사실을 확인할 수 있음

- 52 -

<부록2-5: GROMACS Potential of Mean Force(PMF) 계산>

※ 현재 GROMACS 5.0 이상의 버전에서는 umbrella sampling 시 버그가 보인다는

결과들이 발표되고 있으니 가급적 4.6.x 버전을 이용 권장. mdrun은 5.x 버전으

로 해도 무방하나 g_wham은 4.x 버전 권장.

※ 서로 다른 두 단일 원자들의 결합은 단순한 상호퍼텐셜 계산을 통하여 얻을 수

있으나 복잡한 모양과 많은 원자수를 가진 생체거대분자의 경우에는 분자들이

가진 높은 Degree of Freedom 에 의하여 단순 상호 퍼텐셜 계산으로 결과를 얻

는 데 어려움이 있음. 따라서 물리학에서는 이러한 문제를 해결하기 위하여 시스

템의 운동을 열역학, 통계역학적으로 접근하여 열역학 퍼텐셜이라는 개념을 도입

하였음. 그 중에서도 생체 분자의 결합-떨어짐과 같은 NPT ensemble 내에서의

현상은 깁스 자유 에너지(G)라는 개념을 도입하여 설명할 수 있음

※ 깁스 자유에너지는 열역학 퍼텐셜의 한 종류이므로 퍼텐셜이라는 개념이 갖는

두 가지 특징

․첫번째 깁스 자유에너지는 서로 다른 상태의 깁스 자유에너지의 차이를 통하여

그 의미. 특정한 분자 시스템이 a라는 열역학적 상태에 있을 때의 깁스 자유 에

너지가 Ga이고, b라는 열역학적 상태에 있을 때의 깁스 자유 에너지가 Gb 일때

두 열역학적 상태 a, b 간의 통계적 관계는 다음과 같이 표현할 수 있음.

[시스템이 열역학적 상태 b에 있을 확률] : [시스템이 열역학적 상태 a에 있을 확

률] = exp[-(Gb-Ga)/kT]

k는 볼츠만 상수, T는 온도이다.

․두번째 깁스 자유에너지는 G=0인 기준상태. 두 분자간의 결합에서의 깁스 자유에

너지를 계산할 때 기준상태는 이상적으로는 두 분자가 무한대로 떨어져 서로 상

호작용을 하지 않는 상태. 하지만 시뮬레이션에서는 유한한 시뮬레이션 셀의 크

기 때문에 기준상태는 충분히 멀리 떨어져 서로간의 상호작용이 0에 가까운 상

태로 정의내리는 경우가 보통

※ 해당 시뮬레이션에서는 GROMACS를 이용한 umbrella sampling (US) 방법으로

이온과 고체 표면 간의 결합 깁스 자유 에너지, Potential of Mean Force(PMF)

- 53 -

를 계산

․ umbrella sampling 방법은 reaction coordinate를 따라 일정한 간격으로 떨어진

여러 개의 configuration을 생성한 뒤 인접한 configuration간의 오버랩을 가지고

PMF를 계산하는 방법으로, 인접한 configuration의 오버랩이 symmetric하면 두

configuration이 같은 깁스 에너지를 가지지만, asymmetric하면 두 configuration

은 깁스 에너지 차이를 가지는 기본 개념에서 출발

․ GROMACS에서는 PMF 계산을 쉽게 할 수 있도록 g_wham이라는 유틸리티를

제공하며, 여기에서는 weighted histogram method를 이용하여 PMF를 계산

․ 본 문서에서는 configuration 제작, 시뮬레이션 파라미터 설정, g_wham 이용을

통하여 PMF를 계산하는 과정을 포함함

* 0. 시뮬레이션에 필요한 고체 크리스탈 좌표 파일을 생성

․앞에서 전술한 단백질 시뮬레이션과는 달리 GROMACS는 특정한 고체 크리스탈

의 좌표 파일 및 그 토폴로지를 제공하지 않음. 대신 Python 혹은 Perl 스크립트

를 이용하여 .gro 좌표 파일 생성 가능. 본 시뮬레이션에서는 python 스크립트를

이용하여 alpha-quartz 모양의 고체 생성함

* 0-1. 힘 파라미터 폴더를 만들어서 힘 파라미터 파일들을 그 안에 생상하여 포함

․좌표 파일과 마찬가지로 힘 파라미터 파일들도 직접 생성해야 함. 우선 힘 파라

미터 이름을 정하고 폴더 생성. 폴더 이름은 .ff로 끝나야 GROMACS가 파라미터

폴더라고 인식 가능. 폴더 안에 반드시 들어가야 하는 파일들은 다음과 같음

(1) atomtypes.atp 파일: 시뮬레이션 시스템에 쓰인 원자 타입 이름들 포함

(2) ffbonded.itp, ffnonbonded.itp 파일: 원자타입간의 결합, 비결합 퍼텐셜 파라미터

들 포함

(3) forcefile.itp 파일: 기본설정, 그리고 ffbonded.itp, ffnonbonded.itp를 포함

(4) spce.itp 파일: 물 분자의 힘 파라미터 파일. GROMACS가 기본제공하는 힘 파

라미터 폴더에서 복사 가능

(5) ion.itp 파일: 이온의 moleculetype을 정의해 놓은 파일. 다만 이 파일에는 이온

의 기본 정보만 담겨져 있고 이온의 힘 파라미터는 ffnonbonded.itp 파일에 들어가

있음. 각 파일의 규격과 정보들은 GROMACS 매뉴얼 혹은 기본제공하는 힘 파라

미터 폴더 내부의 파일을 참고하여 만들면 간편히 파일들 생성 가능

(6) atomnames2types.n2t 파일: 1에서 후술함

* 1. 고체 크리스탈 좌표 파일로부터 토폴로지 파일 생성

․고체 크리스탈은 periodicity를 가지므로 유닛 셀의 원자들 간의 결합정보를 알면

전체 셀의 원자들 간의 결합정보과 토폴로지를 알아낼 수 있음. 본 기능은

GROMACS에 기본적으로 존재하는 g_x2top 유틸리티와 힘 파라미터 폴더 내부의

- 54 -

atomnames2types.n2t 파일을 이용하여 제공

․atomnames2types.n2t 파일은 다음과 같은 양식

SI SI 0.0000 28.0855 5 O 0.161 O 0.161 O 0.161 O 0.161 O 0.161

SI SI 0.0000 28.0855 4 O 0.161 O 0.161 O 0.161 O 0.161

SI SI 0.0000 28.0855 3 O 0.161 O 0.161 O 0.161SI SI 0.0000 28.0855 2 O 0.161 O 0.161……

․첫번째 줄의 의미: SI 원자는 0.000의 전하와 28.0855의 전하량을 가지고 5개의 원

자들과 결합. 5개의 원자들은 각각 O이고 거리는 0.161nm

․g_x2top 유틸리티를 다음과 같이 실행시키면 GROMACS는 atomnames2types.n2t

에 입력된 정보를 바탕으로 토폴로지 파일 생성. 이 때 고체의 periodic 방향의 셀

크기를 고체의 크기와 맞게 설정해 놓으면 자동으로 periodic image 간의 결합 또

한 계산해서 토폴로지 파일에 입력. 명령어는 다음과 같다.

$ g_x2top -f sio2.pdb -o sio2.top -ff clayFF -noparam -v -name SIO․sio2.pdb 에서의 좌표정보로부터 sio2.top 의 토폴로지 파일 생성. -ff 옵션을 이용

해 힘 파라미터 이름을 지정하고 -name을 이용해 시스템의 이름을 지정. 결합 퍼

텐셜 파라미터는 이미 ffbonded.itp 파일에 입력되어 있으므로 -noparam 옵션을

이용해 토폴로지 파일에 추가 퍼텐셜 파라미터가 입력되는 것을 막음

* 2. 고체 크리스탈의 position restraint 파일 생성

$ genrestr -f sio2.pdb -o sio2.itp -fc 1000 1000 1000․토폴로지 파일을 열어서 [diherals] 와 [system] 섹션 사이에 sio2.itp 파일 포함

* 3. 고체 크리스탈을 물에 용해

․1에서 만들어진 토폴로지 파일은 물 분자의 힘 파라미터가 담긴 spce.itp 파일에

서 제외. 토폴로지 파일을 열어서 처음에 보이는 #include “forcefield.itp” 아랫줄

에 spce.itp 파일 포함

$ cp sio2.top sio2.w.top$ genbox -cp sio2.pdb -cs spc216.gro -o sio2.w.pdb -maxsol 2160 -p

sio2.w.top․초기에 시뮬레이션을 설계할 때 원하는 물 분자의 개수를 설정해 놓는 경우가 있

음. 그럴 때 원하는 만큼의 물 분자 개수를 -maxsol 옵션을 이용하여 지정 가능.

다만 시뮬레이션 셀 사이즈에 다 들어갈 수 없는 수준의 물 분자 개수를 지정하면

자동적으로 그보다 적은 시뮬레이션 셀 사이즈에 맞는 최대치의 물 분자 개수 생

성

- 55 -

※고체 크리스탈은(막 단백질 역시) 내부에 물 분자가 들어갈 크기의 공간을 가지

고 있는 경우가 있음. genbox 유틸리티는 고체 크리스탈 외부와 내부를 구분하

지 않고 고체분자의 반 데르 발스 반지름을 계산하여 물 분자가 들어갈 충분한

공간이 존재하면 물 분자를 추가하기 때문에 종종 고체 크리스탈 내부에 물 분

자가 추가되어 artifact를 가할 수 있음. 이러한 경우에는 고체 원자의 반 데르

발스 반지름을 라이브러리 폴더의 vdwradii.dat 파일에 들어가서 인위적으로 늘

려 놓아 해결 가능

* 4. minimization, NVT-NPT equilibriation 시뮬레이션 수행

․minim.mdp, nvt.mdp 파일은 앞의 단백질 시뮬레이션과 동일. npt.mdp 파일은 다

음과 같이 pressure coupling 파라미터에서 변화가 있음

pcoupl = berendsenpcoupltype = semiisotropictau_p = 1 1tau_p = 1 1compressibility = 0 4.5e-5․고체 크리스탈의 경우 xy방향으로 infinite periodicity 를 가지기 때문에 xy 방향

으로 셀의 크기를 변화시킬 수 없음. 따라서 이 시뮬레이션은 z 방향으로만 셀 크

기를 변화시키고 그것을 위해 pcoultype=semiisotropic, compressibility=0 4.5e-5 옵

션 추가

$ grompp -f minim.mdp -c sio2.w.pdb -p sio2.w.top -o em_sio2.tpr$ mdrun -v -deffnm em_sio2$ grompp -f nvt.mdp -c em_sio2.gro -p sio2.w.top -o nvt_sio2.tpr$ mdrun -v -deffnm nvt_sio2$ grompp -f npt.mdp -c nvt_sio2.gro -p sio2.w.top -o npt_sio2.tpr$ mdrun -v -deffnm npt_sio2

* 5. 하나의 이온 분자를 용해

․물-고체 시스템이 안정화되었으면 이제 이온 분자 하나를 용해. 우선 2. 와 마찬

가지로 토폴로지 파일을 열어서 spce.itp 파일이 추가된 밑에 ion.itp 파일을 추가

$ grompp -f ions.mdp -c npt_sio2.gro -p sio2.w.top -o ions.tpr$ cp sio2.w.top cl.top$ genion -s ions.tpr -o cl0.pdb -p cl.top -nname CL -nn 1․선택창이 뜨면 4. SOL을 선택

․genion 유틸리티는 자동적으로 랜덤한 물 분자를 하나 이온으로 변화. 이제

cl.pdb 파일에 들어가서 이온 분자의 좌표를 xy좌표는 셀의 중앙, z 좌표는 고체

표면과 0.1nm 만큼 떨어져 있도록 교체

- 56 -

* 6. umbrella sampling 을 위해 필요한 configuration 파일들 생성

․본 시뮬레이션에서는 Cl- 이온과 고체 표면의 거리를 0.1nm 부터 0.025nm 간격

으로 점점 멀리 떨어뜨려 52개의 configuration을 준비하고 그 configuration 들의

umbrellas sampling 시뮬레이션을 통하여 PMF를 계산. 여기에서는 cl0.pdb에서

editconf 유틸리티를 이용하여 전체 파일 중 Cl- 이온만 z축 방향으로 0.025nm 만

큼 이동. 우선 인덱스 파일을 make_ndx 를 이용하여 생성

$ make_ndx -f cl0.pdb -o cl.ndx․다음과 같은 프롬프트 보임

0 System : 11188 atoms 1 Other : 2017 atoms 2 SIO : 2016 atoms 3 CL : 1 atoms 4 Water : 9171 atoms 5 SOL : 9171 atoms 6 non-Water : 2017 atoms nr : group ! 'name' nr name 'splitch' nr Enter: list g

roups 'a': atom & 'del' nr 'splitres' nr 'l': list resi

dues 't': atom type | 'keep' nr 'splitat' nr 'h': help 'r': residue 'res' nr 'chain' char "name": group 'case': case sensitive 'q': save and

quit $ 3|4․그러면 7 CL_Water로 명명된 9172 atoms 로 이루어진 그룹이 생성됨

$ name 7 SOL_ION․CL_Water 그룹 이름이 SOL_ION으로 교체

$ q․새롭게 만들어진 그룹 인덱스들이 cl.ndx 인덱스 파일에 저장

․editconf 를 실행

$ editconf -f cl0.pdb -o cl1.pdb -translate 0 0 0.025 -n cl.ndx․첫번째 그룹 선택창에서는 3. CL을 두번째 그룹 선택창에서는 0. System을 선택.

그러면 editconf 유틸리티는 3. CL에 해당하는 원자들의 좌표를 -translate 옵션에

명시된 대로 z축으로 0.025nm만큼 이동시키고 그 결과 0. System에 해당하는 원자

들의 좌표를 cl1.pdb 파일에 저장. 계속 같은 프로세스를 수행하여 cl0~cl51.pdb 총

- 57 -

52개의 좌표파일을 생성. 스크립트를 이용하면 편리하게 52개의 configuration을

만들 수 있음. 다음 그림은 생성된 configuration 중 하나를 VMD로 출력한 결과.

그림을 알아보기 쉽게 물 분자는 이온 주변에 생성되는 수화층의 물 분자만 있음

* 7. minimization, NVT equilibriation 시뮬레이션을 수행

$ cp minim.mdp minim_cl.mdp; cp nvt.mdp nvt_cl.mdp․minim_cl.mdp, nvt_cl.mdp 에 각각 다음 옵션을 추가

freezegrps = SIO CLfreezedim = Y Y Y Y Y Y※ umbrella sampling 도중에는 이온-고체 크리스탈 사이의 거리가 일정하게 유지

되는게 중요. 따라서 equilibriation 도중에 거리가 변하지 않도록 두 그룹을 모두

freezing시킬 필요가 있음

․또한 T-coupling 그룹을 다음과 같이 수정

tc_grps = SOL_ION SIO※ SOL 그룹과 ION 그룹을 분리시키지 않아야 함. ION 그룹은 원자 개수가 하나

뿐이어서 따로 thermocouple을 하면 심각한 열역학적 오류 가능

$ for i in {0..51}; do grompp -f minim_cl.mdp -c cl${i}.pdb -p cl.top -n cl.ndx -o em${i}.tpr ; done

$ for i in {0..51}; do mdrun -v -deffnm em${i}$ for i in {0..51}; do grompp -f nvt_cl.mdp -c em${i}.gro -p cl.to

p -n cl.ndx -o nvt${i}.tpr; done

- 58 -

$ for i in {0..51}; do mdrun -v -deffnm nvt${i}․위의 스크립트들은 52개의 configuration을 실행

* 8. umbrella pulling 시뮬레이션을 수행

$ cp md.mdp md_cl.mdp․md_cl.mdp 파일에 umbrella 파라미터를 추가

pull = umbrellapull_geometry = distancepull_dim = N N Ypull_start = yespull_ngroups = 1pull_group0 = SIOpull_group1 = CLpull_init1 = 0pull_rate1 = 0.0pull_k1 = 4000pull_nstxout = 10pull_nstfout = 10※ 중요한 파라미터는 pull, pull_dim, pull_k1

※ pulling 시뮬레이션을 수행하면 pull_group0 (고체 크리스탈) 과 pull_group1 (이

온) 사이의 거리가 시뮬레이션 동안 외부 퍼텐셜에 의하여 일정하게 유지. 옵션

중 pull은 pulling 퍼텐셜을 선택. umbrella pulling을 위해서는 umbrella 옵션을

선택해야 함. umbrella 퍼텐셜을 선택하면 Hooke퍼텐셜을 가지는 가상스프링이

두 pull_group 사이에 생성되며 외부힘에 의해 두 pull_group의 거리가 바뀌려고

할 때마다 umbrella 퍼텐셜이 가해져 거리를 일정하게 강제로 유지. 따라서 시뮬

레이션 수행 동안의 두 pull_group 사이의 거리를 모두 기록하여 확률분포로 나

타내면 다음 그림의 up panel에 보이는 것과 같이 초기 설정 거리 r0을 중심으

로 분포한다. 여러 개의 인접한 configuration의 umbrella pulling을 수행하면 그

림의 down panel에 보이는 것과 같이 인접한 configuration 간의 확률분포의 오

버랩이 생기고 인접한 configuration간의 확률분포 차이를 통해 PMF를 계산

※ pull_dim은 umbrella 퍼텐셜이 가해지는 방향을 선택. 즉 두 분자의 reaction

coordinate 방향을 지정해 주어야 함. 여기에서는 z축 방향을 설정

※ pull_k1은 가장 중요한 옵션. 인접한 configuration간의 오버랩이 적절히 일어나

도록 몇 번의 튜닝을 거칠 필요가 있음. pull_k1이 너무 큰 값을 가지면 이온-고

체 크리스탈 간의 간격이 너무 심하게 유지되어 인접한 configuration간의 오버

랩이 일어나지 않아 깁스자유에너지 차이를 계산할 수 없고, pull_k1이 너무 작

은 값을 가지면 시뮬레이션 수렴 시간이 오래 걸리거나 이온-고체 크리스탈 간

- 59 -

의 간격이 유지되지 않고 이온이 이탈해버리는 현상이 발생할 수 있음. 여기에서

는 4000을 선택하였으나 모든 상황에 다 적용될 수 있는 값이 아니므로 시뮬레

이션을 할 때마다 몇 번의 튜닝과 관련 논문들을 찾아보는 게 선행되어야 함

․1.5ns 시뮬레이션을 수행

$ for i in {0..51}; do grompp -f md_cl.mdp -c nvt${i}.gro -p cl.top -n cl.ndx -o md${i}

$ for i in {0..51}; do mdrun -v -deffnm md${i} -px md${i}.px -pf md${i}.pf

․시뮬레이션이 끝나면 모두 52쌍의 결과가 생성. 시뮬레이션 양이 많으므로 여러

노드에 각각 할당해서 시뮬레이션을 동시에 수행하는 것을 추천

* 9. PMF 계산

․g_wham을 실행하기 전에 52쌍의 정보를 담고 있는 tpr-files.dat 파일과

pullf-files.dat 파일을 생성. 각각의 파일은 다음 정보를 포함

(1) tpr-files.datmd0.tpr

- 60 -

md1.tpr…

md51.tpr(2) pullf-files.datmd0.pf.xvgmd1.pf.xvg…

md51.pf.xvg․g_wham 을 통해 weighted histogram method를 이용하여 PMF를 계산

$ g_wham -it tpr-files.dat -if pullf-files.dat -min 1.16 -max 2.4 -bins 62 -b 300 -o profile.xvg -hist histo.xvg -bsres bsResult.xvg -nBootstrap 100

․초반 300ps를 제외한 나머지 데이터를 분석에 이용. configuration들이 알맞게 오

버랩되었는지 히스토그램 결과는 histo.xvg에 보여짐. 그림에 나와 있듯이 인접한

configuration들이 적당하게 오버랩 되어 있는 사실을 확인 가능.

․PMF 는 profile.xvg에서 확인할 수 있음. 결과 에러는 Bootstrap method를 이용

하여 계산할 수 있음. -nBootstrap 옵션으로 Bootstrap method 횟수를 지정하고 이

시스템에서는 100번 정도면 충분히 에러 값이 수렴. 또한 에러바를 포함한 PMF는

bsResult.xvg에서 확인 가능. 결과는 Cl- 이온이 어느 정도 표면에 adsorption하는

경향을 가진다는 사실을 표면 근처에 존재하는 PMF 골짜기를 통하여 확인 가능

․F-, Cl-, Br-, I-를 모두 계산하여 비교하면 ion specificity를 명확히 확인 가능. F-

가 작은 이온 크기로 인하여 표면에서 멀어지려는 경향이 보이려는 반면에, Cl-,

Br-, I- 이온은 표면에 adsorption하려는 성향을 확실히 확인할 수 있으며 그 경향

은 이온의 크기에 상관있는 사실을 확인할 수 있음

- 61 -

3. LAMMPS

∙ 개요

- 시스템 내에 입자들 사이에 에너지 포텐셜(potential) 또는 힘이 주어졌을 때

뉴턴의 운동방식을 수치적으로 풀어내어 입자들의 위치 및 속도를 계산하는

오픈소스 프로그램

- NVIDIA GPU 계산의 대부분을 차지하는 원소들 상호간의 pair-wise

interaction (van der Waals, electrostatic)을 계산하여 원소들이 시스템 내에서

받는 힘을 계산하는 부분을 담당하게 되며, LAMMPS 공식 벤치마킹 결과 CPU

전용 계산 대비 10배 정도의 성능 향상을 보고하고 있음

- CPU대비 NVIDIA GPU 활용률에 따라 GPU(CPU와 GPU를 같이 활용)와

CUDA(GPU만 이용) 패키지 두 개를 제공함

- Xeon Phi는 2014년 8월 15일 버전부터 Offload 방식으로 제공하며 Charmm

force field와 Gayberne 포텐셜만 사용 가능

∙ LAMMPS 소개

- LAMMPS(Large-scale Atomic/Molecular Massively Parallel Simulator)는 뉴튼

역학 법칙을 따르는 분자 동역학 시스템을 해석하기 위해 설계된 프로그램이며,

높은 병렬화 효율, 코드 설계의 합리성 등 여러 장점이 있어 분자 레벨에서부터

연속체 영역까지 적용 범위를 지속적으로 넓혀나가고 있음

- 분자 동역학 시뮬레이션은 보통 수천에서 수백만 단위의 원소(단위입자)를 포함

하는 3D periodic unitcell을 구성하고, 펨토초 단위에서 미리 정의 되어있는

force-field 파라미터들을 기반으로 뉴튼 역학 방정식을 풀어 피코초 또는 나노

초 동안의 거동 특성을 파악함

- 신뢰도가 높은 열역학적, 동적 물성들을 도출하기 위해서는 충분히 큰 규모의

시스템을 충분히 긴 시간동안 시뮬레이션을 진행시켜야하기 때문에 시뮬레이션

프로그램의 병렬화를 통해 계산시간을 단축하는 것이 필수적

- LAMMPS는 시뮬레이션 가속화를 위해 spatial-decomposition 병렬화 알고리즘

을 사용하고 있으며, n개의 프로세서가 n개로 나누어진 물리적인 시뮬레이션 공

간을 하나씩 맡아 원소들의 위치 및 속도를 나누어 계산함으로써 전체적인 계산

속도를 향상함

- LAMMPS는 C++ 컴파일러와 MPI (Message Passing Interface) 환경이 설정되

어있는 대부분의 PC 또는 클러스터 환경에서 구동이 가능하며, 최근 CPU대비

GPU의 강력한 부동소수점 계산 능력을 활용하여 병렬화 효율을 더욱 향상시킬

수 있는 package (GPU 또는 USER-CUDA)가 기본적으로 포함되어 배포

- 62 -


- NVIDIA GPU 설치 방법

※ C++, MPI 라이브러리, 플랫폼에 최적화된 FFT 라이브러리, CUDA 라이브러리

가 필요

․ Intel Cluster Studio (C++ compiler, MPI, FFTW)

․ Intel Cluster Studio (C++ compiler, FFTW) + Openmpi(1.8.1)

에서 1Feb14 버전 빌드 방법을 기준

* 1. LAMMPS source code 다운로드

․ LAMMPS 공식 홈페이지의 다운로드 페이지

(http://lammps.sandia.gov/download.html#tar)에서 stable version을 다운받아

서 설치하고자하는 경로(예 $HOME/programs)에 SFTP를 사용하여 이동

시킨 후 다음 명령으로 압축을 해제

$ tar zxvf lammps-stable.tar.gz․압축이 풀리면 다음과 같은 하위 디렉토리 구조를 갖는 LAMMPS 디렉토

리(lammps-1Feb14)가 생성

$ lammps-1Feb14 ┬ bench (벤치마킹 예제) ├ doc (LAMMPS 매뉴얼) ├ examples (다양한 package별 예제) ├ lib (LAMMPS package 라이브러리) ├ potentials (eam force-field 파일) ├ python (python 연동 관련 파일) ├ src (메인 source 파일) └ tools (pre, post 프로세스 유틸리티)

* 2. 설치 환경 설정

․Intel Cluster Studio는 Intel 프로세서에 최적화된 C++, fortran 컴파일러와

MPI, MKL(Math Kernal Library)를 통합으로 제공하기 때문에 Intel 프로

세서로 구성된 클러스터에서 용이하게 사용 가능. 해당 클러스터에서 Intel

Cluster Studio 환경을 불러오기 위해서는 module 명령어를 다음과 같이

입력

$ module purge # 기존의 설정된 환경 초기화$ module avail # 사용 가능한 module list 확인$ module load intel_cluster_studio-2013_beta # 변경 가능․Intel MPI가 아닌 Openmpi를 사용하기 위해서는 다음 명령을 추가로 실행

한다. (bash shell의 경우)

$ export MPI_HOME = /applic/test_only/mpi/cuda/openmpi-1.

- 63 -

8.1/intel-2013$ export PATH=$MPI_HOME/bin:$PATH$ export LD_LIBRARY_PATH=$MPI_HOME/lib:$LD_LIBRARY_PATH․추가적으로 GPU 연동을 위한 cuda 툴킷의 위치를 확인. 해당 시스템에서

의 위치는 /usr/local/cuda-6.0

* 3. 패키지 설정 및 빌드

․LAMMPS는 프로그램에서 지원하는 다양한 기능들이 독립적인 모듈로 구

성되어 있어 사용자가 원하는 패키지만을 선택하여 컴파일 가능.

․여기서는 GPU 관련 패키지의 GPU, USER-CUDA 설치 과정을 설명하며,

추가 패키지들의 상세한 설치 방법은 LAMMPS 공식 매뉴얼이나 KISTI

자료실의 LAMMPS 지침서를 참조. 다음 명령어를 통해 설치하고자 하는

패키지를 선택 (default로 KSPACE, MANYBODY, MOLECULE 패키지가

선택되어 있음)

$ cd lammps-1Feb14/src$ make yes-GPU$ make yes-CUDA$ make package-status # 선택된 패키지 확인; DIPOLE, COLLOID 등선택되지 않은 패키지 관련 파일이 존재하지 않는다고 출력되며, 관련패키지를 사용하지 않는 경우에는 무시하고 진행하면 됨

․패키지 선택을 완료한 후 관련 외부 라이브러리(GPU, CUDA)를 컴파일하

기 위해 lib 디렉토리로 이동

[GPU 패키지]$ cd ../lib/gpu$ vi Makefile.linux # 컴파일 환경에 맞게 다음 변수를 수정

lammps-1Feb14/lib/gpu/Makefile.linux

...CUDA_HOME = /usr/local/cuda-6.0...CUDA_ARCH = -arch=sm_35 # for Tesla K40...CUDR_CPP = mpicxx –DMPI_GERYON –DUCL_NO_EXIT –DMPICH_IGNORE_CXX_SEEK...

$ make –f Makefile.linux․컴파일 완료 후 libgpu.a 파일이 생성된 것을 확인

- 64 -

[CUDA 패키지]$ cd ../cuda$ vi Makefile.common # 컴파일 환경에 맞게 다음 변수를 수정

lammps-1Feb14/lib/cuda/Makefile.common...CUDA_INSTALL_PATH = /usr/local/cuda-6.0...

$ make precision=4 arch=35․컴파일 완료 후 liblammpscuda.a 파일이 생성된 것을 확인

[LAMMPS]․관련 라이브러리를 컴파일 한 후 src 디렉토리로 이동하여 LAMMPS 컴

파일을 위한 Makefile을 만들고 환경에 맞게 수정

$ cd ../../src$ cp MAKE/Makefile.linux MAKE/Makefile.gpu$ vi MAKE/Makefile.gpu

lammps-1Feb14/src/MAKE/Makefile.gpu (Inter Cluster Studio)...CC = mpicxx –cxx=icpcCCFLAGS = -O -msse4.2 -DMPICH_IGNORE_CXX_SEEK...LINK = mpicxx –cxx=icpcLINKFLAGS = -O -L/applic/compilers/intel/2013sp1/mkl/lib/intel64 –L../../lib/gpu -L/usr/local/cuda-6.0/lib64LIB = -lstdc++ -lpthread -mkl:cluster -lcuda -lcudart...MPI_INC = -I/applic/compilers/intel/2013sp1/impi/4.1.3.048/include64MPI_PATH = -L/applic/compilers/intel/2013sp1/impi/4.1.3.048/lib64MPI_LIB = -lmpi –lpthread...FFT_INC = -DFFT_FFTW -I/applic/compilers/intel/2013sp1/mkl/include/fftw...FFT_LIB = /applic/compilers/intel/2013sp1/mkl/lib/intel64/libfftw2xc_double_intel.a...

- 65 -

lammps-1Feb14/src/MAKE/Makefile.gpu-openmpi (Openmpi)...CC = mpicxx...LINK = mpicxx...MPI_INC = -I${MPI_HOME}/includeMPI_PATH = -L${MPI_HOME}/lib...(다른 변수들은 Intel Cluster Studio와 동일)

$ make gpu (make gpu -j 4 : 병렬 컴파일 지원)․컴파일이 완료되면 lmp_gpu라는 실행파일이 생성되며 ./lmp_gpu를 실행했

을 때 다음과 같은 출력이 나오면 정상적으로 빌드된 것임

$ ./lmp_gpuLAMMPS (1 Feb 2014)# Using LAMMPS_CUDA USER-CUDA mode is enabled (../lammps.cpp:425)

* 4. LAMMPS 실행 방법 및 input 설정

※병렬환경에서 LAMMPS를 실행하는 방법은 하드웨어, 소프트웨어 설정에

따라 달라질 수 있음

․먼저 실제 프로그램을 구동할 계산 노드들의 정보를 갖고 있는 hostfile을

적당한 위치에 생성하고 (예, $HOME/hostfile) 다음 내용을 입력

$HOME/hostfile (Intel Cluster Studio)tesla01:20tesla02:20tesla03:20...(사용할 노드 모두 입력, 20은 노드당 CPU threads 개수)$HOME/hostfile (Openmpi)tesla01 slots=20tesla02 slots=20tesla03 slots=20...

․병렬 실행은 다음 명령을 통해 수행

$ mpirun -np <# of processes> -hostfile $HOME/hostfile $HOME/programs/lammps-1Feb14/src/lmp_gpu -c on/off –in input_file

- 66 -

․여기서 명령줄의 –c 옵션은 CUDA tag이며, 기본으로 on 상태이기 때문

에 CUDA 패키지를 사용하지 않는 일반 CPU 계산이나 GPU 계산의 경우

필수적으로 –c off로 명시해야 함

․각 패키지 별 input 파일 설정 시 주의해야할 점

[GPU 패키지]․GPU 패키지는 GPU 버전으로 업데이트된 특정 pair style에 대해서만 적

용할 수 있으며, 지원하는 주요 pair style은 다음 표에 명시되어 있음

lj/cut/gpulj/cut/coul/cut/gpulj/cut/coul/long/gpulj/charmm/cou/long/gpucoul/long/gpubuck/gpubuck/coul/cut/gpubuck/coul/long/gpumorse/gpueam/gpueam/alloy/gpu... (공식 메뉴얼 pair_style 참고)

※특히 long-range charge interaction을 계산하기 위한 kspace scheme은

pppm만 사용 가능하며 (ewald scheme 사용 불가) “kspace_style

pppm/gpu”를 input 파일에 명시해주어야 함

․명령줄 옵션 “-sf gpu”: gpu를 지원하는 LAMMPS 기능들을 한 번에 적

용 하는 옵션이며, 예를 들어 pair_style을 lj/cut으로 선언해도 자동으로

lj/cut/gpu로 사용하게 됨

․input 파일 “package gpu” tag: LAMMPS 계산에서 GPU를 어떻게 사용

할 것인가에 대한 tag이며, 계산 노드 당 몇 개의 GPU가 설치되어 있는지,

GPU에서 force만 계산할 것인지, neighbor list까지 계산할 것인지 등을 설

정할 수 있음.

※명령줄 옵션 “-sf gpu”를 사용할 경우 “package gpu force/neigh 0 0 1”을

자동으로 적용하며 이는 force와 neighbor list를 모두 GPU에서 계산하며

0번에서 0번 GPU까지 사용하고 (GPU를 1개만 사용, GPU가 2개 설치된

경우 0 1 입력), 계산 load를 GPU에만 할당하겠다는 의미 (자동으로 GPU

와 CPU의 계산 load balancing을 원하면 –1을 입력)

․input 파일 “newton” tag: LAMMPS는 기본적으로 pairwise와 bonded

interaction를 계산할 때 뉴튼 3법칙을 사용해서 계산 cost를 줄이는

“newton on” 조건이 설정되어 있음. 하지만 GPU 패키지 사용 시에는

GPU에 분산되어있는 입자들의 상호관계를 뉴튼 3법칙을 사용하지 않고

- 67 -

개별적으로 계산하기 때문에 “newton off”를 명시적으로 넣어주어야 함

․다음은 위에서 설명한 옵션들을 포함한 명령줄 옵션 및 input 파일

$ mpirun -np 10 –hostfile $HOME/hostfile $HOME/programs/lammps-1Feb14/src/lmp_gpu –c off –sf gpu –in in.lj.gpuin.lj.gpunewton off # 필수 옵션

package gpu force/neigh 0 0 –1 # GPU 개수, load balancing 조건에

맞게 수정 (-sf gpu 사용시 gpu force/neigh 0 0 1 로 기본값 적용됨)

units ljatom_style atomic

lattice fcc 0.8442region box block 0 8 0 8 0 8create_box 1 boxcreate_atoms 1 boxmass 1 1.0

velocity all create 1.44 87287 loop geom

pair_style lj/cut/gpu 5.0 # -sf gpu 사용 시 lj/cut 사용 가능

pair_coeff 1 1 1.0 1.0 5.0

neighbor 0.3 binneigh_modify delay 0 every 20 check no

fix 1 all nverun 100

[CUDA 패키지]․CUDA 패키지는 GPU 패키지와는 달리 LAMMPS 전체 계산을 GPU에 올

려서 계산하는 방식으로 CPU 코어는 GPU 당 1개씩 사용하도록 설계되어

있음

․CUDA 패키지를 지원하는 많은 pair_style, fix, compute들이 있으며,

long-range charge interaction을 계산하기 위해서는 pppm kspace scheme

을 사용해야 함.

․계산과정에서 CPU 프로세스간 MPI를 제외하고 모든 계산이 GPU에서 이

루어지기 때문에 CUDA 패키지를 지원하지 않는 fix나 compute 사용 시

GPU에서 CPU로 모든 atom base property들을 옮겨서 계산을 진행하기

때문에 속도가 느려질 수 있으므로 사용 시 주의해야 함

- 68 -

․다음은 CUDA 패키지를 지원하는 주요 pair_style 및 fix

pair_stylelj/cut/cudalj/cut/coul/cut/cudalj/cut/coul/long/cudalj/charmm/coul/long/cudalj/charmm/coul/charmm/cudaeam/cudaeam/alloy/cudabuck/cudabuck/coul/long/cudamorse/cuda...fixnve/cudanvt/cudanpt/cudashake/cuda...

․명령줄 옵션 “-c on”: CUDA 패키지를 포함하여 LAMMPS를 컴파일할 경

우 기본값으로 적용되어 있으며 input 파일에서 “package cuda 1”을 적용

한 것과 같은 기능 (LAMMPS 공식 매뉴얼 package 참조). 계산 노드 하

나에 GPU가 2기 이상 설치되어있을 경우 “package cuda <# of GPU>”를

명시적으로 input 파일에 넣어주어야 하며 “–pk cuda <# of GPU>“를 명

령줄에 같이 넣어도 가능

․명령줄 옵션 “-sf cuda”: CUDA를 지원하는 LAMMPS 기능들을 한 번에

적용 하는 옵션이며, 예를 들어 pair_style을 lj/cut으로 선언해도 자동으로

lj/cut/cuda로 사용하게 됨

․다음은 위에서 설명한 옵션들을 포함한 명령줄 옵션 및 input 파일

- 69 -

$ mpirun -np 10 –hostfile $HOME/hostfile $HOME/programs/lammps-1Feb14/src/lmp_gpu –c on –sf cuda –in in.lj.cudain.lj.cudapackage cuda 1 # GPU 개수 (-sf cuda 사용시 package cuda 1 로 기본값

적용됨)

units ljatom_style atomic

lattice fcc 0.8442region box block 0 8 0 8 0 8create_box 1 boxcreate_atoms 1 boxmass 1 1.0


pair_style lj/cut/cuda 5.0 # -sf cuda 사용 시 lj/cut 사용 가능

pair_coeff 1 1 1.0 1.0 5.0

neighbor 0.3 binneigh_modify delay 0 every 20 check no

fix 1 all nverun 100

- 70 -

- Intel Xeon Phi 설치 방법

※Intel compiler 2013sp1 이후 버전의 설치가 필수

※18Sep14 버전을 기준으로 설명

* 1. LAMMPS source code 다운로드

․ LAMMPS 공식 홈페이지의 다운로드 페이지

(http://lammps.sandia.gov/download.html#tar)에서 stable version을 다운받아

서 설치하고자하는 경로(예 $HOME/programs)에 SFTP를 사용하여 이동

시킨 후 다음 명령으로 압축을 해제

$ tar zxvf lammps.tar.gz․압축이 풀리면 다음과 같은 하위 디렉토리 구조를 갖는 LAMMPS 디렉토

리(lammps-18Sep14)가 생성

$ lammps-18Sep14 ┬ bench (벤치마킹 예제) ├ doc (LAMMPS 매뉴얼) ├ examples(다양한 포텐셜 및 목적에 따른 예제 및,

package별 예제) ├ lib (LAMMPS package 라이브러리) ├ potentials (EAM, REAX, COMB, Airebo 등의

forcefield 파일) ├ python (python 연동 관련 파일) ├ src (메인 source 파일) └ tools (pre, post 프로세스 유틸리티)

* 2. 설치 환경 설정

․Intel Cluster Studio는 Intel 프로세서에 최적화된 C++, fortran 컴파일러와

MPI, MKL(Math Kernal Library)를 통합으로 제공하기 때문에 Intel 프로

세서로 구성된 클러스터에서 용이하게 사용 가능. 해당 클러스터에서 Intel

Cluster Studio 환경을 불러오기 위해서는 module 명령어를 다음과 같이

입력

$ module purge # 기존의 설정된 환경 초기화$ module avail # 사용 가능한 module list 확인$ module load intel_cluster_studio-2013_beta # 변경 가능․Intel MPI가 아닌 Openmpi를 사용하기 위해서는 다음 명

* 3. 패키지 설정 및 빌드

․MIC offload 기능을 활용하기 위해서는 필수적인 패키지를 같이 설치. src

디렉터리에 들어가서 다음과 같이 패키지 설정

$ make yes-user-intel yes-user-omp

- 71 -

․다양한 패키지가 제공되고, make yes-“package name” 또는 make

no-“package name”으로 패키지를 추가 또는 삭제

$ make package-status ․명령어로 설치할 패키지에 대한 설정을 확인하고 설치한다. 설치는 제공된

Makefile의 기본옵션으로 진행

$make intel_offload lammps설치 디렉터리/src/MAKE/Makefile.intel_offloadSHELL = /bin/sh......CC = mpiicpc -openmp -DLMP_INTEL_OFFLOAD -DLAMMPS_MEMALIGN=64MIC_OPT = -offload-option,mic,compiler,"-fp-model fast=2 -mGLOB_default_function_attrs=\"gather_scatter_loop_unroll=4\""CCFLAGS = -g -O3 -xHost -fno-alias -ansi-alias -restrict -override-limits $(MIC_OPT)SHFLAGS = -fPICDEPFLAGS = -M

LINK = mpiicpc -openmp -offloadLINKFLAGS = -O3 -xHostLIB = SIZE = size

ARCHIVE = arARFLAGS = -rcSHLIBFLAGS = -shared......LMP_INC = -DLAMMPS_GZIP -DLAMMPS_JPEG......MPI_INC = -DMPICH_SKIP_MPICXX MPI_PATH = MPI_LIB =......FFT_INC = -DFFT_MKL -DFFT_SINGLEFFT_PATH = FFT_LIB = -L$(MKLROOT)/lib/intel64/ -lmkl_intel_ilp64 -lmkl_intel_thread -lmkl_core......

- 72 -

fix_intel.h...namespace LAMMPS_NS {...class FixIntel : public Fix { public: int nomp; //추가

FixIntel(class LAMMPS *, int, char **); ...

lmp_intel_offload 실행

LAMMPS (18 Sep 2014)WARNING: OMP_NUM_THREADS environment is not set. (../comm.cpp:88) using 1 OpenMP thread(s) per MPI task.

hostfilephi01:20phi02:20phi03:20....

※사용된 버전에서는 컴파일 도중 Error 메시지가 나오는데, fix_intel.cpp

nomp라는 변수가 정의가 안 되었다는 메시지로 컴파일이 중단됨.

fix_intel.h의 public변수로 int nomp를 추가하여 컴파일을 진행하면 문제없

이 진행됨

․컴파일을 완료한 후에 lmp_intel_offload라는 실행파일이 생성되며

./lmp_intel_offload를 실행하여 다음과 같은 출력을 확인하면 됨

※Warning은 OpenMP를 사용하는 환경변수 설정하지 않았기 때문에 발생.

다음을 실행하고 다시 한번 ./lmp_intel_offload를 실행하면 Warning이 사

라진 것을 확인할 수 있음

$export OMP_NUM_THREADS=1

* 4. 실행 방법

․intel_offload의 경우, OpenMP-MPI hybdrid 병렬화가 가능한데, 이 때 사

용하는 OpenMP threads 숫자에 따라서 hostfile을 다르게 작성해야함

․모든 CPU를 MPI를 사용하여 프로그램을 실행시키기 위해서는 다음과 같

이 hostfile을 작성

․만약 OMP_NUM_THREADS를 1보다 큰 수로 설정한다면, 그에 따라 MPI가 할

당될 노드수를 수정해야 함

- 73 -

hostfile2phi01:10phi02:10phi03:10....

in.intel_offload$ package intel 1 mode mixed balance 1 omp 0 tptask 240 $ package omp 0$ suffix intel

․OMP_NUM_THREADS=2인 경우, 다음과 같이 hostfile을 작성

․병렬 실행은 다음 명령어를 통해 수행 가능

$mpirun –n <# of MPI> -hostfile $HOME/hostfile lmp_intel_offload < input_file

[Intel 패키지]

․현재 릴리즈된 버전에서 가능한 퍼텐셜은 제한적이고 Charmm force field

와 Gayberne potential만 사용 가능

․기본적으로 입력 스크립트 내의 모든 명령어는 동일하게 사용가능하지만

입력 파일 시작부분에 다음과 같은 내용을 추가해야 함. 예제폴더에서 제

공하는 예제파일의 경우 그 인풋형식이 최근 릴리즈된 버전의 형식과 맞지

않기 때문에 다음과 같이 수정 필요

※ 처음 intel 뒤에 나오는 숫자는 1 노드당 MIC의 개수를 지정

※ mode 뒤에 나오는 mixed는 precision 선택관련 명령어: single, double,

mixed 선택 가능

※ balance의 뒤에 오는 숫자는 한 노드내에서 CPU와 MIC의 작업량을 할당

하는 변수. 1의 경우 MIC만을 사용하고, 0의 경우 CPU만을 사용한다. 0~1

의 값을 지정하여, MIC와 CPU의 작업할당량을 임의로 변경 가능. -1의

경우는 자동으로 작업량을 할당하며, 시스템 사이즈별로 최적화된 할당량

이 다르기 때문에 최적화된 작업량비율을 할당해야 함. 하지만 –1 옵션으

로 최적화된 작업량비율은 어느 정도 잘 조절이 되는 것으로 보임

※ omp 뒤에 오는 숫자는 CPU와 MIC를 동시에 활용할 경우 CPU에서

MPI당 활용하는 OMP Thread의 개수를 지정. 이 숫자는 MIC의 thread개

수와는 무관하며 0의 경우 환경변수에서 지정된 값을 사용

※tptask 뒤에 오는 숫자는 MIC에서 사용하는 최대 threads의 개수. Xeon

Phi의 경우 60 core 사용을 기준으로 한 코어에 4 threads를 할당하여 240

이 기본 설정

- 74 -

※ package omp 0 의 경우, 숫자는 MPI작업당 사용하는 thread의 개수를

의미하며, 0은 환경변수 OMP_NUM_THREADS 값을 사용

※ suffix intel의 경우 CPU에서 실행되는 명령어를 자동으로 intel offload가

사용가능하게끔 변경해 주는 역할. Charmm의 경우 pair_style 명령어는

lj/charmm/coul/long이 되는데 suffix intel의 역할은 이것을

lj/charmm/coul/long/intel로 바꿔주는 역할. 이는 기타 omp package, cuda,

gpu등에서도 동일함

- 75 -

∙ 수행 내용

- NVIDIA GPU 벤치마크 수행 시스템

* Lennard-Jones 입자 (약 100만개의 입자)

* EAM(Embeded Atom Method) 입자 (Cu (구리) 원자 1,048,576개)

* Long range Coulomb interaction 시스템 (Charged particle 295,650개로 이

루어진 모델에 대해 PPPM scheme을 적용하여 NPT dynamics 수행):

FFT 계산이 포함

* 일반 분자 시스템 (Charmm force field: 원자 256,000개)

* 시스템 크기에 따른 GPU 효과

* Lennard-Jones 입자 (약 100만개의 입자)

․Lennard-Jones 포텐셜로 단원자 입자들간의 상호관계를 모사하는 가장 기

본적인 분자동역학 시스템에 대해서 GPU에 의한 성능 향상정도를 평가

․약 100만개의 입자로 구성된 시스템이며 다음은 사용한 input과 명령어

CPU 계산 <input file> in.lj.cpuunits ljatom_style atomiclattice fcc 0.8442region box block 0 64 0 64 0 64 # 1,048,675ea LJ particlescreate_box 1 boxcreate_atoms 1 boxmass 1 1.0velocity all create 1.44 87287 loop geompair_style lj/cut 2.5pair_coeff 1 1 1.0 1.0 2.5neighbor 0.3 binneigh_modify delay 0 every 20 check nofix 1 all nverun 1000 # 1,000 timestep$ mpirun –np <number of processes> –hostfile $HOME/hostfile $HOME/programs/lammps-1Feb14/src/lmp_gpu –c off –in <input file>

- 76 -

GPU 패키지 계산 <input file> in.lj.gpunewton offpackage gpu force/neigh 0 0 –1 # dynamic load balanceunits ljatom_style atomiclattice fcc 0.8442region box block 0 64 0 64 0 64create_box 1 boxcreate_atoms 1 boxmass 1 1.0velocity all create 1.44 87287 loop geompair_style lj/cut/gpu 2.5pair_coeff 1 1 1.0 1.0 2.5neighbor 0.3 binneigh_modify delay 0 every 20 check nofix 1 all nverun 1000$ mpirun –np <number of processes> –hostfile $HOME/hostfile $HOME/programs/lammps-1Feb14/src/lmp_gpu –c off –sf gpu -in <input file>

CUDA 패키지 계산 <input file> in.lj.cudapackage cuda gpu/node 1units ljatom_style atomiclattice fcc 0.8442region box block 0 64 0 64 0 64create_box 1 boxcreate_atoms 1 boxmass 1 1.0velocity all create 1.44 87287 loop geompair_style lj/cut 2.5pair_coeff 1 1 1.0 1.0 2.5neighbor 0.3 binneigh_modify one 10000neigh_modify delay 0 every 20 check nofix 1 all nverun 1000$ mpirun –np <number of processes> –hostfile $HOME/hostfile $HOME/programs/lammps-1Feb14/src/lmp_gpu –c on –sf cuda -in <input file>

- 77 -

* EAM 입자

․EAM (Embeded Atom Method) 포텐셜은 주로 금속 원소들의 결합력을

분자동역학 시스템 내에서 모사하기 위해 설계된 것으로, 일반적인 공유결

합과 특성이 달라 분자동역학에서 다루기 힘든 금속의 거동을 모사하는데

널리 사용됨

․여기에서는 Cu (구리) 원소 1,048,576개로 이루어진 결정이 1,600K에서 녹

는 과정을 시뮬레이션 하였으며, 다음은 사용한 input

CPU 계산 <input file> in.eam.cpuunits metalatom_style atomiclattice fcc 3.615region box block 0 64 0 64 0 64 # 1,048,675ea LJ particlescreate_box 1 boxcreate_atoms 1 boxpair_style eampair_coeff 1 1 Cu_u3.eam # Cu EAM 포텐셜 파일

velocity all create 1600.0 376847 loop geomneighbor 1.0 binneigh_modify every 1 delay 5 check yesfix 1 all nvetimestep 0.005thermo 50run 100

- 78 -

GPU 패키지 계산 <input file> in.eam.gpunewton offpackage gpu force/neigh 0 0 1 # GPU 패키지에서는 splitting 1 만

허용

units metalatom_style atomiclattice fcc 3.615region box block 0 64 0 64 0 64create_box 1 boxcreate_atoms 1 boxpair_style eampair_coeff 1 1 Cu_u3.eamvelocity all create 1600.0 376847 loop geomneighbor 1.0 binneigh_modify every 1 delay 5 check yesfix 1 all nvetimestep 0.005thermo 50run 100

CUDA 패키지 계산 <input file> in.lj.cudapackage cuda gpu/node 1units metalatom_style atomiclattice fcc 3.615region box block 0 64 0 64 0 64create_box 1 boxcreate_atoms 1 boxpair_style eampair_coeff 1 1 Cu_u3.eamvelocity all create 1600.0 376847 loop geomneighbor 1.0 binneigh_modify every 1 delay 5 check yesfix 1 all nvetimestep 0.005thermo 50run 100

※GPU 패키지에서 EAM 포텐셜 사용 시 주의해야할 점은 load splitting 변

수를 1만 적용 가능가능함 (“package gpu force/neigh 0 0 1”에서 마지막

변수). Auto balancing 조건인 –1은 허용되지 않음

- 79 -

* Long range Coulomb interaction 시스템

․분자동역학 시뮬레이션에서 가장 상호작용 거리가 긴 쿨롱 작용을 제한된

모델 시스템 내에서 효과적으로 계산하기 위해 LAMMPS에는 FFT를 활

용한 Ewald summation method (kspace_style ewald)와 particle-particle

particle-mesh solver (kspace_style PPPM) 가 적용되어 있음

※주의할 사항은 GPU나 CUDA 패키지의 경우 Ewald method는 지원하지

않기 때문에 PPPM method만 사용 가능함. 또한 –sf gpu|cuda 명령줄 옵

션을 사용한다 하더라도 pppm scheme에는 자동으로 적용되지 않기 때문

에 kspace_stype에 pppm 대신 pppm/gpu 또는 pppm/cuda로 명시해주어야

함

․FFT 계산이 포함되어 있기 때문에 일반적인 분자동역학 계산보다 컴퓨팅

파워가 더 요구됨

․Charged particle 295,650 개로 이루어진 모델에 대해 PPPM scheme을 적

용하여 NPT dynamics 시뮬레이션을 수행하였고, input은 다음과 같음

※본 시스템을 구동하기 위해서는 원소들의 위치가 미리 지정되어있는 data

파일을 필요로 하며 다음 경로에서 찾을 수 있음

<$LAMMPS_HOME>/examples/gpu/data.phosphateCPU 계산 <input file> in.cpu.phosphateunits metalatom_style chargeread_data data.phosphate # 미리 정의된 data 파일 로딩

replicate 3 3 3pair_style lj/cut/coul/long 15.0pair_coeff 1 1 0.0 0.29pair_coeff 1 2 0.0 0.29pair_coeff 1 3 0.000668 2.5738064pair_coeff 2 2 0.0 0.29pair_coeff 2 3 0.004251 1.91988674pair_coeff 3 3 0.012185 2.91706967kspace_style pppm 1e-5 # pppm type 쿨롱 작용 계산

neighbor 2.0 binthermo 100timestep 0.001fix 1 all npt temp 400 400 0.01 iso 1000.0 1000.0 1.0run 200unfix 1

- 80 -

GPU 패키지 계산 <input file> in.gpu.phosphateunits metalnewton offpackage gpu force/neigh 0 0 1atom_style chargeread_data data.phosphatereplicate 3 3 3pair_style lj/cut/coul/long/gpu 15.0pair_coeff 1 1 0.0 0.29pair_coeff 1 2 0.0 0.29pair_coeff 1 3 0.000668 2.5738064pair_coeff 2 2 0.0 0.29pair_coeff 2 3 0.004251 1.91988674pair_coeff 3 3 0.012185 2.91706967kspace_style pppm/gpu 1e-5 # pppm/gpu로 명시

neighbor 2.0 binthermo 100timestep 0.001fix 1 all npt temp 400 400 0.01 iso 1000.0 1000.0 1.0run 200unfix 1CUDA 패키지 계산 <input file> in.cuda.phosphateunits metalpackage cuda gpu/node 1atom_style chargeread_data data.phosphatereplicate 3 3 3pair_style lj/cut/coul/long 15.0pair_coeff 1 1 0.0 0.29pair_coeff 1 2 0.0 0.29pair_coeff 1 3 0.000668 2.5738064pair_coeff 2 2 0.0 0.29pair_coeff 2 3 0.004251 1.91988674pair_coeff 3 3 0.012185 2.91706967kspace_style pppm/cuda 1e-5 # pppm/cuda로 명시

neighbor 2.0 binthermo 100timestep 0.001fix 1 all npt temp 400 400 0.01 iso 1000.0 1000.0 1.0run 200unfix 1

- 81 -

GPU 패키지 계산 <input file> in.gpu.rhodonewton offpackage gpu force/neigh 0 0 -1units realneighbor 2.0 binneigh_modify delay 5 every 1atom_style fullbond_style harmonic

* 일반 분자 시스템

․일반 분자 시스템은 원소들만으로 이루어진 Lennard-Jones, EAM 모델 등

에서 더 나아가 원소들 간의 결합(bonding)이 정의되어 있어 원소들 간의

상호작용을 계산할 때 결합에 의한 작용까지 모두 포함하여 계산하게 되

며, 계산 로드는 제일 큰 시스템

․본 평가에서는 256,000개의 원소와 221,784개의 결합이 정의되어 있는 단

백질 시스템에 대해서 시뮬레이션을 진행하였고, 다음은 input

※Long-range 쿨롱 시스템과 마찬가지로 원소들의 위치와 결합에 대한 정보

는 data 파일에 따로 정의되어 있으며 위치는 다음에서 찾을 수 있다.

<$LAMMPS_HOME>/examples/gpu/data.rhodoCPU 계산 <input file> in.cpu.rhodounits realneighbor 2.0 binneigh_modify delay 5 every 1atom_style fullbond_style harmonicangle_style charmmdihedral_style charmmimproper_style harmonicpair_style lj/charmm/coul/long 8.0 10.0pair_modify mix arithmetickspace_style pppm 1e-4read_data data.proteinreplicate 2 2 2fix 1 all shake 0.0001 5 0 m 1.0 a 232fix 2 all npt temp 300.0 300.0 100.0 z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1special_bonds charmmthermo_style multitimestep 2.0run 100

- 82 -

angle_style charmmdihedral_style charmmimproper_style harmonicpair_style lj/charmm/coul/long 8.0 10.0pair_modify mix arithmetickspace_style pppm/gpu 1e-4read_data data.proteinreplicate 2 2 2fix 1 all shake 0.0001 5 0 m 1.0 a 232fix 2 all npt temp 300.0 300.0 100.0 z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1special_bonds charmmthermo_style multitimestep 2.0run 100CUDA 패키지 계산 <input file> in.cuda.phosphatepackage cuda gpu/node 1units realneighbor 2.0 binneigh_modify delay 5 every 1atom_style fullbond_style harmonicangle_style charmmdihedral_style charmmimproper_style harmonicpair_style lj/charmm/coul/long 8.0 10.0pair_modify mix arithmetickspace_style pppm/cuda 1e-4read_data data.proteinreplicate 2 2 2fix 1 all shake 0.0001 5 0 m 1.0 a 232fix 2 all npt temp 300.0 300.0 100.0 z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1special_bonds charmmthermo_style multitimestep 2.0run 100

- 83 -

in.intel.rhodo (MIC+CPU)# Rhodopsin modelpackage intel 1 mode mixed balance -1 omp 1 tptask 240package omp 0suffix intel

variable x index 4 #시스템사이즈 조절 1,2,4 에대해서 각각 테스트진행

variable y index 4 # 1,1,1 = 3만2천개, 2,2,2 256000개, 4,4,4 2048000개

variable z index 4

units realneigh_modify delay 5 every 1

atom_style fullatom_modify map hashbond_style harmonicangle_style charmmdihedral_style charmmimproper_style harmonicpair_style lj/charmm/coul/long 8.0 10.0pair_modify mix arithmetickspace_style pppm 1e-4

read_data data.rhodo

replicate $x $y $z

fix 1 all shake 0.0001 5 0 m 1.0 a 232fix 2 all npt temp 300.0 300.0 100.0 & z 0.0 0.0 1000.0 mtk no pchain 0 tchain 1

special_bonds charmm

- Xeon Phi 벤치마크 수행 시스템

* 일반 분자 시스템 (Charmm force field: 원자 32,000개, 256,000개,

2,048,000개)

* 액정 시스템 (Gayberne force field: 원자 32,700개, 260,000개, 2,010,000개)


․벤치마크 테스트로 example/user-intel 디렉터리에 제공되는 입력파일을

수정. 다음은 MIC, MIC+CPU, CPU에 대한 인풋파일

- 84 -

thermo 50thermo_style multitimestep 2.0

run 100in.intel.rhodo_cpu (CPU)# Rhodopsin model

variable x index 4 #시스템사이즈 조절 1,2,4 에 대해서 각각 테스트진행


variable z index 4




replicate $x $y $z




run 100

- 85 -

in.intel.rhodo_mic (MIC)# Rhodopsin modelpackage intel 1 mode mixed balance 1 omp 1 tptask 240 package omp 0 suffix intel



variable z index 4




replicate $x $y $z




run 100

- 86 -

in.intel.lc (MIC+CPU)# Gay-Berne benchmark# biaxial ellipsoid mesogens in isotropic phase# shape: 2 1.5 1# cutoff 4.0 with skin 0.8# NPT, T=2.4, P=8.0

package intel 1 mode mixed balance -1 omp 1 tptask 240 package omp 0suffix intel

processors * * * grid numa


variable y index 4 # 1,1,1 = 32000개, 2,2,2 26000개, 4,4,4 2090000개

variable z index 4

variable i equal $x*32variable j equal $y*32variable k equal $z*32

units ljatom_style ellipsoid

# creationlattice sc 0.22region box block 0 $i 0 $j 0 $kcreate_box 1 boxcreate_atoms 1 box

set type 1 mass 1.5set type 1 shape 1 1.5 2set group all quat/random 982381

compute rot all temp/aspheregroup spheroid type 1

* 액정 시스템

․Gayberne force field는 액정 (liquid crystal)과 같은 anisotropic 입자를 다

룰 때 사용됨

․다음은 MIC, MIC+CPU, CPU에 사용된 각각의 입력 파일

- 87 -

variable dof equal count(spheroid)+3compute_modify rot extra ${dof}


pair_style gayberne 1.0 3.0 1.0 4.0pair_coeff 1 1 1.0 1.0 1.0 0.5 0.2 1.0 0.5 0.2

neighbor 0.8 bin

timestep 0.002thermo 300

# equilibration runfix 1 all npt/asphere temp 2.4 2.4 0.1 iso 5.0 8.0 0.1compute_modify 1_temp extra ${dof}run 210thermo 50

reset_timestep 0unfix 1fix 1 all nve/asphererun 100

in.intel.lc_mic (MIC)# Gay-Berne benchmark# biaxial ellipsoid mesogens in isotropic phase# shape: 2 1.5 1# cutoff 4.0 with skin 0.8# NPT, T=2.4, P=8.0

package intel 1 mode mixed balance 1 omp 1 tptask 240 package omp 0suffix intel




variable z index 4

- 88 -





compute rot all temp/aspheregroup spheroid type 1variable dof equal count(spheroid)+3compute_modify rot extra ${dof}



neighbor 0.8 bin



reset_timestep 0unfix 1

- 89 -

fix 1 all nve/asphererun 100

in.intel.lc_cpu (CPU)# Gay-Berne benchmark# biaxial ellipsoid mesogens in isotropic phase# shape: 2 1.5 1# cutoff 4.0 with skin 0.8# NPT, T=2.4, P=8.0




variable z index 4





compute rot all temp/aspheregroup spheroid type 1variable dof equal count(spheroid)+3compute_modify rot extra ${dof}


- 90 -


neighbor 0.8 bin



reset_timestep 0unfix 1fix 1 all nve/asphererun 100

- 91 -

∙ 결과


단일노드 (Single-Node) 멀티노드 (Multi-Node)

Lennard-Jo

nes 입자

(약

백만개)

GPU 패키지: CPU 계산(20ppn)대비

20ppn+1GPU는 약2.65배 향상

CUDA 패키지: CPU

계산(20ppn)대비 1GPU추가시 약

2.77배 향상

GPU 패키지: 단일노드(20ppn+1GPU)

대비 2개는 1.85배, 4 개는 3.93배 향상

CUDA 패키지: 단일 노드 대비 노드

2개에서 1.68배, 노드 4개에서 2.74배

향상

EAM 입자

(Cu

1,048,576개

)


20ppn+1GPU는 약 3.32배 향상

CUDA 패키지: CPU


3.19배 향상

GPU패키지: 단일노드(20ppn+1GPU)

대비 2개는 1.84배, 4개는 3.82배 향상


2개에서 1.78배, 4개에서 3.2배 향상

Long

range 쿨롱

시스템

(원자

295,650개)



CUDA 패키지: CPU


1.55배 향상


대비 2개는 1.63배, 4개는 4.03배 향상



일반 분자

시스템

(원자

256,000개)



CUDA 패키지: CPU


17배 성능감소


대비 2개는 1.55배, 4개는 3.85배 향상



※ ppn: process per node (MPI병렬실행시 노드별 프로세스 할당 개수)

※ NVIDIA 보고서에 따르면 GPU 패키지인 경우 MPS 사용시 단일노드 기준으

로 Lennard-Jones는 1.1배, EAM은 1.25배 정도의 성능향상을 기대할 수 있음

(하지만 멀티노드에서 Lennard-Jones는 MPS 적용시 성능향상이 거의 없음)

- 92 -

* Lennard-Jones 입자

․다음 그림은 노드 하나에서 가용할 수 있는 GPU 카드 한장과 호스트의

20 코어수 까지 사용한 결과

Lennard-Jones 1,048,576 입자 계산속도 비교

※CPU만 사용한 경우 1ppn에서 20ppn까지 선형적으로 계산속도가 향상되는

것을 확인하였으며, GPU 패키지를 사용한 경우 1ppn+GPU 조건에서 CPU

계산 대비 약 14배의 성능 증가를 얻을 수 있었음

※CUDA 패키지를 사용한 경우에는 1ppn+CUDA 조건에서 CPU 계산 대비

약 45배의 성능 증가를 얻을 수 있었음

※GPU 패키지 사용 조건에서 ppn을 올릴 경우 추가적인 성능 증가를 얻을

수 있으나 (20ppn+gpu 조건에서 1ppn+gpu 대비 약 3배, cpu 대비 약 43

배) 10ppn+gpu 수준에서 병렬화 효율이 더 이상 증가하지 않았음

※CUDA 패키지는 1ppn에서 사용하도록 설계되어 있기 때문에 ppn을 올릴

경우 오히려 계산 속도가 저하됨 (2ppn+cuda 조건에서 loop time 25.6초)

※결과적으로 GPU를 연동함으로써 CPU 계산 대비 최대 45배까지 계산 속

도가 향상되었으며, CUDA 패키지가 제일 우수한 성능을 나타냄. 그리고

GPU가 연동되면 CPU에 의한 계산속도 향상 효과는 상대적으로 낮은 것

으로 평가됨

- 93 -

․다음 그림은 노드를 2개 이상 사용하여 여러 기의 GPU를 사용한 결과

Lennard-Jones 시스템 멀티노드 사용 시 계산속도 비교

※ 노드 2개의 CPU를 모두 사용한(40ppn) 결과 5ppn+GPU 계산과 유사한

성능을 보였으며 노드 2개의 CPU와 GPU를 모두 사용하면 (40ppn+2gpu)

노드 1개를 모두 활용했을 경우(20ppn+1GPU) 대비 약 2배의 성능 향상을

얻을 수 있음

※추가적으로 CPU의 병렬화 효과를 배제하고 GPU에 의한 효과를 극대화시

키기 위해 각 노드의 CPU는 1 프로세스만 사용하고 (1ppn) 각 노드의

GPU를 모두 활용하여 노드 4기 까지 평가한 결과를 그림에 1x2, 1x3, 1x4

로 표시하였으며, GPU, CUDA 패키지 모두 추가적인 성능 향상을 보였음

※종합적으로 볼 때 GPU를 연동한 계산속도 향상 정도는 CPU를 적게 사용

하는 상황에서 극대화 되는 것을 알 수 있으며, CUDA 패키지의 GPU 활

용 성능이 제일 좋은 것을 알 수 있음

- 94 -

․다음 그림은 LAMMPS 계산 과정에서 GPU에 의해 가속화되는 부분을 정

확히 비교하기 위해 1ppn, 1ppn+gpu, 1ppn+cuda 조건에서 주요 계산 프로

세스별 타이밍 비교

※LAMMPS 시뮬레이션에서 대부분을 차지하는 입자간 pair 상호작용과

neighbor 리스트를 작성하는 부분에서 GPU에 의해 계산 속도가 대폭 향

상되는 것을 확인할 수 있음

Lennard-Jones 시스템 계산 프로세스별 타이밍 비교

* EAM 입자

․다음 그림은 노드 1개에서 GPU 관련 패키지 성능 향상 효과

EAM 1,048,576 입자 계산속도 비교

※CPU 프로세스 1개를 사용한 조건에서(1ppn) GPU 패키지 사용 시 CPU

대비 약 24배의 성능 향상이 있었으며, CUDA 패키지 사용 시 CPU 대비

약 43배의 성능 향상

- 95 -

※CPU 프로세스를 20개 까지 사용한 (20ppn) 경우보다도 2~3배 정도 빠른

속도이며, GPU 1기에 의한 성능 향상 효과가 EAM 모델에서도 잘 적용되

는 것으로 평가됨

※GPU 패키지 사용 시 CPU 프로세스 개수를 증가시킬 경우 추가적으로 2

배 정도의 성능 향상을 얻을 수 있음

․다음 그림은 멀티노드에서 2개 이상의 GPU를 활용한 계산 결과

EAM 멀티노드 사용 시 계산속도 비교

※Lennard-Jonse 시스템과 유사하게 GPU 사용 개수가 늘어나면서 추가적인

속도 향상 효과를 얻을 수 있었고, CUDA 패키지가 가장 좋은 성능

․다음 그림에서 EAM 계산 프로세스별 타이밍 비교

EAM 계산 프로세스별 타이밍 비교

※Lennard-Jones 입자 시스템과 마찬가지로 EAM 시스템에서도 pair와

neighbor 계산 프로세스의 속도가 GPU에 의해 가속화되면서 전체적인 시

뮬레이션 속도가 향상된 것을 확인가능

- 96 -

* Long range Coulomb interaction 시스템

․다음 그림은 long-range 쿨롱 시스템에 대한 GPU 적용 결과

Long range 쿨롱 계산을 적용한 시스템에 대한 계산속도 비교

※ 1 ppn 조건에서 GPU 패키지의 경우 CPU 대비 약 7배의 성능 향상이 있

었고, CUDA 패키지의 경우 약 26배의 큰 성능 향상을 보였음

※ CPU 프로세스 사용을 늘일수록 CPU 계산과 GPU 계산의 격차는 감소

․다음 그림은 멀티노드 사용 시 GPU 계산 성능 향상 효과

Long-range 쿨롱 시스템 멀티노드 사용 시 계산속도 비교

※ Long-range 쿨롱 시스템에서도 다른 시스템과 마찬가지로 GPU를 멀티

로 사용하면서 계산 속도가 비례하게 향상되는 것을 확인 할 수 있음

- 97 -

일반 분자시스템에 대한 GPU/CUDA 패키지 성능 비교

․다음 그림은 계산 프로세스별 타이밍 비교 결과

Long-range 쿨롱 시스템 계산 프로세스 타이밍 비교

※ CPU 계산에서 대부분을 차지하는 FFT 계산이 GPU에서 가속화되면서

전체 계산 속도의 향상이 이루어졌고, GPU 패키지에서는 pair 계산의 가

속화 정도가 CUDA 패키지에 비해 낮은 것으로 보아 코드 최적화의 여지

가 남아있을 것으로 생각됨


․다음 그림은 일반 분자시스템에 대한 GPU/CUDA 패키지 성능 비교

- 98 -

일반 분자 시스템에 대한 멀티노드 사용 시 계산속도 비교

※ GPU 패키지 사용 시 CPU대비 약 9배 속도가 향상되었으며 CUDA 패키

지 사용 시 약 15배 향상

※ 앞서 수행한 결합이 없는 시스템에 비해 속도 향상 정도가 제일 적으며,

이는 결합과 관련된 분자 내부의 진동, 회전 등을 계산하는데 CPU 로드를

많이 사용하게 되기 때문임. 그 결과 결합이 없는 시스템과는 달리 CPU만

으로 20ppn 시뮬레이션 할 경우 1ppn+gpu 또는 1ppn+cuda의 경우보다 계

산 속도가 더 빠르게 수행됨

․다음 그림은 멀티노드 사용 시 GPU 계산 성능 향상 효과

※ 멀티 GPU 사용의 경우를 보면 노드 2기의 CPU를 모두 사용하는 경우와

GPU 패키지나 CUDA 패키지를 사용하는 경우 계산 속도의 차이가 크게

나지 않는 것을 알 수 있음. 이는 복잡한 시스템으로 갈수록 GPU 뿐만 아

니라 CPU 리소스에도 의존성이 커지기 때문

* 시스템 크기에 따른 GPU 효과

․ 일반적으로 병렬화 효과는 시스템의 크기 (원자, 분자의 개수)에 따라 차

이가 있으며, 시스템이 작은 경우에는 오히려 단일 프로세스 계산 보다 느

려지는 경우도 발생함

․GPU를 연동한 계산도 역시 GPU에 있는 다수의 CUDA 코어에 분산시켜

계산을 수행하는 방식이기 때문에 시스템 크기에 따른 병렬화 효과에 차이

가 발생

- 99 -

시스템 크기에 따른 GPU 패키지의 병렬화 효율

․여기서는 Lennard-Jones 입자의 개수에 따른 CPU, GPU, CUDA 계산의

병렬화 효율 결과를 정리하였음

. 다음 그림은 CPU 계산의 병렬화 효율

시스템 크기에 따른 CPU 계산의 병렬화 효율

※ CPU 계산에서는 시스템 크기가 제일 작은 2,048의 경우에 CPU 프로세스

40개 이상에서 병렬화 효과가 더 이상 보이지 않았으나 그 이상의 경우에

는 노드 12개를 모두 사용할 때까지 병렬화에 의한 속도 증가 효과를 얻을

수 있었음

. 다음 그림은 GPU 패키지의 병렬화 효율

- 100 -

※ GPU 패키지 계산에서는 시스템이 작은 경우 GPU 1개를 사용하고 CPU

프로세스 개수를 늘인 경우나 GPU를 여러 개 사용한 경우 모두 병렬화

효과가 좋지 않았음. 특히 CPU 프로세스를 늘인 경우에는 오히려 계산 속

도가 느려지는 경우가 발생함

. 다음 그림은 CUDA 패키지의 병렬화 효율

시스템 크기에 따른 CUDA 패키지의 병렬화 효율

※ CUDA 패키지의 경우 역시 시스템이 작은 경우에는 GPU 병렬화에 따라

오히려 계산 속도가 느려지는 것이 확인되었고, 적어도 입자 10만개 이상

에서 병렬화에 의한 계산 속도 향상을 얻을 수 있음

. 결과적으로 GPU를 활용한 계산을 수행할 때 시스템 크기에 따라 병렬화

및 GPU에 의한 계산 효율이 오히려 낮아지는 경우가 발생하기 때문에 시

스템 크기에 맞게 적절한 하드웨어 배분이 필요하다고 볼 수 있으며, GPU

연동은 기본적으로 10만개 이상의 입자로 이루어진 규모가 큰 시스템에서

적용할 경우에 효율적인 것으로 판단됨

- 101 -

- Xeon Phi 테스트

단일 노드(Single-Node) 멀티 노드(Multi-Node)

일

반

분

자

시

스

템

원자

32,000

개

CPU 계산(20ppn)대비

20ppn+1MIC는 약1.53배

향상

단일 노드(20ppn+1MIC) 대비 2개는 1.18배,

4개는 1.37배, 8개는 1.73배 향상

원자

256,000

개



향상

단일 노드 대비 2개는 1.58배, 4개는 2.38배,

12개는 5.15배 향상

원자

2,048,00

0개



향상

단일 노드 대비 2개는 1.94배, 4개는 3.61배,

12개는 3.61배 향상

액

정

시

스

템

원자

32,768

개



향상

단일 노드대비(20ppn+1MIC) 2개는 2.32배,

4개는 4.41배, 12개는 2.32배 향상

원자

262,144

개



향상

단일 노드대비 2개는 2.05배, 4개는 2.13배,

12개는 5.14배 향상

원자

2,097,15

2개


40ppn+2MICs는 약8.27배

향상

(20ppn+1MIC에서 실행불가)

2개 노드대비 4개는 1.89배, 8개는 3.25배,

12개는 4.20배 향상

※ 200만개, 20만개수준의 시스템에서 12 노드까지 양호한 병렬확장성을 보

였으나 3만개 수준의 시스템에서는 분자시스템에서는 병렬확장성이 좋지

않음

※ Flops수를 고려한 성능효율 50%이상 활용하는 것을 기준으로 할 경우 3

만개 시스템에서 일반적인 분자는 CPU만을 사용 (Tachyon2 사용),

Gayberne 시스템에서는 4개의 노드 이하를 사용해야 함. 즉 계산하는 시스

템 (퍼텐셜의 종류)과 사이즈에 따라서 효율적으로 사용할 수 있는 노드

수가 다름

※ 200만개 시스템에서 20 CPU대비 MIC만을 사용할 경우, 일반적인 분자시

스템에서 2.7배, Gayberne시스템에서 6.0배 이상의 성능향상을 보임.

CPU20개가 400GFlops MIC가 1200GFlops 임을 고려하면, 제공되는 가속

기 환경에서 각각 75%, 200% 이상의 성능 효율이 나옴. 하지만 사이즈가

줄어들면 통신에 의한 성능 저하로 효율이 현저히 떨어짐

- 102 -


․ 다음 그림처럼 약 200만개의 원자 시스템에서는 12노드를 모두 사용했을

때 매우 좋은 병렬확장성을 보임

200만개 원자로 이루어진 분자시스템 100step에

소요된 시간. CPU, MIC, CPU+MIC 모두 좋은

병렬확장성을 보인다.

․다음 그림은 25만개 시스템에서 결과

25만개의 원자로 이루어진 분자 시스템. 비교적 좋은 병렬

확장성을 보이지만 160 코어 이상의 경우 약간의 성능저하를 보임

- 103 -

․다음 그림은 3만2천개의 시스템에서 결과. 2개 노드 이상인 경우에 병렬확

장성이 없음

3만2천개 원자로 이루어진 분자시스템. 낮은 병렬확장성을

보인다. 40 코어(2노드) 이상 사용할 때에는 MIC사용하는

의미가 없음

․ 성능평가

이론적인 CPU 20개와 MIC의 성능은 400+1200 GFlops 이며, 분자동력학

프로그램에서 이를 100프로 사용하는 것은 불가능함. 그렇기 때문에 시스

템의 성능 이론치 대비 프로그램의 성능을 측정하는 것은 하이브리드 시스

템에서 큰 의미가 없음. 하지만 CPU200의 성능을 1로 환산하여 MIC의 이

론적인 성능, MIC+CPU의 이론적인 성능 대비 실제 계산 성능을 계산하여

MIC로 포팅된 프로그램의 효율 및 MIC+CPU의 연동효율을 어림잡는 것

은 가능함. 즉, CPU 환경에서 최적화된 성능 1(400GFlops) 을 MIC에서

100로 활용가능하다면 그 이론치는 3(1200GFlops)이 될 것이고 MIC+CPU

의 경우는 4(400+1200=1600GFlops)가 됨. 이를 기준으로 효율성능을 분석

하였음. PCI를 통한 CPU와 MIC간의 통신속도 및 CPU와 MIC간의 로드밸

런스가 완벽하지 않기 때문에 성능 효율은 100%를 넘기 어렵지만 입자의

수가 많을수록 사용하는 노드의 수가 적을수록 효율은 100%에 가까워지며

이 수치를 통해서 사용자는 자신의 사용할 계산가속기의 노드의 개수를 어

림 할 수 있음

- 104 -

2,000,000 원자에 대해서

Flops 수를 고려한 성능효율

250,000 원자에 대해서


32,000 원자에 대해서


- 105 -

–통신 속도에 의한 성능 저하가 생기지 않는 범위 내에서 많은 수의 노

드를 사용할수록 사용자 입장에서 계산의 속도가 빨라지기 때문에 (위의

그림에서 CPU만 사용한 성능에 주목하였을 때 160개를 사용할 때 까지

계속 좋아지지만 240개를 사용할 때는 오히려 성능이 저하됨) 사용자의 선

택에 따라 사용노드수가 달라지겠지만 사용자는 사용시간을 할당받기 때문

에 조금 속도가 느리더라도 적은양의 자원을 활용하여 효율을 극대화할 필

요가 있음

– 예를 들어 효율의 기준을 50%로 잡는다고 생각하면, 2백만개 이상의

시스템에서는 12계산노드를 다 사용해도 60%(CPU+MIC) 이상의 성능효율

이 나오기 때문에 모든 노드를 활용하는 선택을 하는 것이 나음. 하지만, 2

만5천개 시스템에서는 노드를 2개까지 사용할 경우만 성능이 50%가 넘음.

또한 3만2천개의 시스템에서는 1노드를 사용해도 그 성능효율이 50%를 넘

지 못함. 이 경우 사용자는 계산 가속기시스템을 활용하는 것 보다 CPU로

만 구성된 클러스터 시스템을 활용하는 것이 사용자 입장에서 더 효율적임

* 액정 시스템

2백만 개 Gayberne 퍼텐셜 시스템의 병렬확장성 평가

1노드(20개 코어) 사용할 경우 MIC 메모리 문제로

실행불가

- 106 -

26만개 시스템에서 병렬확장성 테스트

3만2천 입자시스템 병렬확장성테스트

․일반적인 분자시스템에 비해서 Gayberne 시스템은 MIC를 활용할 때 더

좋은 성능을 보임

․병렬 확장성의 경우 분자시스템과 비슷한 수준으로 확장성이 좋았으며, 작

은 사이즈의 시스템에서도 CPU 병렬확장성이 뛰어난 것으로 보아, 일반적

인 분자시스템보다 통신에 할당되는 시간이 적다는 것을 알 수 있음

․기본적으로 FFT를 사용하지 않기 때문에 전체 노드가 통신을 필요로 하

는 계산이 분자시스템보다 적기 때문이라고 추측할 수 있음. 또한 Flops수

를 고려한 성능 효율이 매우 좋게 나타나는데 몇 가지 세부 항으로 나누어

지는 일반 분자시스템과는 달리, Gayberne 시스템은 1종류의 pair만 고려

하기 때문에 MIC성능향상에 필수적인 벡터화의 효율이 높기 때문일 것이

라도 추정됨

․성능평가

- 107 -

2백만개 시스템에서 Flops수를 고려한 성능효율.

1노드의 경우 메모리 문제로 실행 불가

26만개 입자 시스템에서 Flops수를 고려한 성능 효율

3만2천개 입자시스템에서 Flops수를 고려한 계산 효율

- 108 -

* GPU, CUDA 패키지와 성능 비교

․25만6개 원자로 이루어진 일반 분자 시스템(rhodo.data, 2x2x2)을 기준으로

GPU, CUDA패키지와 성능을 비교

․GPU 및 CUDA패키지를 사용한 결과는 기본적으로 2x2x2사이즈로

100step의 loops시간을 동일하게 측정하였기 때문에 비교가 가능. 두 시스

템이 스펙이 다르기 때문에 정확 비교가 불가능하지만, 사용하는 가속기

(GPU or Xeon phi) 개수를 늘릴수록 병렬확정성에 의해서 성능차이가 줄

어들었고 1개의 가속기를 사용할 때 Xeob phi의 성능이 GPU대비 2배 이

상 좋게 나타남

분자 시스템의 NVIDIA GPU와 Xeon Phi 성능 비교

(GPU대비 Xeon Phi성능이 1.3배이상 빠름)

- 109 -

<부록3-1: LAMMPS에 대해서 NVIDIA에서 직접 수행한 벤치마크>

* LAMMPS Feb14버전에 대해서 테스트

※ 다음 테스트베드에서 테스트

․Intel IvyBridge E5-2690 v2 @ 3.00GHz, dual socket, 10 CPU cores per socket

․FDR Infiniband

․128GB of memory

․각 노드마다 K40 카드 한 장 혹은 두 장 장착

* 설치 순서

1) tar -xzf lammps_stable.tar.gz && cd lammps-1Feb14/ 2) cd lib/gpu 3) Makefile.linux 수정. CUDA_INCLUDE and CUDA_LIB를 다음과 같이 수정

필요

CUDA_HOME = /usr/local/cuda It is also suggested that when building for an NVIDIA Kepler GPU, set the following: CUDA_ARCH = -arch=sm_35 ․수정 후에 다음 make명령어 실행

make -f Makefile.linux If this completes successfully, libgpu.a and Makefile.lammps will be created. It may be necessary to edit Makefile.lammps to point to your CUDA installation, for example: gpu_SYSPATH = -L$(CUDA_HOME)/lib64 4) cd ../../src Edit MAKE/Makefile.g++ to reflect your system configuration. In particular, it will likely be necessary to edit MPI_PATH and FFT_PATH to point to the appropriate locations on your system. For example: MPI_INC = -DMPICH_SKIP_MPICXX MPI_PATH = -L$(MPI_HOME)/lib MPI_LIB = -lmpich -lmpl -lpthread FFT_INC = -DFFT_FFTW3 FFT_PATH = -L$(FFTLIB)/lib FFT_LIB = -lfftw3 Once this file is edited, run the following commands:

- 110 -

make yes-asphere yes-manybody yes-molecule yes-kspace yes-gpu make g++ ․빌드가 끝나면 실행파일 “lmp_g++"가 생성됨

* 실행방법

․일반적으로 사용되는 Leonard-Jones와 EAM benchmark를 수행

․run.lj.sh, run.eam.sh, lj.throughput.plot, eam.throughput.plot 파일을 bench/GPU

directory에 복사

․각 sh 스크립트를 실행

․각 스크립트는 CPU, GPU카드 한 장, GPU카드 두 장에 대해서 실행할 수 있는

출력물 생성

․gnuplot을 이용해서 graph를 생성

* 성능

- 111 -

․단일 노드, Strong 스케일링

Leonard Jones 결과

EAM 단일노드 결과

- 112 -

․멀티 노드, Weak 스케일링

※ 단일 노드에서 가장 높은 성능을 보여줌

- 113 -

<부록3-2: LAMMPS에 대해서 Intel에서 직접 수행한 벤치마크>

대상; 원자크기 성능향상

Liquid Crystal Benchmark;

524K Atoms

Xeon E5-2697-v2대비 6.5배 향상됨(단일노드), Xeon

E5-2697-v3대비 5.4배 향상됨(단일노드), 5.3배 향상됨

(32노드)

Rhodopsin Benchmark;

512K Atoms

Xeon E5-2697-v3대비 1.68배 향상됨 (단일노드), 1.47

배 향상됨 (32노드)


256K Atoms




512K Atoms




512K Atoms

Xeon E5-2697-v2대비 1.75배 향상됨(단일노드), 1.72배

향상됨(32노드)

※NVIDIA Tesla K20 대비 1.94배 향상됨(단일노드),

1.41배 향상됨(32노드)


256K Atoms



※NVIDIA Tesla K20 대비 1.82배 향상됨(단일노드),

1.47배 향상됨(32노드)

Liquid Crystal BenchmarkXeon E5-2697-v2대비 5.07배 향상됨 (단일노드), 4.84


Production Protein Sim.;

474K Atoms

Xeon E5-2697-v2대비 1.9배 향상됨(단일노드), 1.7배

향상됨(32노드)

- 114 -

* CPU 수행 대비 6.5배 향상 (Liquid Crystal Benchmark; 524K Atoms)

․대상: Liquid Crystal Benchmark; 524K Atoms

․사용모델: Offload

․결과: Xeon E5-2697-v2대비 6.5배 향상됨(단일노드), Xeon E5-2697-v3대비 5.4

배 향상됨(단일노드), 5.3배 향상됨(32노드)

- 115 -

* CPU 수행 대비 1.68배 향상 (Rhodopsin Benchmark; 512K Atoms)

․대상: Rhodopsin Benchmark; 512K Atoms


․결과: Xeon E5-2697-v3대비 1.68배 향상됨 (단일노드), 1.47배 향상됨 (32노드)





- 116 -








․결과: Xeon E5-2697-v2대비 1.75배 향상됨(단일노드), 1.72배 향상됨(32노드)

※NVIDIA Tesla K20 대비 1.94배 향상됨(단일노드), 1.41배 향상됨(32노드)

- 117 -





※NVIDIA Tesla K20 대비 1.82배 향상됨(단일노드), 1.47배 향상됨(32노드)

* CPU 수행 대비 5.07배 향상 (Liquid Crystal Benchmark)

․대상: Liquid Crystal Benchmark



- 118 -

* CPU 수행 대비 1.9배 향상 (Production Protein Sim.; 474K Atoms)

․대상: Production Protein Sim.; 474K Atoms


․결과: Xeon E5-2697-v2대비 1.9배 향상됨(단일노드), 1.7배 향상됨(32노드)

Documents

2014년 분자동역학 분야 계산가속기 이식성 및 성능테스트 ......기술 보고서 2014년 분자동역학 분야 계산가속기 이식성 및 성능테스트 보고서