Escribir definiciones de flujos de trabajo para HealthOmics flujos de trabajo - AWS HealthOmics
Escribir flujos de trabajo en WDLEscribir flujos de trabajo en NextflowFlujos de trabajo de escritura en CWLEjemplo de definición de flujo de trabajoEjemplo de definición de flujo de trabajo de WDL

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Escribir definiciones de flujos de trabajo para HealthOmics flujos de trabajo

HealthOmics admite definiciones de flujos de trabajo escritas en WDL, Nextflow o CWL. Para obtener más información sobre estos lenguajes de flujo de trabajo, consulte las especificaciones de WDL, Nextflow o CWL.

HealthOmics admite la administración de versiones para los tres lenguajes de definición de flujos de trabajo. Para obtener más información, consulte Soporte de versiones para lenguajes de definición HealthOmics de flujos de trabajo .

Escribir flujos de trabajo en WDL

En las tablas siguientes se muestra cómo las entradas de la WDL se asignan al tipo primitivo o al tipo JSON complejo coincidente. La coerción de tipos es limitada y, siempre que sea posible, los tipos deben ser explícitos.

Tipos primitivos
Tipo WDL Tipo JSON Ejemplo de WDL Ejemplo de clave y valor de JSON Notas
Boolean boolean Boolean b "b": true El valor debe estar en minúsculas y sin comillas.
Int integer Int i "i": 7 No debe estar entre comillas.
Float number Float f "f": 42.2 No debe estar entre comillas.
String string String s "s": "characters" Las cadenas JSON que son un URI deben asignarse a un archivo WDL para importarlas.
File string File f "f": "s3://amzn-s3-demo-bucket1/path/to/file" Amazon S3 y el HealthOmics almacenamiento URIs se importan siempre que la función de IAM proporcionada para el flujo de trabajo tenga acceso de lectura a estos objetos. No se admite ningún otro esquema de URI (como file://https://, yftp://). El URI debe especificar un objeto. No puede ser un directorio, lo que significa que no puede terminar con un/.
Directory string Directory d "d": "s3://bucket/path/" El Directory tipo no está incluido en WDL 1.0 ni 1.1, por lo que tendrá que añadirlo version development al encabezado del archivo WDL. El URI debe ser un URI de Amazon S3 y tener un prefijo que termine en «/». Todo el contenido del directorio se copiará de forma recursiva en el flujo de trabajo como una sola descarga. Solo Directory debe contener archivos relacionados con el flujo de trabajo.

Los tipos complejos de la WDL son estructuras de datos compuestas por tipos primitivos. Las estructuras de datos, como las listas, se convertirán en matrices.

Tipos complejos
Tipo WDL Tipo JSON Ejemplo de WDL Ejemplo de clave y valor de JSON Notas
Array array Array[Int] nums “nums": [1, 2, 3] Los miembros de la matriz deben seguir el formato del tipo de matriz WDL.
Pair object Pair[String, Int] str_to_i “str_to_i": {"left": "0", "right": 1} Cada valor del par debe usar el formato JSON del tipo de WDL correspondiente.
Map object Map[Int, String] int_to_string "int_to_string": { 2: "hello", 1: "goodbye" } Cada entrada del mapa debe usar el formato JSON del tipo de WDL correspondiente.
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" 
}
Los nombres de los miembros de la estructura deben coincidir exactamente con los nombres de las claves de los objetos JSON. Cada valor debe usar el formato JSON del tipo WDL correspondiente.
Object N/A N/A N/A El Object tipo WDL está desactualizado y debe sustituirse por él Struct en todos los casos.

El motor HealthOmics de flujo de trabajo no admite parámetros de entrada cualificados o espaciados por nombres. El lenguaje de la WDL no especifica el manejo de los parámetros calificados y su asignación a los parámetros de la WDL y puede resultar ambigua. Por estos motivos, la mejor práctica consiste en declarar todos los parámetros de entrada en el archivo de definición del flujo de trabajo de nivel superior (principal) y pasarlos a las llamadas de los subflujos de trabajo mediante los mecanismos de WDL estándar.

Escribir flujos de trabajo en Nextflow

HealthOmics es compatible con Nextflow y. DSL1 DSL2 Para obtener más información, consulte Compatibilidad con la versión de Nextflow.

Nextflow DSL2 se basa en el lenguaje de programación Groovy, por lo que los parámetros son dinámicos y la coerción de tipos es posible utilizando las mismas reglas que Groovy. Los parámetros y valores proporcionados por el JSON de entrada están disponibles en el mapa de parámetros () params del flujo de trabajo.

