Características específicas de la definición del flujo de trabajo de W

En los siguientes temas se proporciona información detallada 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 usar la conversión de tipos implícita, especifique que el motor de flujo de trabajo sea compatible con WDL al crear el flujo de trabajo. WDL lenient incluye todas las funciones estándar de la WDL, además de comportamientos de compatibilidad adicionales diseñados para 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: https://github.com/openwdl/wdl/blob/wdl-1.1/SPEC.md#-limited-exceptions

Para usar 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 declaras 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 WDL se asignan a los tipos primitivos coincidentes. HealthOmics ofrece un soporte limitado para 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 WDL se asignan a los tipos JSON complejos coincidentes. 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.

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 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 usar estas directivas:

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

Configure el reintento de tareas para detectar 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 puede excluirse de los reintentos por errores de servicio. De forma predeterminada, HealthOmics intenta un máximo de dos reintentos.

En el siguiente ejemplo, se establece preemptible la opción de inhabilitar 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 casos de falta de memoria

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 por cada intento de reintento.

De forma predeterminada, HealthOmics no vuelve a intentarlo en caso de error de este tipo. Usa la maxRetries directiva para especificar el número máximo de reintentos.

En 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 devolución, o un conjunto de códigos de devolución, 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 continue OnReturnCode, que tiene las mismas funciones que ReturnCodes. Si especificas ambos atributos, HealthOmics usa el valor ReturnCodes.

Formularios de discos WDL compatibles

HealthOmics acepta todos los formularios WDL 1.1 disks estándar. La ruta de montaje y el especificador de tipo de disco (SSD,HDD) se ignoran; solo se extrae el tamaño numérico. Si se declaran varias entradas, los tamaños se suman en una sola asignación. /tmp

HealthOmics monta todo el almacenamiento efímero en. /tmp Si su definición de flujo de trabajo declara varias disks entradas, los tamaños se suman y el total se aprovisiona como un único volumen. /tmp Para obtener más información sobre el atributo de tiempo de disks ejecución de la WDL, consulte la especificación de la WDL 1.1.

Otros atributos de tiempo de ejecución compatibles

Configure el tiempo de espera a nivel de tarea con el atributo de tiempo de ejecución OmicsTimeout

HealthOmics proporciona un omicsTimeout atributo personalizado para establecer la duración máxima de las tareas en su flujo de trabajo. Especifique la duración del tiempo de espera como un entero (segundos) o como una cadena con una o más de las siguientes unidades:s, mh, od. Por ejemplo, "40m", "1h30m" o "1m3s".

El siguiente ejemplo muestra cómo especificar el omicsTimeout atributo en la runtime sección de la definición de una tarea de WDL. En este ejemplo se establece un tiempo de espera de 40 minutos.

    runtime {
        omicsTimeout: "40m"
    }

HealthOmics proporciona la siguiente compatibilidad con el atributo de tiempo de omicsTimeout ejecución de la WDL:

Todas las ejecuciones tienen una duración máxima que la que HealthOmics cuotas de servicio controla la cuota ajustable. Puedes solicitar un aumento de esta cuota.

Metadatos de tareas en WDL

HealthOmics admite las siguientes opciones de metadatos para las tareas de la WDL.

Deshabilite el almacenamiento en caché a nivel de tarea con el atributo volatile

El atributo volatile le permite deshabilitar el almacenamiento en caché de llamadas para tareas específicas de su flujo de trabajo de WDL. Cuando una tarea se marca como volátil, siempre se ejecutará y nunca utilizará los resultados almacenados en caché, incluso si el almacenamiento en caché está habilitado para la ejecución.

Añade el atributo volatile a la sección meta de la definición de tu tarea:

task my_volatile_task {
    meta {
        volatile: true
    }
    
    input {
        String input_file
    }
    
    command {
        echo "Processing ${input_file}" > output.txt
    }
    
    output {
        File result = "output.txt"
    }
}

Ejemplo de definición de flujo de trabajo de WDL

Los siguientes ejemplos muestran definiciones de flujos de trabajo privados para convertir de CRAM a BAM en WDL. El CRAM BAM flujo de trabajo de destino define dos tareas y utiliza las herramientas del genomes-in-the-cloud contenedor, que se muestra en el ejemplo y 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 a ejecutarse.

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