Spesifikasi definisi alur kerja WDL

Topik berikut memberikan detail tentang jenis dan arahan yang tersedia untuk definisi alur kerja WDL di HealthOmics.

Konversi tipe implisit dalam WDL lunak

HealthOmics mendukung konversi tipe implisit dalam file input.json dan definisi alur kerja. Untuk menggunakan pengecoran tipe implisit, tentukan mesin alur kerja sebagai WDL lunak saat Anda membuat alur kerja. WDL lenient mencakup semua fitur WDL standar ditambah perilaku kompatibilitas tambahan yang dirancang untuk alur kerja yang dimigrasikan dari Cromwell. Ini mendukung arahan Cromwell pelanggan dan beberapa logika yang tidak sesuai.

WDL lenient mendukung konversi tipe untuk item berikut dalam daftar pengecualian terbatas WDL: https://github.com/openwdl/wdl/blob/wdl-1.1/SPEC.md#-limited-exceptions

Untuk menggunakan pengecoran tipe implisit, tentukan mesin alur kerja sebagai WDL_LENIENT saat Anda membuat alur kerja atau versi alur kerja.

Di konsol, parameter mesin alur kerja diberi nama Langu age. Di API, parameter mesin alur kerja diberi nama engine. Untuk informasi selengkapnya, lihat Buat alur kerja pribadi atau Buat versi alur kerja.

Definisi namespace di input.json

HealthOmics mendukung variabel yang sepenuhnya memenuhi syarat di input.json. Misalnya, jika Anda mendeklarasikan dua variabel input bernama number1 dan number2 dalam alur kerja: SumWorkflow

workflow SumWorkflow {
  input {
    Int number1
    Int number2
  }
}   

Anda dapat menggunakannya sebagai variabel yang sepenuhnya memenuhi syarat di input.json:

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

Tipe primitif di WDL

Tabel berikut menunjukkan bagaimana input dalam WDL memetakan ke tipe primitif yang cocok. HealthOmics menyediakan dukungan terbatas untuk paksaan tipe, jadi sebaiknya Anda menetapkan tipe eksplisit.

Jenis kompleks dalam WDL

Tabel berikut menunjukkan bagaimana input dalam WDL memetakan ke tipe JSON kompleks yang cocok. Tipe kompleks dalam WDL adalah struktur data yang terdiri dari tipe primitif. Struktur data seperti daftar akan dikonversi ke array.

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

Arahan dalam WDL

HealthOmics mendukung arahan berikut di semua versi WDL yang HealthOmics mendukung.

Konfigurasikan sumber daya GPU

HealthOmics mendukung atribut runtime acceleratorType dan acceleratorCount dengan semua instans GPU yang didukung. HealthOmics juga mendukung alias bernama gpuType dangpuCount, yang memiliki fungsi yang sama dengan rekan-rekan akseleratornya. Jika definisi WDL berisi kedua arahan, HealthOmics menggunakan nilai akselerator.

Contoh berikut menunjukkan cara menggunakan arahan ini:

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

Konfigurasikan percobaan ulang tugas untuk kesalahan layanan

HealthOmics mendukung hingga dua percobaan ulang untuk tugas yang gagal karena kesalahan layanan (kode status HTTP 5XX). Anda dapat mengonfigurasi jumlah maksimum percobaan ulang (1 atau 2) dan Anda dapat memilih keluar dari percobaan ulang untuk kesalahan layanan. Secara default, HealthOmics coba maksimal dua kali percobaan ulang.

Contoh berikut diatur preemptible untuk memilih keluar dari percobaan ulang untuk kesalahan layanan:

{
  preemptible: 0 
}     

Untuk informasi selengkapnya tentang percobaan ulang tugas di HealthOmics, lihatTugas Mencoba Ulang.

Konfigurasikan percobaan ulang tugas untuk kehabisan memori

HealthOmics mendukung percobaan ulang untuk tugas yang gagal karena kehabisan memori (kode keluar wadah 137, kode status HTTP 4XX). HealthOmics menggandakan jumlah memori untuk setiap upaya coba lagi.

Secara default, HealthOmics tidak mencoba lagi untuk jenis kegagalan ini. Gunakan direk maxRetries tif untuk menentukan jumlah maksimum percobaan ulang.

