"
ResourceRequirement:
coresMax: 2
ramMax: 4000 # specified in mebibytes
```
------
# Aufgabenbeschleuniger in einer Workflow-Definition HealthOmics
In der Workflow-Definition können Sie optional die GPU-Beschleuniger-Spezifikation für eine Aufgabe angeben. HealthOmics unterstützt die folgenden Beschleunigerspezifikationswerte zusammen mit den unterstützten Instanztypen:
| Beschleuniger-Spezifikation | Instanztypen von Healthomics |
| --- | --- |
| nvidia-tesla-t4 | G4 |
| nvidia-tesla-t4-a 10 g | G4 und G5 |
| nvidia-tesla-a10 g | G5 |
| nvidia-t4-a10g-l4 | G4, G5 und G6 |
| nvidia-l4-a10g | G5 und G6 |
| nvidia-l4 | G6 |
| nvidia-l40 s | G6e |
Wenn Sie einen Beschleunigertyp angeben, der mehrere Instance-Typen unterstützt, HealthOmics wählt der Instance-Typ auf der Grundlage der verfügbaren Kapazität aus. Wenn beide Instance-Typen verfügbar sind HealthOmics , wird die kostengünstigere Instanz bevorzugt. Die Ausnahme bildet der Task Accelerator nvidia-t4-a10g-l4, der der verfügbaren Instanz der neuesten Generation den Vorzug gibt.
Einzelheiten zu den Instanztypen [Instanzen für beschleunigte Datenverarbeitung](memory-and-compute-tasks.md#workflow-task-accelerated-computing-instances) finden Sie unter.
Im folgenden Beispiel gibt die Workflow-Definition `nvidia-l4` als Beschleuniger an:
------
#### [ WDL ]
```
task my_task {
runtime {
...
acceleratorCount: 1
acceleratorType: "nvidia-l4"
}
...
}
```
------
#### [ NextFlow ]
```
process my_task {
...
accelerator 1, type: "nvidia-l4"
...
}
```
------
#### [ CWL ]
```
cwlVersion: v1.2
class: CommandLineTool
requirements:
...
cwltool:CUDARequirement:
cudaDeviceCountMin: 1
cudaComputeCapability: "nvidia-l4"
cudaVersionMin: "1.0"
```
------
# 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
**Topics**
+ [Implizite Typkonvertierung in WDL Lenient](#workflow-wdl-type-conversion)
+ [Namespace-Definition in input.json](#workflow-wdl-namespace-defn)
+ [Primitive Typen in WDL](#workflow-wdl-primitive-types)
+ [Komplexe Typen in WDL](#workflow-wdl-complex-types)
+ [Richtlinien in WDL](#workflow-wdl-directives)
+ [Aufgaben-Metadaten in WDL](#workflow-wdl-task-metadata)
+ [Beispiel für eine WDL-Workflow-Definition](#wdl-example)
## 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:](https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#-limited-exceptions)
+ Float wird in Int umgewandelt, wobei der Zwang zu keinem Genauigkeitsverlust führt (z. B. 1,0 entspricht 1).
+ Von String zu Int/Float, wobei der Zwang zu keinem Genauigkeitsverlust führt.
+ Ordnen Sie [W, X] dem Array [Pair [Y, Z]] zu, falls W gegen Y und X gegen Z erzwingbar ist.
+ Ordnen Sie [Paar [W, X]] an, um [Y, Z] zuzuordnen, falls W gegen Y und X gegen Z erzwingbar ist (z. B. 1,0 entspricht 1).
Um implizites Typ-Casting zu verwenden, geben Sie die Workflow-Engine als WDL\$1LENIENT 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](create-private-workflow.md) oder [Workflow-Version erstellen](workflows-version-create.md).
## 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.
**Primitive Typen**
| WDL-Typ | JSON-Typ | Beispiel WDL | Beispiel für einen JSON-Schlüssel und -Wert | Hinweise |
| --- | --- | --- | --- | --- |
| Boolean | boolean | Boolean b | "b": true | Der Wert muss in Kleinbuchstaben geschrieben werden und darf keine Anführungszeichen enthalten. |
| Int | integer | Int i | "i": 7 | Darf nicht in Anführungszeichen gesetzt werden. |
| Float | number | Float f | "f": 42.2 | Darf nicht in Anführungszeichen stehen. |
| String | string | String s | "s": "characters" | JSON-Zeichenfolgen, die eine URI sind, müssen einer zu importierenden WDL-Datei zugeordnet werden. |
| File | string | File f | "f": "s3://amzn-s3-demo-bucket1/path/to/file" | Amazon S3 und HealthOmics Speicher URIs werden importiert, solange die für den Workflow bereitgestellte IAM-Rolle Lesezugriff auf diese Objekte hat. Andere URI-Schemas werden nicht unterstützt (wie file://https://, undftp://). Die URI muss ein Objekt angeben. Es kann kein Verzeichnis sein, was bedeutet, dass es nicht mit einem enden kann/. |
| Directory | string | Directory d | "d": "s3://bucket/path/" | Der Directory Typ ist nicht in WDL 1.0 oder 1.1 enthalten, daher müssen Sie ihn zum Header der WDL-Datei hinzufügenversion development. Die URI muss eine Amazon S3 S3-URI sein und ein Präfix haben, das mit einem '/' endet. Der gesamte Inhalt des Verzeichnisses wird rekursiv als einziger Download in den Workflow kopiert. Der Directory sollte nur Dateien enthalten, die sich auf den Workflow beziehen. |
## 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.
**Komplexe Typen**
| Typ WDL | JSON-Typ | Beispiel WDL | Beispiel für einen JSON-Schlüssel und -Wert | Hinweise |
| --- | --- | --- | --- | --- |
| Array | array | Array[Int] nums | “nums": [1, 2, 3] | Die Mitglieder des Arrays müssen dem Format des WDL-Arraytyps folgen. |
| Pair | object | Pair[String, Int] str\$1to\$1i | “str\$1to\$1i": \$1"left": "0", "right": 1\$1 | Jeder Wert des Paares muss das JSON-Format des entsprechenden WDL-Typs verwenden. |
| Map | object | Map[Int, String] int\$1to\$1string | "int\$1to\$1string": \$1 2: "hello", 1: "goodbye" \$1 | Jeder Eintrag in der Map muss das JSON-Format des entsprechenden WDL-Typs verwenden. |
| Struct | object | 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"
} | Die Namen der Strukturmitglieder müssen exakt mit den Namen der JSON-Objektschlüssel übereinstimmen. Jeder Wert muss das JSON-Format des entsprechenden WDL-Typs verwenden. |
| Object | – | – | – | Der Object WDL-Typ ist veraltet und sollte Struct in jedem Fall durch ersetzt werden. |
## 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](https://docs.aws.amazon.com/omics/latest/dev/task-accelerators.html). HealthOmics unterstützt auch Aliase mit dem Namen **gpuType** und**gpuCount**, 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 fest`preemptible`, dass Wiederholungsversuche bei Dienstfehlern deaktiviert werden:
```
{
preemptible: 0
}
```
Weitere Hinweise zu Wiederholungsversuchen von Aufgaben finden Sie unter HealthOmics. [Die Aufgabe wird erneut versucht](monitoring-runs.md#run-status-task-retries)
### 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
}
```
**Anmerkung**
Für die Wiederholung der Aufgabe bei fehlendem Arbeitsspeicher sind GNU Findutils 4.2.3\$1 erforderlich. Der Standard-Image-Container enthält dieses Paket HealthOmics . Wenn Sie in Ihrer WDL-Definition ein benutzerdefiniertes Bild angeben, stellen Sie sicher, dass das Bild GNU Findutils 4.2.3\$1 enthält.
### 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.
## Aufgaben-Metadaten in WDL
HealthOmics unterstützt die folgenden Metadatenoptionen für WDL-Aufgaben.
### Deaktivieren Sie das Caching auf Aufgabenebene mit dem Attribut volatile
Mit dem **flüchtigen** Attribut können Sie das Caching von Anrufen für bestimmte Aufgaben in Ihrem WDL-Workflow deaktivieren. Wenn eine Aufgabe als flüchtig markiert ist, wird sie immer ausgeführt und verwendet niemals zwischengespeicherte Ergebnisse, selbst wenn das Caching für die Ausführung aktiviert ist.
Fügen Sie das **flüchtige** Attribut zum **Metabereich** Ihrer Aufgabendefinition hinzu:
```
task my_volatile_task {
meta {
volatile: true
}
input {
String input_file
}
command {
echo "Processing ${input_file}" > output.txt
}
output {
File result = "output.txt"
}
}
```
## 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":".dkr.ecr..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 = ".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}"
}
}
```
# Einzelheiten der Nextflow-Workflow-Definition
HealthOmics unterstützt DSL1 Nextflow und. DSL2 Details hierzu finden Sie unter [Unterstützung der Nextflow-Version](workflows-lang-versions.md#workflows-lang-versions-nextflow).
Nextflow DSL2 basiert auf der Programmiersprache Groovy, sodass Parameter dynamisch sind und Typenzwang nach den gleichen Regeln wie Groovy möglich ist. Parameter und Werte, die von der JSON-Eingabe bereitgestellt werden, sind in der Parameters () -Map des Workflows verfügbar. `params`
**Topics**
+ [Verwenden Sie die Plug-ins NF-Schema und NF-Validation](#schema-and-validation-plugins-nextflow)
+ [Speicher angeben URIs](#storage-uris-nextflow)
+ [Nextflow-Direktiven](#workflow-nexflow-directives)
+ [Inhalte auf Workflow-Ebene exportieren](#exporting-workflow-content-nextflow)
+ [Aufgabeninhalt exportieren](#exporting-task-content-nextflow)
## Verwenden Sie die Plug-ins NF-Schema und NF-Validation
**Anmerkung**
Zusammenfassung der Unterstützung für Plugins HealthOmics :
v22.04 — keine Unterstützung für Plugins
v23.10 — unterstützt und `nf-schema` `nf-validation`
v24.10 — unterstützt `nf-schema`
v25.10 — unterstützt`nf-schema`,, und `nf-core-utils` `nf-fgbio` `nf-prov`
HealthOmics bietet die folgende Unterstützung für Nextflow-Plugins:
+ Für Nextflow v23.10 ist das Plugin nf-validation @1 HealthOmics .1.1 vorinstalliert.
+ Für Nextflow v23.10 und höher wird das Plugin nf-schema @2 .3.0 vorinstalliert. HealthOmics
+ Sie können während einer Workflow-Ausführung keine zusätzlichen Plugins abrufen. HealthOmics ignoriert alle anderen Plugin-Versionen, die Sie in der `nextflow.config` Datei angeben.
+ Für Nextflow v24 und höher `nf-schema` ist dies die neue Version des veralteten Plugins. `nf-validation` Weitere Informationen finden Sie unter [nf-schema im Nextflow-Repository](https://github.com/nextflow-io/nf-schema). GitHub
## Speicher angeben URIs
Wenn ein Amazon S3 oder HealthOmics URI verwendet wird, um eine Nextflow-Datei oder ein Nextflow-Pfadobjekt zu erstellen, stellt es das entsprechende Objekt für den Workflow zur Verfügung, sofern Lesezugriff gewährt wird. Die Verwendung von Präfixen oder Verzeichnissen ist für Amazon S3 URIs zulässig. Beispiele finden Sie unter [Amazon S3 S3-Eingabeparameterformate](workflows-run-inputs.md#s3-run-input-formats).
HealthOmics unterstützt teilweise die Verwendung von Glob Patterns in Amazon S3 URIs oder HealthOmics Storage URIs. Verwenden Sie Glob-Muster in der Workflow-Definition für die Erstellung von Or-Kanälen`path`. `file` Informationen zum erwarteten Verhalten und zu den genauen Fällen finden Sie unter[Nextflow-Behandlung von Glob-Mustern in Amazon S3 S3-Eingaben](workflows-run-inputs.md#wd-nextflow-s3-formats).
## Nextflow-Direktiven
Sie konfigurieren Nextflow-Direktiven in der Nextflow-Konfigurationsdatei oder Workflow-Definition. Die folgende Liste zeigt die Rangfolge, in der die HealthOmics Konfigurationseinstellungen angewendet werden, von der niedrigsten zur höchsten Priorität:
1. Globale Konfiguration in der Konfigurationsdatei.
1. Aufgabenbereich der Workflow-Definition.
1. Aufgabenspezifische Selektoren in der Konfigurationsdatei.
**Topics**
+ [Strategie zur Wiederholung von Aufgaben unter Verwendung von `errorStrategy`](#workflow-nextflow-errorStrategy)
+ [Versuche, Aufgaben erneut zu versuchen, verwenden `maxRetries`](#workflow-nexflow-task-retry)
+ [Deaktivieren Sie die Wiederholung von Aufgaben mit `omicsRetryOn5xx`](#workflow-nextflow-retry-5xx)
+ [Dauer der Aufgabe unter Verwendung der Direktive `time`](#time-directive-nextflow)
### Strategie zur Wiederholung von Aufgaben unter Verwendung von `errorStrategy`
Verwenden Sie die `errorStrategy` Direktive, um die Strategie für Aufgabenfehler zu definieren. Wenn eine Aufgabe mit einer Fehleranzeige (einem Exit-Status ungleich Null) zurückkehrt, wird die Aufgabe standardmäßig gestoppt und die gesamte HealthOmics Ausführung beendet. Wenn Sie `errorStrategy` auf festlegen, wird HealthOmics versucht`retry`, die fehlgeschlagene Aufgabe erneut zu versuchen. Informationen zur Erhöhung der Anzahl der Wiederholungen finden Sie unter. [Versuche, Aufgaben erneut zu versuchen, verwenden `maxRetries`](#workflow-nexflow-task-retry)
```
process {
label 'my_label'
errorStrategy 'retry'
script:
"""
your-command-here
"""
}
```
Informationen darüber, wie mit Wiederholungsversuchen HealthOmics von Aufgaben während einer Ausführung umgegangen wird, finden Sie unter. [Die Aufgabe wird erneut versucht](monitoring-runs.md#run-status-task-retries)
### Versuche, Aufgaben erneut zu versuchen, verwenden `maxRetries`
Führt standardmäßig HealthOmics keine Wiederholungsversuche für eine fehlgeschlagene Aufgabe durch, oder versucht einen erneuten Versuch, wenn Sie dies konfigurieren. `errorStrategy` Um die maximale Anzahl von Wiederholungen zu erhöhen, legen `errorStrategy` Sie die maximale Anzahl von Wiederholungen fest `retry` und konfigurieren Sie sie mithilfe der Direktive. `maxRetries`
Im folgenden Beispiel wird die maximale Anzahl von Wiederholungen in der globalen Konfiguration auf 3 festgelegt.
```
process {
errorStrategy = 'retry'
maxRetries = 3
}
```
Das folgende Beispiel zeigt, wie `maxRetries` im Aufgabenbereich der Workflow-Definition festgelegt wird.
```
process myTask {
label 'my_label'
errorStrategy 'retry'
maxRetries 3
script:
"""
your-command-here
"""
}
```
Das folgende Beispiel zeigt, wie eine aufgabenspezifische Konfiguration in der Nextflow-Konfigurationsdatei auf der Grundlage der Namens- oder Labelselektoren angegeben wird.
```
process {
withLabel: 'my_label' {
errorStrategy = 'retry'
maxRetries = 3
}
withName: 'myTask' {
errorStrategy = 'retry'
maxRetries = 3
}
}
```
### Deaktivieren Sie die Wiederholung von Aufgaben mit `omicsRetryOn5xx`
HealthOmics Unterstützt für Nextflow v23 und höher Aufgabenwiederholungen, wenn die Aufgabe aufgrund von Dienstfehlern fehlgeschlagen ist (5XX-HTTP-Statuscodes). Standardmäßig werden bis zu zwei HealthOmics Wiederholungen einer fehlgeschlagenen Aufgabe versucht.
Sie können so konfigurieren`omicsRetryOn5xx`, dass die Wiederholung von Aufgaben bei Dienstfehlern deaktiviert wird. Weitere Informationen zur Wiederholung von Aufgaben finden Sie unter HealthOmics. [Die Aufgabe wird erneut versucht](monitoring-runs.md#run-status-task-retries)
Im folgenden Beispiel wird die globale Konfiguration so konfiguriert`omicsRetryOn5xx`, dass die Aufgabenwiederholung deaktiviert wird.
```
process {
omicsRetryOn5xx = false
}
```
Das folgende Beispiel zeigt, wie die Konfiguration `omicsRetryOn5xx` im Aufgabenbereich der Workflow-Definition erfolgt.
```
process myTask {
label 'my_label'
omicsRetryOn5xx = false
script:
"""
your-command-here
"""
}
```
Das folgende Beispiel zeigt, wie eine aufgabenspezifische Konfiguration in der Nextflow-Konfigurationsdatei auf der Grundlage der Namens- oder Labelauswahl festgelegt `omicsRetryOn5xx` wird.
```
process {
withLabel: 'my_label' {
omicsRetryOn5xx = false
}
withName: 'myTask' {
omicsRetryOn5xx = false
}
}
```
### Dauer der Aufgabe unter Verwendung der Direktive `time`
HealthOmics stellt ein einstellbares Kontingent bereit (siehe[HealthOmics Servicekontingenten](service-quotas.md)), um die maximale Dauer eines Laufs anzugeben. Für Workflows mit Nextflow Version 23 und höher können Sie mithilfe der Nextflow-Direktive auch die maximale Aufgabendauer angeben. `time`
Bei der Entwicklung neuer Workflows hilft Ihnen die Festlegung der maximalen Aufgabendauer dabei, außer catch geratene Aufgaben und lang andauernde Aufgaben zu erkennen.
Weitere Informationen zur Nextflow-Zeitdirektive finden Sie unter [Zeitdirektive](https://www.nextflow.io/docs/latest/reference/process.html#process-time) in der Nextflow-Referenz.
HealthOmics bietet die folgende Unterstützung für die Nextflow-Zeitdirektive:
1. HealthOmics unterstützt eine Granularität von 1 Minute für die Zeitdirektive. Sie können einen Wert zwischen 60 Sekunden und dem Wert für die maximale Laufzeit angeben.
1. Wenn Sie einen Wert unter 60 eingeben, wird HealthOmics dieser auf 60 Sekunden aufgerundet. Bei Werten über 60 wird auf die nächste Minute HealthOmics abgerundet.
1. Wenn der Workflow Wiederholungsversuche für eine Aufgabe unterstützt, versucht er die Aufgabe HealthOmics erneut, wenn das Timeout überschritten wird.
1. Wenn bei einer Aufgabe das Timeout überschritten wird (oder bei der letzten Wiederholung), wird die Aufgabe HealthOmics abgebrochen. Dieser Vorgang kann eine Dauer von ein bis zwei Minuten haben.
1. Bei Zeitüberschreitung der Aufgabe werden die Ausführung und der Aufgabenstatus auf Fehlgeschlagen gesetzt und die anderen Aufgaben in der Ausführung abgebrochen (für Aufgaben mit dem Status „Gestartet“, „Ausstehend“ oder „Wird ausgeführt“). HealthOmics HealthOmics exportiert die Ausgaben von Aufgaben, die vor dem Timeout abgeschlossen wurden, an den von Ihnen angegebenen S3-Ausgabespeicherort.
1. Die Zeit, die eine Aufgabe im Status „Ausstehend“ verbringt, wird nicht auf die Dauer der Aufgabe angerechnet.
1. Wenn die Ausführung Teil einer Ausführungsgruppe ist und das Timeout der Ausführungsgruppe vor Ablauf des Task-Timers abläuft, gehen Ausführung und Task in den Status Fehlgeschlagen über.
Geben Sie die Timeoutdauer mit einer oder mehreren der folgenden Einheiten an:`ms`,`s`, `m``h`, oder`d`.
Das folgende Beispiel zeigt, wie die globale Konfiguration in der Nextflow-Konfigurationsdatei angegeben wird. Es legt ein globales Timeout von 1 Stunde und 30 Minuten fest.
```
process {
time = '1h30m'
}
```
Das folgende Beispiel zeigt, wie eine Zeitanweisung im Aufgabenbereich der Workflow-Definition angegeben wird. In diesem Beispiel wird ein Timeout von 3 Tagen, 5 Stunden und 4 Minuten festgelegt. Dieser Wert hat Vorrang vor dem globalen Wert in der Konfigurationsdatei, hat jedoch keinen Vorrang vor einer aufgabenspezifischen Zeitanweisung für `my_label` in der Konfigurationsdatei.
```
process myTask {
label 'my_label'
time '3d5h4m'
script:
"""
your-command-here
"""
}
```
Das folgende Beispiel zeigt, wie aufgabenspezifische Zeitdirektiven in der Nextflow-Konfigurationsdatei auf der Grundlage der Namens- oder Labelselektoren angegeben werden. In diesem Beispiel wird ein globaler Task-Timeout-Wert von 30 Minuten festgelegt. Es legt einen Wert von 2 Stunden für eine Aufgabe `myTask` und einen Wert von 3 Stunden für Aufgaben mit Bezeichnung `my_label` fest. Bei Aufgaben, die dem Selektor entsprechen, haben diese Werte Vorrang vor dem globalen Wert und dem Wert in der Workflow-Definition.
```
process {
time = '30m'
withLabel: 'my_label' {
time = '3h'
}
withName: 'myTask' {
time = '2h'
}
}
```
## Inhalte auf Workflow-Ebene exportieren
Für Nextflow v25.10 können Sie Dateien exportieren, die außerhalb einzelner Aufgaben erstellt wurden, z. B. Provenienzberichte oder Pipelines. DAGs Um diese Dateien zu exportieren, schreiben Sie sie in. `/mnt/workflow/output/` HealthOmics exportiert Dateien, die sich in diesem Verzeichnis befinden, an das `output/` Präfix im Amazon S3 S3-Ausgabespeicherort Ihres Laufs.
Das folgende Beispiel zeigt, wie Sie das `nf-prov` Plugin konfigurieren, für das ein Herkunftsbericht geschrieben werden soll`/mnt/workflow/output/`.
```
prov {
formats {
bco {
file = "/mnt/workflow/output/pipeline_info/manifest.bco.json"
}
}
}
```
Sie können diesen Pfad auch als Parameter in der JSON-Eingabe Ihres Laufs übergeben. Dieser Ansatz ist bei NF-Core-Workflows üblich, die verwenden. `params.outdir`
```
{
"outdir": "/mnt/workflow/output/"
}
```
## Aufgabeninhalt exportieren
Definieren Sie für in Nextflow geschriebene Workflows eine **PublishDir-Direktive**, um Aufgabeninhalte in Ihren Amazon S3 S3-Ausgabe-Bucket zu exportieren. Wie im folgenden Beispiel gezeigt, setzen Sie den Wert **publishDir** auf. `/mnt/workflow/pubdir` Um Dateien nach Amazon S3 zu exportieren, müssen sich die Dateien in diesem Verzeichnis befinden.
```
nextflow.enable.dsl=2
workflow {
CramToBamTask(params.ref_fasta, params.ref_fasta_index, params.ref_dict, params.input_cram, params.sample_name)
ValidateSamFile(CramToBamTask.out.outputBam)
}
process CramToBamTask {
container ".dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-cloud"
publishDir "/mnt/workflow/pubdir"
input:
path ref_fasta
path ref_fasta_index
path ref_dict
path input_cram
val sample_name
output:
path "${sample_name}.bam", emit: outputBam
path "${sample_name}.bai", emit: outputBai
script:
"""
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
"""
}
process ValidateSamFile {
container ".dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-cloud"
publishDir "/mnt/workflow/pubdir"
input:
file input_bam
output:
path "validation_report"
script:
"""
java -Xmx3G -jar /usr/gitc/picard.jar \
ValidateSamFile \
INPUT=${input_bam} \
OUTPUT=validation_report \
MODE=SUMMARY \
IS_BISULFITE_SEQUENCED=false
"""
}
```
Für Nextflow v25.10 können Sie alternativ Workflow-Ausgaben verwenden`publishDir`, um Aufgabeninhalte zu exportieren. Das folgende Beispiel zeigt, wie ein `output` Workflow-Block definiert wird, der Aufgabenergebnisse nach Amazon S3 exportiert.
```
process myTask {
input:
val data
output:
path 'result.txt'
script:
"""
echo ${data} > result.txt
"""
}
workflow {
main:
output_file = myTask('hello')
publish:
results = output_file
}
output {
results {
path '.'
}
}
```
Weitere Informationen zu Workflow-Ausgaben finden Sie unter [Workflow-Ausgaben](https://www.nextflow.io/docs/latest/workflow.html#workflow-output-def) in der Nextflow-Dokumentation.
# 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: []
```
# Beispiele für Workflow-Definitionen
Das folgende Beispiel zeigt dieselbe Workflow-Definition in WDL, Nextflow und CWL.
------
#### [ WDL ]
```
version 1.1
task my_task {
runtime { ... }
inputs {
File input_file
String name
Int threshold
}
command <<<
my_tool --name ~{name} --threshold ~{threshold} ~{input_file}
>>>
output {
File results = "results.txt"
}
}
workflow my_workflow {
inputs {
File input_file
String name
Int threshold = 50
}
call my_task {
input:
input_file = input_file,
name = name,
threshold = threshold
}
outputs {
File results = my_task.results
}
}
```
------
#### [ Nextflow ]
```
nextflow.enable.dsl = 2
params.input_file = null
params.name = null
params.threshold = 50
process my_task {
//
input:
path input_file
val name
val threshold
output:
path 'results.txt', emit: results
script:
"""
my_tool --name ${name} --threshold ${threshold} ${input_file}
"""
}
workflow MY_WORKFLOW {
my_task(
params.input_file,
params.name,
params.threshold
)
}
workflow {
MY_WORKFLOW()
}
```
------
#### [ CWL ]
```
cwlVersion: v1.2
class: Workflow
requirements:
InlineJavascriptRequirement: {}
inputs:
input_file: File
name: string
threshold: int
outputs:
result:
type: ...
outputSource: ...
steps:
my_task:
run:
class: CommandLineTool
baseCommand: my_tool
requirements:
...
inputs:
name:
type: string
inputBinding:
prefix: "--name"
threshold:
type: int
inputBinding:
prefix: "--threshold"
input_file:
type: File
inputBinding: {}
outputs:
results:
type: File
outputBinding:
glob: results.txt
```
------