Écrire des flux de travail dans WDL Écrire des flux de travail dans Nextflow Écrire des flux de travail dans CWL Exemple de définition de flux de travail Exemple de définition de flux de travail WDL

Rédaction de définitions pour les HealthOmics flux de travail

HealthOmics prend en charge les définitions de flux de travail écrites en WDL, Nextflow ou CWL. Pour en savoir plus sur ces langages de flux de travail, consultez les spécifications de WDL, Nextflow ou CWL.

HealthOmics prend en charge la gestion des versions pour les trois langages de définition du flux de travail. Pour de plus amples informations, veuillez consulter Support de version pour les langages HealthOmics de définition des flux de travail .

Rubriques

Écrire des flux de travail dans WDL
Écrire des flux de travail dans Nextflow
Écrire des flux de travail dans CWL
Exemple de définition de flux de travail
Exemple de définition de flux de travail WDL

Écrire des flux de travail dans WDL

Les tableaux suivants montrent comment les entrées dans WDL correspondent au type primitif ou au type JSON complexe correspondant. La coercition de type est limitée et, dans la mesure du possible, les types doivent être explicites.

Types primitifs
Type WDL	Type JSON	Exemple WDL	Exemple de clé et de valeur JSON	Remarques
`Boolean`	`boolean`	`Boolean b`	`"b": true`	La valeur doit être en minuscules et sans guillemets.
`Int`	`integer`	`Int i`	`"i": 7`	Ne doit pas être entre guillemets.
`Float`	`number`	`Float f`	`"f": 42.2`	Ne doit pas être entre guillemets.
`String`	`string`	`String s`	`"s": "characters"`	Les chaînes JSON qui sont des URI doivent être mappées à un fichier WDL pour être importées.
`File`	`string`	`File f`	`"f": "s3://amzn-s3-demo-bucket1/path/to/file"`	Amazon S3 et le HealthOmics stockage URIs sont importés tant que le rôle IAM fourni pour le flux de travail dispose d'un accès en lecture à ces objets. Aucun autre schéma d'URI n'est pris en charge (tel que `file://https://`, et`ftp://`). L'URI doit spécifier un objet. Il ne peut pas s'agir d'un répertoire, ce qui signifie qu'il ne peut pas se terminer par un`/`.
`Directory`	`string`	`Directory d`	`"d": "s3://bucket/path/"`	Le `Directory` type n'est pas inclus dans WDL 1.0 ou 1.1, vous devrez donc l'ajouter `version development` à l'en-tête du fichier WDL. L'URI doit être un URI Amazon S3 avec un préfixe se terminant par un «/». Tout le contenu du répertoire sera copié de manière récursive dans le flux de travail en un seul téléchargement. Le ne `Directory` doit contenir que des fichiers liés au flux de travail.

Les types complexes dans WDL sont des structures de données composées de types primitifs. Les structures de données telles que les listes seront converties en tableaux.

Types complexes
Type WDL	Type JSON	Exemple WDL	Exemple de clé et de valeur JSON	Remarques
`Array`	`array`	`Array[Int] nums`	`“nums": [1, 2, 3]`	Les membres du tableau doivent suivre le format du type de tableau WDL.
`Pair`	`object`	`Pair[String, Int] str_to_i`	`“str_to_i": {"left": "0", "right": 1}`	Chaque valeur de la paire doit utiliser le format JSON du type WDL correspondant.
`Map`	`object`	`Map[Int, String] int_to_string`	`"int_to_string": { 2: "hello", 1: "goodbye" }`	Chaque entrée de la carte doit utiliser le format JSON du type WDL correspondant.
`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" }`	Les noms des membres de la structure doivent correspondre exactement aux noms des clés d'objet JSON. Chaque valeur doit utiliser le format JSON du type WDL correspondant.
`Object`	N/A	N/A	N/A	Le `Object` type WDL est obsolète et doit être remplacé par `Struct` dans tous les cas.

Le moteur HealthOmics de flux de travail ne prend pas en charge les paramètres d'entrée qualifiés ou espacés par des noms. La gestion des paramètres qualifiés et leur mappage aux paramètres WDL ne sont pas spécifiés par le langage WDL et peuvent être ambigus. Pour ces raisons, la meilleure pratique consiste à déclarer tous les paramètres d'entrée dans le fichier de définition du flux de travail de niveau supérieur (principal) et à les transmettre aux appels de sous-flux de travail à l'aide des mécanismes WDL standard.

Écrire des flux de travail dans Nextflow

HealthOmics prend en charge DSL1 Nextflow et. DSL2 Pour en savoir plus, consultez Support de la version Nextflow.

