[mephi-hpc] SIESTA

Tue Feb 12 21:17:06 MSK 2019

Спасибо!

Вторник, 12 февраля 2019, 12:05 +03:00 от anikeev <anikeev at ut.mephi.ru>:
>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

-- 
Мария Шутикова
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mephi.ru/pipermail/hpc/attachments/20190212/fa09c9ef/attachment-0001.html>