Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Besonderheiten der CWL-Workflow-Definition

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.

Es hat sich bewährt, für jeden Container, den Sie verwenden, einen separaten CWL-Workflow zu definieren. Wir empfehlen, den DockerPull-Eintrag nicht mit einer festen Amazon ECR-URI fest zu codieren.

Konvertieren Sie die zu verwendenden CWL-Workflows HealthOmics

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

Deaktivieren Sie die Aufgabenwiederholung mit omicsRetryOn5xx

HealthOmics unterstützt Aufgabenwiederholungen, wenn die Aufgabe aufgrund von Dienstfehlern fehlgeschlagen ist (5XX-HTTP-Statuscodes). Standardmäßig werden bis zu zwei Wiederholungen einer HealthOmics fehlgeschlagenen Aufgabe versucht. Weitere Hinweise zur Wiederholung von Aufgaben finden Sie unter HealthOmics. Die Aufgabe wird erneut versucht

Um die Wiederholung von Aufgaben bei Servicefehlern zu deaktivieren, konfigurieren Sie die omicsRetryOn5xx Anweisung in der Workflow-Definition. Sie können diese Direktive unter Anforderungen oder Hinweisen definieren. Wir empfehlen, die Direktive als Hinweis für die Portabilität hinzuzufügen.

requirements:
  ResourceRequirement:
    omicsRetryOn5xx: false

hints:
  ResourceRequirement:
    omicsRetryOn5xx: false     

Anforderungen haben Vorrang vor Hinweisen. Wenn eine Aufgabenimplementierung einen Ressourcenbedarf in Hinweisen enthält, der auch durch Anforderungen in einem umschließenden Workflow bereitgestellt wird, haben die einschließenden Anforderungen Vorrang.

Wenn dieselbe Aufgabenanforderung auf verschiedenen Ebenen des Workflows vorkommt, wird der spezifischste Eintrag von HealthOmics verwendet requirements (oderhints, falls es keine Einträge in gibt). requirements Die folgende Liste zeigt die Rangfolge, in der die HealthOmics Konfigurationseinstellungen angewendet werden, von der niedrigsten zur höchsten Priorität:

Das folgende Beispiel zeigt, wie die omicsRetryOn5xx Direktive auf verschiedenen Ebenen des Workflows konfiguriert wird. In diesem Beispiel hat die Anforderung auf Workflow-Ebene Vorrang vor den Hinweisen auf Workflow-Ebene. Die Anforderungskonfigurationen auf Aufgaben- und Schrittebene haben Vorrang vor den Hinweiskonfigurationen.

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      
    

Beispiele

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