Skip to content
Woyce Technologies
AboutTeamCareersContactStart a project →

Digital Twins of the Earth: Kilometre-Scale Climate Simulation

A look at how kilometre-scale digital twins of Earth work, why they represent a step change from traditional climate models, and what they mean for planning around floods, heat, and energy systems.

Digital Twins of the Earth: Kilometre-Scale Climate Simulation — Woyce Technologies

A city planner in Rotterdam asking "will this specific neighborhood flood in a 1-in-100-year storm, given the drainage upgrade we finished last year" cannot get a useful answer from a traditional global climate model. Those models see the whole of the Netherlands as a handful of grid boxes, each one averaging weather over roughly 100 kilometres. A digital twin of Earth is built to answer that planner's question directly, at the scale of streets and storm drains, and to do it inside a system that keeps updating as new observations arrive. That shift — from coarse, averaged projections to living, kilometre-scale simulations — is what people mean when they talk about "digital twins of Earth."

This matters well beyond climate science. Insurers, utilities, infrastructure owners and city governments are all making long-lived investment decisions against climate risk, and coarse regional averages are a weak basis for choosing where to build a substation or how high to raise a flood barrier. This article explains what an Earth digital twin climate model actually is, how the simulation runs and stays synchronised with observations, why it has become feasible now, how businesses and builders can use its outputs, and where the limitations still lie.

What a Digital Twin of Earth Actually Is

The term gets used loosely, so it helps to separate it from two things it is often confused with.

It is not a video-game rendering of the planet. Digital twins of Earth are physics-based numerical models — the same family as weather and climate models — run at much finer spatial resolution and coupled to continuous streams of satellite, ocean buoy, and ground-station data. The "twin" part refers to a goal shared with digital twin development more broadly: a virtual counterpart of the Earth system that mirrors the real one closely enough, and updates fast enough, that you can test interventions against it (a new seawall, a change in land use, a shift in emissions) before committing resources in the real world.

It is also not the same as a single-purpose climate model. Conventional global climate models divide the atmosphere and ocean into a grid of cells roughly 50-100 km on a side and rely on "parameterizations" — statistical shortcuts — to approximate anything smaller than that, including individual thunderstorms, most ocean eddies, and cloud formation. Kilometre-scale digital twins shrink that grid to somewhere between 1 and 10 km, which is fine enough to represent many of those processes explicitly rather than statistically, building on the same underlying techniques covered in how AI weather models work.

The Core Technical Difference: Resolving vs. Parameterizing

This distinction matters more than it sounds like it should, because it changes what the model can and can't be trusted to say.

AspectTraditional climate model (~50-100 km grid)Kilometre-scale digital twin (~1-10 km grid)
Convection (thunderstorms)Parameterized (statistically approximated)Explicitly resolved
Ocean eddiesMostly parameterizedPartially to fully resolved
Extreme rainfall estimatesSystematically underestimatedMuch closer to observed intensity
Compute costRuns on a large workstation clusterRequires exascale supercomputing
Typical outputRegional trends over decadesStreet- or catchment-level events
Update cadenceStatic projection runsContinuously reinitialized with observations

Resolving convection explicitly is the single biggest reason kilometre-scale models produce more believable extreme-rainfall numbers. Coarse models tend to spread heavy rain over too wide an area at too low an intensity, because a 100-km grid cell simply cannot contain the sharp gradient of a real storm cell. That underestimation has been one of the most persistent, well-known blind spots in climate science for decades — kilometre-scale twins are the first practical attempt to close it at scale rather than patch it with statistics.

Two columns: kilometre-scale climate models now resolve convection, ocean eddies and extreme rainfall, while cloud microphysics, land surface and vegetation are still parameterized.

How the Simulation Actually Runs

A useful mental model is three layers stacked on top of each other.

  1. The physics core. A numerical model that solves the equations of fluid motion, thermodynamics, and radiation for the atmosphere and ocean, discretized onto the fine grid. This is computationally the most expensive layer by far — cutting grid spacing in half roughly increases compute cost by a factor of eight to ten once you also shorten the time step to keep the simulation numerically stable.
  2. The data assimilation layer. A continuous stream of observations — satellite radiances, radar, ocean floats, weather stations — is blended into the running simulation so the model's state stays anchored to reality rather than drifting off into its own internally consistent but wrong version of the atmosphere. This is what makes it a "twin" rather than a one-off projection: the simulation is periodically corrected against the real system it represents.
  3. The machine-learning layer. Because running the full physics core at kilometre resolution for every scenario a user might want is still too expensive, most digital twin projects pair the physics model with ML emulators — neural networks trained on the physics model's own output that can approximate its behavior orders of magnitude faster for exploratory "what if" runs, with the full physics model used sparingly to keep the emulator honest.

