Я знаю, что я задал тот же вопрос ранее по этой ссылке:Установка ПГОС для запуска исполняемого файла с различными входными файлами на разных узлах (обновлено: с некоторыми проблемами)
Setting SGE for running an executable with different input files on different nodes
Как я уже говорил в этой теме , Я работал с подобными вещами в системе SLURM раньше, без каких-либо проблем, потому что все обернуто в один сценарий подачи. Однако, адаптировавшись к предыдущему вопросу в ссылке выше, вот мой подход к SGE (я знаю, что это плохая практика, но я действительно не мог придумать никаких лучших способов ...)
Работа прикована через 4 + N скриптов: run.sh
, submitSerial.sh
, wrap.sh
, temp.sh
и job{1-N}.sh
run.sh
: Основная работа сценария
#!/bin/bash
...some stuffs...
...create N directories to run N input files in parallel (like last problems)
...generate wrap.sh and job{1-N}.sh...
...parameters definition...
for ((i=0; i<=M; i++))
do
...generate submitSerial.sh...
sh submitSerial.sh
...initialize boolean flag...
while flag
do
sh wrap.sh
...run an executable to determine the flag status...
done
done
...some cleanup...
submitSerial.sh
иtemp.sh
: Мне нужно выполнить этот исполняемый файл в последовательном порядке, и попросить кластер ждать, пока это будет сделано, чтобы перейти к следующей строке процедур вrun.sh
. Посколькуrun.sh
не находится в кластере (т. Е. Нет параметров Grid Engine), но существует только в узле входа, это сгенерируетtemp.sh
и запускает последовательный скрипт через qsub сразу. Поскольку я не знаю, как проверить, выполнена ли работа qsub , поэтому я должен был сделать это глупо. Интересно, есть ли лучший способ проверки? ?
#!/bin/bash
echo "#!/bin/bash" >> $workDir/temp.sh
echo >> $workDir/temp.sh
echo "#$ -N serialForce" >> $workDir/temp.sh
echo "#$ -q batch.q" >> $workDir/temp.sh
echo "#$ -l h_rt=0:10:00" >> $workDir/temp.sh
echo "#$ -pe orte 120" >> $workDir/temp.sh
echo "#$ -wd /path/to/working/dir/" >> $workDir/temp.sh
echo "#$ -j y" >> $workDir/temp.sh
echo "#$ -S /bin/bash" >> $workDir/temp.sh
echo "#$ -V" >> $workDir/temp.sh
echo >> $workDir/temp.sh
echo "mpirun -np 120 nwchem-6.5 $workDir/step0_1.nw" >> $workDir/temp.sh
qsub $workDir/temp.sh
while true
do
qstat > $workDir/temp
if [ -s $workDir/temp ]
then
sleep 1
else
rm $workDir/temp
break
fi
done
rm $workDir/temp.sh
wrap.sh
иjob{1-N}.sh
: Это был создан ранее в начале сценария. Это та часть, которая была у меня вопрос в прошлый раз, и я также использовал сон, чтобы проверить состояние qsub а
#!/bin/bash
for i in {1..10}
do
qsub $workDir/wd$i/job$i.sh
done
while true
do
qstat > $workDir/temp
if [ -s $workDir/temp ]
then
sleep 1
else
rm $workDir/temp
break
fi
done
for j in {1..10}
do
rm $workDir/wd$j/*
done
Проблема с этим подходом является раз я бегу run.sh
, я не могу это сделать в фоновом режиме и с необходимостью делать отдельные qsub
, существует потенциальная проблема, если кластер заполнен. Интересно, есть ли решение с одним qsub
, как подход SLURM? Я просто хочу отправить задание и просто подождать, пока это не будет сделано, вместо того, чтобы сценарий передавал несколько заданий qsub, не зная, умерли ли какие-либо неизвестные задания в середине (и у меня никогда не было идеи, где он умирает).
Пожалуйста, помогите мне с этим! Ваша помощь очень ценится! Заранее большое спасибо!
Привет Винс, На самом деле я также изучил некоторые другие возможности, а также начал новую тему. Мои проблемы могут быть решены с помощью функции контекста приложения mpirun, но у меня все еще были проблемы с этим, описанные в этом новом потоке. http://stackoverflow.com/questions/29481433/mpirun-app-option-on-grid-engine-for-mpmd-settings Я также рассмотрел задание массива SGE как возможное решение, но я указываю некоторые проблемы в этой теме. Не могли бы вы, пожалуйста, посмотреть и на эту тему? Большое вам спасибо за вашу помощь! – KhunWasut
Я действительно заглядываю в опцию '-hold_jid' для' qsub'. Это потенциально решает мою проблему, но я все еще обеспокоен тем, что работа, которую я запускаю, может занимать несколько часов или до одного дня, а кластер, над которым я работаю, не слишком надежный, а некоторые 'qsub' рабочие места могут застрять. По крайней мере, когда я работал с SLURM, все обернуто в одно представление, но похоже, что я должен сделать несколько (возможно, тысяч) запросов для выполнения той же проблемы. – KhunWasut
Еще одна проблема - когда я отправляю задание в свой кластер, иногда он застрял в 'qw' целыми днями и не будет работать (не знаю, в чем причина). Если все в одном представлении, если это произойдет, я могу сразу удалить задание и начать новый. Однако, если это произойдет, когда я нахожусь, скажем, на 543-й работе, было бы очень неприятно, что работа застряла в автоматическом скрипте, не имея возможности отслеживать ее, и время будет потрачено впустую, делая это снова, не будучи способный сначала перехватить проблему. У вас есть какие-либо решения, которые помогают объединить все в один скрипт? – KhunWasut