<HTML><BODY>Теперь я понимаю! <div>Спасибо!</div><div>В будущем действительно планируются вычисления, занимающие больше ресурсов. Но их нельзя было провести без результатов этих. </div><div><br></div><div>Если можно, еще маленький вопрос. Я слышала, что на кластере установлена Quantum Espresso,  с поддержкой mpi, и у QE существует больше возможностей для распараллеливания. Не подскажете, где находится ее рабочая версия? После тестов с SIESTA мне нужно сравнить их на одной и той же задаче. Вооружившись знаниями, надеюсь, что справлюсь с этим сама)</div><div><br>Понедельник, 11 февраля 2019, 18:18 +03:00 от anikeev <anikeev@ut.mephi.ru>:<br>
<blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">
        <div id="">

        

        
        
        













        







<div class="js-helper js-readmsg-msg">
        <style type="text/css"></style>
        <div id="viewmessagebody" class="mr_read__body">
                <base target="_self" href="https://touch.mail.ru/cgi-bin/">
                
                        <div id="style_15498983020000000668_BODY">On Fri, 2019-02-08 at 19:38 +0300, Мария Шутикова wrote:<br>
> Спасибо!<br>
    
Добрый день!<br>
<br>
> Входные файлы и скрипт для запуска задачи поместила в<br>
> pool/4/mishutikova/W_444_test<br>
> Наверное, лучше дождаться завершения моей текущей задачи, и запускать<br>
> после, тогда наверняка ничего не повредится.<br>
> И я после нее не буду пока ставить задач, дождусь Вашего совета.<br>
<br>
Проблема оказалась в том, что алгоритм siesta не очень хорошо<br>
параллелизован. Действительно, есть участки алгоритма, когда программа<br>
использует все доступные потоки, но большую часть времени она работает<br>
в один поток. Когда Вы запрашиваете полный вычислительный узел, Вашу<br>
задачу принудительно завершает менеджер ресурсов т.к. она использует<br>
менее 10% от затребованных ресурсов суммарно с момента запуска.<br>
<br>
С другой стороны, фактическое потребление памяти оказалось небольшим.<br>
Под такую задачу не обязательно резервировать целый узел. Попробуйте<br>
построить график роста производительности для таких точек:<br>
<br>
nodes=1 ppn=1  OMP_NUM_THREADS=1<br>
nodes=1 ppn=2  OMP_NUM_THREADS=2<br>
nodes=1 ppn=4  OMP_NUM_THREADS=4<br>
nodes=1 ppn=8  OMP_NUM_THREADS=8<br>
<br>
Эти задачи не должны прерываться, т.к. в худшем случае даже при<br>
занятости только одного ядра оно будет составлять более 10% от 8 ядер.<br>
К сожалению, поскольку программа большую часть времени даже не<br>
использует дополнительные вычислительные потоки, прирост<br>
производительности должен оказаться весьма скромным, но будет<br>
правильнее, если Вы убедитесь в этом сами. В таком случае логичнее<br>
всего использовать nodes=1 ppn=1  OMP_NUM_THREADS=1.<br>
<br>
Эти результаты получены для тестовой задачи. Эффективность параллелизма<br>
может быть разной не только у разных алгоритмов siesta, но и для разных<br>
входных данных. Это же утверждение справедливо для потребления памяти.<br>
При установке siesta оговаривалось большое потребление памяти, но на<br>
предложенном тесте оно не проявляется. Возможно, Ваши коллеги<br>
используют какой-то другой алгоритм или сильно отличающиеся входные<br>
данные. При существенном изменении задачи анализ производительности<br>
надо проводить заново, если планируется достаточное число однотипных<br>
запусков.<br>
<br>
> Пятница, 8 февраля 2019, 16:04 +03:00 от anikeev <<a href="/compose?To=anikeev@ut.mephi.ru">anikeev@ut.mephi.ru</a><br>
> >:<br>
> <br>
> On Fri, 2019-02-08 at 15:55 +0300, Мария Шутикова wrote:<br>
> > Понятно!<br>
> > Значит из того, что задачи с nodes=1::ppn=32 и OMP_NUM_THREADS=1,<br>
> 4,<br>
> > 8, 32 так завершаются, а задача с  nodes=1::ppn=1<br>
> > и  OMP_NUM_THREADS=1 считается 10 часов, осталось поменять pnn,<br>
> > скажем, на  nodes=1::ppn=4, чтобы задача не завершалась как<br>
> > зависшая, и подобрать OMP_NUM_THREADS, или я ошибаюсь?<br>
> Как запустить Вашу задачу, не повредив Ваши данные? Что-то с ней<br>
> слишком много проблем, давайте я посмотрю более детально.<br>
> <br>
> > Пятница, 8 февраля 2019, 14:15 +03:00 от anikeev <anikeev@ut.mephi.<br>
> ru<br>
> > >:<br>
> > <br>
> > On Fri, 2019-02-08 at 10:20 +0300, Мария Шутикова wrote:<br>
> > > Здравствуйте!<br>
> > Добрый день!<br>
> > <br>
> > > Мой вопрос про ppn возник не с проста!<br>
> > > В папке pool/4/mishutikova остались файлы torque от двух задач:<br>
> > > W444job.sh.o143244, соответствующий запуску с nodes=1::ppn=1<br>
> > > и OMP_NUM_THREADS=1<br>
> > > <br>
> > > и<br>
> > > <br>
> > > W444job.sh.o143517, соответствующий запуску с nodes=1::ppn=32<br>
> > > и OMP_NUM_THREADS=1<br>
> > > <br>
> > > В первом случае задача посчиталась полностью (через ~10 часов) и<br>
> > > написала в конце Job completed<br>
> > > <br>
> > > Во втором случае задача застыла через  примерно 40 минут работы и<br>
> > > все. Если зайти и проверить ее статус, то выясняется, что задачи<br>
> > > больше нет, хотя она стояла в очереди long, и время выйти еще не<br>
> > > должно было.<br>
> > > И вот так было и раньше когда я ставила ppn=32<br>
> > > <br>
> > > Вот...<br>
> > <br>
> > Torque не различает задачи, завершившиеся аварийно или штатно. Он<br>
> > просто записывает STDOUT и STDERR.<br>
> > <br>
> > Проблема оказалась в том, что Ваша задача потребляет слишком малую<br>
> > часть запрошенных ресурсов и принудительно завершается как<br>
> зависшая.<br>
> > Попробуйте начать с OMP_NUM_THREADS=4 и больше.<br>
> > <br>
> > > _______________________________________________<br>
> > > hpc mailing list<br>
> > > <a href="/compose?To=hpc@lists.mephi.ru">hpc@lists.mephi.ru</a><br>
> > > <a href="https://lists.mephi.ru/listinfo/hpc" target="_blank">https://lists.mephi.ru/listinfo/hpc</a><br>
> > -- <br>
> > С уважением,<br>
> > инженер отдела Unix-технологий МИФИ,<br>
> > Аникеев Артём.<br>
> > Тел.: 8<br>
> > (495) 788-56-99, доб. 8998<br>
> > <br>
> > <br>
> > _______________________________________________<br>
> > hpc mailing list<br>
> > <a href="/compose?To=hpc@lists.mephi.ru">hpc@lists.mephi.ru</a><br>
> > <a href="https://lists.mephi.ru/listinfo/hpc" target="_blank">https://lists.mephi.ru/listinfo/hpc</a><br>
> -- <br>
> С уважением,<br>
> инженер отдела Unix-технологий МИФИ,<br>
> Аникеев Артём.<br>
> Тел.: 8<br>
> (495) 788-56-99, доб. 8998<br>
> <br>
> <br>
> _______________________________________________<br>
> hpc mailing list<br>
> <a href="/compose?To=hpc@lists.mephi.ru">hpc@lists.mephi.ru</a><br>
> <a href="https://lists.mephi.ru/listinfo/hpc" target="_blank">https://lists.mephi.ru/listinfo/hpc</a><br>
-- <br>
С уважением,<br>
инженер отдела Unix-технологий МИФИ,<br>
Аникеев Артём.<br>
Тел.: 8<br>
(495) 788-56-99, доб. 8998<br>
</div>
                        
                
                <base target="_self" href="https://touch.mail.ru/cgi-bin/">
        </div>

        
</div>







</div>
</blockquote>
<br>
<br>-- <br>Мария Шутикова<br></div></BODY></HTML>