Spécificités de la définition du flux de travail WDL

Les rubriques suivantes fournissent des détails sur les types et les directives disponibles pour les définitions de flux de travail WDL dans HealthOmics.

Conversion de type implicite dans WDL lenient

HealthOmics prend en charge la conversion de type implicite dans le fichier input.json et dans la définition du flux de travail. Pour utiliser la conversion de type implicite, spécifiez le moteur de flux de travail comme WDL indulgent lorsque vous créez le flux de travail. WDL Lenient inclut toutes les fonctionnalités WDL standard ainsi que des comportements de compatibilité supplémentaires conçus pour les flux de travail migrés depuis Cromwell. Il prend en charge les directives Cromwell des clients et certaines logiques non conformes.

WDL Lenient prend en charge la conversion de type pour les éléments suivants de la liste des exceptions limitées de la WDL : https://github.com/openwdl/wdl/blob/wdl-1.1/SPEC.md#-limited-exceptions

Pour utiliser la conversion de type implicite, spécifiez le moteur de flux de travail comme WDL_LENIENT lorsque vous créez le flux de travail ou la version du flux de travail.

Dans la console, le paramètre du moteur de flux de travail est nommé Langue. Dans l'API, le paramètre du moteur de flux de travail est nommé moteur. Pour plus d’informations, consultez Création d'un flux de travail privé ou Création d'une version de flux de travail.

Définition de l'espace de noms dans input.json

HealthOmics prend en charge les variables entièrement qualifiées dans input.json. Par exemple, si vous déclarez deux variables d'entrée nommées number1 et number2 dans le workflow : SumWorkflow

workflow SumWorkflow {
  input {
    Int number1
    Int number2
  }
}   

Vous pouvez les utiliser comme variables complètes dans input.json :

{
    "SumWorkflow.number1": 15,
    "SumWorkflow.number2": 27
}   

Types primitifs dans WDL

Le tableau suivant montre comment les entrées de la WDL correspondent aux types primitifs correspondants. HealthOmics fournit une prise en charge limitée de la coercition de type, nous vous recommandons donc de définir des types explicites.

Types complexes dans WDL

Le tableau suivant montre comment les entrées de la WDL correspondent aux types JSON complexes correspondants. Les types complexes dans WDL sont des structures de données composées de types primitifs. Les structures de données telles que les listes seront converties en tableaux.

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

Directives dans WDL

HealthOmics prend en charge les directives suivantes dans toutes les versions de WDL compatibles HealthOmics .

Configurer les ressources du GPU

HealthOmics prend en charge les attributs d'exécution acceleratorType et acceleratorCount avec toutes les instances GPU prises en charge. HealthOmics prend également en charge les alias nommés gpuType etgpuCount, qui ont les mêmes fonctionnalités que leurs homologues accélérateurs. Si la définition WDL contient les deux directives, HealthOmics utilise les valeurs de l'accélérateur.

L'exemple suivant montre comment utiliser ces directives :

runtime {
    gpuCount: 2
    gpuType: "nvidia-tesla-t4"
} 

Configurer la nouvelle tentative de tâche pour les erreurs de service