Contoh berikut ditetapkan maxRetries ke 3, sehingga HealthOmics mencoba maksimal empat upaya untuk menyelesaikan tugas (upaya awal ditambah tiga percobaan ulang):

runtime {
    maxRetries: 3
}     

Konfigurasikan kode pengembalian

A tribut returnCodes menyediakan mekanisme untuk menentukan kode pengembalian, atau sekumpulan kode pengembalian, yang menunjukkan keberhasilan eksekusi tugas. Mesin WDL menghormati kode pengembalian yang Anda tentukan di bagian runtime definisi WDL, dan menetapkan status tugas yang sesuai.

runtime {
    returnCodes: 1
}     

HealthOmics juga mendukung alias bernama continue OnReturnCode, yang memiliki kemampuan yang sama dengan Retur nCodes. Jika Anda menentukan kedua atribut, HealthOmics menggunakan nilai ReturnCodes.

Bentuk disk WDL yang didukung

HealthOmics menerima semua formulir standar WDL 1.1disks. Jalur pemasangan dan penentu tipe disk (SSD,HDD) diabaikan — hanya ukuran numerik yang diekstraksi. Jika beberapa entri dideklarasikan, ukuran dijumlahkan menjadi satu /tmp alokasi.

HealthOmics memasang semua penyimpanan sementara di. /tmp Jika definisi alur kerja Anda mendeklarasikan beberapa disks entri, ukuran akan dijumlahkan dan total disediakan sebagai satu /tmp volume. Untuk informasi selengkapnya tentang atribut disks runtime WDL, lihat spesifikasi WDL 1.1.

Atribut runtime lain yang didukung

Konfigurasikan batas waktu tingkat tugas dengan atribut runtime OmicsTimeOut

HealthOmics menyediakan omicsTimeout atribut khusus untuk mengatur durasi tugas maksimum dalam alur kerja Anda. Tentukan durasi batas waktu sebagai bilangan bulat (detik) atau string menggunakan satu atau lebih unit berikut:s,, mh, ataud. Sebagai contoh, "40m", "1h30m", atau "1m3s".

Contoh berikut menunjukkan cara menentukan omicsTimeout atribut di runtime bagian definisi tugas WDL. Contoh ini menetapkan batas waktu 40 menit.

    runtime {
        omicsTimeout: "40m"
    }

HealthOmics menyediakan dukungan berikut untuk atribut omicsTimeout runtime WDL:

Semua lari memiliki durasi maksimum yang kuota yang dapat disesuaikan dalam HealthOmics kuota layanan kontrol. Anda dapat meminta kenaikan kuota ini.

Metadata tugas di WDL

HealthOmics mendukung opsi metadata berikut untuk tugas WDL.

Nonaktifkan caching tingkat tugas dengan atribut volatile

A tribut volatile memungkinkan Anda menonaktifkan cache panggilan untuk tugas-tugas tertentu dalam alur kerja WDL Anda. Ketika tugas ditandai sebagai volatile, itu akan selalu dieksekusi dan tidak pernah menggunakan hasil cache, bahkan ketika caching diaktifkan untuk dijalankan.

Tambahkan atribut volatile ke bagian meta definisi tugas Anda:

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

Contoh definisi alur kerja WDL

Contoh berikut menunjukkan definisi alur kerja pribadi untuk mengonversi dari CRAM ke BAM dalam WDL. Alu CRAM r BAM kerja to mendefinisikan dua tugas dan menggunakan alat dari genomes-in-the-cloud wadah, yang ditunjukkan dalam contoh dan tersedia untuk umum.

Contoh berikut menunjukkan cara memasukkan wadah Amazon ECR sebagai parameter. Ini memungkinkan HealthOmics untuk memverifikasi izin akses ke wadah Anda sebelum memulai menjalankan proses.

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

Contoh berikut menunjukkan cara menentukan file mana yang akan digunakan dalam proses Anda, saat file berada di bucket 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"
}       

Jika Anda ingin menentukan file dari penyimpanan urutan, tunjukkan seperti yang ditunjukkan dalam contoh berikut, menggunakan URI untuk penyimpanan urutan.

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

Anda kemudian dapat menentukan alur kerja Anda di WDL seperti yang ditunjukkan pada contoh berikut.

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