Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Spécificités de définition du flux de travail CWL

Les flux de travail écrits en langage de flux de travail commun, ou CWL, offrent des fonctionnalités similaires à celles des flux de travail écrits en WDL et Nextflow. Vous pouvez utiliser Amazon S3 ou le HealthOmics stockage URIs comme paramètres d'entrée.

Si vous définissez une entrée dans un fichier secondaire dans un sous-flux de travail, ajoutez la même définition dans le flux de travail principal.

HealthOmics les flux de travail ne prennent pas en charge les processus opérationnels. Pour en savoir plus sur les processus opérationnels dans les flux de travail CWL, consultez la documentation CWL.

La meilleure pratique consiste à définir un flux de travail CWL distinct pour chaque conteneur que vous utilisez. Nous vous recommandons de ne pas coder en dur l'entrée DockerPull avec un URI Amazon ECR fixe.

Convertissez les flux de travail CWL à utiliser HealthOmics

Pour convertir une définition de flux de travail CWL existante à utiliser HealthOmics, apportez les modifications suivantes :

Désactiver la tâche, réessayez en utilisant omicsRetryOn5xx

HealthOmics prend en charge les nouvelles tentatives de tâche si la tâche a échoué en raison d'erreurs de service (codes d'état HTTP 5XX). Par défaut, HealthOmics tente jusqu'à deux tentatives d'une tâche qui a échoué. Pour plus d'informations sur la nouvelle tentative d'une tâche HealthOmics, consultezNouvelles tentatives de tâches.

Pour désactiver la nouvelle tentative de tâche en cas d'erreur de service, configurez la omicsRetryOn5xx directive dans la définition du flux de travail. Vous pouvez définir cette directive dans la section « exigences » ou « astuces ». Nous vous recommandons d'ajouter la directive comme indication de portabilité.

requirements:
  ResourceRequirement:
    omicsRetryOn5xx: false

hints:
  ResourceRequirement:
    omicsRetryOn5xx: false     

Les exigences l'emportent sur les conseils. Si l'implémentation d'une tâche fournit un besoin en ressources sous forme d'indications qui est également fourni par les exigences d'un flux de travail englobant, les exigences générales ont priorité.

Si la même exigence de tâche apparaît à différents niveaux du flux de travail, HealthOmics utilise l'entrée la plus spécifique provenant de requirements (ouhints, s'il n'y a aucune entréerequirements). La liste suivante indique l'ordre de priorité HealthOmics utilisé pour appliquer les paramètres de configuration, de la priorité la plus faible à la plus élevée :

L'exemple suivant montre comment configurer la omicsRetryOn5xx directive à différents niveaux du flux de travail. Dans cet exemple, l'exigence relative au niveau du flux de travail remplace les indications relatives au niveau du flux de travail. Les configurations d'exigences au niveau des tâches et des étapes remplacent les configurations indicatives.

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      
    

Boucler une étape du flux de travail

HealthOmics permet de mettre en boucle une étape du flux de travail. Vous pouvez utiliser des boucles pour exécuter les étapes du flux de travail de manière répétée jusqu'à ce qu'une condition spécifiée soit remplie. Cela est utile pour les processus itératifs dans lesquels vous devez répéter une tâche plusieurs fois ou jusqu'à ce qu'un certain résultat soit atteint.

Remarque : La fonctionnalité de boucle nécessite la version 1.2 ou ultérieure de CWL. Les flux de travail utilisant des versions CWL antérieures à 1.2 ne prennent pas en charge les opérations en boucle.

Pour utiliser des boucles dans votre flux de travail CWL, définissez une exigence de boucle. L'exemple suivant montre la configuration requise pour les boucles :

requirements:
  - class: "http://commonwl.org/cwltool#Loop"
    loopWhen: $(inputs.counter < inputs.max)
    loop:
      counter:
        loopSource: result
        valueFrom: $(self)
    outputMethod: last

Le loopWhen champ contrôle le moment où la boucle se termine. Dans cet exemple, la boucle continue tant que le compteur est inférieur à la valeur maximale. Le loop champ définit la manière dont les paramètres d'entrée sont mis à jour entre les itérations. loopSourceSpécifie le résultat de l'itération précédente qui alimente l'itération suivante. Le outputMethod champ défini sur last renvoie uniquement le résultat de l'itération finale.

Réessayer des tâches avec une mémoire accrue

HealthOmics permet une nouvelle tentative automatique en cas d'échec des out-of-memory tâches. Lorsqu'une tâche se termine avec le code 137 (out-of-memory), HealthOmics crée une nouvelle tâche avec une allocation de mémoire accrue en fonction du multiplicateur spécifié.

L'exemple suivant montre comment configurer la out-of-memory nouvelle tentative :

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

Lorsqu'une tâche échoue en raison de out-of-memory, HealthOmics calcule l'allocation de mémoire pour les nouvelles tentatives à l'aide de la formule :. previous_run_memory × memoryRetryMultiplier Dans l'exemple ci-dessus, si la tâche avec 4 096 Mo de mémoire échoue, la nouvelle tentative utilise 4 096 × 2,5 = 10 240 Mo de mémoire.

Le memoryRetryMultiplier paramètre contrôle la quantité de mémoire supplémentaire à allouer pour les nouvelles tentatives :

Exemples

Voici un exemple de flux de travail écrit en 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            
    

Le fichier suivant définit la copy.cwl tâche.

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)"      

Voici un exemple de flux de travail écrit en CWL avec une exigence de 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: []