Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Besonderheiten der CWL-Workflow-Definition

Workflows, die in Common Workflow Language (CWL) geschrieben wurden, bieten ähnliche Funktionen wie Workflows, die in WDL und Nextflow geschrieben wurden. Sie können Amazon S3 oder HealthOmics Storage URIs als Eingabeparameter verwenden.

Wenn Sie die Eingabe in einer SecondaryFile in einem Unter-Workflow definieren, fügen Sie dieselbe Definition im Haupt-Workflow hinzu.

HealthOmics Workflows unterstützen keine Betriebsprozesse. Weitere Informationen zu Betriebsprozessen in CWL-Workflows finden Sie in der CWL-Dokumentation.

Es hat sich bewährt, für jeden Container, den Sie verwenden, einen separaten CWL-Workflow zu definieren. Wir empfehlen, den DockerPull-Eintrag nicht mit einer festen Amazon ECR-URI fest zu codieren.

Konvertieren Sie die zu verwendenden CWL-Workflows HealthOmics

Um eine bestehende CWL-Workflow-Definition zur Verwendung zu konvertieren HealthOmics, nehmen Sie die folgenden Änderungen vor:

Deaktivieren Sie die Aufgabenwiederholung mit omicsRetryOn5xx

HealthOmics unterstützt Aufgabenwiederholungen, wenn die Aufgabe aufgrund von Dienstfehlern fehlgeschlagen ist (5XX-HTTP-Statuscodes). Standardmäßig werden bis zu zwei Wiederholungen einer HealthOmics fehlgeschlagenen Aufgabe versucht. Weitere Hinweise zur Wiederholung von Aufgaben finden Sie unter HealthOmics. Die Aufgabe wird erneut versucht

Um die Wiederholung von Aufgaben bei Servicefehlern zu deaktivieren, konfigurieren Sie die omicsRetryOn5xx Anweisung in der Workflow-Definition. Sie können diese Direktive unter Anforderungen oder Hinweisen definieren. Wir empfehlen, die Direktive als Hinweis für die Portabilität hinzuzufügen.

requirements:
  ResourceRequirement:
    omicsRetryOn5xx: false

hints:
  ResourceRequirement:
    omicsRetryOn5xx: false     

Anforderungen haben Vorrang vor Hinweisen. Wenn eine Aufgabenimplementierung einen Ressourcenbedarf in Hinweisen enthält, der auch durch Anforderungen in einem umschließenden Workflow bereitgestellt wird, haben die einschließenden Anforderungen Vorrang.

Wenn dieselbe Aufgabenanforderung auf verschiedenen Ebenen des Workflows vorkommt, wird der spezifischste Eintrag von HealthOmics verwendet requirements (oderhints, falls es keine Einträge in gibt). requirements Die folgende Liste zeigt die Rangfolge, in der die HealthOmics Konfigurationseinstellungen angewendet werden, von der niedrigsten zur höchsten Priorität:

Das folgende Beispiel zeigt, wie die omicsRetryOn5xx Direktive auf verschiedenen Ebenen des Workflows konfiguriert wird. In diesem Beispiel hat die Anforderung auf Workflow-Ebene Vorrang vor den Hinweisen auf Workflow-Ebene. Die Anforderungskonfigurationen auf Aufgaben- und Schrittebene haben Vorrang vor den Hinweiskonfigurationen.

class: Workflow
# Workflow-level requirement and hint
requirements:
  ResourceRequirement:
    omicsRetryOn5xx: false

hints:
  ResourceRequirement:
    omicsRetryOn5xx: false  # The value in requirements overrides this value 

steps:
  task_step:
    # Step-level requirement
    requirements:
      ResourceRequirement:
        omicsRetryOn5xx: false
    # Step-level hint
    hints:
      ResourceRequirement:
        omicsRetryOn5xx: false
    run:
      class: CommandLineTool
      # Task-level requirement
      requirements:
        ResourceRequirement:
          omicsRetryOn5xx: false
      # Task-level hint
      hints:
        ResourceRequirement:
          omicsRetryOn5xx: false      
    

Einen Workflow-Schritt wiederholen

HealthOmics unterstützt die Schleife eines Workflow-Schritts. Sie können Schleifen verwenden, um Workflow-Schritte wiederholt auszuführen, bis eine bestimmte Bedingung erfüllt ist. Dies ist nützlich für iterative Prozesse, bei denen Sie eine Aufgabe mehrmals wiederholen müssen oder bis ein bestimmtes Ergebnis erreicht ist.

