Zrównoleglenie w VASP
Mam system, który ma 1 punkt k, 54 atomy NBANDS=152, i NGZ=80. Prowadzę symulację AIMD na VASP w wersji 5.4.4
Superkomputer ma 32 rdzenie / węzeł. To klaster LINUX połączony przez Infiniband, nowoczesną maszynę wielordzeniową. Zastanawiałem się, jaki byłby najlepszy sposób na wybranie parametrów i zażądanie zasobów, aby uzyskać wydajne i szybkie obliczenia. Oto kilka scenariuszy, które rozważałem. Jestem ciekaw, jaka byłaby najlepsza metoda (pod względem wydajności i szybkości).
- Na podstawie tego, co przeczytałem tutaj
- Powinienem poprosić o jakieś 19 zespołów (152/8). Może ustawić NBANDS = 160, aby zażądać nawet 20 rdzeni.
- Czy wtedy ustawiłbym NCORE = 20 w moim pliku INCAR i zażądał 20 rdzeni w 1 węźle?
- A może lepiej byłoby ustawić NCORE = 10. A potem zażądać czegoś w rodzaju 2 węzłów i 10 rdzeni na węzeł? czy też spowodowałoby to zbyt duże obciążenie komunikacyjne i spowolniłoby symulację?
- Jeśli zdecyduję się użyć # rdzeni = # atomów = 54
- Czy ustawiłbym NCORE = 32, a następnie zażądałbym 54 rdzeni na 2 węzłach (32 na 1 węźle + 22 na drugim)? Lub 9 rdzeni / węzeł i 6 węzłów?
- Czy nie mogę po prostu zażądać całego węzła? 1 węzeł, 32 rdzenie
- więc ustaw NCORE = 32 i po prostu zażądam całego węzła. Jednak podręcznik VASP sugeruje przeciwdziałanie temu, ponieważ spowodowałoby to, że NPAR = 1
- to mnie trochę dezorientuje, ponieważ zakładam, że 32 rdzenie w jednym węźle byłyby bardziej wydajne niż posiadanie rdzeni w kilku węzłach komunikujących się ze sobą
Odpowiedzi
Jako ktoś, kto wykonał wiele testów porównawczych dla VASP, sugerowałbym wypróbowanie podejścia eksperymentalnego. Wierzę, że VASP doda dla ciebie dodatkowe pasma, jeśli zajdzie potrzeba zrównoleglenia, więc nie martwiłbym się o to osobiście. Fizyczny układ węzła (32 rdzenie na 1 procesorze w porównaniu z 16 rdzeniami na 2 procesorach w porównaniu ze specjalnymi układami procesorów AMD na jednym procesorze) może się znacznie różnić w zależności od klastra, nie możesz wiedzieć, co jest optymalne bez próby.
Ponieważ wydaje się, że przeprowadzasz symulacje MD, myślę, że warto przetestować każdy system przed uruchomieniem długiej symulacji. Drobne zmiany nie wymagają ponownego porównania, ale jeśli przejdziesz od 50 do 150 do 300 atomów, ideał może się zmienić. Uruchom serię szybkich obliczeń z całym zakresem NCORE, co wydaje się rozsądne. Użyj najlepszego wyniku. Zwykle sprawdzam każdy czynnik największego węzła.
Dla 32 rdzeni sprawdzałbym NCORE = (1, 2, 4, 8, 16, 32). Zmierzyłbym to z 10 lub więcej geometrycznymi krokami. Może się to wydawać stratą czasu, ale w przyszłości może się okazać, że pozwoli zaoszczędzić dużo czasu.
Prawie zawsze sugerowałbym żądanie całych węzłów, chyba że masz dobry powód, aby tego nie robić. W końcu możesz zobaczyć opcję KPAR podczas rozglądania się, słyszałem mieszane opinie. Osobiście nigdy nie uzyskałem lepszego wyniku z równoległością kpoint niż bez niej. Może to jednak mieć wpływ na pamięć.
Pomyślałem, że opublikuję wyniki benchmarkingu zgodnie z sugestią Tristana. Może przyda się komuś w przyszłości. Zrobiłem tylko 10 kroków w MD (wielkość kroku 1 fs, łącznie 10 fs).
Procentowe różnice odnoszą się do przebiegu NCORE = 1 z 32 rdzeniami i 1 węzłem. Przyspieszenie o 33% następuje po przejściu do 2 węzłów z 64 rdzeniami (NCORE = 32).
Oczywiście może się to różnić w zależności od klastra. Nawiasem mówiąc, to jest klaster Graham na Sharcnet w Kanadzie - więc miejmy nadzieję, że jest przydatna dla innych Kanadyjczyków :)