That third layer is a fairly recent addition, and it is what has made the whole approach practical on anything resembling a usable timescale. Running kilometre-scale physics alone, for every scenario a city or utility wants tested, would consume more supercomputer time than currently exists.

Flow of an Earth digital twin: satellite, radar, ocean and station observations feed data assimilation, which anchors a kilometre-scale physics core whose runs train fast ML emulators.

Where the Observations Come From

The assimilation layer is only as good as what feeds it, and the input list for a modern Earth digital twin is considerably longer than what fed earlier generations of climate models, spanning much of the same earth observation data businesses increasingly use for risk and planning decisions. It typically draws on:

  • Polar-orbiting and geostationary satellites, providing radiance measurements, sea-surface temperature, soil moisture, and vegetation indices across the full globe on a repeating cycle.
  • Weather radar networks, which give near-real-time precipitation intensity at a resolution fine enough to actually validate what the kilometre-scale grid is producing.
  • Ocean observation systems — surface buoys, subsurface floats, and research vessel transects — that constrain the ocean half of the coupled model, which behaves on much slower timescales than the atmosphere but stores the bulk of the system's heat.
  • Ground-based weather stations, still the backbone for near-surface temperature and precipitation verification, despite being unevenly distributed across the globe.
  • Reanalysis datasets, which blend decades of historical observations into a physically consistent record used to initialize and validate long simulation runs.

Fusing all of that into a single, physically consistent model state, on a schedule fast enough to matter operationally, is itself a substantial engineering problem — arguably as hard as the physics simulation itself, and one of the main reasons these systems are built by large institutional consortia rather than individual research groups.

Why This Matters Now

Europe's Destination Earth initiative — a joint effort of the European Space Agency, the European Centre for Medium-Range Weather Forecasts, and EUMETSAT — has been the most visible attempt to build this kind of system at operational scale. Its climate-adaptation digital twin, one of the program's two initial "core" twins (the other focuses on extreme weather), published its system description in 2026, laying out in public detail how the platform combines kilometre-scale physical simulation with continuous data assimilation and impact modeling aimed specifically at adaptation planning — the kind of decisions cities, insurers, and infrastructure operators need to make about where to build, reinforce, or retreat.

That documentation matters because it moves the concept from research demonstration to something closer to reference architecture. When a program of that scale publishes exactly how its assimilation pipeline, coupling between components, and output products are structured, it gives every other national meteorological service, utility, and climate-tech vendor a concrete pattern to build against or compare themselves to, rather than reverse-engineering the approach from conference papers.

It also reflects a broader convergence happening across the field at the same time: national weather agencies, hyperscale cloud providers, and a growing set of climate-tech startups are all racing toward the same kilometre-scale, ML-accelerated architecture — the broader trend covered in AI climate modelling — for the same underlying reason — the applications that matter most economically (insurance pricing, grid planning, flood defense, agricultural risk) all live at a spatial scale that coarse climate models were never designed to serve.

Benefits of Kilometre-Scale Earth Digital Twins

The step from coarse projections to a continuously updated, kilometre-scale twin gives decision-makers several things they didn't have before.

More realistic extremes

Because convection is resolved rather than approximated, heavy rainfall comes out closer to its observed intensity and location. For anyone sizing drainage, setting flood defences, or pricing storm risk, that matters more than any improvement in average temperature trends, since the costly failures are driven by extremes rather than averages.

Answers at the scale decisions are made

A substation, a river catchment, or a city district is far smaller than a 100-km grid cell. Kilometre-scale output lets planners and risk teams ask questions about the assets they actually manage instead of extrapolating from regional averages that hide local variation. Two neighbourhoods a few kilometres apart can face very different heat or flood exposure because of terrain, coastline, or urban form, and coarse models simply can't separate them.

A model that stays anchored to reality

Continuous data assimilation keeps the simulation's state close to what satellites, radar, and stations are observing. That makes the twin useful across time horizons, from upcoming extreme weather to multi-decade adaptation planning, using one consistent architecture instead of separate tools. Users can also see when the model was last corrected against observations, which helps them judge how far to trust a given output.

Room to test interventions before building them

