#snakemake
#snakemake
Вопрос:
вот сложная проблема, для которой я изо всех сил пытаюсь найти чистое решение:
Представьте, что у вас есть рабочий процесс Snakemake с несколькими правилами, которые можно каким-то образом параметризовать. Теперь мы, возможно, захотим протестировать различные настройки параметров для некоторых правил, чтобы увидеть, как отличаются результаты. Однако, в идеале, если эти правила зависят от выходных данных других правил, которые не параметризованы, мы хотим повторно использовать эти неизменяющиеся файлы вместо повторного вычисления их для каждой из наших настроек параметров. Кроме того, если это вообще возможно, все это должно быть необязательным, чтобы в случае по умолчанию пользователь ничего этого не видел.
В этом есть внутренняя сложность (указать, какие файлы используются повторно, и т.д.). Я также знаю, что это не совсем предполагаемый вариант использования Snakemake («воспроизводимые рабочие процессы»), а скорее мета-функция для экспериментов.
Вот несколько подходов:
- Наивное решение: добавьте подстановочные знаки для каждого возможного параметра в пути к файлам. Это становится уродливым, сложным в обслуживании и трудно быстро расширяемым. Не решение.
- Хорошим подходом могло бы быть присвоение имени каждому запуску и создание отдельного конфигурационного файла для этого имени, который содержит все необходимые нам настройки. Тогда нам нужен только подстановочный знак для такого именованного набора настроек параметров. Для этого, вероятно, потребуется прочитать некоторую таблицу файла meta-config и обработать ее. Однако это не решает проблему повторного использования. Кроме того, это означает, что нам нужно несколько конфигурационных файлов для одного вызова snakemake, и, похоже, это невозможно (вместо этого они обновляли бы друг друга, но не рассматривались как отдельные конфигурации для запуска отдельно).
- Каким-то образом используйте вспомогательные рабочие процессы, каждый раз указывая отдельные конфигурационные файлы, например, с помощью подстановочного знака. Не уверен, что это можно сделать (например,
configfile: path/to/{config_name}.yaml). Все еще не решение для повторного использования файлов. - Быстрый запуск: запустите все правила до последнего выходного файла, который является общим для разных конфигураций. Затем вручную (или с помощью какого-нибудь дополнительного скрипта) создайте каталоги с символическими ссылками на этот «базовый» запуск с отдельными конфигурационными файлами, которые определяют параметры для каждого конфигурационного запуска. Это по-прежнему требует вызова snakemake индивидуально для каждого из этих каталогов, усложняя использование кластера.
Однако ни одно из этих решений не решает всех проблем. Любые идеи приветствуются!
Заранее спасибо, всего наилучшего Лукас
Комментарии:
1. Я тоже думал об этом раньше. «Лучшее», что я мог придумать (но я никогда не реализовывал это), — это вычислить, например, shasum по соответствующим параметрам и добавить это в качестве подстановочного знака к имени файла.
2. Можете ли вы опубликовать какой-нибудь минимальный пример (ы) того, что вы пытаетесь сделать?
3. «Наивное решение: добавить подстановочные знаки для каждого возможного параметра в пути к файлам» Это действительно некрасиво, но для меня это очевидный путь. Snakemake, похоже, создан для работы на основе имен файлов.
4. «Кроме того, это означает, что нам нужно несколько конфигурационных файлов для одного вызова snakemake, и, похоже, это невозможно (вместо этого они обновляли бы друг друга, но не рассматривались как отдельные конфигурации для запуска отдельно)». Я не уверен, что понимаю, зачем вам понадобилось бы несколько «основных» конфигурационных файлов. Будет ли полезен конфигурационный файл, содержащий пути к другим конфигурационным файлам?
Ответ №1:
Snakemake теперь предлагает помощник Paramspace для решения этой проблемы! https://snakemake.readthedocs.io/en/stable/snakefiles/rules.html ?выделить=параметр#parameter-space-exploration
Я еще не пробовал это, но, похоже, это решение проблемы!