HealthOmics prend en charge jusqu'à deux nouvelles tentatives pour une tâche qui a échoué en raison d'erreurs de service (codes d'état HTTP 5XX). Vous pouvez configurer le nombre maximum de tentatives (1 ou 2) et vous pouvez désactiver les nouvelles tentatives en cas d'erreur de service. Par défaut, HealthOmics tente au maximum deux nouvelles tentatives.

L'exemple suivant définit les paramètres preemptible permettant de désactiver les nouvelles tentatives en cas d'erreur de service :

{
  preemptible: 0 
}     

Pour plus d'informations sur les nouvelles tentatives de tâches HealthOmics, consultezNouvelles tentatives de tâches.

Configurer la nouvelle tentative de tâche en cas de manque de mémoire

HealthOmics prend en charge les nouvelles tentatives pour une tâche qui a échoué car la mémoire était insuffisante (code de sortie du conteneur 137, code d'état HTTP 4XX). HealthOmics double la quantité de mémoire pour chaque nouvelle tentative.

Par défaut, HealthOmics ne réessaie pas pour ce type d'échec. Utilisez la maxRetries directive pour spécifier le nombre maximum de nouvelles tentatives.

L'exemple suivant définit la maxRetries valeur 3, de sorte que quatre HealthOmics tentatives au maximum sont tentées pour terminer la tâche (la première tentative plus trois nouvelles tentatives) :

runtime {
    maxRetries: 3
}     

Configurer les codes de retour

L'attribut ReturnCodes fournit un mécanisme permettant de spécifier un code de retour, ou un ensemble de codes de retour, qui indique la réussite de l'exécution d'une tâche. Le moteur WDL respecte les codes de retour que vous spécifiez dans la section d'exécution de la définition WDL et définit l'état des tâches en conséquence.

runtime {
    returnCodes: 1
}     

HealthOmics prend également en charge un alias nommé continue OnReturnCode, qui possède les mêmes fonctionnalités que ReturnCodes. Si vous spécifiez les deux attributs, HealthOmics utilise la valeur ReturnCodes.

Formulaires de disques WDL pris en charge

HealthOmics accepte tous les disks formulaires WDL 1.1 standard. Le chemin de montage et le spécificateur de type de disque (SSD,HDD) sont ignorés ; seule la taille numérique est extraite. Si plusieurs entrées sont déclarées, les tailles sont additionnées en une seule /tmp allocation.

HealthOmics installe tous les rangements éphémères à. /tmp Si la définition de votre flux de travail déclare plusieurs disks entrées, les tailles sont additionnées et le total est provisionné en un seul /tmp volume. Pour plus d'informations sur l'attribut disks d'exécution WDL, consultez la spécification WDL 1.1.

Autres attributs d'exécution pris en charge

Configurer le délai d'expiration au niveau des tâches avec l'attribut d'exécution OmicsTimeout

HealthOmics fournit un omicsTimeout attribut personnalisé permettant de définir la durée maximale des tâches dans votre flux de travail. Spécifiez la durée du délai d'attente sous la forme d'un entier (secondes) ou d'une chaîne en utilisant une ou plusieurs des unités suivantes : sm,h, oud. Par exemple, "40m", "1h30m" ou "1m3s".

L'exemple suivant montre comment spécifier l'omicsTimeoutattribut dans la runtime section d'une définition de tâche WDL. Cet exemple définit un délai d'attente de 40 minutes.

    runtime {
        omicsTimeout: "40m"
    }

HealthOmics fournit le support suivant pour l'attribut omicsTimeout d'exécution WDL :

Toutes les courses ont une durée maximale que le quota ajustable dans HealthOmics quotas de service les contrôles. Vous pouvez demander une augmentation de ce quota.

Métadonnées des tâches dans WDL

HealthOmics prend en charge les options de métadonnées suivantes pour les tâches WDL.

Désactivez la mise en cache au niveau des tâches avec l'attribut volatile

L'attribut volatile vous permet de désactiver la mise en cache des appels pour des tâches spécifiques de votre flux de travail WDL. Lorsqu'une tâche est marquée comme volatile, elle s'exécute toujours et n'utilise jamais les résultats mis en cache, même lorsque la mise en cache est activée pour l'exécution.

Ajoutez l'attribut volatile à la section méta de votre définition de tâche :

task my_volatile_task {
    meta {
        volatile: true
    }
    
    input {
        String input_file
    }
    
    command {
        echo "Processing ${input_file}" > output.txt
    }
    
    output {
        File result = "output.txt"
    }
}

Exemple de définition de flux de travail WDL

Les exemples suivants présentent des définitions de flux de travail privés pour la conversion de CRAM vers BAM dans WDL. Le BAM flux de travail CRAM to définit deux tâches et utilise les outils du genomes-in-the-cloud conteneur, illustré dans l'exemple et accessible au public.

L'exemple suivant montre comment inclure le conteneur Amazon ECR en tant que paramètre. Cela permet HealthOmics de vérifier les autorisations d'accès à votre conteneur avant qu'il ne commence l'exécution.

{
   ...
   "gotc_docker":"<account_id>.dkr.ecr.<region>.amazonaws.com/genomes-in-the-cloud:2.4.7-1603303710"
}       

L'exemple suivant montre comment spécifier les fichiers à utiliser lors de votre exécution, lorsque les fichiers se trouvent dans un compartiment 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"
}       

Si vous souhaitez spécifier des fichiers à partir d'un magasin de séquences, indiquez-le comme indiqué dans l'exemple suivant, en utilisant l'URI du magasin de séquences.

{
    "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"
}       

Vous pouvez ensuite définir votre flux de travail dans WDL comme illustré dans l'exemple suivant.

 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 = "<account>.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}"
    }
}