2015-04-03 6 views
0

Я знаю, что я задал тот же вопрос ранее по этой ссылке:Установка ПГОС для запуска исполняемого файла с различными входными файлами на разных узлах (обновлено: с некоторыми проблемами)

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, не зная, умерли ли какие-либо неизвестные задания в середине (и у меня никогда не было идеи, где он умирает).

Пожалуйста, помогите мне с этим! Ваша помощь очень ценится! Заранее большое спасибо!

ответ

0

Не могли бы вы быть более конкретными и понятными, с чем вы столкнулись. Я бы сказал, что последний вопрос, на который вы ссылаетесь, в основном обращается к сценариям wrap.sh и jobN.sh, т. Е. Использует массивы заданий.

Чтобы решить вашу другую проблему, то есть, как проверить/дождаться завершения задания, см. Ниже.

Чтобы выполнить работу, необходимо выполнить другую работу, чтобы использовать опцию qsub-hold_jid. Чтобы применить это к нескольким заданиям, каждая из которых зависит от предыдущей, чтобы завершить, моя первая мысль была бы циклом for. Например:

holdid=$(echo "<some code for job 1>" | qsub -terse) 
for jobn in {1..99} 
do 
    holdid=$(echo "<some code for jobn>" | qsub -terse -hold_jid ${holdid}) 
done 

Я с удовольствием отредактировал этот ответ, чтобы помочь вам в дальнейшем.

+0

Привет Винс, На самом деле я также изучил некоторые другие возможности, а также начал новую тему. Мои проблемы могут быть решены с помощью функции контекста приложения mpirun, но у меня все еще были проблемы с этим, описанные в этом новом потоке. http://stackoverflow.com/questions/29481433/mpirun-app-option-on-grid-engine-for-mpmd-settings Я также рассмотрел задание массива SGE как возможное решение, но я указываю некоторые проблемы в этой теме. Не могли бы вы, пожалуйста, посмотреть и на эту тему? Большое вам спасибо за вашу помощь! – KhunWasut

+0

Я действительно заглядываю в опцию '-hold_jid' для' qsub'. Это потенциально решает мою проблему, но я все еще обеспокоен тем, что работа, которую я запускаю, может занимать несколько часов или до одного дня, а кластер, над которым я работаю, не слишком надежный, а некоторые 'qsub' рабочие места могут застрять. По крайней мере, когда я работал с SLURM, все обернуто в одно представление, но похоже, что я должен сделать несколько (возможно, тысяч) запросов для выполнения той же проблемы. – KhunWasut

+0

Еще одна проблема - когда я отправляю задание в свой кластер, иногда он застрял в 'qw' целыми днями и не будет работать (не знаю, в чем причина). Если все в одном представлении, если это произойдет, я могу сразу удалить задание и начать новый. Однако, если это произойдет, когда я нахожусь, скажем, на 543-й работе, было бы очень неприятно, что работа застряла в автоматическом скрипте, не имея возможности отслеживать ее, и время будет потрачено впустую, делая это снова, не будучи способный сначала перехватить проблему. У вас есть какие-либо решения, которые помогают объединить все в один скрипт? – KhunWasut