Weather

https://blog-assets.ringsaturn.me/pic/2026/2026-10-12-arxan-fire/arxan-fire-spread-960.en.mp4 VIIRS 375 m active fire (NASA) detections accumulated hour by hour, 10-08 11:00 to 10-16 14:00 UTC+8, one frame per hour. Bright yellow: detected within 3 h; orange: 3–12 h; dark red: earlier. Lower right: total FRP per overpass. At the end the 10-16 NOAA-21 false colour (M11-I2-I1) fades in, where dark red is burn scar; yellow circles are MODIS fire detections (FIRMS) of the new fire south of the main fire on 10-15. Base map: Copernicus DEM hillshade; dashed line: border (OSM). Overpass times are L2 granule start times, a few minutes earlier than the FIRMS acquisition times used in the text and in the other fire-detection figures; the first detection, for example, is at 12:06 here and at 12:08 in FIRMS. Around noon on 2026-10-08, a fire started near Nömrög (Нөмрөг; also romanised Numrug or Nomrog) in Khalkhgol soum, Dornod Province, Mongolia, about 27 km from the China–Mongolia border. Two geostationary satellites put the ignition between 11:41 and 11:51, the first FY-4C detection published by the National Satellite Meteorological Centre (NSMC) was at 11:501, and Mongolia’s National Emergency Management Agency (NEMA) received the call at 11:552. The Mongolian telecom operator Mobicom is a subsidiary3 of Japan’s KDDI. Its statement of 10-124 says that a vehicle caught fire while a group was handing over telecommunications work at border outposts and the Sümber border crossing and surveying local conditions, and that this started the grassland fire. The statement5 of Mongolia’s General Authority for Border Protection says the vehicle caught fire “due to the carelessness of citizens who entered the border zone”. The Dornod Province police department began investigating6 the cause of the fire on 10-17; as of 10-25 no findings have been published. The fire peaked twice, on the evening of 10-10 and during the day on 10-11, and on 10-11 and 10-12 its front reached the border west of Arxan City, Hinggan League, Inner Mongolia. After a cold front passed early on 10-12 the fire weakened. Residual burning continued intermittently inside the Mongolian fire area until the afternoon of 10-15, after which the satellites detected no more fire pixels; NEMA declared the fire fully extinguished at 07:00 on 10-167. From the afternoon of 10-22 several new fires started in western Hulunbuir and eastern Mongolia, at least 172 km from this burn scar and unrelated to this fire; see New fires on 10-22. The burned area is about 4,900 km². Montsame, quoting the Mongolian emergency services, reports that about 80% of the Nömrög Strictly Protected Area burned8; the preliminary estimate of Mongolia’s Ministry of Environment and Climate Change on 10-20 is 528,765.5 hectares, of which 468,965.7 hectares, or 79.8% of the protected area, lie inside it9. On 10-28 the ministry set the official figure, from Sentinel-2 10 m imagery of 10-25, at 504,960.4 hectares in total (about 5,050 km²), of which 448,993.6 hectares, or 76.4% of the protected area, lie inside it10. China deployed first more than 2,00011 and then more than 3,40012 personnel along the border, and its reports say the fire did not cross the border line. The satellites show no contiguous burned area extending into China. On the Sentinel-2 scenes of 10-20, 54–62 km² burned on the Chinese side within 2 km of the border, of which 34–38 km² lies within 0.5 km of the line, consistent with the hundred-metre buffer that Hinggan League counter-burned (对冲点烧, backburning toward the oncoming fire) along the border from 10-11. The parts more than 1 km from the line are concentrated in three sections: about 21 km² in the south section on the East Ujimqin Banner side, up to 3.6 km from the line, whose main patch is consistent with the backburning operations that the East Ujimqin Banner authorities reported publicly; about 11.5 km² west of Arxan, up to 2.2 km, where VIIRS fire pixels crossed the border at midday on 10-12; and about 6 km² on the east front, up to 1.7 km. The imagery cannot distinguish fire that crossed from Mongolia from backburning on the Chinese side. Smoke reached Hailar on 10-11 and Baicheng on 10-12, and the PM2.5 peaks in the two cities on those days contain smoke from this fire. This post records the accounts from the parties involved, the ignition time and the spread, the weather at the fire area, the burned area, the assessment of burning near the border, and the smoke transport. The confidence in each conclusion is listed at the end. ...

Today I ran a 12-hour simulation around Mount Fuji at 500 m resolution in the WOOF web app from Recast Systems, with boundary conditions from GFS 0.25°. I think the result is excellent: it ran on an RTX PRO 6000 (on-demand instance), took 11 minutes 40 seconds and cost 1.34 USD in total. Video demo below: https://blog-assets.ringsaturn.me/pic/2026/2026-10-10-recast-gpu-woof/recast-area-tsk-2026-10-10-1600gmt%2B9-mobile.mp4 This result surprised me somewhat. It means that in the future, if higher-resolution real-time observations become available (satellite remote sensing in particular), they could first be used to apply rapid rolling corrections to the assimilation output of large-scale models, and the corrected fields could then drive a model like WOOF, a port of WRF-ARW to the GPU. Local weather forecasting and hazard warning could improve as a result, forecasts of severe convective weather most of all. ...

Verifying the 6.5 K/km elevation correction of GFS and ECMWF 2 m temperature against about 3000 stations over four seasons, and the pressure-level method with a decaying near-surface anomaly that xue now uses

In the previous post, 雪：更快速更流畅的气象数据动画 (Chinese), I packed forecast variables into a single-file container, .xue, which the browser read frame by frame through its index. For two variables of one GFS run, per-frame precolored PMTiles (zoom 0–4) came to 3,205.87 MB, the source GRIB2 was 137.73 MB, and .xue brought it down to about 65 MB. The size problem was solved. The problem with a custom container is that only its own decoder can read it. ...

Picking up where I left off: earlier this year I built a project called sitian, which analyzes weather processes from a sequence of synoptic charts over a period of time. Using it myself and backtesting it against historical weather, I found that combined analysis across multiple data sources did not work well. Take one example: a region is about to be affected by a typhoon, and the relevant data includes: Radiosonde soundings around the typhoon’s track Model forecast data Satellite observations Radar data Surface observations as supporting context The previous setup made it awkward to handle fairly complex combinations of input data. It also meant maintaining and integrating several data sources. So the sitian project has, in practice, stopped running. ...

There is no built-in UV index in the original’s NOAA’s GFS data. However, Open Meteo provides UV index forecast in GFS’s data API and other weather models. That’s very interesting because it means that Open Meteo is doing some additional processing on top of the raw GFS data to derive the UV index. So I dig into it’s source code to see how they are calculating the UV index: 1 2 3 4 5 6 7 8 9 10 11 // https://github.com/open-meteo/open-meteo/blob/bf9577492dde460f9428d5d892b43bab9faa93ef/Sources/App/Gfs/GfsVariableDownloadable.swift#L473-L477 func multiplyAdd(domain: GfsDomain) -> (multiply: Float, add: Float)? { switch self { // ... case .uv_index, .uv_index_clear_sky: // UVB to etyhemally UV factor 18.9 https://link.springer.com/article/10.1039/b312985c // 0.025 m2/W to get the uv index // compared to https://www.aemet.es/es/eltiempo/prediccion/radiacionuv return (18.9 * 0.025, 0) // ... That make things simple. Just use existing GFS UVB data and apply a simple linear transformation to get the UV index.

Some historical fragments discovered while researching.