nota

HealthOmics es compatible con los nf-validation complementos nf-schema y con la versión 23.10 de Nextflow (pero no con la 22.04).

La siguiente información se refiere al uso de estos complementos con los flujos de trabajo de Nextflow v23.10:

  • HealthOmics preinstala los complementos nf-schema @2 .3.0 y nf-validation @1 .1.1. HealthOmics ignora cualquier otra versión del complemento que especifique en el archivo. nextflow.config

  • No puedes recuperar complementos adicionales durante la ejecución de un flujo de trabajo.

  • En la versión 24.04 de Nextflow y versiones posteriores, el nombre del nf-validation complemento pasa a ser. nf-schema Para obtener más información, consulte nf-schema en el repositorio de Nextflow. GitHub

Cuando se utiliza un Amazon S3 o un HealthOmics URI para crear un archivo o un objeto de ruta de Nextflow, el objeto coincidente está disponible para el flujo de trabajo, siempre y cuando se conceda el acceso de lectura. Se permite el uso de prefijos o directorios en Amazon S3 URIs. Para ver ejemplos, consulta Formatos de parámetros de entrada de Amazon S3.

HealthOmics admite el uso de patrones globales en Amazon S3 URIs o HealthOmics Storage URIs. Utilice patrones globales en la definición del flujo de trabajo para la creación de nuestros canalespath. file

Para los flujos de trabajo escritos en Nextflow, defina una directiva PublishDir para exportar el contenido de las tareas a su bucket de salida de Amazon S3. Como se muestra en el siguiente ejemplo, defina el valor PublishDir en. /mnt/workflow/pubdir Para exportar archivos a Amazon S3, los archivos deben estar en este directorio.

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

Flujos de trabajo de escritura en CWL

Los flujos de trabajo escritos en Common Workflow Language, o CWL, ofrecen una funcionalidad similar a los flujos de trabajo escritos en WDL y Nextflow. Puede utilizar Amazon S3 o el HealthOmics almacenamiento URIs como parámetros de entrada.

Si define la entrada en un archivo secundario de un subflujo de trabajo, añada la misma definición en el flujo de trabajo principal.

HealthOmics los flujos de trabajo no admiten los procesos de operación. Para obtener más información sobre los procesos operativos en los flujos de trabajo de CWL, consulte la documentación de CWL.

Para convertir un archivo de definición de flujo de trabajo de CWL existente y utilizarlo HealthOmics, realice los siguientes cambios:

  • Sustituya todos los contenedores URIs de Docker por Amazon URIs ECR.

  • Asegúrese de que todos los archivos del flujo de trabajo estén declarados en el flujo de trabajo principal como entrada y de que todas las variables estén definidas de forma explícita.

  • Asegúrese de que todo el JavaScript código cumpla con el modo estricto.

Los flujos de trabajo de CWL deben definirse para cada contenedor utilizado. No se recomienda codificar de forma rígida la entrada de DockerPull con una URI de Amazon ECR fija.

El siguiente es un ejemplo de un flujo de trabajo escrito 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

El siguiente archivo define la copy.cwl tarea.


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

El siguiente es un ejemplo de un flujo de trabajo escrito en CWL con un requisito 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: []

Ejemplo de definición de flujo de trabajo

El siguiente ejemplo muestra la misma definición de flujo de trabajo en WDL, Nextflow y 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

Ejemplo de definición de flujo de trabajo de WDL

Los siguientes ejemplos muestran las definiciones de flujos de trabajo privados para convertir de CRAM a BAM en WDL. El BAM flujo de trabajo CRAM to define dos tareas y utiliza las herramientas del genomes-in-the-cloud contenedor, como se muestra en el ejemplo y que está disponible públicamente.

El siguiente ejemplo muestra cómo incluir el contenedor Amazon ECR como parámetro. Esto permite HealthOmics verificar los permisos de acceso a su contenedor antes de que comience la ejecución. 

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

El siguiente ejemplo muestra cómo especificar qué archivos usar en la ejecución cuando los archivos están en un bucket de 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 desea especificar archivos de un almacén de secuencias, indíquelo como se muestra en el siguiente ejemplo, utilizando el URI del almacén de secuencias.

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

A continuación, puede definir su flujo de trabajo en WDL, tal y como se muestra a continuación. 

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