Specifiche di definizione del flusso di lavoro WDL

I seguenti argomenti forniscono dettagli sui tipi e sulle direttive disponibili per le definizioni dei flussi di lavoro WDL in. HealthOmics

Conversione implicita dei tipi in WDL lenient

HealthOmics supporta la conversione implicita dei tipi nel file input.json e nella definizione del flusso di lavoro. Per utilizzare la conversione implicita dei tipi, specificate il motore del flusso di lavoro come WDL lenient al momento della creazione del flusso di lavoro. WDL lenient include tutte le funzionalità WDL standard oltre a comportamenti di compatibilità aggiuntivi progettati per i flussi di lavoro migrati da Cromwell. Supporta le direttive Cromwell dei clienti e alcune logiche non conformi.

WDL lenient supporta la conversione dei tipi per i seguenti elementi nell'elenco delle eccezioni limitate di WDL: https://github.com/openwdl/wdl/blob/wdl-1.1/SPEC.md#-limited-exceptions

Per utilizzare la trasmissione implicita dei tipi, specificate il motore del flusso di lavoro come WDL_LENIENT quando create il flusso di lavoro o la versione del flusso di lavoro.

Nella console, il parametro del motore di workflow è denominato Language. Nell'API, il parametro del motore di flusso di lavoro è denominato engine. Per ulteriori informazioni, consulta Creare un flusso di lavoro privato o Creare una versione del flusso di lavoro.

Definizione dello spazio dei nomi in input.json

HealthOmics supporta variabili completamente qualificate in input.json. Ad esempio, se dichiari due variabili di input denominate numero1 e numero2 nel flusso di lavoro: SumWorkflow

workflow SumWorkflow {
  input {
    Int number1
    Int number2
  }
}   

Puoi usarle come variabili complete in input.json:

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

Tipi primitivi in WDL

La tabella seguente mostra come gli input in WDL corrispondono ai tipi primitivi corrispondenti. HealthOmics fornisce un supporto limitato per la coercizione dei tipi, pertanto consigliamo di impostare tipi espliciti.

Tipi complessi in WDL

La tabella seguente mostra come gli input in WDL corrispondono ai tipi JSON complessi corrispondenti. I tipi complessi in WDL sono strutture di dati composte da tipi primitivi. Le strutture di dati come gli elenchi verranno convertite in matrici.

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

Direttive in WDL

HealthOmics supporta le seguenti direttive in tutte le versioni WDL supportate. HealthOmics

Configura le risorse GPU

HealthOmics supporta gli attributi di runtime acceleratorType e acceleratorCount con tutte le istanze GPU supportate. HealthOmics supporta anche alias denominati gpuType egpuCount, che hanno le stesse funzionalità delle loro controparti acceleratrici. Se la definizione WDL contiene entrambe le direttive, HealthOmics utilizza i valori dell'acceleratore.

L'esempio seguente mostra come utilizzare queste direttive:

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

Configurare il nuovo tentativo dell'operazione per gli errori di servizio

HealthOmics supporta fino a due tentativi per un'operazione non riuscita a causa di errori di servizio (codici di stato HTTP 5XX). È possibile configurare il numero massimo di tentativi (1 o 2) e disattivare i tentativi per errori di servizio. Per impostazione predefinita, HealthOmics tenta un massimo di due tentativi.

L'esempio seguente imposta preemptible la disattivazione dei tentativi per errori di servizio:

{
  preemptible: 0 
}     

Per ulteriori informazioni sui tentativi di riavvio delle attività HealthOmics, vedere. Ritentativi di attività

Configurare il ritentativo dell'operazione in caso di memoria esaurita

HealthOmics supporta i tentativi per un'operazione non riuscita perché esaurita la memoria (codice di uscita del contenitore 137, codice di stato HTTP 4XX). HealthOmics raddoppia la quantità di memoria per ogni tentativo di nuovo tentativo.

Per impostazione predefinita, HealthOmics non riprova per questo tipo di errore. Utilizzate la maxRetries direttiva per specificare il numero massimo di tentativi.