Hinweis: Für die Loop-Funktionalität ist CWL Version 1.2 oder höher erforderlich. Workflows, die CWL-Versionen vor 1.2 verwenden, unterstützen keine Loop-Operationen.

Um Loops in Ihrem CWL-Workflow zu verwenden, definieren Sie eine Loop-Anforderung. Das folgende Beispiel zeigt die Konfiguration der Loop-Anforderungen:

requirements:
  - class: "http://commonwl.org/cwltool#Loop"
    loopWhen: $(inputs.counter < inputs.max)
    loop:
      counter:
        loopSource: result
        valueFrom: $(self)
    outputMethod: last

Das loopWhen Feld steuert, wann die Schleife endet. In diesem Beispiel wird die Schleife fortgesetzt, solange der Zähler unter dem Maximalwert liegt. Das loop Feld definiert, wie Eingabeparameter zwischen den Iterationen aktualisiert werden. Das loopSource gibt an, welche Ausgabe der vorherigen Iteration in die nächste Iteration einfließen wird. Das outputMethod Feld, das auf gesetzt ist, last gibt nur die Ausgabe der letzten Iteration zurück.

Führen Sie Aufgaben mit mehr Arbeitsspeicher erneut aus

HealthOmics unterstützt die automatische Wiederholung fehlgeschlagener out-of-memory Aufgaben. Wenn eine Aufgabe mit dem Code 137 (out-of-memory) beendet HealthOmics wird, wird eine neue Aufgabe mit erhöhter Speicherzuweisung auf der Grundlage des angegebenen Multiplikators erstellt.

Das folgende Beispiel zeigt, wie Wiederholungen konfiguriert werden: out-of-memory

hints:
  ResourceRequirement:
    ramMin: 4096
  http://arvados.org/cwl#OutOfMemoryRetry:
    memoryRetryMultiplier: 2.5

Wenn eine Aufgabe aufgrund von fehlschlägt out-of-memory, HealthOmics berechnet die Speicherzuweisung beim erneuten Versuch anhand der Formel:. previous_run_memory × memoryRetryMultiplier Wenn im obigen Beispiel die Aufgabe mit 4096 MB Arbeitsspeicher fehlschlägt, verwendet der Wiederholungsversuch 4096 × 2,5 = 10.240 MB Arbeitsspeicher.

Der memoryRetryMultiplier Parameter steuert, wie viel zusätzlicher Speicher für Wiederholungsversuche reserviert werden soll:

Beispiele

Im Folgenden finden Sie ein Beispiel für einen in CWL geschriebenen Workflow.

cwlVersion: v1.2
class: Workflow

inputs:
in_file:
type: File
secondaryFiles: [.fai]

out_filename: string
docker_image: string


outputs:
copied_file:
type: File
outputSource: copy_step/copied_file

steps:
copy_step:
in:
  in_file: in_file
  out_filename: out_filename
  docker_image: docker_image
out: [copied_file]
run: copy.cwl            
    

Die folgende Datei definiert die copy.cwl Aufgabe.

cwlVersion: v1.2
class: CommandLineTool
baseCommand: cp

inputs:
in_file:
type: File
secondaryFiles: [.fai]
inputBinding:
  position: 1

out_filename:
type: string
inputBinding:
  position: 2
docker_image:
type: string

outputs:
copied_file:
type: File
outputBinding:
    glob: $(inputs.out_filename)

requirements:
InlineJavascriptRequirement: {}
DockerRequirement:
dockerPull: "$(inputs.docker_image)"      

Im Folgenden finden Sie ein Beispiel für einen in CWL geschriebenen Workflow mit einer GPU-Anforderung.

cwlVersion: v1.2
class: CommandLineTool
baseCommand: ["/bin/bash", "docm_haplotypeCaller.sh"]
$namespaces:
cwltool: http://commonwl.org/cwltool#
requirements:
cwltool:CUDARequirement:
cudaDeviceCountMin: 1
cudaComputeCapability: "nvidia-tesla-t4" 
cudaVersionMin: "1.0"
InlineJavascriptRequirement: {}
InitialWorkDirRequirement:
listing:
- entryname: 'docm_haplotypeCaller.sh'
  entry: |
          nvidia-smi --query-gpu=gpu_name,gpu_bus_id,vbios_version --format=csv   

inputs: []
outputs: []