Especificações da definição do fluxo de trabalho WDL

Os tópicos a seguir fornecem detalhes sobre os tipos e diretivas disponíveis para definições de fluxo de trabalho da WDL em. HealthOmics

Conversão de tipo implícita em WDL leniente

HealthOmics oferece suporte à conversão implícita de tipos no arquivo input.json e na definição do fluxo de trabalho. Para usar a conversão de tipos implícita, especifique o mecanismo de fluxo de trabalho como WDL tolerante ao criar o fluxo de trabalho. O WDL lenient inclui todos os recursos padrão da WDL, além de comportamentos adicionais de compatibilidade projetados para fluxos de trabalho migrados do Cromwell. Ele suporta as diretivas Cromwell do cliente e algumas lógicas não conformes.

O WDL lenient suporta a conversão de tipos para os seguintes itens na lista de exceções limitadas da WDL: https://github.com/openwdl/wdl/blob/wdl-1.1/SPEC.md#-limited-exceptions

Para usar a conversão de tipos implícita, especifique o mecanismo de fluxo de trabalho como WDL_LENIENT ao criar o fluxo de trabalho ou a versão do fluxo de trabalho.

No console, o parâmetro do mecanismo de fluxo de trabalho é chamado de Idioma. Na API, o parâmetro do mecanismo de fluxo de trabalho é denominado engine. Para acessar mais informações, consulte Crie um fluxo de trabalho privado ou Crie uma versão do fluxo de trabalho.

Definição de namespace em input.json

HealthOmics suporta variáveis totalmente qualificadas em input.json. Por exemplo, se você declarar duas variáveis de entrada chamadas número1 e número2 no fluxo de trabalho: SumWorkflow

workflow SumWorkflow {
  input {
    Int number1
    Int number2
  }
}   

Você pode usá-las como variáveis totalmente qualificadas em input.json:

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

Tipos primitivos na WDL

A tabela a seguir mostra como as entradas na WDL são mapeadas para os tipos primitivos correspondentes. HealthOmics fornece suporte limitado para coerção de tipos, portanto, recomendamos que você defina tipos explícitos.

Tipos complexos na WDL

A tabela a seguir mostra como as entradas no WDL são mapeadas para os tipos JSON complexos correspondentes. Os tipos complexos na WDL são estruturas de dados compostas por tipos primitivos. Estruturas de dados, como listas, serão convertidas em matrizes.

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

Diretivas na WDL

HealthOmics suporta as seguintes diretivas em todas as versões da WDL que HealthOmics suportam.

Configurar recursos de GPU

HealthOmics suporta atributos de tempo de execução acceleratorType e acceleratorCount com todas as instâncias de GPU suportadas. HealthOmics também oferece suporte a aliases chamados gpuType egpuCount, que têm a mesma funcionalidade de seus equivalentes aceleradores. Se a definição da WDL contiver as duas diretivas, HealthOmics usa os valores do acelerador.

O exemplo a seguir mostra como usar essas diretivas:

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

Configurar a nova tentativa de tarefa para erros de serviço

HealthOmics suporta até duas novas tentativas para uma tarefa que falhou devido a erros de serviço (códigos de status HTTP 5XX). Você pode configurar o número máximo de novas tentativas (1 ou 2) e optar por não receber novas tentativas devido a erros de serviço. Por padrão, HealthOmics tenta no máximo duas tentativas.

O exemplo a seguir define preemptible a opção de não receber novas tentativas por erros de serviço:

{
  preemptible: 0 
}     

Para obter mais informações sobre novas tentativas de tarefas HealthOmics, consulteTentativas de tarefas.

Configurar nova tentativa de tarefa para falta de memória

HealthOmics suporta novas tentativas para uma tarefa que falhou porque ficou sem memória (código de saída do contêiner 137, código de status HTTP 4XX). HealthOmics dobra a quantidade de memória para cada tentativa de repetição.

Por padrão, HealthOmics não tenta novamente em caso de falha. Use a maxRetries diretiva para especificar o número máximo de novas tentativas.

