Hồ sơ C3S Seasonal

Dataset liệt kê 35 giá trị system nhưng phần lớn đã ngừng chạy. Tiêu chí phân loại ở đây là dữ liệu thực có trong catalogue tại thời điểm 02/09/2026: hệ thống còn sống phải có dữ liệu tới tháng 08/2026 — tháng mới nhất đã được phát hành.

Vừa thay ukmo/604, ukmo/605, jma/3, dwd/21, cmcc/35, meteo_france/8 — vẫn còn số liệu tới 2025 hoặc đầu 2026 nhưng đã bị hệ thống mới thay thế; không dùng cho thiết kế nghiệp vụ.

Lưu trữ ecmwf/4, ecmwf/5, meteo_france/5,6,7, ukmo/12,13,14,15,600–603, dwd/2, cmcc/3, eccc/1,2,3, jma/2 — chỉ còn hữu ích khi cần chuỗi hindcast của phiên bản mô hình cũ.

Có mặt đúng hẹn hay không

“Đang chạy real-time” và “giao đúng hẹn” là hai chuyện khác nhau. Kiểm tra từng phiên bản catalogue của 12 lô gần nhất và hỏi: hệ nào thực sự có mặt với init ngày 01 của đúng tháng đó?

Hai bất thường duy nhất trong 12 tháng:

• Khoảng trống JMA. Lô tháng 2 và tháng 3/2026 chỉ có 9 hệ. JMA CPS3 bị ngừng ngày 21/01/2026 còn CPS4 mãi tháng 4/2026 mới vào — hai tháng không có đóng góp nào từ JMA. Một pipeline đa mô hình cố định 10 thành viên sẽ gãy ở đây.
• Lô tháng 3/2026 đi sớm. Ghi lúc 09/03 15:05 UTC thay vì ngày 10 — sớm một ngày, không phải trễ. Lô ngày 06 tháng đó vẫn đúng hẹn với riêng ECMWF.

Không có lô nào bị trễ trong suốt 12 tháng. Rủi ro thực tế không nằm ở việc chậm giờ mà ở việc một trung tâm biến mất giữa hai phiên bản hệ thống — đã xảy ra với JMA, và sẽ còn xảy ra với UKMO vì nó đổi số hiệu 2–3 lần mỗi năm.

Số ensemble dưới đây là đếm số bản ghi GRIB thực tế từ các yêu cầu tải thử (một điểm lưới, một lead, biến mx2t24), không lấy từ tài liệu. Với hệ thống lagged, con số là số thành viên của một ngày init; ensemble đầy đủ được tạo bằng cách gộp nhiều ngày init liên tiếp.

Cấu trúc cycle và ngày khởi tạo

Đây là chỗ dễ đếm nhầm nhất, vì hai đại lượng khác hẳn nhau cùng bị gọi là “thành viên ensemble”. Kiểm tra khoá dataTime trong từng bản ghi GRIB tách được chúng ra: nếu các bản ghi cùng dataTime và khác number thì đó là nhiễu động của cùng một cycle; nếu khác dataTime thì đó là các cycle khác nhau trong ngày.

Số bản ghi mỗi cycle đã được kiểm chứng là đồng nhất trên mọi ngày init, không riêng ngày 01: ukmo/610 ngày 17/07/2010 vẫn 7 bản ghi và ngày 15/07/2026 vẫn 2; ncep/2 ngày 15/07/2026 vẫn đủ 4 cycle 00/06/12/18 UTC; bom/2 ngày 25/07 cho 3 bản ghi ở hindcast và 11 ở real-time.

UKMO bị chia nhỏ theo số hiệu system

Met Office sinh lại hindcast cho từng phiên bản hệ thống, và số hiệu system đổi ngay giữa năm. Luồng real-time nhảy qua nhiều số hiệu: 603 (T1–T2/2025) → 604 (T2/2025–T2/2026) → 605 (T2–T3/2026) → 610 (T3–T8/2026).

Hệ quả trực tiếp: ukmo/610 mới chỉ có hindcast cho tháng 3 đến tháng 9 (24 ngày init/năm), không phải cả năm.

Muốn chuỗi UKMO đủ 12 tháng thì phải dùng ukmo/604 — đã kiểm chứng có hindcast trọn năm (cả tháng 1 lẫn tháng 7 đều 7 bản ghi), 4 ngày init mỗi tháng, tổng 1.152 cycle độc lập. Cấu hình 7 bản ghi ở hindcast và 2 ở real-time giữ nguyên qua các số hiệu system, nên đổi phiên bản không làm thay đổi cỡ ensemble — chỉ đổi cửa sổ tháng và phiên bản mô hình. Cái giá phải trả là nó không còn khớp với phiên bản đang chạy nghiệp vụ. Với bài toán nắng nóng mùa hè ở Việt Nam thì cửa sổ tháng 3–9 của 610 lại vừa đủ dùng, nên đây là đánh đổi chấp nhận được.

Về độ phân giải không gian

