Scrittura delle definizioni dei flussi di lavoro per i flussi HealthOmics di lavoro

HealthOmics supporta le definizioni dei flussi di lavoro scritte in WDL, Nextflow o CWL. Per ulteriori informazioni su questi linguaggi di workflow, consulta le specifiche di WDL, Nextflow o CWL.

HealthOmics supporta la gestione delle versioni per i tre linguaggi di definizione del flusso di lavoro. Per ulteriori informazioni, consulta Supporto della versione per i linguaggi HealthOmics di definizione del flusso di lavoro .

Flussi di lavoro di scrittura in WDL

Le tabelle seguenti mostrano come gli input in WDL vengono mappati al tipo primitivo corrispondente o al tipo JSON complesso. La coercizione dei tipi è limitata e, quando possibile, i tipi devono essere espliciti.

I tipi complessi in WDL sono strutture di dati composte da tipi primitivi. Le strutture di dati come gli elenchi verranno convertite in matrici.

struct SampleBamAndIndex { 
  String sample_name 
  File bam 
  File bam_index 
} SampleBamAndIndex b_and_i

"b_and_i": { 
   "sample_name": "NA12878", 
   "bam": "s3://amzn-s3-demo-bucket1/NA12878.bam", 
   "bam_index": "s3://amzn-s3-demo-bucket1/NA12878.bam.bai" 
}           

Il motore HealthOmics di workflow non supporta parametri di input qualificati o con spaziatura tra nomi. La gestione dei parametri qualificati e la loro mappatura ai parametri WDL non sono specificate dal linguaggio WDL e possono essere ambigue. Per questi motivi, è consigliabile dichiarare tutti i parametri di input nel file di definizione del flusso di lavoro di primo livello (principale) e trasmetterli alle chiamate del flusso di lavoro secondario utilizzando meccanismi WDL standard.

Scrittura di flussi di lavoro in Nextflow

HealthOmics supporta Nextflow e. DSL1 DSL2 Per informazioni dettagliate, consultare Supporto per la versione Nextflow.

Nextflow si DSL2 basa sul linguaggio di programmazione Groovy, quindi i parametri sono dinamici e la coercizione dei tipi è possibile utilizzando le stesse regole di Groovy. I parametri e i valori forniti dall'input JSON sono disponibili nella mappa parameters () del flusso di lavoro. params

Utilizzo dei plugin nf-schema e nf-validation

HealthOmics fornisce il seguente supporto per i plugin Nextflow:

Specificare lo storage URIs

Quando un Amazon S3 o un HealthOmics URI viene utilizzato per costruire un file o un oggetto di percorso Nextflow, rende l'oggetto corrispondente disponibile per il flusso di lavoro, purché sia concesso l'accesso in lettura. L'uso di prefissi o directory è consentito per Amazon S3. URIs Per alcuni esempi, consulta Formati dei parametri di input di Amazon S3.

HealthOmics supporta l'uso di modelli glob in Amazon URIs S3 HealthOmics o Storage. URIs Usa i pattern Glob nella definizione del flusso di lavoro per la creazione dei path nostri canali. file

Impostazione della durata massima delle attività utilizzando le direttive temporali

HealthOmics fornisce una quota regolabile (vediHealthOmics quote di servizio) per specificare la durata massima di un'esecuzione. Per i flussi di lavoro Nextflow v23 e v24, puoi anche specificare la durata massima delle attività utilizzando le direttive temporali di Nextflow.

Durante lo sviluppo di nuovi flussi di lavoro, l'impostazione della durata massima delle attività consente di catturare attività inutili e attività di lunga durata.

Per ulteriori informazioni sulla direttiva time di Nextflow, consulta la direttiva time nel riferimento di Nextflow.

HealthOmics fornisce il seguente supporto per le direttive temporali di Nextflow:

Specificate la durata del timeout utilizzando una o più delle seguenti unità:ms,, s mh, o. d È possibile specificare le direttive temporali nel file di configurazione di Nextflow e nella definizione del flusso di lavoro. L'elenco seguente mostra l'ordine di precedenza, dalla priorità più bassa a quella più alta:

L'esempio seguente mostra come specificare la configurazione globale nel file di configurazione Nextflow. Imposta un timeout globale di 1 ora e 30 minuti:

process {
    time = '1h30m'
}     

L'esempio seguente mostra come specificare una direttiva temporale nella sezione delle attività della definizione del flusso di lavoro. Questo esempio imposta un timeout di 3 giorni, 5 ore e 4 minuti. Questo valore ha la precedenza sul valore globale nel file di configurazione, ma non ha la precedenza su una direttiva temporale specifica per l'attività nel file di configurazione: my_label

process myTask {
    label 'my_label'
    time '3d5h4m'
        
    script:
    """
    your-command-here
    """
}     

