"
ResourceRequirement:
coresMax: 2
ramMax: 4000 # specified in mebibytes
```
------
# Acceleratori di attività in una definizione di workflow HealthOmics
Nella definizione del flusso di lavoro, puoi facoltativamente specificare le specifiche dell'acceleratore GPU per un'attività. HealthOmics supporta i seguenti valori accelerator-spec, oltre ai tipi di istanza supportati:
| Specifiche dell'acceleratore | Tipi di istanze Healthomics |
| --- | --- |
| nvidia-tesla-t4 | G4 |
| nvidia-tesla-t4 a 10 g | G4 e G5 |
| nvidia-tesla-a10 g | G5 |
| nvidia-t4-a10g-l4 | G4, G5 e G6 |
| nvidia-l4-a10g | G5 e G6 |
| nvidia-l4 | G6 |
| nvidia-l40s | G6e |
Se si specifica un tipo di acceleratore che supporta più tipi di istanza, HealthOmics seleziona il tipo di istanza in base alla capacità disponibile. Se entrambi i tipi di istanza sono disponibili, HealthOmics dà la preferenza all'istanza a basso costo. L'eccezione è rappresentata dal task accelerator nvidia-t4-a10g-l4 che dà la preferenza all'istanza di ultima generazione disponibile.
Per i dettagli sui tipi di istanze[Istanze di elaborazione accelerata](memory-and-compute-tasks.md#workflow-task-accelerated-computing-instances), vedere.
Nell'esempio seguente, la definizione del flusso di lavoro specifica `nvidia-l4` come acceleratore:
------
#### [ 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"
```
------
# Specifiche della definizione del flusso di lavoro WDL
I seguenti argomenti forniscono dettagli sui tipi e le direttive disponibili per le definizioni dei flussi di lavoro WDL in. HealthOmics
**Topics**
+ [Conversione implicita dei tipi in WDL lenient](#workflow-wdl-type-conversion)
+ [Definizione dello spazio dei nomi in input.json](#workflow-wdl-namespace-defn)
+ [Tipi primitivi in WDL](#workflow-wdl-primitive-types)
+ [Tipi complessi in WDL](#workflow-wdl-complex-types)
+ [Direttive in WDL](#workflow-wdl-directives)
+ [Metadati delle attività in WDL](#workflow-wdl-task-metadata)
+ [Esempio di definizione del flusso di lavoro WDL](#wdl-example)
## Conversione implicita dei tipi in WDL lenient
HealthOmics supporta la conversione implicita dei tipi nel file input.json e nella definizione del flusso di lavoro. Per utilizzare il tipo di casting implicito, specificate il motore di workflow come WDL clemente quando create il flusso di lavoro. WDL lenient è progettato per gestire i flussi di lavoro migrati da Cromwell. Supporta le direttive Cromwell dei clienti e alcune logiche non conformi.
[WDL lenient supporta la conversione dei tipi per i seguenti elementi nell'elenco delle eccezioni limitate di WDL:](https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#-limited-exceptions)
+ Float to Int, dove la coercizione non comporta alcuna perdita di precisione (ad esempio 1,0 mappato a 1).
+ String to Int/Float, dove la coercizione non comporta alcuna perdita di precisione.
+ Mappa [W, X] su Array [Pair [Y, Z]], nel caso in cui W sia coercibile con Y e X sia coercibile con Z.
+ Array [Pair [W, X] to Map [Y, Z], nel caso in cui W sia coercibile con Y e X sia coercibile con Z (ad esempio 1,0 mappato a 1).
Per utilizzare il type casting implicito, specificate il motore di workflow come WDL\$1LENIENT quando create il workflow o la versione del workflow.
**Nella console, il parametro del motore di workflow è denominato Language.** Nell'API, il parametro del motore di workflow è denominato **engine**. Per ulteriori informazioni, consulta [Creare un flusso di lavoro privato](create-private-workflow.md) o [Creare una versione del flusso di lavoro](workflows-version-create.md).
## Definizione dello spazio dei nomi in input.json
HealthOmics supporta variabili completamente qualificate in input.json. Ad esempio, se dichiarate due variabili di input denominate number1 e number2 nel flusso di lavoro: **SumWorkflow**
```
workflow SumWorkflow {
input {
Int number1
Int number2
}
}
```
Puoi usarle come variabili complete in input.json:
```
{
"SumWorkflow.number1": 15,
"SumWorkflow.number2": 27
}
```
## Tipi primitivi in WDL
La tabella seguente mostra come gli input in WDL vengono mappati ai tipi primitivi corrispondenti. HealthOmics fornisce un supporto limitato per la coercizione dei tipi, quindi consigliamo di impostare tipi espliciti.
**tipi primitivi**
| Tipo WDL | Tipo JSON | Esempio WDL | Esempio di chiave e valore JSON | Note |
| --- | --- | --- | --- | --- |
| Boolean | boolean | Boolean b | "b": true | Il valore deve essere minuscolo e senza virgolette. |
| Int | integer | Int i | "i": 7 | Deve essere senza virgolette. |
| Float | number | Float f | "f": 42.2 | Deve essere non quotato. |
| String | string | String s | "s": "characters" | Le stringhe JSON che sono un URI devono essere mappate su un file WDL per essere importate. |
| File | string | File f | "f": "s3://amzn-s3-demo-bucket1/path/to/file" | Amazon S3 e HealthOmics lo storage URIs vengono importati purché il ruolo IAM fornito per il flusso di lavoro abbia accesso in lettura a questi oggetti. Non sono supportati altri schemi URI (come file://https://, eftp://). L'URI deve specificare un oggetto. Non può essere una directory, il che significa che non può terminare con un/. |
| Directory | string | Directory d | "d": "s3://bucket/path/" | Il Directory tipo non è incluso in WDL 1.0 o 1.1, quindi sarà necessario aggiungerlo version development all'intestazione del file WDL. L'URI deve essere un URI Amazon S3 e deve avere un prefisso che termina con un '/'. Tutti i contenuti della directory verranno copiati in modo ricorsivo nel flusso di lavoro come singolo download. DirectoryDeve contenere solo file relativi al flusso di lavoro. |
## Tipi complessi in WDL
La tabella seguente mostra come gli input in WDL vengono mappati ai tipi JSON complessi corrispondenti. I tipi complessi in WDL sono strutture di dati composte da tipi primitivi. Le strutture di dati, come gli elenchi, verranno convertite in matrici.
**Tipi complessi**
| Tipo WDL | Tipo JSON | Esempio WDL | Esempio di chiave e valore JSON | Note |
| --- | --- | --- | --- | --- |
| Array | array | Array[Int] nums | “nums": [1, 2, 3] | I membri dell'array devono seguire il formato del tipo di array WDL. |
| Pair | object | Pair[String, Int] str\$1to\$1i | “str\$1to\$1i": \$1"left": "0", "right": 1\$1 | Ogni valore della coppia deve utilizzare il formato JSON del tipo WDL corrispondente. |
| Map | object | Map[Int, String] int\$1to\$1string | "int\$1to\$1string": \$1 2: "hello", 1: "goodbye" \$1 | Ogni voce nella mappa deve utilizzare il formato JSON del tipo WDL corrispondente. |
| 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"
} | I nomi dei membri della struttura devono corrispondere esattamente ai nomi delle chiavi degli oggetti JSON. Ogni valore deve utilizzare il formato JSON del tipo WDL corrispondente. |
| Object | N/D | N/D | N/D | Il Object tipo WDL è obsoleto e deve essere sostituito da Struct in tutti i casi. |
## Direttive in WDL
HealthOmics supporta le seguenti direttive in tutte le versioni WDL che supportano. HealthOmics
### Configura le risorse della GPU
HealthOmics supporta gli attributi di runtime **acceleratorType** e **acceleratorCount** con tutte le istanze [GPU](https://docs.aws.amazon.com/omics/latest/dev/task-accelerators.html) supportate. HealthOmics supporta anche gli alias denominati **gpuType** and**gpuCount**, che hanno le stesse funzionalità delle controparti con acceleratore. Se la definizione WDL contiene entrambe le direttive, HealthOmics utilizza i valori dell'acceleratore.
L'esempio seguente mostra come utilizzare queste direttive:
```
runtime {
gpuCount: 2
gpuType: "nvidia-tesla-t4"
}
```
### Configurare la ripetizione delle attività per gli errori di servizio
HealthOmics supporta fino a due tentativi per un'operazione non riuscita a causa di errori di servizio (codici di stato HTTP 5XX). È possibile configurare il numero massimo di tentativi (1 o 2) e disattivare i tentativi per errori di servizio. Per impostazione predefinita, HealthOmics tenta un massimo di due nuovi tentativi.
L'esempio seguente imposta `preemptible` la disattivazione dei nuovi tentativi per errori di servizio:
```
{
preemptible: 0
}
```
Per ulteriori informazioni sui nuovi tentativi di attività in HealthOmics, vedere. [Ritentativi di attività](monitoring-runs.md#run-status-task-retries)
### Configurare un nuovo tentativo di operazione in caso di esaurimento della memoria
HealthOmics supporta nuovi tentativi per un'operazione che non è riuscita perché la memoria è esaurita (codice di uscita del contenitore 137, codice di stato HTTP 4XX). HealthOmics raddoppia la quantità di memoria per ogni nuovo tentativo.
Per impostazione predefinita, HealthOmics non riprova per questo tipo di errore. Utilizzate la `maxRetries` direttiva per specificare il numero massimo di tentativi.
L'esempio seguente è `maxRetries` impostato su 3, in modo che HealthOmics tenti un massimo di quattro tentativi di completare l'operazione (il tentativo iniziale più tre tentativi):
```
runtime {
maxRetries: 3
}
```
**Nota**
Per riprovare l'operazione se la memoria non è sufficiente, è necessario GNU findutils 4.2.3\$1. Il contenitore di immagini predefinito include questo pacchetto. HealthOmics Se specificate un'immagine personalizzata nella definizione WDL, assicuratevi che l'immagine includa GNU findutils 4.2.3\$1.
### Configura i codici di restituzione
L'attributo **ReturnCodes** fornisce un meccanismo per specificare un codice di ritorno, o un set di codici di ritorno, che indica l'esecuzione corretta di un'attività. Il motore WDL rispetta i codici restituiti specificati nella sezione **runtime** della definizione WDL e imposta lo stato delle attività di conseguenza.
```
runtime {
returnCodes: 1
}
```
HealthOmics **supporta anche un alias denominato **continueOnReturnCode**, che ha le stesse funzionalità di ReturnCodes.** **Se si specificano entrambi gli attributi, HealthOmics utilizza il valore ReturnCodes.**
## Metadati delle attività in WDL
HealthOmics supporta le seguenti opzioni di metadati per le attività WDL.
### Disattiva la memorizzazione nella cache a livello di attività con l'attributo volatile
L'attributo **volatile** consente di disabilitare la memorizzazione nella cache delle chiamate per attività specifiche nel flusso di lavoro WDL. Quando un'attività è contrassegnata come volatile, verrà sempre eseguita e non utilizzerà mai i risultati memorizzati nella cache, anche quando la memorizzazione nella cache è abilitata per l'esecuzione.
Aggiungi l'attributo **volatile** alla **meta-sezione della definizione** dell'attività:
```
task my_volatile_task {
meta {
volatile: true
}
input {
String input_file
}
command {
echo "Processing ${input_file}" > output.txt
}
output {
File result = "output.txt"
}
}
```
## Esempio di definizione del flusso di lavoro WDL
Gli esempi seguenti mostrano le definizioni di workflow private per la conversione da `CRAM` a `BAM` in WDL. Il `BAM` flusso di lavoro `CRAM` to definisce due attività e utilizza gli strumenti del `genomes-in-the-cloud` contenitore, illustrato nell'esempio e disponibile pubblicamente.
L'esempio seguente mostra come includere il contenitore Amazon ECR come parametro. Ciò consente di HealthOmics verificare le autorizzazioni di accesso al contenitore prima che inizi l'esecuzione.
```
{
...
"gotc_docker":".dkr.ecr..amazonaws.com/genomes-in-the-cloud:2.4.7-1603303710"
}
```
L'esempio seguente mostra come specificare quali file utilizzare nell'esecuzione, quando i file si trovano in un bucket Amazon S3.
```
{
"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"
}
```
Se desideri specificare file da un archivio di sequenze, indicalo come mostrato nell'esempio seguente, utilizzando l'URI per l'archivio delle sequenze.
```
{
"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"
}
```
È quindi possibile definire il flusso di lavoro in WDL come illustrato nell'esempio seguente.
```
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}"
}
}
```
# Specifiche della definizione del flusso di lavoro Nextflow
HealthOmics supporta Nextflow e. DSL1 DSL2 Per informazioni dettagliate, vedi [Supporto per la versione Nextflow](workflows-lang-versions.md#workflows-lang-versions-nextflow).
Nextflow si DSL2 basa sul linguaggio di programmazione Groovy, quindi i parametri sono dinamici e la coercizione dei tipi è possibile utilizzando le stesse regole di Groovy. I parametri e i valori forniti dall'input JSON sono disponibili nella mappa parameters () del flusso di lavoro. `params`
**Topics**
+ [Usa i plugin nf-schema e nf-validation](#schema-and-validation-plugins-nextflow)
+ [Specificare l'archiviazione URIs](#storage-uris-nextflow)
+ [Direttive Nextflow](#workflow-nexflow-directives)
+ [Esporta contenuti a livello di flusso di lavoro](#exporting-workflow-content-nextflow)
+ [Esporta il contenuto delle attività](#exporting-task-content-nextflow)
## Usa i plugin nf-schema e nf-validation
**Nota**
Riepilogo del supporto per i plugin: HealthOmics
v22.04 — nessun supporto per i plugin
v23.10 — supporta e `nf-schema` `nf-validation`
v24.10 — supporta `nf-schema`
v25.10 — supporta`nf-schema`,, e `nf-core-utils` `nf-fgbio` `nf-prov`
HealthOmics fornisce il seguente supporto per i plugin Nextflow:
+ Per Nextflow v23.10, preinstalla il plugin nf-validation @1 .1.1 HealthOmics .
+ Per Nextflow v23.10 e versioni successive, preinstalla il plugin nf-schema @2 .3.0. HealthOmics
+ Non è possibile recuperare plug-in aggiuntivi durante l'esecuzione di un flusso di lavoro. HealthOmics ignora qualsiasi altra versione del plugin specificata nel file. `nextflow.config`
+ Per Nextflow v24 e versioni successive, `nf-schema` è la nuova versione del plugin obsoleto. `nf-validation` [Per ulteriori informazioni, consulta nf-schema nel repository Nextflow.](https://github.com/nextflow-io/nf-schema) GitHub
## Specificare l'archiviazione URIs
Quando un Amazon S3 o un HealthOmics URI viene utilizzato per costruire un file o un oggetto di percorso Nextflow, rende l'oggetto corrispondente disponibile per il flusso di lavoro, purché sia concesso l'accesso in lettura. L'uso di prefissi o directory è consentito per Amazon S3. URIs Per alcuni esempi, consulta [Formati dei parametri di input di Amazon S3](workflows-run-inputs.md#s3-run-input-formats).
HealthOmics supporta parzialmente l'uso di modelli glob in Amazon URIs S3 HealthOmics o Storage. URIs Usa i pattern Glob nella definizione del flusso di lavoro per la creazione dei `path` nostri canali. `file` Per il comportamento previsto e i casi esatti, vedi[Gestione Nextflow del pattern Glob negli input di Amazon S3](workflows-run-inputs.md#wd-nextflow-s3-formats).
## Direttive Nextflow
Le direttive Nextflow vengono configurate nel file di configurazione di Nextflow o nella definizione del flusso di lavoro. L'elenco seguente mostra l'ordine di precedenza HealthOmics utilizzato per applicare le impostazioni di configurazione, dalla priorità più bassa a quella più alta:
1. Configurazione globale nel file di configurazione.
1. Sezione delle attività della definizione del flusso di lavoro.
1. Selettori specifici dell'attività nel file di configurazione.
**Topics**
+ [Strategia di ripetizione delle attività utilizzando `errorStrategy`](#workflow-nextflow-errorStrategy)
+ [Tentativi di riprovare l'attività utilizzando `maxRetries`](#workflow-nexflow-task-retry)
+ [Disattiva la ripetizione dell'attività utilizzando `omicsRetryOn5xx`](#workflow-nextflow-retry-5xx)
+ [`time`Durata dell'attività utilizzando la direttiva](#time-directive-nextflow)
### Strategia di ripetizione delle attività utilizzando `errorStrategy`
Usa la `errorStrategy` direttiva per definire la strategia per gli errori delle attività. Per impostazione predefinita, quando un'attività ritorna con un'indicazione di errore (uno stato di uscita diverso da zero), l'attività si interrompe e HealthOmics termina l'intera esecuzione. Se è impostata su `errorStrategy``retry`, HealthOmics tenta un nuovo tentativo dell'operazione non riuscita. Per aumentare il numero di tentativi, vedere. [Tentativi di riprovare l'attività utilizzando `maxRetries`](#workflow-nexflow-task-retry)
```
process {
label 'my_label'
errorStrategy 'retry'
script:
"""
your-command-here
"""
}
```
Per informazioni su come HealthOmics gestisce i nuovi tentativi di operazione durante un'esecuzione, vedere. [Ritentativi di attività](monitoring-runs.md#run-status-task-retries)
### Tentativi di riprovare l'attività utilizzando `maxRetries`
Per impostazione predefinita, HealthOmics non tenta di ripetere un'operazione non riuscita o tenta un solo tentativo se configurato. `errorStrategy` Per aumentare il numero massimo di tentativi, imposta `errorStrategy` `retry` e configura il numero massimo di tentativi utilizzando la direttiva. `maxRetries`
L'esempio seguente imposta il numero massimo di tentativi su 3 nella configurazione globale.
```
process {
errorStrategy = 'retry'
maxRetries = 3
}
```
L'esempio seguente mostra come impostare `maxRetries` la definizione del flusso di lavoro nella sezione delle attività.
```
process myTask {
label 'my_label'
errorStrategy 'retry'
maxRetries 3
script:
"""
your-command-here
"""
}
```
L'esempio seguente mostra come specificare la configurazione specifica dell'attività nel file di configurazione di Nextflow, in base ai selettori di nome o etichetta.
```
process {
withLabel: 'my_label' {
errorStrategy = 'retry'
maxRetries = 3
}
withName: 'myTask' {
errorStrategy = 'retry'
maxRetries = 3
}
}
```
### Disattiva la ripetizione dell'attività utilizzando `omicsRetryOn5xx`
Per Nextflow v23 e versioni successive, HealthOmics supporta i nuovi tentativi di attività se l'operazione non è riuscita a causa di errori di servizio (5XX codici di stato HTTP). Per impostazione predefinita, HealthOmics tenta fino a due nuovi tentativi di un'operazione non riuscita.
È possibile `omicsRetryOn5xx` configurare la disattivazione del nuovo tentativo di operazione per errori di servizio. Per ulteriori informazioni su come riprovare l'attività HealthOmics, vedere. [Ritentativi di attività](monitoring-runs.md#run-status-task-retries)
L'esempio seguente configura `omicsRetryOn5xx` la configurazione globale per disattivare il nuovo tentativo di operazione.
```
process {
omicsRetryOn5xx = false
}
```
L'esempio seguente mostra come eseguire la configurazione `omicsRetryOn5xx` nella sezione delle attività della definizione del flusso di lavoro.
```
process myTask {
label 'my_label'
omicsRetryOn5xx = false
script:
"""
your-command-here
"""
}
```
L'esempio seguente mostra `omicsRetryOn5xx` come impostare una configurazione specifica per l'attività nel file di configurazione Nextflow, in base ai selettori di nome o etichetta.
```
process {
withLabel: 'my_label' {
omicsRetryOn5xx = false
}
withName: 'myTask' {
omicsRetryOn5xx = false
}
}
```
### `time`Durata dell'attività utilizzando la direttiva
HealthOmics fornisce una quota regolabile (vedi[HealthOmics quote di servizio](service-quotas.md)) per specificare la durata massima di un'esecuzione. Per i flussi di lavoro Nextflow v23 e versioni successive, puoi anche specificare la durata massima delle attività utilizzando la direttiva Nextflow. `time`
Durante lo sviluppo di nuovi flussi di lavoro, l'impostazione della durata massima delle attività consente di catturare attività inutili e attività di lunga durata.
[Per ulteriori informazioni sulla direttiva time di Nextflow, consulta la direttiva time nel riferimento di Nextflow.](https://www.nextflow.io/docs/latest/reference/process.html#process-time)
HealthOmics fornisce il seguente supporto per la direttiva time Nextflow:
1. HealthOmics supporta la granularità di 1 minuto per la direttiva time. È possibile specificare un valore compreso tra 60 secondi e il valore massimo della durata dell'esecuzione.
1. Se si immette un valore inferiore a 60, lo HealthOmics arrotonda a 60 secondi. Per valori superiori a 60, HealthOmics arrotonda per difetto al minuto più vicino.
1. Se il flusso di lavoro supporta nuovi tentativi per un'operazione, HealthOmics riprova l'operazione in caso di timeout.
1. Se un'attività scade (o scade l'ultimo tentativo), HealthOmics annulla l'attività. Questa operazione può avere una durata da uno a due minuti.
1. In caso di timeout dell'attività, HealthOmics imposta l'esecuzione e lo stato dell'attività su Non riuscita e annulla le altre attività in esecuzione (per le attività con stato Avvio, In sospeso o In esecuzione). HealthOmics esporta gli output delle attività completate prima del timeout nella posizione di output S3 designata.
1. Il tempo trascorso da un'attività in sospeso non viene conteggiato ai fini della durata dell'attività.
1. Se l'esecuzione fa parte di un gruppo di esecuzione e il gruppo di esecuzione scade prima del timer dell'attività, l'esecuzione e l'attività passano allo stato non riuscito.
Specificate la durata del timeout utilizzando una o più delle seguenti unità:`ms`,, `s` `m``h`, o. `d`
L'esempio seguente mostra come specificare la configurazione globale nel file di configurazione Nextflow. Imposta un timeout globale di 1 ora e 30 minuti.
```
process {
time = '1h30m'
}
```
L'esempio seguente mostra come specificare una direttiva temporale nella sezione delle attività della definizione del flusso di lavoro. Questo esempio imposta un timeout di 3 giorni, 5 ore e 4 minuti. Questo valore ha la precedenza sul valore globale nel file di configurazione, ma non ha la precedenza su una direttiva temporale specifica per l'attività nel file di configurazione. `my_label`
```
process myTask {
label 'my_label'
time '3d5h4m'
script:
"""
your-command-here
"""
}
```
L'esempio seguente mostra come specificare le direttive temporali specifiche dell'attività nel file di configurazione Nextflow, in base ai selettori di nome o etichetta. Questo esempio imposta un valore di timeout globale dell'attività di 30 minuti. Imposta un valore di 2 ore per l'attività `myTask` e imposta un valore di 3 ore per le attività con etichetta`my_label`. Per le attività che corrispondono al selettore, questi valori hanno la precedenza sul valore globale e sul valore nella definizione del flusso di lavoro.
```
process {
time = '30m'
withLabel: 'my_label' {
time = '3h'
}
withName: 'myTask' {
time = '2h'
}
}
```
## Esporta contenuti a livello di flusso di lavoro
Per Nextflow v25.10, puoi esportare file prodotti al di fuori di singole attività, come report di provenienza o pipeline. DAGs Per esportare questi file, scrivili su. `/mnt/workflow/output/` HealthOmics esporta i file inseriti in questa directory nel `output/` prefisso nella posizione di output Amazon S3 della tua corsa.
L'esempio seguente mostra come configurare il `nf-prov` plug-in su cui scrivere un rapporto di provenienza. `/mnt/workflow/output/`
```
prov {
formats {
bco {
file = "/mnt/workflow/output/pipeline_info/manifest.bco.json"
}
}
}
```
Puoi anche passare questo percorso come parametro nell'input JSON della tua esecuzione. Questo approccio è comune ai flussi di lavoro nf-core che utilizzano. `params.outdir`
```
{
"outdir": "/mnt/workflow/output/"
}
```
## Esporta il contenuto delle attività
Per i flussi di lavoro scritti in Nextflow, definisci una direttiva **PublishDir** per esportare il contenuto delle attività nel tuo bucket Amazon S3 di output. **Come mostrato nell'esempio seguente, imposta il valore PublishDir su.** `/mnt/workflow/pubdir` Per esportare file in Amazon S3, i file devono trovarsi in questa directory.
```
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
"""
}
```
Per Nextflow v25.10, in alternativa a`publishDir`, puoi utilizzare gli output del flusso di lavoro per esportare il contenuto delle attività. L'esempio seguente mostra come definire un `output` blocco di flusso di lavoro che esporta i risultati delle attività in Amazon S3.
```
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 '.'
}
}
```
Per ulteriori informazioni sugli output del flusso di lavoro, consulta Output del [flusso di lavoro nella documentazione](https://www.nextflow.io/docs/latest/workflow.html#workflow-output-def) di Nextflow.
# Specifiche della definizione del flusso di lavoro CWL
I flussi di lavoro scritti in Common Workflow Language, o CWL, offrono funzionalità simili ai flussi di lavoro scritti in WDL e Nextflow. Puoi utilizzare Amazon S3 o HealthOmics lo storage URIs come parametri di input.
Se definisci l'input in un SecondaryFile in un flusso di lavoro secondario, aggiungi la stessa definizione nel flusso di lavoro principale.
HealthOmics i flussi di lavoro non supportano i processi operativi. [Per ulteriori informazioni sui processi operativi nei flussi di lavoro CWL, consultate la documentazione CWL.](https://www.commonwl.org/user_guide/topics/operations.html)
La migliore pratica consiste nel definire un flusso di lavoro CWL separato per ogni contenitore utilizzato. Ti consigliamo di non codificare la voce DockerPull con un URI Amazon ECR fisso.
**Topics**
+ [Converti i flussi di lavoro CWL da utilizzare HealthOmics](#workflow-cwl-convert)
+ [Disattiva la ripetizione dell'attività utilizzando `omicsRetryOn5xx`](#workflow-cwl-retry-5xx)
+ [Ripeti una fase del flusso di lavoro](#workflow-cwl-loop)
+ [Riprova le attività con maggiore memoria](#workflow-cwl-out-of-memory-retry)
+ [Esempi](#workflow-cwl-examples)
## Converti i flussi di lavoro CWL da utilizzare HealthOmics
Per convertire una definizione di workflow CWL esistente da utilizzare HealthOmics, apportate le seguenti modifiche:
+ Sostituisci tutti i container Docker URIs con Amazon URIs ECR.
+ Assicurati che tutti i file del flusso di lavoro siano dichiarati come input nel flusso di lavoro principale e che tutte le variabili siano definite in modo esplicito.
+ Assicurati che tutto il JavaScript codice sia conforme alla modalità rigorosa.
## Disattiva la ripetizione dell'attività utilizzando `omicsRetryOn5xx`
HealthOmics supporta nuovi tentativi di attività se l'operazione non è riuscita a causa di errori di servizio (codici di stato HTTP 5XX). Per impostazione predefinita, HealthOmics tenta fino a due nuovi tentativi di un'operazione non riuscita. Per ulteriori informazioni su come riprovare l'operazione HealthOmics, vedere. [Ritentativi di attività](monitoring-runs.md#run-status-task-retries)
Per disattivare la ripetizione dell'attività a causa di errori di servizio, configura la `omicsRetryOn5xx` direttiva nella definizione del flusso di lavoro. È possibile definire questa direttiva in base a requisiti o suggerimenti. Consigliamo di aggiungere la direttiva come suggerimento per la portabilità.
```
requirements:
ResourceRequirement:
omicsRetryOn5xx: false
hints:
ResourceRequirement:
omicsRetryOn5xx: false
```
I requisiti hanno la precedenza sui suggerimenti. Se l'implementazione di un'attività fornisce un fabbisogno di risorse nei suggerimenti che è fornito anche dai requisiti in un flusso di lavoro che lo include, i requisiti di inclusione hanno la precedenza.
Se lo stesso requisito di attività viene visualizzato a livelli diversi del flusso di lavoro, HealthOmics utilizza la voce più specifica di `requirements` (o`hints`, se non sono presenti voci). `requirements` L'elenco seguente mostra l'ordine di precedenza HealthOmics utilizzato per applicare le impostazioni di configurazione, dalla priorità più bassa a quella più alta:
+ Livello di flusso di lavoro
+ Livello di gradino
+ Sezione delle attività della definizione del flusso di lavoro
L'esempio seguente mostra come configurare la `omicsRetryOn5xx` direttiva a diversi livelli del flusso di lavoro. In questo esempio, il requisito a livello di flusso di lavoro ha la precedenza sui suggerimenti a livello di flusso di lavoro. Le configurazioni dei requisiti a livello di attività e fase hanno la precedenza sulle configurazioni dei suggerimenti.
```
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
```
## Ripeti una fase del flusso di lavoro
HealthOmics supporta la ripetizione ciclica di una fase del flusso di lavoro. È possibile utilizzare i loop per eseguire ripetutamente le fasi del flusso di lavoro fino a quando non viene soddisfatta una condizione specificata. Ciò è utile per i processi iterativi in cui è necessario ripetere un'operazione più volte o fino al raggiungimento di un determinato risultato.
**Nota:** la funzionalità Loop richiede la versione CWL 1.2 o successiva. I flussi di lavoro che utilizzano versioni CWL precedenti alla 1.2 non supportano le operazioni di loop.
Per utilizzare i loop nel flusso di lavoro CWL, definite un requisito di Loop. L'esempio seguente mostra la configurazione dei requisiti del loop:
```
requirements:
- class: "http://commonwl.org/cwltool#Loop"
loopWhen: $(inputs.counter < inputs.max)
loop:
counter:
loopSource: result
valueFrom: $(self)
outputMethod: last
```
Il `loopWhen` campo controlla quando il ciclo termina. In questo esempio, il ciclo continua finché il contatore è inferiore al valore massimo. Il `loop` campo definisce come i parametri di input vengono aggiornati tra le iterazioni. `loopSource`specifica quale output dell'iterazione precedente viene immesso nell'iterazione successiva. Il `outputMethod` campo impostato su `last` restituisce solo l'output dell'iterazione finale.
## Riprova le attività con maggiore memoria
HealthOmics supporta la ripetizione automatica degli errori delle out-of-memory attività. Quando un'attività termina con il codice 137 (out-of-memory), HealthOmics crea una nuova attività con una maggiore allocazione di memoria in base al moltiplicatore specificato.
**Nota**
HealthOmics riprova gli out-of-memory errori fino a 3 volte o finché l'allocazione della memoria non raggiunge i 1536 GiB, a seconda del limite raggiunto per primo.
L'esempio seguente mostra come configurare retry: out-of-memory
```
hints:
ResourceRequirement:
ramMin: 4096
http://arvados.org/cwl#OutOfMemoryRetry:
memoryRetryMultiplier: 2.5
```
Quando un'operazione fallisce a causa di out-of-memory, HealthOmics calcola l'allocazione della memoria tra tentativi utilizzando la formula:. `previous_run_memory × memoryRetryMultiplier` Nell'esempio precedente, se l'operazione con 4096 MB di memoria ha esito negativo, il nuovo tentativo utilizza 4096 × 2,5 = 10.240 MB di memoria.
Il `memoryRetryMultiplier` parametro controlla la quantità di memoria aggiuntiva da allocare per i tentativi di riprovare:
+ **Valore predefinito:** se non si specifica un valore, il valore predefinito è `2` (raddoppia la memoria)
+ **Intervallo valido:** deve essere un numero positivo maggiore di. `1` I valori non validi generano un errore di convalida 4XX
+ **Valore minimo effettivo:** i valori compresi tra `1` e `1.5` vengono aumentati automaticamente per `1.5` garantire un aumento significativo della memoria e prevenire tentativi eccessivi di nuovi tentativi
## Esempi
Di seguito è riportato un esempio di workflow scritto in CWL.
```
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
```
Il file seguente definisce l'`copy.cwl`attività.
```
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)"
```
Di seguito è riportato un esempio di flusso di lavoro scritto in CWL con un requisito GPU.
```
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: []
```
# Esempi di definizioni del flusso di lavoro
L'esempio seguente mostra la stessa definizione di flusso di lavoro in WDL, Nextflow e 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
```
------