팀은 은하수 구조 시뮬레이션을 만듭니다.
2014년 11월 18일
작성자: Katie Elyce Jones, Oak Ridge National Laboratory
오늘 멀리서 은하수 사진을 찍는다면, 그 사진은 밀집된 별 집단으로 이루어진 밝은 중앙 막대(때때로 팽대부라고도 함)가 있는 나선 은하를 보여줄 것입니다. 사진에서 보기 매우 어려운 태양은 별과 성간 먼지로 구성된 나선형 팔 중 하나 근처에 있는 이 막대 바깥에 위치합니다. 눈에 보이는 은하계 너머에는 암흑물질 후광이 있을 것입니다. 카메라에는 보이지 않지만 그럼에도 불구하고 막대와 나선형 팔의 회전 속도를 끌어내려 모든 것을 함께 유지하기 때문에 중요합니다.
이제 시간을 거슬러 올라가 은하수가 형성되는 모습을 동영상으로 찍고 싶다면 100억 년 전으로 돌아갈 수 있지만 은하계의 두드러진 특징 중 많은 부분을 인식할 수 없을 것입니다. 지구 태양계의 형성을 목격하려면 약 50억년을 기다려야 합니다. 46억년 전인 이 시점에서 은하계는 오늘날과 거의 비슷하게 보입니다.
네덜란드 라이덴 천문대의 사이먼 포르테지스 즈바르트(Simon Portegies Zwart)는 “은하의 거대한 구조는 지난 100억년에 걸쳐 항성 분포가 스스로 조직화되면서 생겨나 결국 사진 속 은하수처럼 보이게 됐다”고 말했다.
이것은 Portegies Zwart를 포함한 네덜란드와 일본의 연구원 팀이 슈퍼컴퓨터를 사용하여 은하계의 진화를 시뮬레이션할 때 나타나는 타임라인입니다. 에너지부 오크리지 국립연구소(Oak Ridge National Laboratory)에 위치한 Cray XK7 Titan을 포함하여 GPU 슈퍼컴퓨팅 아키텍처용으로 개발된 코드를 사용하여 팀의 시뮬레이션은 Gordon Bell Prize 최종 후보로 인정받았습니다. 이 상은 고성능 컴퓨팅 분야의 뛰어난 업적을 인정하는 것이며 11월 20일 SC14에서 컴퓨팅 기계 협회가 수여할 예정입니다.
Portegies Zwart는 "우리는 은하계의 구조가 어떻게 형성되었는지 실제로 알지 못합니다."라고 말했습니다. "우리가 깨달은 것은 3차원 공간에서 별의 위치, 속도 및 질량을 사용하여 시스템의 자체 중력에서 구조가 나타날 수 있다는 것입니다."
별별로 은하 구조를 계산하는 과제는 여러분이 상상할 수 있듯이 은하계에 있는 별의 수(최소 1000억 개)입니다. 따라서 팀은 모든 점을 연결하기 위해 최소한 1000억 개의 입자 시뮬레이션이 필요했습니다. Bonsai라고 알려진 팀의 코드가 개발되기 전에는 가장 큰 은하계 시뮬레이션에서 10억 개가 아닌 약 1억 개의 입자가 발견되었습니다.
팀은 코드 확장성을 향상시키기 위해 세계에서 두 번째로 강력한 슈퍼컴퓨터인 Oak Ridge Leadership Computing Facility의 Titan에서 Bonsai의 초기 버전을 테스트했습니다. Bonsai를 Titan GPU 노드의 거의 절반으로 확장한 후 팀은 스위스 국립 슈퍼컴퓨팅 센터의 Piz Daint 슈퍼컴퓨터에서 Bonsai를 실행하고 별과 암흑 물질의 힘을 나타내는 5,100만 개의 입자로 60억 년이 넘는 은하 형성을 시뮬레이션했습니다. 성공적인 Piz Daint 실행 후 팀은 코드의 병렬성을 최대화하기 위해 Titan으로 돌아왔습니다.
Bonsai 코드는 18,600개의 Titan 노드(머신 GPU 노드의 96%)에서 확장성을 보여주었으며, 이를 통해 800만년, 2,420억 개의 입자 은하수 시뮬레이션이 가능해졌습니다. Bonsai는 Titan에서 약 25페타플롭의 지속적인 단정밀도 부동 소수점 성능을 달성했습니다. 단정밀도 부동 소수점 연산은 32비트를 사용하여 숫자를 표현함으로써 더 적은 메모리를 사용하는 반면, 배정밀도 연산은 64비트를 사용하여 더 정확한 숫자를 표현합니다.
Portegies Zwart는 "대학원생인 Jeroen Bédorf와 함께 GPU용 단일 코드 작성으로 시작했으며 전체 코드가 GPU에서 실행되어 병렬성을 활용하기를 원했기 때문에 의도적으로 CPU에 코드를 작성하지 않았습니다."라고 말했습니다. "호스트 CPU는 노드와 GPU 간의 통신을 간소화하는 데만 사용됩니다. 이러한 방식으로 우리는 숫자 처리를 위한 GPU 사용을 완전히 최적화하고 통신 오버헤드를 최소화하기 위해 훨씬 느린 CPU를 사용할 수 있습니다."