[mephi-hpc] SIESTA

Tue Feb 12 12:05:06 MSK 2019

On Mon, 2019-02-11 at 21:03 +0300, Мария Шутикова wrote:
> Теперь я понимаю! 
> Спасибо!

Добрый день!

> В будущем действительно планируются вычисления, занимающие больше
> ресурсов. Но их нельзя было провести без результатов этих. 

В последовательных (не параллельных) вычислениях нет ничего плохого.
Суть ограничения в том, чтобы не занимать ресурсы, которые Ваше ПО не
может использовать. Просто используйте node=1:ppn=1 для
последовательных задач.

> Если можно, еще маленький вопрос. Я слышала, что на кластере
> установлена Quantum Espresso,  с поддержкой mpi, и у QE существует
> больше возможностей для распараллеливания. Не подскажете, где
> находится ее рабочая версия? После тестов с SIESTA мне нужно сравнить
> их на одной и той же задаче. Вооружившись знаниями, надеюсь, что
> справлюсь с этим сама)

Базовая версия Quantum Espresso (без дополнительных модулей)
установлена системно на кластере cherenkov:

anikeev at master.cherenkov ~ $ dpkg -l | grep quantum
ii  quantum-espresso                       6.0-
3                                amd64        Electronic-Structure and
Ab-Initio Molecular Dynamics Suite
ii  quantum-espresso-data                  6.0-
3                                all          Electronic-Structure and
Ab-Initio Molecular Dynamics Suite (Documentation)

В пакете Quantum Espresso имеется много различных исполняемых файлов.
Полный список установленных пакетом файлов можно узнать командой:

anikeev at master.cherenkov ~ $ dpkg-query -L quantum-espresso

Исполняемый файлы находятся в /usr/bin

anikeev at master.cherenkov ~ $ dpkg-query -L quantum-espresso | grep
/usr/bin

Кроме того, часть пользователей использует собственный сборки Qunatum
Espresso, отличающиеся версиями и конфигурациями. Вы можете попробовать
связаться с ними зерез lists.

