У меня есть существующая система Snakemake, работающая под управлением conda, в кластере SGE. Это восхитительно и очень выполнимо. Я постараюсь предложить точку зрения и рекомендации.
Местоположение вашей миниконды, локальное или общее, может не иметь значения. Если вы используете учетную запись для доступа к кластеру, вы сможете обновить свои переменные по умолчанию после входа в систему. Это будет иметь глобальный эффект. Если возможно, я настоятельно рекомендую изменить настройки по умолчанию в вашем .bashrc для выполнения это. Это правильно и автоматически настроит ваш путь к conda при входе в систему.
Одна из строк в моем файле "home / tboyarski / .bashrc"
export PATH=$HOME/share/usr/anaconda/4.3.0/bin:$PATH
ИЗМЕНИТЬ 1 Хорошее замечание, сделанное в комментарии
Лично я считаю хорошей практикой все ставить под контроль conda; однако это может быть не идеально для пользователей, которым обычно требуется доступ к программному обеспечению, не поддерживаемому conda. Обычно проблемы с поддержкой связаны с использованием старых операционных систем (например, недавно была прекращена поддержка CentOS 5). Как предлагается в комментарии, ручной экспорт переменной PATH в одном сеансе терминала может быть более идеальным для пользователей, которые не работают исключительно с конвейерами, поскольку это не будет иметь глобального эффекта.
С учетом сказанного, как и я до выполнения Snakemake, я рекомендую инициализировать среду conda, используемую большинством или целиком вашего конвейера. Я считаю, что это предпочтительный способ, поскольку он позволяет conda создать среду, вместо того, чтобы заставить Snakemake запрашивать conda создать среду. У меня нет ссылки на веб-обсуждение, но я полагаю, что где-то читал, что люди, которые полагаются только на Snakemake для создания сред, а не запускаются из базовой среды, они обнаружили, что среды хранились в каталоге /. каталог snakemake, и что он становится чрезмерно большим. Не стесняйтесь искать пост. Проблема была устранена автором, который уменьшил нагрузку на скрытую папку, но все же я думаю, что имеет больше смысла запускать задания из существующей среды Snakemake, которая взаимодействует с вашим головным узлом, а затем передает соответствующие переменные среды в это дочерние узлы. Мне нравится немного иерархии.
С учетом вышесказанного вам, вероятно, потребуется передать среды своим дочерним узлам, если вы запускаете Snakemake из среды своего головного узла и позволяете Snakemake взаимодействовать с планировщиком заданий SGE через qsub. На самом деле я использую встроенную функцию DRMAA, что я очень рекомендую. Оба средства подачи требуют от меня предоставить следующие аргументы:
-V Available for qsub, qsh, qrsh with command and qalter.
Specifies that all environment variables active within the qsub
utility be exported to the context of the job.
Также...
-S [[hostname]:]pathname,...
Available for qsub, qsh and qalter.
Specifies the interpreting shell for the job. pathname must be
an executable file which interprets command-line options -c and
-s as /bin/sh does.
Чтобы дать вам лучшую отправную точку, я также указываю виртуальную память и количество ядер, это может быть специфическим для моей системы SGE, я не знаю.
-V -S /bin/bash -l h_vmem=10G -pe ncpus 1
Я очень надеюсь, что вам потребуются оба аргумента при отправке кластера SGE, как и мне лично. Я рекомендую поместить переменные представления кластера в формате JSON в отдельный файл. Приведенный выше фрагмент кода можно найти в этом примере того, что Я сделал лично. Я организовал его немного иначе, чем в руководстве, но это потому, что мне нужно было немного больше детализации.
Лично я использую команду --use-conda только при запуске среды conda, отличной от той, которую я использовал для запуска и отправки своих заданий Snakemake. Пример: моя основная среда conda запускает python 3, но если мне нужно использовать инструмент, который, скажем, требует python 2, я тогда и только тогда буду использовать Snakemake для запуска правила с этой конкретной средой, так что выполнение этого Правило использует путь, соответствующий установке python2. Это имело огромное значение для моего работодателя, поскольку существующая система, которую я заменял, изо всех сил пыталась беспрепятственно переключаться между python2 и 3, с conda и snakemake, это очень просто.
В принципе, я думаю, что это хорошая практика - запускать базовую среду conda и запускать оттуда Snakemake. Это поощряет использование единой среды для всего цикла. Будь проще, правда? Усложняйте вещи только при необходимости, например, когда нужно запустить python2 и python3 в одном конвейере. :)
person
TBoyarski
schedule
21.08.2017