Đây là điểm dễ hiểu nhầm nhất. Độ phân giải gốc của các mô hình cao hơn nhiều — ECMWF SEAS5 chạy ở T_Co319 ≈ 36 km, Met Office ở N216 ≈ 0,83°×0,55°, JMA ở TL319 ≈ 55 km ○ — nhưng CDS không giao lưới gốc. Mọi thứ đã được nội suy về lưới đều trước khi lưu trữ.

Với mô hình AI theo điểm lưới, câu hỏi thực sự là có bao nhiêu mẫu độc lập. Bảng dưới tách ba đại lượng thường bị gộp làm một: ngày init, cycle độc lập (ngày init × số cycle trong ngày — mỗi cycle là một trạng thái khí quyển ban đầu riêng) và tổng lần chạy (các nhiễu động trong cùng một cycle tương quan rất mạnh, không phải mẫu độc lập).

Hai nhóm rõ rệt, đánh đổi ngược chiều nhau:

• Nhóm giàu cycle, nghèo nhiễu động — NCEP (7.008 cycle), BOM (2.808). Đây là nhóm hợp với bài toán phân loại EHD theo điểm lưới, nơi số tình huống khí quyển khác nhau mới là thứ quyết định. NCEP dẫn đầu nhờ 4 cycle mỗi ngày trên chu kỳ 5 ngày liên tục.
• Nhóm nghèo cycle, giàu nhiễu động — ECMWF, Météo-France, CMCC, DWD, ECCC. Chỉ 372–432 cycle nhưng 20–31 bản ghi mỗi cycle, cho phép ước lượng xác suất EHD trực tiếp từ tỷ lệ thành viên vượt ngưỡng thay vì phải học nó.

Đây là điểm mạnh rõ ràng nhất của bộ số liệu. Toàn bộ 10 hệ thống real-time đều cung cấp đầy đủ nhóm biến dưới đây ở bước thời gian 24 giờ, từ lead 24h tới hết hạn dự báo.

C3S phát hành theo lô, mỗi tháng một lần. Với dự báo mùa 6 tháng thì vài ngày trễ không đáng kể, nhưng với bài toán nội mùa 45 ngày thì nó ăn mất phần lead có giá trị nhất. Đây là ràng buộc quyết định toàn bộ thiết kế nghiệp vụ, nên mục này tách riêng phần tài liệu công bố khỏi phần quan sát trực tiếp.

1. Ngày 01, 00 UTCCác hệ thống khởi tạo dự báo. Đây là lead day 0.
2. Ngày 02 – 05Dữ liệu nằm trong thời gian cấm vận. Không truy cập được.
3. Ngày 06, 12:05 UTCECMWF SEAS5.1 lên CDS — và chỉ ECMWF. Đã mất 5,50 ngày lead. ◆
4. Ngày 10, 12:05 UTCChín hệ còn lại lên CDS, cùng lúc với toàn bộ ngày init lagged 02–31 của tháng trước. Đã mất 9,50 ngày lead. ◆

Đo trực tiếp thời điểm dữ liệu lên hệ thống

Không cần suy đoán từ tài liệu. Mỗi lần CDS đăng ký dữ liệu mới, nó sinh lại constraints.json của dataset và ghi vào một object store công khai, giữ nguyên mọi phiên bản cũ kèm dấu thời gian ghi. Liệt kê bucket đó khôi phục được đúng thời điểm từng lô dữ liệu có mặt — không cần API key, không cần chờ.

Biên độ dao động của cả 39 lô chỉ khoảng 30 phút. Đây là lịch đủ ổn định để chốt cron nghiệp vụ.

Cửa sổ lead thực sự khai thác được

Tính theo tuần kể từ ngày khởi tạo: W1 = ngày 1–7, W2 = 8–14, W3 = 15–21, W4 = 22–28, W5 = 29–35, W6 = 36–42.

Vậy bộ số liệu này là subseasonal hay seasonal?

Câu trả lời nằm ở chỗ tách hạn dự báo khỏi tần suất cập nhật. Hai thứ này thường bị gộp làm một, nhưng chỉ một trong hai là ràng buộc thật.

Ba trên bốn tiêu chí đạt. Nên nói bộ này “chỉ dùng cho seasonal” là chưa chính xác — nó có phủ đúng khoảng subseasonal. Cái nó không làm được là cập nhật.

Cách gọi đúng cho bộ số liệu này là “dự báo nội mùa phát hành hằng tháng”. Nó trả lời được câu “sáu tuần tới có đợt nắng nóng nào không”, mỗi tháng một lần. Nó không trả lời được câu “tuần này tình hình thay đổi thế nào so với tuần trước”.

Kiểm tra theo ngưỡng vận hành

Một hệ dự báo nội mùa nghiệp vụ cần thoả đồng thời hai điều kiện, và cả hai đều là ngưỡng cứng chứ không phải mong muốn:

• C1 — Nhịp khởi tạo ≤ 5 ngày. Thưa hơn thì giữa hai lần cập nhật, bản dự báo đang dùng đã trôi quá xa so với trạng thái khí quyển thực.
• C2 — Độ trễ số liệu ≤ 5 ngày. Trễ hơn thì phần lead có kỹ năng cao nhất đã bị ăn mất trước khi dùng được.

