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](https://www.commonwl.org/user_guide/topics/operations.html).
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.
**Topics**
+ [Konvertieren Sie die zu verwendenden CWL-Workflows HealthOmics](#workflow-cwl-convert)
+ [Deaktivieren Sie die Aufgabenwiederholung mit `omicsRetryOn5xx`](#workflow-cwl-retry-5xx)
+ [Einen Workflow-Schritt wiederholen](#workflow-cwl-loop)
+ [Führen Sie Aufgaben mit mehr Arbeitsspeicher erneut aus](#workflow-cwl-out-of-memory-retry)
+ [Beispiele](#workflow-cwl-examples)
## 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:
+ Ersetzen Sie alle Docker-Container URIs durch Amazon URIs ECR.
+ Stellen Sie sicher, dass alle Workflow-Dateien im Haupt-Workflow als Eingabe deklariert sind und dass alle Variablen explizit definiert sind.
+ Stellen Sie sicher, dass der gesamte JavaScript Code Strict-Mode-konform ist.
## 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](monitoring-runs.md#run-status-task-retries)
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` (oder`hints`, 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:
+ Workflow-Ebene
+ Schrittebene
+ Aufgabenbereich der Workflow-Definition
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.
**Anmerkung**
HealthOmics wiederholt out-of-memory Fehler bis zu dreimal oder bis die Speicherzuweisung 1536 GiB erreicht, je nachdem, welcher Grenzwert zuerst erreicht wird.
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:
+ **Standardwert:** Wenn Sie keinen Wert angeben, wird der Standardwert verwendet `2` (verdoppelt den Speicher)
+ **Gültiger Bereich:** Muss eine positive Zahl größer als sein. `1` Ungültige Werte führen zu einem 4XX-Validierungsfehler
+ **Effektiver Mindestwert:** Werte zwischen `1` und `1.5` werden automatisch erhöht, `1.5` um eine sinnvolle Speichererweiterung sicherzustellen und übermäßige Wiederholungsversuche zu verhindern
## 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: []
```