L'esempio seguente mostra come specificare le direttive temporali specifiche dell'attività nel file di configurazione Nextflow, in base ai selettori di nome o etichetta. Questo esempio imposta un valore di timeout globale dell'attività di 30 minuti. Imposta un valore di 2 ore per l'attività myTask e imposta un valore di 3 ore per le attività con etichettamy_label. Per le attività che corrispondono al selettore, questi valori hanno la precedenza sul valore globale e sul valore nella definizione del flusso di lavoro:

process {
    time = '30m'
    
    withLabel: 'my_label' {
        time = '3h'  
    }

    withName: 'myTask' {
        time = '2h'  
    }
}     

Esportazione del contenuto delle attività

Per i flussi di lavoro scritti in Nextflow, definisci una direttiva PublishDir per esportare il contenuto delle attività nel tuo bucket Amazon S3 di output. Come mostrato nell'esempio seguente, imposta il valore PublishDir su. /mnt/workflow/pubdir Per esportare file in Amazon S3, i file devono trovarsi in questa directory.

 nextflow.enable.dsl=2
              
  workflow {
    CramToBamTask(params.ref_fasta, params.ref_fasta_index, params.ref_dict, params.input_cram, params.sample_name)
    ValidateSamFile(CramToBamTask.out.outputBam)
  }
  
  process CramToBamTask {
    container "<account>.dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-cloud"
  
    publishDir "/mnt/workflow/pubdir"
  
    input:
        path ref_fasta
        path ref_fasta_index
        path ref_dict
        path input_cram
        val sample_name
  
    output:
        path "${sample_name}.bam", emit: outputBam
        path "${sample_name}.bai", emit: outputBai
  
    script:
    """
        set -eo pipefail
  
        samtools view -h -T $ref_fasta $input_cram |
        samtools view -b -o ${sample_name}.bam -
        samtools index -b ${sample_name}.bam
        mv ${sample_name}.bam.bai ${sample_name}.bai
    """
  }
  
  process ValidateSamFile {
    container "<account>.dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-cloud"
  
    publishDir "/mnt/workflow/pubdir"
  
    input:
        file input_bam
  
    output:
        path "validation_report"
  
    script:
    """
        java -Xmx3G -jar /usr/gitc/picard.jar \
        ValidateSamFile \
        INPUT=${input_bam} \
        OUTPUT=validation_report \
        MODE=SUMMARY \
        IS_BISULFITE_SEQUENCED=false
    """
  }   

Scrittura di flussi di lavoro in CWL

I flussi di lavoro scritti in Common Workflow Language, o CWL, offrono funzionalità simili ai flussi di lavoro scritti in WDL e Nextflow. Puoi utilizzare Amazon S3 o HealthOmics lo storage URIs come parametri di input.

Se definisci l'input in un SecondaryFile in un flusso di lavoro secondario, aggiungi la stessa definizione nel flusso di lavoro principale.

HealthOmics i flussi di lavoro non supportano i processi operativi. Per ulteriori informazioni sui processi operativi nei flussi di lavoro CWL, consultate la documentazione CWL.

Per convertire un file di definizione del flusso di lavoro CWL esistente da utilizzare HealthOmics, apportate le seguenti modifiche:

I flussi di lavoro CWL devono essere definiti per ogni contenitore utilizzato. Non è consigliabile codificare la voce DockerPull con un URI Amazon ECR fisso.

Di seguito è riportato un esempio di flusso di lavoro scritto in CWL.

cwlVersion: v1.2
class: Workflow

inputs:
in_file:
  type: File
  secondaryFiles: [.fai]
 
out_filename: string
docker_image: string


outputs:
copied_file:
  type: File
  outputSource: copy_step/copied_file

steps:
copy_step:
  in:
    in_file: in_file
    out_filename: out_filename
    docker_image: docker_image
  out: [copied_file]
  run: copy.cwl            
      

Il file seguente definisce l'copy.cwlattività.

cwlVersion: v1.2
class: CommandLineTool
baseCommand: cp

inputs:
in_file:
  type: File
  secondaryFiles: [.fai]
  inputBinding:
    position: 1

out_filename:
  type: string
  inputBinding:
    position: 2
docker_image:
  type: string

outputs:
copied_file:
  type: File
  outputBinding:
      glob: $(inputs.out_filename)

requirements:
InlineJavascriptRequirement: {}
DockerRequirement:
  dockerPull: "$(inputs.docker_image)"      

Di seguito è riportato un esempio di flusso di lavoro scritto in CWL con un requisito GPU.

cwlVersion: v1.2
class: CommandLineTool
baseCommand: ["/bin/bash", "docm_haplotypeCaller.sh"]
$namespaces:
cwltool: http://commonwl.org/cwltool#
requirements:
cwltool:CUDARequirement:
  cudaDeviceCountMin: 1
  cudaComputeCapability: "nvidia-tesla-t4" 
  cudaVersionMin: "1.0"
InlineJavascriptRequirement: {}
InitialWorkDirRequirement:
  listing:
  - entryname: 'docm_haplotypeCaller.sh'
    entry: |
            nvidia-smi --query-gpu=gpu_name,gpu_bus_id,vbios_version --format=csv   