Cột thứ hai và thứ ba là chỗ đáng chú ý nhất. Bốn hệ — NCEP, UKMO, JMA, BOM — sản xuất ở nhịp vượt xa ngưỡng C1, nhưng nhịp giao qua CDS vẫn là 30 ngày. Nút thắt nằm ở khâu phát hành của C3S, không nằm ở mô hình. Muốn khai thác nhịp thật thì phải lấy dữ liệu từ trung tâm gốc.

Những đường thực sự đáp ứng được cả hai ngưỡng

Kiểm tra lại bất cứ lúc nào

Lịch này là thông báo từ tháng 3/2023 và C3S đã từng đổi. Script info/release_schedule.py dựng lại toàn bộ lịch phát hành từ object store, chạy lúc nào cũng cho kết quả cập nhật tới lô gần nhất:

python release_schedule.py                 # lich + thong ke do tre
python release_schedule.py --diff          # tung lo mang them nhung gi
python release_schedule.py --dataset seasonal-monthly-single-levels

Không cần API key, không cần cron, không phải chờ tháng sau — bucket đã giữ sẵn 63 phiên bản catalogue từ tháng 3/2024. Nên chạy lại mỗi khi thiết kế lại lịch nghiệp vụ, hoặc khi một trung tâm nâng cấp hệ thống.

Sáu trên mười hệ thống thay đổi kích thước ensemble giữa chế độ hindcast và chế độ real-time. Nếu huấn luyện mô hình trên hindcast rồi áp dụng nguyên xi cho real-time, phân bố của mọi đặc trưng dạng ensemble — độ tán, phân vị, tỷ lệ thành viên vượt ngưỡng — sẽ lệch một cách hệ thống.

Hai cách xử lý, chọn theo mục tiêu:

• Cắt bớt về mẫu số chung. Chỉ dùng N thành viên đầu ở cả hai chế độ (ECMWF: 25). Đơn giản, an toàn, nhưng bỏ phí một nửa thông tin real-time.
• Dùng đặc trưng bất biến theo cỡ ensemble. Trung bình, độ lệch chuẩn hiệu chỉnh bậc tự do, phân vị nội suy, tỷ lệ vượt ngưỡng. Tránh mọi đặc trưng phụ thuộc thứ hạng thô hay giá trị cực trị của ensemble, vì cực trị phụ thuộc trực tiếp vào số thành viên.

Nếu chọn ukmo/610, chú ý chiều thay đổi bị đảo: hindcast nhiều thành viên hơn real-time trên mỗi ngày init. Bù lại bằng cách gộp lagged nhiều ngày init trong real-time để đạt cỡ ensemble hiệu dụng tương đương.

Toàn bộ bảng cấu hình dựng lại được từ hai lệnh. Lấy catalogue để biết năm, tháng, ngày init và lead khả dụng:

curl -sSL "https://cds.climate.copernicus.eu/api/catalogue/v1/collections/\
seasonal-original-single-levels/constraints.json" -o cons.json

Đếm số thành viên ensemble bằng một yêu cầu tải cực nhỏ — một điểm lưới, một lead, một biến — rồi đếm số bản ghi GRIB:

import cdsapi
cdsapi.Client().retrieve("seasonal-original-single-levels", {
    "originating_centre": "ecmwf", "system": "51",
    "variable": ["maximum_2m_temperature_in_the_last_24_hours"],
    "year": ["2026"], "month": ["07"], "day": ["01"],
    "leadtime_hour": ["24"], "data_format": "grib",
    "area": [22, 105, 21, 106],          # 1 gridpoint
}, "probe.grib")

# grib_ls -p dataDate,dataTime,number probe.grib
#
#   ecmwf/51 -> 51 ban ghi, dataTime deu = 0, number = 0..50
#               => 1 cycle/ngay, 51 nhieu dong
#   ncep/2   ->  4 ban ghi, dataTime = 0/600/1200/1800, number deu = 0
#               => 4 cycle/ngay, moi cycle 1 lan chay

Khoá dataTime là thứ phân biệt cycle với nhiễu động — bỏ qua nó là nguồn gốc của việc đếm nhầm NCEP thành “ensemble 4 thành viên”. Ngày init hợp lệ của mỗi tháng cũng phải đọc từ constraints.json chứ không suy ra được, vì NCEP và JMA có ngày init trôi theo lịch:

import json
cons = json.load(open("cons.json"))
V = "maximum_2m_temperature_in_the_last_24_hours"

def init_days(centre, system, year, month):
    d = set()
    for b in cons:
        if (V in b["variable"] and centre in b["originating_centre"]
                and system in b["system"] and year in b["year"]
                and month in b["month"]):
            d |= set(b["day"])
    return sorted(d)

init_days("ncep", "2", "2010", "01")   # ['01','06','11','16','21','26','31']
init_days("ncep", "2", "2010", "02")   # ['05','10','15','20','25']

Hàng đợi CDS chỉ chạy một job mỗi lần cho mỗi tài khoản, nên 20 lần thăm dò mất khoảng 20 phút. Mỗi file chỉ vài KB.