Flussi di lavoro di scrittura in WDL Scrittura di flussi di lavoro in Nextflow Scrittura di flussi di lavoro in CWL Esempio di definizione del workflow Esempio di definizione del flusso di lavoro WDL

Scrittura di definizioni di 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 .

Argomenti

Flussi di lavoro di scrittura in WDL
Scrittura di flussi di lavoro in Nextflow
Scrittura di flussi di lavoro in CWL
Esempio di definizione del workflow
Esempio di definizione del flusso di lavoro WDL

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.

Tipi primitivi
Tipo WDL	Tipo JSON	Esempio WDL	Esempio di chiave e valore JSON	Note
`Boolean`	`boolean`	`Boolean b`	`"b": true`	Il valore deve essere minuscolo e senza virgolette.
`Int`	`integer`	`Int i`	`"i": 7`	Deve essere senza virgolette.
`Float`	`number`	`Float f`	`"f": 42.2`	Deve essere non quotato.
`String`	`string`	`String s`	`"s": "characters"`	Le stringhe JSON che sono un URI devono essere mappate su un file WDL per essere importate.
`File`	`string`	`File f`	`"f": "s3://amzn-s3-demo-bucket1/path/to/file"`	Amazon S3 e HealthOmics lo storage URIs vengono importati purché il ruolo IAM fornito per il flusso di lavoro abbia accesso in lettura a questi oggetti. Non sono supportati altri schemi URI (come `file://https://`, e`ftp://`). L'URI deve specificare un oggetto. Non può essere una directory, il che significa che non può terminare con un`/`.
`Directory`	`string`	`Directory d`	`"d": "s3://bucket/path/"`	Il `Directory` tipo non è incluso in WDL 1.0 o 1.1, quindi sarà necessario aggiungerlo `version development` all'intestazione del file WDL. L'URI deve essere un URI Amazon S3 e deve avere un prefisso che termina con un '/'. Tutti i contenuti della directory verranno copiati in modo ricorsivo nel flusso di lavoro come singolo download. `Directory`Deve contenere solo file relativi al flusso di lavoro.

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

Tipi complessi
Tipo WDL	Tipo JSON	Esempio WDL	Esempio di chiave e valore JSON	Note
`Array`	`array`	`Array[Int] nums`	`“nums": [1, 2, 3]`	I membri dell'array devono seguire il formato del tipo di array WDL.
`Pair`	`object`	`Pair[String, Int] str_to_i`	`“str_to_i": {"left": "0", "right": 1}`	Ogni valore della coppia deve utilizzare il formato JSON del tipo WDL corrispondente.
`Map`	`object`	`Map[Int, String] int_to_string`	`"int_to_string": { 2: "hello", 1: "goodbye" }`	Ogni voce nella mappa deve utilizzare il formato JSON del tipo WDL corrispondente.
`Struct`	`object`	`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" }`	I nomi dei membri della struttura devono corrispondere esattamente ai nomi delle chiavi degli oggetti JSON. Ogni valore deve utilizzare il formato JSON del tipo WDL corrispondente.
`Object`	N/D	N/D	N/D	Il `Object` tipo WDL è obsoleto e deve essere sostituito da `Struct` in tutti i casi.

Il motore del HealthOmics flusso di lavoro 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

Nota

HealthOmics supporta i nf-validation plugin nf-schema e con la versione di Nextflow v23.10 (ma non v22.04).

Le seguenti informazioni si riferiscono all'utilizzo di questi plugin con i flussi di lavoro Nextflow v23.10:

HealthOmics preinstalla i plugin nf-schema @2 .3.0 e nf-validation @1 .1.1. HealthOmics ignora qualsiasi altra versione del plugin specificata nel file. nextflow.config
Non è possibile recuperare plug-in aggiuntivi durante l'esecuzione di un flusso di lavoro.
In Nextflow v24.04 e versioni successive, il plugin viene rinominato in. nf-validation nf-schema Per ulteriori informazioni, consulta nf-schema nel repository Nextflow. GitHub

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

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:

Sostituisci tutti i container Docker URIs con Amazon URIs ECR.
Assicurati che tutti i file del flusso di lavoro siano dichiarati come input nel flusso di lavoro principale e che tutte le variabili siano definite in modo esplicito.
Assicurati che tutto il JavaScript codice sia conforme alla modalità rigorosa.

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.

WDL


version 1.1

task my_task {
   runtime { ... }
   inputs {
       File input_file
       String name
       Int threshold
   }
   
   command <<<
   my_tool --name ~{name} --threshold ~{threshold} ~{input_file}
   >>>
   
   output {
       File results = "results.txt"
   }
}

workflow my_workflow {
   inputs {
       File input_file
       String name
       Int threshold = 50
   }
   
   call my_task {
       input:
          input_file = input_file,
          name = name,
          threshold = threshold
   }
   outputs {
       File results = my_task.results
   }
}

Nextflow


nextflow.enable.dsl = 2

params.input_file = null
params.name = null
params.threshold = 50

process my_task {
   // <directives>
   
   input:
     path input_file
     val name
     val threshold
   
   output:
     path 'results.txt', emit: results
   
   script:
     """
     my_tool --name ${name} --threshold ${threshold} ${input_file}
     """
     
   
}

workflow MY_WORKFLOW {
   my_task(
       params.input_file,
       params.name,
       params.threshold
   )
}

workflow {
   MY_WORKFLOW()
}

CWL


cwlVersion: v1.2
class: Workflow

requirements:
    InlineJavascriptRequirement: {}

inputs:
   input_file: File
   name: string
   threshold: int

outputs:
    result:
        type: ...
        outputSource: ...

steps:
    my_task:
        run:
            class: CommandLineTool
            baseCommand: my_tool
            requirements:
                ...
            inputs:
                name:
                    type: string
                    inputBinding:
                        prefix: "--name"
                threshold:
                    type: int
                    inputBinding:
                        prefix: "--threshold"
                input_file:
                    type: File
                    inputBinding: {}
            outputs:
                results:
                    type: File
                    outputBinding:
                        glob: results.txt

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}"
      }
  }

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Acceleratori di attività

File modello di parametri