> Понедельник, 11 февраля 2019, 18:18 +03:00 от anikeev
> <anikeev at ut.mephi.ru>:
> On Fri, 2019-02-08 at 19:38 +0300, Мария Шутикова wrote:
> > Спасибо!
> Добрый день!
> 
> > Входные файлы и скрипт для запуска задачи поместила в
> > pool/4/mishutikova/W_444_test
> > Наверное, лучше дождаться завершения моей текущей задачи, и
> запускать
> > после, тогда наверняка ничего не повредится.
> > И я после нее не буду пока ставить задач, дождусь Вашего совета.
> 
> Проблема оказалась в том, что алгоритм siesta не очень хорошо
> параллелизован. Действительно, есть участки алгоритма, когда
> программа
> использует все доступные потоки, но большую часть времени она
> работает
> в один поток. Когда Вы запрашиваете полный вычислительный узел, Вашу
> задачу принудительно завершает менеджер ресурсов т.к. она использует
> менее 10% от затребованных ресурсов суммарно с момента запуска.
> 
> С другой стороны, фактическое потребление памяти оказалось небольшим.
> Под такую задачу не обязательно резервировать целый узел. Попробуйте
> построить график роста производительности для таких точек:
> 
> nodes=1 ppn=1 OMP_NUM_THREADS=1
> nodes=1 ppn=2 OMP_NUM_THREADS=2
> nodes=1 ppn=4 OMP_NUM_THREADS=4
> nodes=1 ppn=8 OMP_NUM_THREADS=8
> 
> Эти задачи не должны прерываться, т.к. в худшем случае даже при
> занятости только одного ядра оно будет составлять более 10% от 8
> ядер.
> К сожалению, поскольку программа большую часть времени даже не
> использует дополнительные вычислительные потоки, прирост
> производительности должен оказаться весьма скромным, но будет
> правильнее, если Вы убедитесь в этом сами. В таком случае логичнее
> всего использовать nodes=1 ppn=1 OMP_NUM_THREADS=1.
> 
> Эти результаты получены для тестовой задачи. Эффективность
> параллелизма
> может быть разной не только у разных алгоритмов siesta, но и для
> разных
> входных данных. Это же утверждение справедливо для потребления
> памяти.
> При установке siesta оговаривалось большое потребление памяти, но на
> предложенном тесте оно не проявляется. Возможно, Ваши коллеги
> используют какой-то другой алгоритм или сильно отличающиеся входные
> данные. При существенном изменении задачи анализ производительности
> надо проводить заново, если планируется достаточное число однотипных
> запусков.
> 
> > Пятница, 8 февраля 2019, 16:04 +03:00 от anikeev <anikeev at ut.mephi.
> ru
> > >:
> > 
> > On Fri, 2019-02-08 at 15:55 +0300, Мария Шутикова wrote:
> > > Понятно!
> > > Значит из того, что задачи с nodes=1::ppn=32 и OMP_NUM_THREADS=1,
> > 4,
> > > 8, 32 так завершаются, а задача с  nodes=1::ppn=1
> > > и  OMP_NUM_THREADS=1 считается 10 часов, осталось поменять pnn,
> > > скажем, на  nodes=1::ppn=4, чтобы задача не завершалась как
> > > зависшая, и подобрать OMP_NUM_THREADS, или я ошибаюсь?
> > Как запустить Вашу задачу, не повредив Ваши данные? Что-то с ней
> > слишком много проблем, давайте я посмотрю более детально.
> > 
> > > Пятница, 8 февраля 2019, 14:15 +03:00 от anikeev <anikeev at ut.meph
> i.
> > ru
> > > >:
> > > 
> > > On Fri, 2019-02-08 at 10:20 +0300, Мария Шутикова wrote:
> > > > Здравствуйте!
> > > Добрый день!
> > > 
> > > > Мой вопрос про ppn возник не с проста!
> > > > В папке pool/4/mishutikova остались файлы torque от двух задач:
> > > > W444job.sh.o143244, соответствующий запуску с nodes=1::ppn=1
> > > > и OMP_NUM_THREADS=1
> > > > 
> > > > и
> > > > 
> > > > W444job.sh.o143517, соответствующий запуску с nodes=1::ppn=32
> > > > и OMP_NUM_THREADS=1
> > > > 
> > > > В первом случае задача посчиталась полностью (через ~10 часов)
> и
> > > > написала в конце Job completed
> > > > 
> > > > Во втором случае задача застыла через  примерно 40 минут работы
> и
> > > > все. Если зайти и проверить ее статус, то выясняется, что
> задачи
> > > > больше нет, хотя она стояла в очереди long, и время выйти еще
> не
> > > > должно было.
> > > > И вот так было и раньше когда я ставила ppn=32
> > > > 
> > > > Вот...
> > > 
> > > Torque не различает задачи, завершившиеся аварийно или штатно. Он
> > > просто записывает STDOUT и STDERR.
> > > 
> > > Проблема оказалась в том, что Ваша задача потребляет слишком
> малую
> > > часть запрошенных ресурсов и принудительно завершается как
> > зависшая.
> > > Попробуйте начать с OMP_NUM_THREADS=4 и больше.
> > > 
> > > > _______________________________________________
> > > > hpc mailing list
> > > > hpc at lists.mephi.ru
> > > > https://lists.mephi.ru/listinfo/hpc
> > > -- 
> > > С уважением,
> > > инженер отдела Unix-технологий МИФИ,
> > > Аникеев Артём.
> > > Тел.: 8
> > > (495) 788-56-99, доб. 8998
> > > 
> > > 
> > > _______________________________________________
> > > hpc mailing list
> > > hpc at lists.mephi.ru
> > > https://lists.mephi.ru/listinfo/hpc
> > -- 
> > С уважением,
> > инженер отдела Unix-технологий МИФИ,
> > Аникеев Артём.
> > Тел.: 8
> > (495) 788-56-99, доб. 8998
> > 
> > 
> > _______________________________________________
> > hpc mailing list
> > hpc at lists.mephi.ru
> > https://lists.mephi.ru/listinfo/hpc
> -- 
> С уважением,
> инженер отдела Unix-технологий МИФИ,
> Аникеев Артём.
> Тел.: 8
> (495) 788-56-99, доб. 8998
> 
> 
> _______________________________________________
> hpc mailing list
> hpc at lists.mephi.ru
> https://lists.mephi.ru/listinfo/hpc
-- 
С уважением,
инженер отдела Unix-технологий МИФИ,
Аникеев Артём.
Тел.: 8
(495) 788-56-99, доб. 8998