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

In Common Workflow Language (CWL) geschriebene Workflows bieten ähnliche Funktionen wie in WDL und Nextflow geschriebene Workflows. Sie können Amazon S3 verwenden oder HealthOmics Speicher-URIs als Eingabeparameter.

Wenn Sie die Eingabe in einem SecondaryFile in einem Unterworkflow 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.

Weitere Informationen zur Validierung einer CWL-Definition vor der Erstellung des Workflows finden Sie unter Workflow-Definitionen lokal validieren.

CWL-Workflows zur Verwendung konvertieren HealthOmics

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

Deaktivieren Sie die Wiederholung von Aufgaben mit ComicsRetryOn5xx

HealthOmics unterstützt Aufgabenwiederholungen, wenn die Aufgabe aufgrund von Dienstfehlern fehlgeschlagen ist (5XX HTTP-Statuscodes). In der Standardeinstellung HealthOmics versucht bis zu zwei Wiederholungen einer fehlgeschlagenen Aufgabe. Weitere Informationen zur Aufgabenwiederholung finden Sie unter HealthOmics, siehe Die Aufgabe wird erneut versucht.

Um die Wiederholung von Aufgaben aufgrund von Servicefehlern abzubestellen, konfigurieren Sie das omicsRetryOn5xx Direktive in der Workflow-Definition. Sie können diese Direktive unter Anforderungen oder Hinweise definieren. Wir empfehlen, die Richtlinie als Hinweis für die Portabilität hinzuzufügen.

requirements:
  ResourceRequirement:
    omicsRetryOn5xx: false

hints:
  ResourceRequirement:
    omicsRetryOn5xx: false     

Die Anforderungen haben Vorrang vor Hinweisen. Wenn eine Aufgabenimplementierung in Hinweisen eine Ressourcenanforderung vorsieht, die auch durch Anforderungen in einem umschließenden Workflow bereitgestellt wird, haben die einschließenden Anforderungen Vorrang.

Wenn dieselbe Aufgabenanforderung auf verschiedenen Ebenen des Workflows auftaucht, HealthOmics verwendet den spezifischsten Eintrag von requirements (oder hints, wenn es keine Einträge in requirements). Die folgende Liste zeigt die Rangfolge, die HealthOmics verwendet, um Konfigurationseinstellungen von der niedrigsten zur höchsten Priorität anzuwenden:

Das folgende Beispiel zeigt, wie das konfiguriert wird omicsRetryOn5xx Direktive auf verschiedenen Ebenen des Workflows. In diesem Beispiel überschreibt die Anforderung auf Workflow-Ebene die Hinweise 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 das Abspielen eines Workflow-Schritts in einer Schleife. 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 Schleifen 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

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

Versuchen Sie Aufgaben mit erhöhtem Arbeitsspeicher erneut

HealthOmics unterstützt die automatische Wiederholung von Aufgabenfehlern, die nicht über genügend Arbeitsspeicher verfügen. Wenn eine Aufgabe mit dem Code 137 (nicht genügend Arbeitsspeicher) beendet wird, HealthOmics erstellt eine neue Aufgabe mit erhöhter Speicherzuweisung auf der Grundlage des angegebenen Multiplikators.

Das folgende Beispiel zeigt, wie Wiederholungsversuche bei unzureichendem Arbeitsspeicher konfiguriert werden:

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

Wenn eine Aufgabe aufgrund von zu wenig Arbeitsspeicher fehlschlägt, HealthOmics berechnet die Speicherzuweisung für Wiederholungsversuche anhand der folgenden Formel: previous_run_memory × memoryRetryMultiplier. Wenn im obigen Beispiel die Aufgabe mit 4096 MB Arbeitsspeicher fehlschlägt, verbraucht der Wiederholungsversuch 4096 × 2,5 = 10.240 MB Speicher.

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

Beispiele

Das Folgende ist 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 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)"      

Das Folgende ist 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: []