Nextflow DSL2 est basé sur le langage de programmation Groovy, les paramètres sont donc dynamiques et la coercition de type est possible en utilisant les mêmes règles que Groovy. Les paramètres et valeurs fournis par le JSON d'entrée sont disponibles dans la carte parameters (params) du flux de travail.

Note

HealthOmics supporte les nf-validation plugins nf-schema et avec la version 23.10 de Nextflow (mais pas la version 22.04).

Les informations suivantes concernent l'utilisation de ces plug-ins avec les flux de travail Nextflow v23.10 :

HealthOmics préinstalle les plugins nf-schema @2 .3.0 et nf-validation @1 .1.1. HealthOmics ignore toutes les autres versions de plug-in que vous spécifiez dans le nextflow.config fichier.
Vous ne pouvez pas récupérer de plug-ins supplémentaires lors de l'exécution d'un flux de travail.
Dans Nextflow v24.04 et versions ultérieures, le nf-validation plugin est renommé en. nf-schema Pour plus d'informations, consultez nf-schema dans le référentiel GitHub Nextflow.

Lorsqu'un Amazon S3 ou un HealthOmics URI est utilisé pour créer un fichier ou un objet de chemin Nextflow, l'objet correspondant est mis à la disposition du flux de travail, à condition que l'accès en lecture soit accordé. L'utilisation de préfixes ou de répertoires est autorisée pour Amazon S3 URIs. Pour obtenir des exemples, consultez Formats de paramètres d'entrée Amazon S3.

HealthOmics prend en charge l'utilisation de modèles globaux dans Amazon S3 URIs ou HealthOmics Storage URIs. Utilisez des modèles Glob dans la définition du flux de travail pour la création de path file canaux.

Pour les flux de travail écrits dans Nextflow, définissez une directive PublishDir pour exporter le contenu des tâches vers votre compartiment Amazon S3 de sortie. Comme indiqué dans l'exemple suivant, définissez la valeur PublishDir sur. /mnt/workflow/pubdir Pour exporter des fichiers vers Amazon S3, les fichiers doivent se trouver dans ce répertoire.


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

Écrire des flux de travail dans CWL

Les flux de travail écrits en langage de flux de travail commun, ou CWL, offrent des fonctionnalités similaires à celles des flux de travail écrits en WDL et Nextflow. Vous pouvez utiliser Amazon S3 ou le HealthOmics stockage URIs comme paramètres d'entrée.

Si vous définissez une entrée dans un fichier secondaire dans un sous-flux de travail, ajoutez la même définition dans le flux de travail principal.

HealthOmics les flux de travail ne prennent pas en charge les processus opérationnels. Pour en savoir plus sur les processus opérationnels dans les flux de travail CWL, consultez la documentation CWL.

Pour convertir un fichier de définition de flux de travail CWL existant à utiliser HealthOmics, apportez les modifications suivantes :

Remplacez tous les conteneurs Docker URIs par Amazon URIs ECR.
Assurez-vous que tous les fichiers de flux de travail sont déclarés en entrée dans le flux de travail principal et que toutes les variables sont définies de manière explicite.
Assurez-vous que tout le JavaScript code est conforme au mode strict.

Les flux de travail CWL doivent être définis pour chaque conteneur utilisé. Il n'est pas recommandé de coder en dur l'entrée DockerPull avec un URI Amazon ECR fixe.

Voici un exemple de flux de travail écrit en 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

Le fichier suivant définit la copy.cwl tâche.



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

Voici un exemple de flux de travail écrit en CWL avec une exigence de 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: []

Exemple de définition de flux de travail

L'exemple suivant montre la même définition de flux de travail dans WDL, Nextflow et 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

Exemple de définition de flux de travail WDL

Les exemples suivants présentent des définitions de flux de travail privés pour la conversion de CRAM vers BAM dans WDL. Le BAM flux CRAM de travail to définit deux tâches et utilise les outils du genomes-in-the-cloud conteneur, qui est illustré dans l'exemple et est accessible au public.

L'exemple suivant montre comment inclure le conteneur Amazon ECR en tant que paramètre. Cela permet HealthOmics de vérifier les autorisations d'accès à votre conteneur avant qu'il ne commence l'exécution.


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

L'exemple suivant montre comment spécifier les fichiers à utiliser lors de votre exécution, lorsque les fichiers se trouvent dans un compartiment 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"
  }

Si vous souhaitez spécifier des fichiers à partir d'un magasin de séquences, indiquez-le comme indiqué dans l'exemple suivant, en utilisant l'URI du magasin de séquences.


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

Vous pouvez ensuite définir votre flux de travail dans WDL comme indiqué ci-dessous.


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

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Accélérateurs de tâches

Fichiers de modèles de paramètres