Pairing the physics core with fast ML emulators makes it practical to run many "what if" scenarios: a new seawall, a retention pond, a change in land use. Organisations can compare options against simulated extreme events before committing capital, rather than learning from the first flood after construction.

A shared foundation for a wider ecosystem

When public programmes publish their architecture and outputs, smaller organisations can build sector-specific tools on top instead of running exascale infrastructure. That lowers the barrier for insurers, utilities, and startups to use high-resolution climate information in everyday decisions. It also gives different organisations a common reference, so a utility, an insurer, and a city council discussing the same flood risk can start from the same underlying data.

Earth Digital Twin Use Cases

The shift to kilometre-scale, continuously updated simulation changes what kinds of products and decisions become possible, in a few concrete ways.

Insurance and reinsurance pricing

Flood and wind risk genuinely vary block by block, not just region by region, yet pricing has often relied on broad risk zones. With kilometre-scale hazard data, insurers and reinsurers can move towards structure-level exposure estimates, separating properties on the same street that face very different flood depths. The result is pricing and portfolio limits that better reflect where losses are likely to occur.

Grid stress-testing

Grid operators can stress-test specific substations and transmission corridors against localized heat and storm scenarios instead of relying on state- or country-level climate summaries that mask the local extremes that actually trip equipment — a concern that overlaps with how grid-interactive data centers are being planned around localized capacity constraints. The outcome is a reinforcement plan prioritised by asset-level exposure rather than by average conditions.

Agriculture and supply-chain planning

Agricultural and supply-chain planners get sub-regional projections of growing-season shifts, water stress, and extreme-heat days that align with how farms and logistics networks are actually organized. That supports decisions about crop choice, irrigation investment, and where to hold buffer stock. Logistics teams can also identify which routes and warehouses are most exposed to heat or flooding and plan alternatives before a disruption rather than during one.

Urban flood and heat planning

Urban planners and civil engineers can evaluate specific interventions — a retention pond, a rerouted storm drain, a change in building codes for a particular district — against simulated extreme events before spending capital, the same kind of localized planning question that comes up across broader smart cities work. This is the Rotterdam planner's question from the start of this article, answered at the scale of streets and drains.

Sector-specific climate products

Climate-tech and geospatial startups now have a technical pattern (physics core plus assimilation plus ML emulator) to build lighter-weight, sector-specific twins on top of, rather than needing to operate their own exascale infrastructure — echoing how supply chain digital twins get built on shared infrastructure rather than from scratch.

Practical Implications for Businesses and Builders

None of this requires every organization to build its own kilometre-scale model. The more realistic near-term pattern, similar to how weather forecasting evolved, is a small number of large public and quasi-public providers running the core simulation, with a wider ecosystem of vendors building interpretation layers, APIs, and sector-specific tools on top of the outputs.

That layered pattern is worth spelling out, because it's the part most likely to determine who actually captures value from this technology over the next several years.

LayerWho typically operates itExample function
Core physics simulationNational/multinational agencies, hyperscalersRunning the exascale kilometre-scale model itself
Data assimilation and reanalysisSame institutions, often in partnership with space agenciesFusing satellite, radar, and station data into the model state
ML emulation and downscalingResearch labs, cloud providers, specialist vendorsFast approximate runs for scenario exploration
Sector-specific interpretationStartups, consultancies, in-house data teamsTranslating raw output into insurance pricing, grid stress tests, crop models
End-user decision toolsSoftware vendors, internal product teamsDashboards, APIs, and risk scores non-specialists can act on

Most of the near-term commercial opportunity sits in the bottom two rows. Very few organizations will ever need to touch the physics core directly; the more common path is subscribing to or licensing outputs from a provider like Destination Earth or a national weather service, then building the translation layer that turns kilometre-scale grid data into a number a risk manager or planning department can actually use.

Common Earth Digital Twin Mistakes

Teams building products on top of these systems tend to run into the same few issues.

Treating output as ground truth

A digital twin's output is a simulation with its own error bars, not an observation. Kilometre-scale models are far better than coarse ones at extremes, but presenting a single run's flood depth as a fact invites bad decisions and, later, lost credibility. Downstream products should carry the uncertainty through to the person making the decision.

Underestimating downscaling

Kilometre-scale is fine for many uses but still coarser than the meter-scale detail some infrastructure decisions actually need. Drainage design, building-level flood depth, and site engineering often require further downscaling with local terrain and hydrology models, which adds cost and introduces its own errors. Budget for that step rather than assuming the twin's grid is the final answer.

Ignoring the assimilation cadence

