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

Les rubriques suivantes fournissent des informations détaillées 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 le casting de type implicite, spécifiez le moteur de flux de travail comme WDL indulgent lorsque vous créez le flux de travail. WDL Lenient est conçu pour gérer les flux de travail migrés depuis Cromwell. Il prend en charge les directives Cromwell du client 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 WDL :

Pour utiliser le casting de type implicite, spécifiez le moteur de flux de travail sous la forme 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 s'appelle Language. 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 numéro1 et numéro2 dans le flux de travail : SumWorkflow

workflow SumWorkflow {
  input {
    Int number1
    Int number2
  }
}   

Vous pouvez les utiliser comme variables entièrement qualifiées dans input.json :

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

Types primitifs dans WDL

Le tableau suivant montre comment les entrées de 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 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 .

Configuration des ressources du GPU

HealthOmics prend en charge les attributs d'exécution acceleratorType et acceleratorCount avec toutes les instances de 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 une nouvelle tentative de tâche pour les erreurs de service

HealthOmics prend en charge jusqu'à deux 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 tentatives en cas d'erreur de service. Par défaut, le nombre maximum de HealthOmics tentatives est de deux tentatives.

L'exemple suivant permet preemptible de désactiver les 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 une nouvelle tentative de tâche en cas de mémoire insuffisante

HealthOmics prend en charge les nouvelles tentatives pour une tâche qui a échoué en raison d'un manque de mémoire (code de sortie du conteneur 137, code d'état HTTP 4XX). HealthOmics double la quantité de mémoire à 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 maximal de tentatives.

L'exemple suivant définit maxRetries la 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, indiquant l'exécution réussie 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 le statut des tâches en conséquence.

runtime {
    returnCodes: 1
}     

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

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 CRAM de travail to définit deux tâches et utilise les outils du genomes-in-the-cloud conteneur, qui est illustré dans l'exemple et est 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 indiqué 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}"
    }
}