Workflow-Definitionen für HealthOmics Workflows schreiben

HealthOmics unterstützt in WDL, Nextflow oder CWL geschriebene Workflow-Definitionen. Weitere Informationen zu diesen Workflow-Sprachen finden Sie in den Spezifikationen für WDL, Nextflow oder CWL.

HealthOmics unterstützt die Versionsverwaltung für die drei Workflow-Definitionssprachen. Weitere Informationen finden Sie unter Versionsunterstützung für HealthOmics Workflow-Definitionssprachen .

Workflows in WDL schreiben

Die folgenden Tabellen zeigen, wie Eingaben in WDL dem passenden primitiven Typ oder komplexen JSON-Typ zugeordnet werden. Der Typzwang ist begrenzt, und Typen sollten, wann immer möglich, explizit sein.

Komplexe Typen in WDL sind Datenstrukturen, die aus primitiven Typen bestehen. Datenstrukturen wie Listen werden in Arrays umgewandelt.

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

Die HealthOmics Workflow-Engine unterstützt keine qualifizierten Eingabeparameter oder Eingabeparameter mit Namensraum. Die Behandlung qualifizierter Parameter und deren Zuordnung zu WDL-Parametern ist in der WDL-Sprache nicht spezifiziert und kann mehrdeutig sein. Aus diesen Gründen empfiehlt es sich, alle Eingabeparameter in der Workflow-Definitionsdatei der obersten Ebene (Haupt-Workflow-Definitionsdatei) zu deklarieren und sie mithilfe von Standard-WDL-Mechanismen an untergeordnete Workflow-Aufrufe weiterzuleiten.

Workflows in Nextflow schreiben

HealthOmics unterstützt DSL1 Nextflow und. DSL2 Details hierzu finden Sie unter Unterstützung für die Nextflow-Version.

Nextflow DSL2 basiert auf der Programmiersprache Groovy, sodass Parameter dynamisch sind und Typenzwang nach den gleichen Regeln wie Groovy möglich ist. Parameter und Werte, die von der JSON-Eingabe bereitgestellt werden, sind in der Parameters () -Map des Workflows verfügbar. params

Verwendung der Plug-ins NF-Schema und NF-Validation

HealthOmics bietet die folgende Unterstützung für Nextflow-Plugins:

Speicher angeben URIs

Wenn ein Amazon S3 oder HealthOmics URI verwendet wird, um eine Nextflow-Datei oder ein Nextflow-Pfadobjekt zu erstellen, stellt es das entsprechende Objekt für den Workflow zur Verfügung, sofern Lesezugriff gewährt wird. Die Verwendung von Präfixen oder Verzeichnissen ist für Amazon S3 URIs zulässig. Beispiele finden Sie unter Amazon S3 S3-Eingabeparameterformate.

HealthOmics unterstützt die Verwendung von Glob-Mustern in Amazon S3 URIs oder HealthOmics Storage URIs. Verwenden Sie Glob-Muster in der Workflow-Definition für die Erstellung von Or-Kanälenpath. file

Festlegung der maximalen Aufgabendauer mithilfe von Zeitanweisungen

HealthOmics stellt ein einstellbares Kontingent bereit (sieheHealthOmics Servicekontingenten), um die maximale Dauer einer Ausführung anzugeben. Für Nextflow v23- und v24-Workflows können Sie mithilfe von Nextflow-Zeitdirektiven auch maximale Aufgabendauern angeben.

Bei der Entwicklung neuer Workflows hilft Ihnen die Festlegung der maximalen Aufgabendauer dabei, außer catch geratene Aufgaben und lang andauernde Aufgaben zu erkennen.

Weitere Informationen zur Nextflow-Zeitdirektive finden Sie unter Zeitdirektive in der Nextflow-Referenz.

HealthOmics bietet die folgende Unterstützung für Nextflow-Zeitdirektiven:

Geben Sie die Timeoutdauer mit einer oder mehreren der folgenden Einheiten an:ms,s, mh, oderd. Sie können Zeitdirektiven in der Nextflow-Konfigurationsdatei und in der Workflow-Definition angeben. Die folgende Liste zeigt die Rangfolge von der niedrigsten zur höchsten Priorität:

Das folgende Beispiel zeigt, wie die globale Konfiguration in der Nextflow-Konfigurationsdatei angegeben wird. Es legt ein globales Timeout von 1 Stunde und 30 Minuten fest:

process {
    time = '1h30m'
}     

Das folgende Beispiel zeigt, wie eine Zeitanweisung im Aufgabenbereich der Workflow-Definition angegeben wird. In diesem Beispiel wird ein Timeout von 3 Tagen, 5 Stunden und 4 Minuten festgelegt. Dieser Wert hat Vorrang vor dem globalen Wert in der Konfigurationsdatei, hat jedoch keinen Vorrang vor einer aufgabenspezifischen Zeitanweisung für my_label in der Konfigurationsdatei:

process myTask {
    label 'my_label'
    time '3d5h4m'
        
    script:
    """
    your-command-here
    """
}     