A twin that reinitializes against observations every few hours behaves very differently, and is trustworthy over very different timescales, than one that only assimilates data at the start of a run. Using short-range, frequently corrected output for long-range planning, or the reverse, mixes up what each product is designed to say.

Assuming compute costs will collapse

Climate simulation compute scales with physical grid resolution and time-step constraints in ways that don't automatically track the same cost curves as other ML workloads. Business plans that assume kilometre-scale runs on demand will soon be cheap are likely to be disappointed. A more robust plan builds on outputs that public providers already publish.

Leaning on emulators outside their training range

ML emulators make scenario exploration affordable, but they learn from past physics runs. Asking them about genuinely novel extremes, the very events many users care most about, pushes them beyond what they were trained on. Check important emulator results against full physics runs.

Table of four pitfalls for builders using Earth digital twin data, each paired with the fix: keep error bars, budget for downscaling, match trust to assimilation cadence, plan for compute limits.

Earth Digital Twin Best Practices

Organisations using twin outputs in risk, planning, or product work get more reliable results when they follow a few habits.

  • Start from the decision, not the dataset. List the specific decisions that would change with street-level rather than regional data, such as where to raise a barrier or which substation to reinforce, and pull only the variables and horizons those decisions need.
  • Work with ensembles and ranges. Use multiple runs or scenarios and report a range of outcomes, not a single number. Decision-makers should see how much the answer moves between plausible futures.
  • Validate against local observations. Before acting on twin output, compare it with your own records: gauge readings, past flood extents, outage logs. Local checks reveal biases a global validation study won't show.
  • Match the product to the time horizon. Use frequently assimilated output for near-term operational decisions and long-run projections for adaptation planning, and label which is which in every tool you build.
  • Plan downscaling explicitly. Where decisions need meter-scale detail, budget for a downscaling step with local terrain, drainage, and land-use data, and document its assumptions.
  • Combine climate signal with your own asset data. Twin output becomes useful when joined to asset locations, values, and vulnerabilities. Invest in that integration layer, since it's where most of the practical value sits and where your organisation's own knowledge adds most.
  • Track provenance and versions. Record which model version, scenario, and data release fed every result, so analyses can be reproduced and updated when new runs are published.
  • Communicate uncertainty in plain language. Explain limits to non-specialist stakeholders up front, so a sharper simulation isn't mistaken for a guarantee. A short note on what the model resolves, what it still approximates, and how it was checked locally goes a long way.

Real Limitations and Open Questions

Kilometre-scale resolution solves the convection problem, but it does not solve climate modeling. A few limitations are worth being explicit about, because marketing language around "digital twins" tends to elide them.

Resolution is not accuracy everywhere. Finer grids resolve convection and much ocean-eddy activity, but processes like cloud microphysics, land-surface interactions, and vegetation response still rely on parameterization even at 1-10 km, because the underlying physical processes happen at scales smaller than that. A kilometre-scale model is a large step forward on some sources of error and essentially unchanged on others.

Compute cost is the binding constraint, not ambition. Running these simulations at genuinely global, genuinely kilometre-scale, genuinely long-time-horizon settings requires supercomputing resources that only a handful of institutions in the world currently operate. That scarcity shapes who gets to run the core simulations and how often — most organizations will consume outputs rather than run the model themselves.

ML emulators inherit the biases of their training data. Using machine learning to approximate expensive physics runs is what makes exploratory, scenario-based use practical, but an emulator is only as trustworthy as the physics-model runs it was trained on, and it can degrade under conditions — genuinely novel extremes, for instance — that differ from what it saw in training.

Validation lags capability. Kilometre-scale simulation of the full globe over multi-decade horizons is new enough that the community is still building the historical record of comparisons needed to say precisely how much better these models are, region by region, than their coarser predecessors. Early results on extreme rainfall are promising; a full accounting across all variables and regions is still in progress.

Access and interpretation are unresolved policy questions. A model this detailed can, in principle, tell a specific property owner or a specific insurer things that a coarse regional model never could. Who gets access to that resolution of information, on what terms, and how it should be priced or regulated, is an open question the underlying science doesn't answer.

What to Watch Next

