Возможна реализация динамического приоритета правил на основе количества входов? (создание змеи)

В моем графике рабочего процесса я объединяю один или несколько входных файлов на основе суффикса. В случаях, когда для данного суффикса существует только один файл, операция слияния тривиальна и может выполняться локально. В случае, если существует несколько таких файлов для слияния, операция слияния должна выполняться в кластере и занимает часы.

Есть ли способ указать / выбрать использование определенного правила, если я заранее знаю все входные файлы? Другими словами, есть ли способ выразить приоритет правила на основе количества входов в правило?

def _all_files_for_the_sample(wildcards):
    # lookup all known files and return list
    # of files matching wildcards.sample
    ...

# these two rules effectively have the same structure.
# I am omitting the implementation
rule super_fast_local_merge:
    input: _all_files_for_the_sample
    output: merged_{sample}.txt
    ...

rule super_slow_merge:
    input: _all_files_for_the_sample
    output: merged_{sample}.txt
    ...

Теперь у меня также есть правила, которые выполняют вычисления на выходах любого из правил выше. В руководстве упоминается, что при связывании нескольких цепочек правил более эффективно ссылаться на символы из глобальных правил напрямую (например, указание rules.super_slow_merge.output, а не дублирование merged_{sample}.txt в другом правиле). Меня заставили поверить, что, применяя псевдоним вывода определенного правила, я смогу повлиять на форму графика:

def _choose_merged_file(wildcards):
    all_inputs = _all_files_for_the_sample(wildcards.sample)
    if len(all_inputs) <= 1:
        # use trivial merge
        return rules.super_fast_local_merge.output
    else:
        # fallback to slow merge
        return rules.super_slow_merge.output

rule work_on_merged_data:
    input: _choose_merged_file,
    output: final_result_{sample}.txt
    ...

Если я запустил здесь что-то подобное, Snakemake пожалуется, что правила неоднозначны. Есть ли способ изменить функцию ввода _choose_merged_file, чтобы преодолеть это ограничение? Есть ли другой способ задать псевдоним для правила, которое я хочу напрямую?

Примечание: мне удалось заставить что-то работать, заставив каждую реализацию возвращать другое имя файла (например, merged_slow_{sample}.txt и merged_trivial_{sample}.txt), но это существенно портит каждое правило, которое работает с объединенными данными, с утомительными функциями ввода

Если бы кто-нибудь мог предоставить рецепт динамического изменения графика рабочего процесса, это было бы здорово.


person init_js    schedule 17.04.2018    source источник


Ответы (1)


С сожалением вынужден сообщить, что в настоящее время нет разумного способа добиться этого. Однако в ближайшем будущем появится решение - функция группировки заданий. Это позволит вам, основываясь на подстановочных знаках, входных файлах и т. Д., Решить, должны ли некоторые связанные задания отправляться вместе (на один и тот же узел в кластере). Таким образом, вы можете сгруппировать задание быстрого слияния с чем-то более длительным.

person Johannes Köster    schedule 17.04.2018
comment
Спасибо за подтверждение. На какую веху это запланировано? Я хотел бы следить за развитием этой функции. Для меня это обычная проблема - время ожидания заданий в очереди затмевает время обработки. Re: эта конкретная проблема с псевдонимом, я думаю, если бы был способ устранить неоднозначность между двумя правилами, производящими одну и ту же выходную строку (возможно, используя другой оператор идентификации в подклассе базовой строки), например merged_foo.txt из правила 1 и merged_foo.txt из правила 2, это был бы изящный способ статического соединения заданий (на первом этапе построения графа). - person init_js; 17.04.2018
comment
В некоторых случаях мне удавалось обойти группировку заданий (и отсутствие функций вывода), вместо этого создавая архивы архивов в качестве выходных данных правил. Это некрасиво. Я подозреваю, что есть способ динамически вводить правила в граф на ранней стадии, но тоже не очень! - person init_js; 17.04.2018