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 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 ayant é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      
    

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