L'esempio seguente viene impostato maxRetries su 3, in modo da HealthOmics tentare un massimo di quattro tentativi per completare l'attività (il tentativo iniziale più tre tentativi):

runtime {
    maxRetries: 3
}     

Configurate i codici di restituzione

L'attributo ReturnCodes fornisce un meccanismo per specificare un codice di ritorno, o un set di codici di ritorno, che indica la corretta esecuzione di un'attività. Il motore WDL rispetta i codici di ritorno specificati nella sezione runtime della definizione WDL e imposta lo stato delle attività di conseguenza.

runtime {
    returnCodes: 1
}     

HealthOmics supporta anche un alias denominato continue OnReturnCode, che ha le stesse funzionalità di ReturnCodes. Se si specificano entrambi gli attributi, viene HealthOmics utilizzato il valore ReturnCodes.

Dischi WDL supportati, moduli

HealthOmics accetta tutti i moduli WDL 1.1 standard. disks Il percorso di montaggio e l'identificatore del tipo di disco (SSD,HDD) vengono ignorati: viene estratta solo la dimensione numerica. Se vengono dichiarate più voci, le dimensioni vengono sommate in un'unica allocazione. /tmp

HealthOmics monta tutti gli archivi effimeri su. /tmp Se la definizione del flusso di lavoro dichiara più disks voci, le dimensioni vengono sommate e il totale viene fornito come un unico volume. /tmp Per ulteriori informazioni sull'attributo disks runtime WDL, consultate la specifica WDL 1.1. https://github.com/openwdl/wdl/blob/wdl-1.1/SPEC.md#disks

Altri attributi di runtime supportati

Configurare il timeout a livello di attività con l'attributo di runtime OMICsTimeout

HealthOmics fornisce un omicsTimeout attributo personalizzato per impostare una durata massima dell'attività nel flusso di lavoro. Specifica la durata del timeout come numero intero (secondi) o stringa utilizzando una o più delle seguenti unità:s, mh, o. d Ad esempio, "40m", "1h30m" o "1m3s".

L'esempio seguente mostra come specificare l'omicsTimeoutattributo nella runtime sezione di una definizione di attività WDL. Questo esempio imposta un timeout di 40 minuti.

    runtime {
        omicsTimeout: "40m"
    }

HealthOmics fornisce il seguente supporto per l'attributo omicsTimeout runtime WDL:

Tutte le esecuzioni hanno una durata massima rispetto alla quota regolabile nei HealthOmics quote di servizio controlli. Puoi richiedere un aumento di questa quota.

Metadati delle attività in WDL

HealthOmics supporta le seguenti opzioni di metadati per le attività WDL.

Disabilita la memorizzazione nella cache a livello di task con l'attributo volatile

L'attributo volatile consente di disattivare la memorizzazione nella cache delle chiamate per attività specifiche nel flusso di lavoro WDL. Quando un'operazione è contrassegnata come volatile, verrà sempre eseguita e non utilizzerà mai i risultati memorizzati nella cache, anche quando la memorizzazione nella cache è abilitata per l'esecuzione.

Aggiungi l'attributo volatile alla metasezione della definizione dell'attività:

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

Esempio di definizione del flusso di lavoro WDL

Gli esempi seguenti mostrano le definizioni dei flussi di lavoro privati per la conversione da CRAM a BAM in WDL. Il BAM flusso di lavoro CRAM to definisce due attività e utilizza gli strumenti del genomes-in-the-cloud contenitore, illustrato nell'esempio e disponibile al pubblico.

L'esempio seguente mostra come includere il contenitore Amazon ECR come parametro. Ciò consente di HealthOmics verificare le autorizzazioni di accesso al contenitore prima che inizi l'esecuzione.

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

L'esempio seguente mostra come specificare quali file utilizzare nell'esecuzione, quando i file si trovano in un bucket 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 desideri specificare i file da un archivio di sequenze, indicalo come mostrato nell'esempio seguente, utilizzando l'URI per l'archivio di sequenze.

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

È quindi possibile definire il flusso di lavoro in WDL come mostrato nell'esempio seguente.

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