Specifiche della definizione del flusso di lavoro WDL

I seguenti argomenti forniscono dettagli sui tipi e le 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 il tipo di casting implicito, specificate il motore di workflow come WDL clemente quando create il flusso di lavoro. WDL lenient è progettato per gestire 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:

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 workflow è 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 dichiarate due variabili di input denominate number1 e number2 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 vengono mappati ai tipi primitivi corrispondenti. HealthOmics fornisce un supporto limitato per la coercizione dei tipi, quindi consigliamo di impostare tipi espliciti.

Tipi complessi in WDL

La tabella seguente mostra come gli input in WDL vengono mappati 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 che supportano. HealthOmics

Configura le risorse della GPU

HealthOmics supporta gli attributi di runtime acceleratorType e acceleratorCount con tutte le istanze GPU supportate. HealthOmics supporta anche gli alias denominati gpuType andgpuCount, che hanno le stesse funzionalità delle controparti con acceleratore. 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 la ripetizione delle attività 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 nuovi tentativi.

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

{
  preemptible: 0 
}     

Per ulteriori informazioni sui nuovi tentativi di attività in HealthOmics, vedere. Ritentativi di attività

Configurare un nuovo tentativo di operazione in caso di esaurimento della memoria

HealthOmics supporta nuovi tentativi per un'operazione fallita perché la memoria è esaurita (codice di uscita del contenitore 137, codice di stato HTTP 4XX). HealthOmics raddoppia la quantità di memoria per ogni 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 è maxRetries impostato su 3, in modo che HealthOmics tenti un massimo di quattro tentativi di completare l'operazione (il tentativo iniziale più tre tentativi):

runtime {
    maxRetries: 3
}     

Configura 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 l'esecuzione corretta di un'attività. Il motore WDL rispetta i codici restituiti specificati nella sezione runtime della definizione WDL e imposta lo stato delle attività di conseguenza.

runtime {
    returnCodes: 1
}     

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

Esempio di definizione del flusso di lavoro WDL

Gli esempi seguenti mostrano le definizioni di workflow private 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 pubblicamente.

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 file da un archivio di sequenze, indicalo come mostrato nell'esempio seguente, utilizzando l'URI per l'archivio delle 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 illustrato 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}"
    }
}