[mephi-hpc] SIESTA

[anikeev]

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