Das folgende Beispiel zeigt, wie aufgabenspezifische Zeitdirektiven in der Nextflow-Konfigurationsdatei auf der Grundlage der Namens- oder Labelselektoren angegeben werden. In diesem Beispiel wird ein globaler Task-Timeout-Wert von 30 Minuten festgelegt. Es legt einen Wert von 2 Stunden für eine Aufgabe myTask und einen Wert von 3 Stunden für Aufgaben mit Bezeichnung my_label fest. Bei Aufgaben, die dem Selektor entsprechen, haben diese Werte Vorrang vor dem globalen Wert und dem Wert in der Workflow-Definition:

process {
    time = '30m'
    
    withLabel: 'my_label' {
        time = '3h'  
    }

    withName: 'myTask' {
        time = '2h'  
    }
}     

Aufgabeninhalt exportieren

Definieren Sie für in Nextflow geschriebene Workflows eine PublishDir-Direktive, um Aufgabeninhalte in Ihren Amazon S3 S3-Ausgabe-Bucket zu exportieren. Wie im folgenden Beispiel gezeigt, setzen Sie den Wert publishDir auf. /mnt/workflow/pubdir Um Dateien nach Amazon S3 zu exportieren, müssen sich die Dateien in diesem Verzeichnis befinden.

 nextflow.enable.dsl=2
              
  workflow {
    CramToBamTask(params.ref_fasta, params.ref_fasta_index, params.ref_dict, params.input_cram, params.sample_name)
    ValidateSamFile(CramToBamTask.out.outputBam)
  }
  
  process CramToBamTask {
    container "<account>.dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-cloud"
  
    publishDir "/mnt/workflow/pubdir"
  
    input:
        path ref_fasta
        path ref_fasta_index
        path ref_dict
        path input_cram
        val sample_name
  
    output:
        path "${sample_name}.bam", emit: outputBam
        path "${sample_name}.bai", emit: outputBai
  
    script:
    """
        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
    """
  }
  
  process ValidateSamFile {
    container "<account>.dkr.ecr.us-west-2.amazonaws.com/genomes-in-the-cloud"
  
    publishDir "/mnt/workflow/pubdir"
  
    input:
        file input_bam
  
    output:
        path "validation_report"
  
    script:
    """
        java -Xmx3G -jar /usr/gitc/picard.jar \
        ValidateSamFile \
        INPUT=${input_bam} \
        OUTPUT=validation_report \
        MODE=SUMMARY \
        IS_BISULFITE_SEQUENCED=false
    """
  }   

Workflows in CWL schreiben

Workflows, die in Common Workflow Language (CWL) geschrieben wurden, bieten ähnliche Funktionen wie Workflows, die in WDL und Nextflow geschrieben wurden. Sie können Amazon S3 oder HealthOmics Storage URIs als Eingabeparameter verwenden.

Wenn Sie die Eingabe in einer SecondaryFile in einem Unter-Workflow definieren, fügen Sie dieselbe Definition im Haupt-Workflow hinzu.

HealthOmics Workflows unterstützen keine Betriebsprozesse. Weitere Informationen zu Betriebsprozessen in CWL-Workflows finden Sie in der CWL-Dokumentation.

Um eine bestehende CWL-Workflow-Definitionsdatei zur Verwendung zu konvertieren HealthOmics, nehmen Sie die folgenden Änderungen vor:

CWL-Workflows sollten für jeden verwendeten Container definiert werden. Es wird nicht empfohlen, den DockerPull-Eintrag mit einer festen Amazon ECR-URI fest zu codieren.

Im Folgenden finden Sie ein Beispiel für einen in CWL geschriebenen Workflow.

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            
      

Die folgende Datei definiert die copy.cwl Aufgabe.

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

Im Folgenden finden Sie ein Beispiel für einen in CWL geschriebenen Workflow mit einer GPU-Anforderung.

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

Beispiel für eine Workflow-Definition

Das folgende Beispiel zeigt dieselbe Workflow-Definition in WDL, Nextflow und CWL.

Beispiel für eine WDL-Workflow-Definition

Die folgenden Beispiele zeigen private Workflow-Definitionen für die Konvertierung von CRAM zu BAM in WDL. Der CRAM BAM To-Workflow definiert zwei Aufgaben und verwendet Tools aus dem genomes-in-the-cloud Container, der im Beispiel gezeigt wird und öffentlich verfügbar ist.

Das folgende Beispiel zeigt, wie der Amazon ECR-Container als Parameter eingebunden wird. Auf diese Weise können HealthOmics Sie die Zugriffsberechtigungen für Ihren Container überprüfen, bevor der Run gestartet wird.

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

Das folgende Beispiel zeigt, wie Sie angeben, welche Dateien in Ihrem Lauf verwendet werden sollen, wenn sich die Dateien in einem Amazon S3 S3-Bucket befinden.

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

Wenn Sie Dateien aus einem Sequenzspeicher angeben möchten, geben Sie dies wie im folgenden Beispiel gezeigt an, indem Sie den URI für den Sequenzspeicher verwenden.

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

Anschließend können Sie Ihren Workflow in WDL definieren, wie im Folgenden gezeigt.

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