A few developments will indicate how quickly this moves from demonstration to standard infrastructure.

  1. Operational uptime and update cadence of public twins like Destination Earth's — whether the system runs as a continuously maintained service or as periodic large-scale experiments.
  2. Third-party validation studies comparing kilometre-scale twin outputs against ground-truth observations across regions and hazard types, not just the flagship extreme-rainfall case.
  3. Commercial API layers emerging on top of public twin data, similar to how weather-API companies built businesses on top of national forecasting agencies' raw model output.
  4. Convergence or divergence between national efforts — whether the US, China, and other major economies converge on similar architecture to Destination Earth or pursue distinct approaches, which will affect interoperability of climate risk data globally.
  5. Cost curves for exascale climate compute — whether specialized hardware and further ML-emulation advances bring the cost of kilometre-scale simulation down enough for smaller institutions to run regional twins independently.

Teams evaluating how kilometre-scale climate data could inform product, infrastructure, or risk decisions can find hands-on help from Woyce Technologies.

FAQ

What is a digital twin of Earth?

It's a physics-based simulation of the atmosphere and ocean, run at much finer spatial resolution than traditional climate models (typically 1-10 km versus 50-100 km) and continuously updated with real observational data, so it stays synchronized with the actual state of the planet rather than producing a single static projection.

How is this different from a regular weather forecast?

Weather forecasts use similarly fine-resolution models but over short timescales, typically days to two weeks. Digital twins of Earth are designed to support both short-term forecasting and longer climate-adaptation planning, using the same underlying architecture across those different time horizons. They also emphasise interactive "what if" questions, such as testing how a new seawall or land-use change would alter local flood risk, which a standard forecast is not built to answer.

Why does kilometre-scale resolution matter for climate risk?

Extreme weather events like thunderstorms and heavy rainfall happen at scales smaller than the grid cells used in older climate models, which forced those models to statistically approximate rather than directly simulate them. Kilometre-scale resolution lets many of these processes be simulated explicitly, producing extreme-event estimates that better match what's actually observed.

Is Destination Earth the only project doing this?

No. Destination Earth is the most publicly documented European effort, but national weather and climate agencies, hyperscale cloud providers, and climate-tech companies elsewhere are pursuing similar kilometre-scale, ML-accelerated architectures, since the same underlying compute and data-assimilation techniques apply regardless of who operates the system. Machine-learning weather models from research labs and technology companies are also narrowing the gap, and many of these efforts share data and methods through the scientific community.

Do businesses need to run their own digital twin?

Almost none will need to run the core physics simulation themselves — that requires exascale computing resources concentrated in a small number of institutions. Most organizations will instead consume outputs and build sector-specific tools, dashboards, or risk models on top of data produced by public or commercial twin providers. The practical skill is integrating those outputs with your own asset, location and financial data so that the climate signal turns into decisions.

What are the biggest limitations of these models right now?

Compute cost, incomplete validation across regions and variables, and the fact that some physical processes — cloud microphysics and land-surface interactions among them — are still statistically approximated even at kilometre resolution. Treating twin outputs as certainty rather than as a much-improved simulation is the most common misuse. Good practice is to use ensembles and ranges, and to check results against local observations before acting on them.

How accurate are kilometre-scale climate simulations compared to older models?

They show meaningful improvement specifically on extremes like heavy rainfall, where coarse models have historically underestimated both intensity and localization. Accuracy gains on other variables — average temperature trends, for example — are more incremental, since coarser models already handled large-scale averages reasonably well. Even with these gains, outputs are still best treated as ranges rather than certainties and checked against local observations.

Conclusion

Traditional climate models were built to answer global questions, so they average weather over grid cells tens of kilometres wide. That leaves a gap for anyone who needs to know what happens to a specific district, river catchment or power line. Kilometre-scale digital twins of Earth close much of that gap by simulating storms, heavy rainfall and other local processes directly and by staying synchronised with live observations.

For most organisations, the opportunity is not running these models, which requires supercomputing resources held by a handful of institutions, but building on their outputs: risk scoring, asset planning tools and adaptation dashboards that combine twin data with internal data.

The limitations deserve equal weight. Compute costs are enormous, validation is uneven across regions and variables, some physics is still approximated, and output is a sharper simulation, not a guarantee. Decisions should rest on ranges and ensembles, not single runs.

A useful next step is to list the climate-exposed decisions your organisation makes and identify which ones would change with street-level rather than regional data. If you want to build tools on top of climate and geospatial data, book a call with our team.

WT

Woyce Technologies

AI & Engineering Team · Woyce

Woyce Technologies builds AI chatbots, LLM integrations, voice AI, and full-stack web applications for businesses in the US, UK, Europe & APAC. Based in Rajkot, Gujarat.

READY TO BUILD?

Let's build something
that actually works.

Tell us about your project. We'll be honest about whether we're the right fit — and if we are, we move fast.