inputs: []
outputs: []     

Esempio di definizione del workflow

L'esempio seguente mostra la stessa definizione di flusso di lavoro in WDL, Nextflow e CWL.

Esempio di definizione del flusso di lavoro WDL

Gli esempi seguenti mostrano le definizioni di workflow private per la conversione da CRAM a BAM in WDL. Il BAM flusso di lavoro CRAM to definisce due attività e utilizza gli strumenti del genomes-in-the-cloud contenitore, illustrato nell'esempio e disponibile pubblicamente.

L'esempio seguente mostra come includere il contenitore Amazon ECR come parametro. Ciò consente di HealthOmics verificare le autorizzazioni di accesso al contenitore prima che inizi l'esecuzione.

{
     ...
     "gotc_docker":"<account_id>.dkr.ecr.<region>.amazonaws.com/genomes-in-the-cloud:2.4.7-1603303710"
  }       

L'esempio seguente mostra come specificare quali file utilizzare nell'esecuzione, quando i file si trovano in un bucket Amazon S3.

{
      "input_cram": "s3://amzn-s3-demo-bucket1/inputs/NA12878.cram",
      "ref_dict": "s3://amzn-s3-demo-bucket1/inputs/Homo_sapiens_assembly38.dict",
      "ref_fasta": "s3://amzn-s3-demo-bucket1/inputs/Homo_sapiens_assembly38.fasta",
      "ref_fasta_index": "s3://amzn-s3-demo-bucket1/inputs/Homo_sapiens_assembly38.fasta.fai",
      "sample_name": "NA12878"
  }       

Se desideri specificare file da un archivio di sequenze, indicalo come mostrato nell'esempio seguente, utilizzando l'URI per l'archivio delle sequenze.

{
      "input_cram": "omics://429915189008.storage.us-west-2.amazonaws.com/111122223333/readSet/4500843795/source1",
      "ref_dict": "s3://amzn-s3-demo-bucket1/inputs/Homo_sapiens_assembly38.dict",
      "ref_fasta": "s3://amzn-s3-demo-bucket1/inputs/Homo_sapiens_assembly38.fasta",
      "ref_fasta_index": "s3://amzn-s3-demo-bucket1/inputs/Homo_sapiens_assembly38.fasta.fai",
      "sample_name": "NA12878"
  }       

È quindi possibile definire il flusso di lavoro in WDL come illustrato di seguito.

 version 1.0
  workflow CramToBamFlow {
      input {
          File ref_fasta
          File ref_fasta_index
          File ref_dict
          File input_cram
          String sample_name
          String gotc_docker = "<account>.dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-
  cloud:latest"
      }
      #Converts CRAM to SAM to BAM and makes BAI.
      call CramToBamTask{
           input:
              ref_fasta = ref_fasta,
              ref_fasta_index = ref_fasta_index,
              ref_dict = ref_dict,
              input_cram = input_cram,
              sample_name = sample_name,
              docker_image = gotc_docker,
       }
       #Validates Bam.
       call ValidateSamFile{
          input:
             input_bam = CramToBamTask.outputBam,
             docker_image = gotc_docker,
       }
       #Outputs Bam, Bai, and validation report to the FireCloud data model.
       output {
           File outputBam = CramToBamTask.outputBam
           File outputBai = CramToBamTask.outputBai
           File validation_report = ValidateSamFile.report
        }
  }
  #Task definitions.
  task CramToBamTask {
      input {
         # Command parameters
         File ref_fasta
         File ref_fasta_index
         File ref_dict
         File input_cram
         String sample_name
         # Runtime parameters
         String docker_image
      }
     #Calls samtools view to do the conversion.
     command {
         set -eo pipefail
  
         samtools view -h -T ~{ref_fasta} ~{input_cram} |
         samtools view -b -o ~{sample_name}.bam -
         samtools index -b ~{sample_name}.bam
         mv ~{sample_name}.bam.bai ~{sample_name}.bai
      }
      
      #Runtime attributes:
      runtime {
          docker: docker_image
      }
  
      #Outputs a BAM and BAI with the same sample name
       output {
           File outputBam = "~{sample_name}.bam"
           File outputBai = "~{sample_name}.bai"
      }
  }
  
  #Validates BAM output to ensure it wasn't corrupted during the file conversion.
  task ValidateSamFile {
     input {
        File input_bam
        Int machine_mem_size = 4
        String docker_image
     }
     String output_name = basename(input_bam, ".bam") + ".validation_report"
     Int command_mem_size = machine_mem_size - 1
     command {
         java -Xmx~{command_mem_size}G -jar /usr/gitc/picard.jar \
         ValidateSamFile \
         INPUT=~{input_bam} \
         OUTPUT=~{output_name} \
         MODE=SUMMARY \
         IS_BISULFITE_SEQUENCED=false
      }
      runtime {
      docker: docker_image
      }
     #A text file is generated that lists errors or warnings that apply.
      output {
          File report = "~{output_name}"
      }
  }