Snakemake работает с Subworkflow, но не с остальной частью моего рабочего процесса (идет напрямую к правилу All) - PullRequest
Новая
       3

Snakemake работает с Subworkflow, но не с остальной частью моего рабочего процесса (идет напрямую к правилу All)

1 голос
/ 12 марта 2020

Я новичок ie в Snakemake и в StackOverflow. Не стесняйтесь сказать мне, если что-то неясно или если вы хотите какие-либо другие детали. Я написал рабочий процесс, позволяющий преобразовывать файлы .BCL Illumina Base Calls в демультиплексированные файлы FASTQ и генерировать отчет Q C (файлы FastQ C). Этот рабочий процесс состоит из:

  • Подпроцесс "convert_bcl_to_fastq" Он создает файлы FASTQ в каталоге с именем Fastq из файлов BCL. Он должен быть выполнен до основного рабочего процесса, поэтому я решил использовать подпроцесс, поскольку мое второе правило зависит от генерации этих файлов FASTQ, имена которых я заранее не знаю. Поддельный файл "convert_bcl_to_fastq.done" создается в качестве выходных данных, чтобы узнать, когда этот подпроцесс выполнялся должным образом.
  • Правило "generate_fastq c" Он принимает файлы FASTQ, сгенерированные благодаря подпроцессу, и создает файлы FASTQ C в каталоге с именем FastQ C.

Проблема

Когда я пытаюсь запустить свой рабочий процесс, у меня не возникает никаких ошибок, но мой рабочий процесс не работает должным образом . Я получаю только подпроцесс для запуска , а затем выполняется основной рабочий процесс, но выполняется только правило "all" . Мое правило "generate_fastq c" вообще не выполняется . Я хотел бы знать, где я мог ошибаться? Вот что я получаю: 

Building DAG of jobs...
Executing subworkflow convert_bcl_to_fastq.
Building DAG of jobs...
Job counts:
        count   jobs
        1       convert_bcl_to_fastq
        1
[...]
Processing completed with 0 errors and 1 warnings.
Touching output file convert_bcl_to_fastq.done.
Finished job 0.
1 of 1 steps (100%) done
Complete log: /path/to/my/working/directory/conversion/.snakemake/log/2020-03-12T171952.799414.snakemake.log
Executing main workflow.
Using shell: /usr/bin/bash
Provided cores: 40
Rules claiming more threads will be scaled down.
Job counts:
        count   jobs
        1       all
        1

localrule all:
    input: /path/to/my/working/directory/conversion/convert_bcl_to_fastq.done
    jobid: 0

Finished job 0.
1 of 1 steps (100%) done

И когда все мои файлы FASTQ сгенерированы, , если я снова запусту свой рабочий процесс , на этот раз он выполнит правило "generate_fastq c ". 

Building DAG of jobs...
Executing subworkflow convert_bcl_to_fastq.
Building DAG of jobs...
Nothing to be done.
Complete log: /path/to/my/working/directory/conversion/.snakemake/log/2020-03-12T174337.605716.snakemake.log
Executing main workflow.
Using shell: /usr/bin/bash
Provided cores: 40
Rules claiming more threads will be scaled down.
Job counts:
        count   jobs
        1       all
        95      generate_fastqc
        96

Я хотел, чтобы мой рабочий процесс выполнялся полностью, запустив правило "generate_fastq c" сразу после завершения выполнения подпроцесса, но Я фактически вынужден выполнить свой рабочий процесс 2 раза . Я думал, что этот рабочий процесс будет работать, так как все файлы, необходимые во второй части рабочего процесса, будут сгенерированы благодаря вспомогательному процессу ... У вас есть идеи, где я мог ошибаться?

Мой код

Вот мой Snake-файл для основного рабочего процесса: 

subworkflow convert_bcl_to_fastq:
    workdir: WDIR + "conversion/"
    snakefile: WDIR + "conversion/Snakefile"

SAMPLES, = glob_wildcards(FASTQ_DIR + "{sample}_R1_001.fastq.gz")

rule all:
    input:
        convert_bcl_to_fastq("convert_bcl_to_fastq.done"),
        expand(FASTQC_DIR + "{sample}_R1_001_fastqc.html", sample=SAMPLES),
        expand(FASTQC_DIR + "{sample}_R2_001_fastqc.html", sample=SAMPLES)

rule generate_fastqc:
    output:
        FASTQC_DIR + "{sample}_R1_001_fastqc.html",
        FASTQC_DIR + "{sample}_R2_001_fastqc.html",
        temp(FASTQC_DIR + "{sample}_R1_001_fastqc.zip"),
        temp(FASTQC_DIR + "{sample}_R2_001_fastqc.zip")
    shell:
        "mkdir -p "+ FASTQC_DIR +" | " #Creates a FastQC directory if it is missing
        "fastqc --outdir "+ FASTQC_DIR +" "+ FASTQ_DIR +"{wildcards.sample}_R1_001.fastq.gz "+ FASTQ_DIR + " {wildcards.sample}_R2_001.fastq.gz &" #Generates FASTQC files for each sample at a time

Вот мой Snake-файл для подпроцесса "convert_bcl_to_fastq": 

rule all:
    input:
        "convert_bcl_to_fastq.done"

rule convert_bcl_to_fastq:
    output:
        touch("convert_bcl_to_fastq.done")
    shell:
        "mkdir -p "+ FASTQ_DIR +" | " #Creates a Fastq directory if it is missing
        "bcl2fastq --no-lane-splitting --runfolder-dir "+ INPUT_DIR +" --output-dir "+ FASTQ_DIR #Demultiplexes and Converts BCL files to FASTQ files

Заранее благодарю за помощь!

1 Ответ

0 голосов
/ 14 марта 2020

Документация о subworkflow s в настоящее время гласит: 

When executing, snakemake first tries to create (or update, if necessary) 
"test.txt" (and all other possibly mentioned dependencies) by executing the subworkflow. 
Then the current workflow is executed.

В вашем случае единственной объявленной зависимостью является "convert_bcl_to_fastq.done", которую Snakemake с радостью создает в первый раз .

Snakemake обычно выполняет однопроходный синтаксический анализ, и основной рабочий процесс не получает указаний искать файлы примеров из подпроцесса. Поскольку примеры файлов еще не существуют во время первого выполнения, основной рабочий процесс не соответствует в операторах expand(). Нет совпадений, никакая работа не требуется :-)

Когда вы запускаете основной рабочий процесс во второй раз, он находит выборочные совпадения в expand() из rule all: и производит их.

Примечание 1: будьте счастливы, заметив это. Используя ваш код, если вы действительно внесли изменения, которые требовали повторного запуска подпроцесса, Snakemake найдет старый "convert_bcl_to_fastq.done" и не выполнит повторный подпроцесс.

Примечание 2: Если вы хотите, чтобы Snakemake был менее «однопроходным», у него есть ключевое слово правила checkpoint, которое можно использовать для переоценки того, что необходимо сделать как следствие правила- выполнение. В вашем случае контрольно-пропускной пункт был бы rule convert_bcl_to_fastq. Это заставило бы правила находиться в одном логическом файле змеи (хотя include разрешает несколько файлов)

...