Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# 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: []
```