Especificaciones de la definición del flujo de trabajo de WDL

En los siguientes temas se proporcionan detalles sobre los tipos y directivas disponibles para las definiciones de flujos de trabajo de la WDL en. HealthOmics

Conversión de tipos implícita en WDL lenient

HealthOmics admite la conversión de tipos implícita en el archivo input.json y en la definición del flujo de trabajo. Para utilizar la conversión de tipos implícita, especifique el motor de flujo de trabajo como compatible con la WDL al crear el flujo de trabajo. WDL lenient está diseñado para gestionar los flujos de trabajo migrados desde Cromwell. Es compatible con las directivas de Cromwell de los clientes y con algunas lógicas no conformes.

WDL lenient admite la conversión de tipos para los siguientes elementos de la lista de excepciones limitadas de WDL:

Para utilizar la conversión de tipos implícita, especifique el motor de flujo de trabajo como WDL_LENIENT al crear el flujo de trabajo o la versión del flujo de trabajo.

En la consola, el parámetro del motor de flujo de trabajo se denomina Idioma. En la API, el parámetro del motor de flujo de trabajo se denomina motor. Para obtener más información, consulte Crear un flujo de trabajo privado o Crear una versión de flujo de trabajo.

Definición del espacio de nombres en input.json

HealthOmics admite variables totalmente calificadas en input.json. Por ejemplo, si declara dos variables de entrada denominadas número1 y número2 en el flujo de trabajo: SumWorkflow

workflow SumWorkflow {
  input {
    Int number1
    Int number2
  }
}   

Puedes usarlas como variables totalmente calificadas en input.json:

{
    "SumWorkflow.number1": 15,
    "SumWorkflow.number2": 27
}   

Tipos primitivos en WDL

La siguiente tabla muestra cómo las entradas de la WDL se asignan a los tipos primitivos coincidentes. HealthOmics proporciona una compatibilidad limitada con la coerción de tipos, por lo que se recomienda establecer tipos explícitos.

Tipos complejos en WDL

La siguiente tabla muestra cómo las entradas de la WDL se asignan a los tipos JSON complejos coincidentes. Los tipos complejos de WDL son estructuras de datos compuestas por tipos primitivos. Las estructuras de datos, como las listas, se convertirán en matrices.

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

Directivas de la WDL

HealthOmics admite las siguientes directivas en todas las versiones de la WDL compatibles HealthOmics .

Configure los recursos de la GPU

HealthOmics admite los atributos de tiempo de ejecución acceleratorType y acceleratorCount con todas las instancias de GPU compatibles. HealthOmics también admite los alias denominados gpuType ygpuCount, que tienen la misma funcionalidad que sus homólogos aceleradores. Si la definición de WDL contiene ambas directivas, HealthOmics utiliza los valores del acelerador.

El siguiente ejemplo muestra cómo utilizar estas directivas:

runtime {
    gpuCount: 2
    gpuType: "nvidia-tesla-t4"
} 

Configure el reintento de tareas para los errores de servicio

HealthOmics admite hasta dos reintentos para una tarea que haya fallado debido a errores de servicio (5XX códigos de estado HTTP). Puede configurar el número máximo de reintentos (1 o 2) y optar por no volver a intentarlo en caso de errores de servicio. De forma predeterminada, HealthOmics intenta un máximo de dos reintentos.

En el siguiente ejemplo, se establece preemptible la exclusión de los reintentos en caso de errores de servicio:

{
  preemptible: 0 
}     

Para obtener más información sobre los reintentos de tareas HealthOmics, consulte. La tarea se reintenta

Configure el reintento de tareas para que no haya memoria suficiente

HealthOmics admite los reintentos de una tarea que ha fallado porque se ha quedado sin memoria (código de salida del contenedor 137, código de estado HTTP 4XX). HealthOmics duplica la cantidad de memoria para cada reintento.

De forma predeterminada, HealthOmics no lo vuelve a intentar en este tipo de errores. Utilice la maxRetries directiva para especificar el número máximo de reintentos.

El ejemplo siguiente se establece maxRetries en 3, de modo que se HealthOmics intenta completar la tarea un máximo de cuatro intentos (el intento inicial más tres reintentos):

runtime {
    maxRetries: 3
}     

Configure los códigos de retorno

El atributo returnCodes proporciona un mecanismo para especificar un código de retorno, o un conjunto de códigos de retorno, que indica que una tarea se ha ejecutado correctamente. El motor WDL respeta los códigos de retorno que se especifican en la sección de tiempo de ejecución de la definición de la WDL y establece el estado de las tareas en consecuencia.

runtime {
    returnCodes: 1
}     

HealthOmics también admite un alias denominado continueOnReturnCode, que tiene las mismas funciones que ReturnCodes. Si especifica ambos atributos, HealthOmics utiliza el valor ReturnCodes.

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

En el siguiente ejemplo, se muestra cómo especificar los archivos que se van a utilizar en la ejecución cuando los archivos se encuentran 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, como se muestra en el siguiente ejemplo.

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