Besonderheiten der WDL-Workflow-Definition

Die folgenden Themen enthalten Einzelheiten zu den Typen und Anweisungen, die für WDL-Workflow-Definitionen in verfügbar sind. HealthOmics

Implizite Typkonvertierung in WDL Lenient

HealthOmics unterstützt die implizite Typkonvertierung in der Datei input.json und der Workflow-Definition. Um implizite Typumwandlung zu verwenden, geben Sie bei der Erstellung des Workflows für die Workflow-Engine den Wert WDL Lenient an. WDL Lenient wurde für Workflows entwickelt, die von Cromwell migriert wurden. Es unterstützt Cromwell-Richtlinien von Kunden und einige nichtkonforme Logiken.

WDL Lenient unterstützt die Typkonvertierung für die folgenden Elemente in der Liste der eingeschränkten Ausnahmen von WDL:

Um implizites Typ-Casting zu verwenden, geben Sie die Workflow-Engine als WDL_LENIENT an, wenn Sie den Workflow oder die Workflow-Version erstellen.

In der Konsole heißt der Workflow-Engine-Parameter Language. In der API heißt der Workflow-Engine-Parameter Engine. Für weitere Informationen siehe Erstellen Sie einen privaten Workflow oder Workflow-Version erstellen.

Namespace-Definition in input.json

HealthOmics unterstützt vollständig qualifizierte Variablen in input.json. Wenn Sie beispielsweise zwei Eingabevariablen mit den Namen number1 und number2 im Workflow deklarieren: SumWorkflow

workflow SumWorkflow {
  input {
    Int number1
    Int number2
  }
}   

Sie können sie als vollqualifizierte Variablen in input.json verwenden:

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

Primitive Typen in WDL

Die folgende Tabelle zeigt, wie Eingaben in WDL den entsprechenden primitiven Typen zugeordnet werden. HealthOmics bietet eingeschränkte Unterstützung für Typenzwang, daher empfehlen wir, explizite Typen festzulegen.

Komplexe Typen in WDL

Die folgende Tabelle zeigt, wie Eingaben in WDL den entsprechenden komplexen JSON-Typen zugeordnet werden. Komplexe Typen in WDL sind Datenstrukturen, die aus primitiven Typen bestehen. Datenstrukturen wie Listen werden in Arrays umgewandelt.

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

Richtlinien in WDL

HealthOmics unterstützt die folgenden Direktiven in allen WDL-Versionen, die HealthOmics sie unterstützen.

GPU-Ressourcen konfigurieren

HealthOmics unterstützt Laufzeitattribute acceleratorType und acceleratorCount mit allen unterstützten GPU-Instanzen. HealthOmics unterstützt auch Aliase mit dem Namen gpuType undgpuCount, die dieselbe Funktionalität wie ihre Accelerator-Gegenstücke haben. Wenn die WDL-Definition beide Direktiven enthält, HealthOmics verwendet die Beschleunigerwerte.

Das folgende Beispiel zeigt, wie diese Direktiven verwendet werden:

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

Konfigurieren Sie die Aufgabenwiederholung bei Servicefehlern

HealthOmics unterstützt bis zu zwei Wiederholungen für eine Aufgabe, die aufgrund von Dienstfehlern fehlgeschlagen ist (5XX-HTTP-Statuscodes). Sie können die maximale Anzahl von Wiederholungen (1 oder 2) konfigurieren und Wiederholungen aufgrund von Servicefehlern deaktivieren. Standardmäßig werden maximal zwei Wiederholungen HealthOmics versucht.

Das folgende Beispiel legt festpreemptible, dass Wiederholungsversuche bei Dienstfehlern deaktiviert werden:

{
  preemptible: 0 
}     

Weitere Hinweise zu Wiederholungsversuchen von Aufgaben finden Sie unter HealthOmics. Die Aufgabe wird erneut versucht

Konfigurieren Sie die Aufgabenwiederholung bei fehlendem Arbeitsspeicher

HealthOmics unterstützt Wiederholungsversuche für eine Aufgabe, die fehlgeschlagen ist, weil ihr nicht genügend Speicherplatz zur Verfügung stand (Container-Exitcode 137, 4XX-HTTP-Statuscode). HealthOmics verdoppelt die Speichermenge für jeden Wiederholungsversuch.

Standardmäßig versucht es bei dieser Art von Fehler HealthOmics nicht erneut. Verwenden Sie die maxRetries Direktive, um die maximale Anzahl von Wiederholungen anzugeben.

Im folgenden Beispiel wird der maxRetries Wert auf 3 gesetzt, sodass HealthOmics maximal vier Versuche unternommen werden, die Aufgabe abzuschließen (der erste Versuch plus drei Wiederholungen):

runtime {
    maxRetries: 3
}     

Konfigurieren Sie Rückgabecodes

Das ReturnCodes-Attribut bietet einen Mechanismus zur Angabe eines Rückgabecodes oder einer Reihe von Rückgabecodes, die auf eine erfolgreiche Ausführung einer Aufgabe hinweisen. Das WDL-Modul berücksichtigt die Rückgabecodes, die Sie im Runtime-Abschnitt der WDL-Definition angeben, und legt den Aufgabenstatus entsprechend fest.

runtime {
    returnCodes: 1
}     

HealthOmics unterstützt auch einen Alias namens continueOnReturnCode, der dieselben Funktionen wie ReturnCodes hat. Wenn Sie beide Attribute angeben, wird der ReturnCodes-Wert HealthOmics verwendet.

Beispiel für eine WDL-Workflow-Definition

Die folgenden Beispiele zeigen private Workflow-Definitionen für die Konvertierung von CRAM zu BAM in WDL. Der CRAM BAM To-Workflow definiert zwei Aufgaben und verwendet Tools aus dem genomes-in-the-cloud Container, der im Beispiel gezeigt wird und öffentlich verfügbar ist.

Das folgende Beispiel zeigt, wie der Amazon ECR-Container als Parameter eingebunden wird. Auf diese Weise können HealthOmics Sie die Zugriffsberechtigungen für Ihren Container überprüfen, bevor der Run gestartet wird.

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

Das folgende Beispiel zeigt, wie Sie angeben, welche Dateien in Ihrem Lauf verwendet werden sollen, wenn sich die Dateien in einem Amazon S3 S3-Bucket befinden.

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

Wenn Sie Dateien aus einem Sequenzspeicher angeben möchten, geben Sie dies wie im folgenden Beispiel gezeigt an, indem Sie den URI für den Sequenzspeicher verwenden.

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

Anschließend können Sie Ihren Workflow in WDL definieren, wie im folgenden Beispiel gezeigt.

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