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 di 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 usare Amazon S3 o HealthOmics URI di archiviazione 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 saperne di più sui processi operativi nei flussi di lavoro CWL, consulta Documentazione CWL.

La procedura migliore 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.

Per ulteriori informazioni sulla convalida di una definizione CWL prima di creare il flusso di lavoro, consulta Convalida delle definizioni del flusso di lavoro a livello locale.

Converti i flussi di lavoro CWL da utilizzare HealthOmics

Per convertire una definizione di flusso di lavoro CWL esistente da utilizzare HealthOmics, apporta le seguenti modifiche:

Disattiva l'attività, riprova a utilizzare FumettiRetryOn5xx

HealthOmics supporta i tentativi di nuova operazione se l'operazione non è riuscita a causa di errori di servizio (codici di stato HTTP 5XX). Per impostazione predefinita, HealthOmics tenta fino a due tentativi di un'operazione non riuscita. Per ulteriori informazioni sull'attività, riprova HealthOmics, vedere Ritentativi di attività.

Per disattivare la possibilità di ripetere l'operazione a causa di errori di servizio, configura omicsRetryOn5xx direttiva nella definizione del flusso di lavoro. È possibile definire questa direttiva in 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 fornito anche dai requisiti di un flusso di lavoro allegato, i requisiti allegati hanno la precedenza.

Se lo stesso requisito di attività appare a diversi livelli del flusso di lavoro, HealthOmics utilizza la voce più specifica da requirements (o hints, se non ci sono iscrizioni in requirements). L'elenco seguente mostra l'ordine di precedenza che HealthOmics utilizza per applicare le impostazioni di configurazione, dalla priorità più bassa a quella più alta:

L'esempio seguente mostra come configurare 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 di 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, definisci un requisito 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 il campo controlla quando il ciclo termina. In questo esempio, il ciclo continua finché il contatore è inferiore al valore massimo. Il loop il campo definisce il modo in cui i parametri di input vengono aggiornati tra le iterazioni. Il 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 relativi alle attività che hanno esaurito la memoria. Quando un'attività termina con il codice 137 (memoria esaurita), HealthOmics crea una nuova attività con una maggiore allocazione di memoria in base al moltiplicatore specificato.

L'esempio seguente mostra come configurare il nuovo tentativo di memoria esaurita:

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

Quando un'operazione non riesce a causa di memoria insufficiente, HealthOmics calcola l'allocazione di memoria per i tentativi successivi utilizzando la formula: previous_run_memory × memoryRetryMultiplier. Nell'esempio precedente, se l'operazione con 4096 MB di memoria fallisce, il tentativo di nuovo utilizza 4096 × 2,5 = 10.240 MB di memoria.

Il memoryRetryMultiplier il parametro controlla la quantità di memoria aggiuntiva da allocare per i tentativi di nuovo tentativo:

Esempi

Di seguito è riportato un esempio di flusso di lavoro 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 copy.cwl operazione.

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 requisiti 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: []