View a markdown version of this page

WDL-Motoränderungsprotokoll für HealthOmics - AWS HealthOmics

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.

WDL-Motoränderungsprotokoll für HealthOmics

Diese Seite enthält das Änderungsprotokoll für die WDL-Engine sowohl für den strikten WDL-Modus als auch für den milden WDL-Modus. In jedem Abschnitt werden neue Funktionen, Verbesserungen und veraltete Funktionen zusammengefasst.

Neue Features und Verbesserungen

In der folgenden Tabelle sind neue Funktionen und Verbesserungen für die WDL-Engine on aufgeführt. HealthOmics

Datum der Änderung Namen ändern Änderungsbeschreibung Empfohlene Aktion
22. September 2026 Konsistente Behandlung von CRLF-Zeilenenden

HealthOmics Die Zeilenenden von trims Windows-style (\r\n) sind in allen Bereichen read_lines() read_tsv() einheitlich und read_map() entsprechen dem Verhalten von Standard-Linux-Tools.

Keine. Es sind keine Workflow-Änderungen erforderlich.
22. September 2026

zip()cross(), und verarbeitet read_tsv() nun Eingaben mit gemischten Typen korrekt. Manuelle Type-Cast-Problemumgehungen können entfernt werden.

Die eingebauten Funktionen zip() und leiten read_tsv() jetzt die cross() Typen ihrer Rückgabewerte korrekt ab. In früheren Versionen konnten diese Funktionen beim Kombinieren gemischter Typen (z. B. Array[String] und Array[Int] in einem zip() Aufruf) zu unerwarteten Typfehlern führen, sodass manuelle Typumwandlungen im WDL-Code erforderlich waren.

Wenn Ihr Arbeitsablauf explizite Typumwandlungen beinhaltet, die hinzugefügt wurden, um Tippfehler vonzip(), oder zu umgehen cross()read_tsv(), können Sie sie entfernen. HealthOmics leitet jetzt automatisch die richtigen Typen ab.

Das Beibehalten vorhandener Typumwandlungen verursacht keine Fehler und beeinträchtigt auch nicht das Workflow-Verhalten.

22. September 2026

basename(path, "")fix gibt den Dateinamen statt einer leeren Zeichenfolge zurück.

basename(path, "")gibt jetzt den Dateinamen zurück.

Zum Beispiel basename("/path/to/file.txt", "") wird "file.txt" anstelle einer leeren Zeichenfolge zurückgegeben.

Durchsuchen Sie Ihre Workflows nach basename(x, "") Anrufen. Falls vorhanden, stellen Sie sicher, dass die Rückgabe des Dateinamens dem erwarteten Verhalten entspricht.

22. September 2026

Float-key Kollisionserkennung in collect_by_key()

collect_by_key()zuvor wurden Float Schlüssel als identisch behandelt, wenn sie mit 6 Dezimalstellen übereinstimmten. Verschiedene Werte wie 0.0000001 und 0.0000002 wurden zu einer Gruppe zusammengefasst.

HealthOmics Erkennt diese Kollision ab dem Änderungsdatum bei der Workflow-Erstellung und schlägt den Workflow mit einem eindeutigen Fehler im GetWorkflow StatusMessage-Feld fehl, anstatt die Ergebnisse zu verwerfen.

Ein Workflow, der zuvor beim Zusammenführen verschiedener Float Schlüssel erfolgreich abgeschlossen wurde, schlägt jetzt mit einem Kollisionserkennungsfehler fehl wie "statusMessage": "(collect_by_key_test.wdl Ln 17 Col 47) No such function: collect_by_key\n Map[Float, Array[String]] collected = collect_by_key(pairs_with_collision)"

Sie können eine der drei Methoden verwenden:

  • StringSchlüssel verwenden: Wechseln Sie Array[Pair[Float, String]] zu Ihren Schlüsselwerten Array[Pair[String, String]] und zitieren Sie sie. Tastenkombinationen sind immer unterschiedlich und schließen das Kollisionsrisiko vollständig aus.

  • IntSchlüssel verwenden: Ändern Sie den Schlüsseltyp, sodass Ihre Gleitkommawerte mit einer Potenz von 10 Array[Pair[Int, String]] multipliziert werden, um die erforderliche Genauigkeit als Ganzzahl beizubehalten.

  • Wenn Float Schlüssel unvermeidlich sind, runden Sie sie zunächst auf eine konsistente Genauigkeit ab, um sicherzustellen, dass jeder Schlüssel wirklich anders ist und keine Daten stillschweigend zusammengeführt werden. Normalisieren Sie jeden Schlüssel, indem Sie ihn round(value * 1000000.0) / 1000000.0 vor der Übergabe an verwenden. collect_by_key()

Demnächst (60 Tage im Voraus ab 22. September 2026)

Die Division mit Gleitkommazahlen (/) gibt Dezimalzahlen zurück, keine gekürzten Ganzzahlen.

Aktuelles Verhalten: Der / Operator für Float Operanden gibt die nächste Ganzzahl zurück. Zum Beispiel gibt er 5.0 / 2 zurück2.0, nicht2.5. Wenn beide Operanden Int (z. B.5 / 2) sind, gibt das Ergebnis 2 zurück.

Kommende Änderung (30. November 2026): Die Float-Division für Float-Operanden wird mit einer Genauigkeit von 16 Dezimalstellen zurückgegeben. Wird nach diesem Datum zurückgegeben2.5, 5.0 / 2.0 150.0 / 7.0 wird 21.428... anstelle eines Integer-Werts zurückgegeben.

Die Genauigkeit des Ergebnisses hängt davon ab, wie es verarbeitet wird: Wenn der Ergebnistyp istFloat, wird der Wert mit einer Genauigkeit von bis zu 16 Dezimalstellen berechnet; wenn das Ergebnis zu a gezwungen wird, wird String es stattdessen mit 6 Dezimalstellen formatiert.

Zum Beispiel 5.0 / 2.0 wird zurückgegeben und 21.4285714285714 als a zurückgegeben2.5, aber 21.428571 wenn es in a Float interpoliert 150.0 / 7.0 wird. String

Int / IntAusdrücke wie 5 / 2 sind nicht betroffen und geben weiterhin 2 zurück.

Um unabhängig von der Engine-Version ganzzahlige Ergebnisse sicherzustellen, schließen Sie die Float-Division in floor() oder ceil() ein:

  • floor(5.0 / 2.0)→ kehrt immer zurück 2

  • ceil(5.0 / 2.0)→ kehrt immer zurück 3

Wenn Ihr Workflow absichtlich Dezimalergebnisse von der Float-Division erwartet, sind keine Änderungen erforderlich. Beim nächsten Divisionsverhalten ab dem 30. November 2026 werden auch Dezimalstellen zurückgegeben.

Hinweis: gibt immer 5/2 noch 2 zurück, da der / Operator auf ganze Zahlen angewendet wird.