[mephi-hpc] SIESTA

Mon Feb 11 21:03:21 MSK 2019

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

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

Понедельник, 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.mephi.
>> 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

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