O exemplo a seguir é definido maxRetries como 3, de forma que HealthOmics tente no máximo quatro tentativas para concluir a tarefa (a tentativa inicial mais três tentativas):

runtime {
    maxRetries: 3
}     

Configurar códigos de devolução

O atributo returnCodes fornece um mecanismo para especificar um código de retorno, ou um conjunto de códigos de retorno, que indica uma execução bem-sucedida de uma tarefa. O mecanismo WDL respeita os códigos de retorno que você especifica na seção de tempo de execução da definição da WDL e define o status das tarefas de acordo.

runtime {
    returnCodes: 1
}     

HealthOmics também oferece suporte a um alias chamado continue OnReturnCode, que tem os mesmos recursos de returnCodes. Se você especificar os dois atributos, HealthOmics usará o valor returnCodes.

Formulários de discos WDL suportados

HealthOmics aceita todos os disks formulários padrão da WDL 1.1. O caminho de montagem e o especificador do tipo de disco (SSD,HDD) são ignorados — somente o tamanho numérico é extraído. Se várias entradas forem declaradas, os tamanhos serão somados em uma única /tmp alocação.

HealthOmics monta todo o armazenamento efêmero em. /tmp Se sua definição de fluxo de trabalho declarar várias disks entradas, os tamanhos serão somados e o total será provisionado como um único volume. /tmp Para obter mais informações sobre o atributo de tempo de disks execução da WDL, consulte a especificação da WDL 1.1.

Outros atributos de tempo de execução suportados

Configure o tempo limite no nível da tarefa com o atributo de tempo de execução OmicsTimeout

HealthOmics fornece um omicsTimeout atributo personalizado para definir a duração máxima da tarefa em seu fluxo de trabalho. Especifique a duração do tempo limite como um número inteiro (segundos) ou uma string usando uma ou mais das seguintes unidades:s, mh, ou. d Por exemplo, "40m", "1h30m" ou "1m3s".

O exemplo a seguir mostra como especificar o omicsTimeout atributo na runtime seção de uma definição de tarefa da WDL. Este exemplo define um tempo limite de 40 minutos.

    runtime {
        omicsTimeout: "40m"
    }

HealthOmics fornece o seguinte suporte para o atributo de tempo de omicsTimeout execução da WDL:

Todas as corridas têm uma duração máxima que a cota ajustável HealthOmics cotas de serviço controla. Você pode solicitar um aumento dessa cota.

Metadados de tarefas na WDL

HealthOmics oferece suporte às seguintes opções de metadados para tarefas da WDL.

Desative o cache em nível de tarefa com o atributo volatile

O atributo volatile permite que você desative o cache de chamadas para tarefas específicas em seu fluxo de trabalho da WDL. Quando uma tarefa é marcada como volátil, ela sempre será executada e nunca usará resultados em cache, mesmo quando o cache estiver habilitado para a execução.

Adicione o atributo volatile à seção meta da sua definição de tarefa:

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

Exemplo de definição de fluxo de trabalho WDL

Os exemplos a seguir mostram definições de fluxo de trabalho privado para conversão de CRAM para BAM na WDL. O BAM fluxo de trabalho CRAM to define duas tarefas e usa ferramentas do genomes-in-the-cloud contêiner, que são mostradas no exemplo e estão disponíveis publicamente.

O exemplo a seguir mostra como incluir o contêiner do Amazon ECR como parâmetro. Isso permite HealthOmics verificar as permissões de acesso ao seu contêiner antes que ele inicie a execução.

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

O exemplo a seguir mostra como especificar quais arquivos usar em sua execução, quando os arquivos estão em um bucket do 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 você quiser especificar arquivos de um armazenamento de sequência, indique isso conforme mostrado no exemplo a seguir, usando o URI para o armazenamento de sequências.

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

Você pode então definir seu fluxo de trabalho na WDL, conforme mostrado no exemplo a seguir.

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