Written by: Olivier Lam, Physical AI Team, Jua.ai AG | Last updated: June 29, 2026
Key Takeaways for Energy Trading Teams
- Physics-informed AI models like EPT-2 beat traditional ECMWF HRES forecasts on key energy variables across all lead times, improving accuracy for wind, temperature, and solar radiation.
- Jua runs complete about 2.5 hours ahead of competing operational forecasts, so traders act on fresher data and gain a timing edge.
- EPT-2e ensemble forecasts outperform the 50-member ECMWF ENS mean on RMSE and CRPS, giving better-calibrated probabilities for tail-risk events.
- The Jua platform exposes 25+ models through a single REST API and Python SDK with Apache Arrow support, cutting integration time from quarters to days for quant teams.
- Book a demo with Jua to benchmark EPT-2 against your current forecast provider and see the full energy-trading stack in action.
Where Physics-Informed AI Fits in the Forecasting Landscape
Energy markets rely on three main categories of atmospheric forecast today. Legacy numerical weather prediction (NWP) uses three-dimensional grid cells and solves differential equations inside each one. This method has led the field for forty years. A single NWP simulation consumes approximately 8,400 kWh and costs €1,000–€20,000 to run on high-performance computing infrastructure, which caps update frequency at two to four global forecasts per day. That hard compute ceiling has barely moved in four decades.
Pure machine learning research outputs such as Google DeepMind GraphCast, Microsoft Aurora, and ECMWF AIFS form the second category. These models usually ship as papers and raw model files. They rarely include productised ensembles, hindcast archives, or operational refresh schedules. Quant teams that subscribe to them must build ingestion pipelines, ensemble logic, and benchmarking harnesses themselves.
Physics-informed foundation models form the third category. The Earth Physics Transformer (EPT) family, the general spatiotemporal transformer foundation model at the core of Jua for Energy, learns conservation laws governing mass, momentum, and energy directly from observational data. A single EPT-2 inference runs on a single GPU in minutes at approximately 0.25 kWh and $0.20–$15, which is roughly four orders of magnitude cheaper than an equivalent NWP simulation. That cost asymmetry makes hourly updates economically viable at production scale.
How the Jua for Energy Stack Is Structured
Jua for Energy is structured as a four-layer trading stack: the EPT foundation model, the Athena agent, a unified data surface, and developer interfaces. This architecture turns raw physics-informed forecasts into a workflow-ready trading system.
The foundation model layer is the EPT family. EPT-2 is the deterministic flagship and produces global forecasts with a native resolution reaching 5 km in Europe (EPT-2 HRRR) and a 20-day horizon. EPT-2e is the ensemble variant and runs 30 members with a 60-day horizon. EPT-2 RR is the rapid-refresh variant and updates up to 24 times per day, which removes stale numbers between traditional NWP runs. EPT-2 is a general physics foundation model by architecture, not an atmospheric model. The atmosphere is the first physical system it has been fine-tuned for, so the architecture learns physics and the domain remains a variable.
The agent layer is Athena. Athena is an AI agent instrumented with the Jua for Energy tool surface, which includes forecast queries, model benchmarks, backtests, and widget generation. A trader types a natural-language objective. Athena plans, calls tools, evaluates intermediate outputs, and returns a deliverable. Typical queries resolve in about 90 seconds, and backtests in about 5 minutes. Trading houses and quant desks describe Athena as another headcount, for free.
The unified data surface puts 25+ models on a single platform with a shared schema. This includes 10 proprietary EPT-family models plus 15 third-party NWP and AI models such as ECMWF HRES, ECMWF ENS, NOAA GFS, Microsoft Aurora, and GFS GraphCast. Power forecasts cover solar, wind onshore, wind offshore, load, and residual load across five European countries. Actual-generation data refreshes every 15 minutes.
The developer interface layer exposes the full model fleet through a REST API and the jua Python SDK on PyPI. Apache Arrow support handles large payloads, and hindcast access supports backtesting.
Strategic Trade-offs That Shape Evaluation
Evaluating physics-informed AI models requires balancing three core trade-offs, and together they map to the four evaluation dimensions in the conclusion: model capability, integration fit, operational usability, and reliability.
Accuracy versus speed. For meteorologists at regulated utilities, accuracy is the primary gate and defines model capability. EPT-2 beats ECMWF HRES on every lead time across 0–240 hours, evaluated against more than 10,000 real ground stations on open-source StationBench with no post-processing or station fine-tuning. Speed then compounds that advantage. EPT-2 RR delivers up to 24 updates per day while preserving that accuracy baseline, which improves operational usability.
Generality versus specialization. For quant developers at funds, the key question is whether a general physics foundation model fits their specific signal and integration needs. EPT-2 covers 25 variables, including wind at 11 height levels from 10 m to 200 m, which spans the full hub-height range for wind-turbine power curves. It also covers surface solar radiation, precipitation, and temperature at multiple levels. EPT-1.5 outperforms GraphCast, FuXi, Pangu-Weather, and ECMWF HRES on European wind and temperature, which shows that generality and regional skill can coexist.
Automation versus human oversight. For traders at physical trading houses, the trade-off sits between Athena’s automated briefings and the meteorologist’s judgment. A 1 GW wind portfolio that gains four percentage points of forecast accuracy saves approximately €1.5 M per year, and that figure scales linearly across multi-GW portfolios. Athena surfaces that signal automatically, and the trader keeps the decision. Divergence alerts fire the moment two models disagree, and correction alerts fire the moment a model revises its own output. The trader acts before the market does, not after, which strengthens both reliability and operational usability.
From Evaluation to Production Deployment
Once you have weighed these trade-offs against your workflow, production deployment of physics-informed AI weather forecasting models follows four connected steps. Each step builds on the validation established in the previous one.
First, run live benchmarking. The Jua platform’s benchmarking surface returns a head-to-head accuracy comparison across any region, variable, and time window in under 30 seconds. This step sets the evaluation baseline before any sales conversation.
After live accuracy meets your threshold, move to hindcast validation. The SDK exposes historical forecast data across multiple Jua and third-party models. Your team can backtest against years of archived forecasts and confirm that live performance holds historically.
With live and historical validation complete, proceed to SDK integration. The command pip install jua installs the Python SDK, and the REST API exposes all 25+ models through a single schema with Apache Arrow for large payloads. Integration that takes a quant team a quarter to build elsewhere stands up in days.
The final step is change management. Day-Ahead and Intraday briefings auto-refresh on every new model run and compress the 7–9 a.m. manual prep routine into a single workspace. Internal meteorologists shift from briefing production to deeper forecast research. A typical Jua run completes about 2.5 hours ahead of competing operational runs at the same cycle, which is the operational statistic that determines who trades first.
Readiness and Opportunity Assessment for Your Desk
Three criteria determine readiness to deploy physics-informed AI weather forecasting models in an energy trading workflow, and all three should be met before deployment proceeds.
Technical readiness comes first. The team can run a self-directed benchmark on the Jua platform in under 30 seconds on their highest-stakes region and variable. They can also install the Python SDK via pip install jua without a sales call.
Technical capability alone does not suffice, so operational readiness comes next. The team has identified the forecast variables that drive their P&L, such as wind at hub height, surface solar radiation, and temperature spreads. They can map those variables to the 25 variables EPT-2 covers at up to 1 km resolution.
Organizational readiness determines whether the investment is material. The €1.5 M annual savings for a 1 GW wind portfolio mentioned earlier, and the corresponding solar figures, must be meaningful at your portfolio scale. If those numbers move the needle, the readiness threshold is met.
Common Evaluation Pitfalls to Avoid
Two evaluation errors recur across all three buyer personas. The first error is relying on vendor-provided graphics instead of self-run benchmarks. A vendor accuracy chart is a marketing asset, not a benchmark. EPT-2’s performance claims are documented in a peer-reviewed technical report on arXiv and validated against more than 10,000 real ground stations, and any team with access to the Jua platform’s benchmarking surface can reproduce that evaluation. Run the benchmark on your own region and let the numbers speak.
The second pitfall is overlooking ensemble calibration. A deterministic forecast that is accurate on average can still misprice tail events such as wind ramps and cold snaps. These events move the most money. The CRPS advantage discussed earlier for EPT-2e over the 50-member ECMWF ENS mean shows why probabilistic spread quality matters as much as mean error. Evaluate CRPS alongside RMSE.
Conclusion and Next Steps for Evaluation
Physics-informed AI weather forecasting models for energy trading are evaluated on four dimensions: model capability, operational usability, reliability, and integration fit. The three trade-offs described earlier map directly to these dimensions and give a practical evaluation framework. EPT-2 and EPT-2e, paired with the Athena agent inside Jua for Energy, supply quantified benchmarks across all four dimensions. The live benchmark surface is the starting point, and any team can run a head-to-head comparison on their own region and variable in under 30 seconds.
See EPT-2 benchmarked against your current forecast provider in a live comparison.
Frequently Asked Questions
What makes a physics-informed AI weather forecasting model different from a standard machine learning weather model for energy trading?
A standard machine learning model applied to atmospheric data learns statistical patterns from historical observations without any constraint on physical laws. It can produce forecasts that violate conservation of mass, momentum, or energy. These outputs may look plausible in the training distribution but fail during the extreme events that matter most to energy traders. A physics-informed foundation model such as EPT-2 learns the governing dynamics of the atmosphere directly from observational data in a latent representation that is physically constrained by construction. The outputs respect conservation laws because the architecture encodes them, not because a post-processing step corrects violations later. For energy trading, this structure means physics-constrained models maintain calibrated skill during wind ramps, cold snaps, and solar irradiance drops, which are the tail events where forecast error is most expensive. EPT-2e, the ensemble variant, beats the 50-member ECMWF ENS mean on CRPS at virtually every lead time, so its probabilistic spread is better calibrated across the full distribution, not just at the mean.
How does the Athena agent work inside Jua for Energy, and what does it replace in a trading workflow?
Athena is an AI agent instrumented with the Jua for Energy tool surface. A trader or meteorologist gives it an objective in natural language, such as a forecast query, a model benchmark request, a backtest specification, or a dashboard build. Athena plans the task, calls the relevant tools, evaluates intermediate outputs, and returns a deliverable. Typical queries resolve in about 90 seconds, and backtests in about 5 minutes. In a standard energy trading workflow, Athena replaces three manual steps. It replaces the 7–9 a.m. briefing production routine, which includes downloading grib files, processing them through in-house pipelines, and stitching a view from multiple sources. It replaces the ad-hoc benchmark request to an internal meteorology team. It also replaces the custom dashboard build that previously required an analyst or a BI team. Athena does not replace the trader’s judgment or the meteorologist’s deeper forecast research. It removes the manual assembly work that consumes time those roles should spend on higher-value analysis. Trading houses and quant desks describe Athena as another headcount, for free, because the throughput increase is that concrete.
How does EPT-2 compare to ECMWF HRES and Microsoft Aurora for wind and solar forecasting?
EPT-2 outperforms ECMWF HRES on every lead time across the full 0–240 hour range on 10 m wind, 100 m wind, 2 m temperature, and surface solar radiation, which are the four variables that drive most energy P&L. This result is evaluated against more than 10,000 real ground stations on open-source StationBench with no post-processing or station fine-tuning. Against Microsoft Aurora, EPT-2 beats Aurora on 10 m wind, 100 m wind, and 2 m temperature across the full 0–240 hour range. On surface solar radiation, EPT-2 wins by default because Aurora has no SSRD output. EPT-2 also forecasts at arbitrary lead times natively, while Aurora rolls forward in fixed 6-hour steps, which compounds error at longer horizons. EPT-2 is approximately 25% faster than Aurora at inference. For probabilistic forecasting, EPT-2e, the ensemble variant, beats the 50-member ECMWF ENS mean on both RMSE and CRPS at virtually every lead time, with 10 members. No AI weather peer has shipped a productised ensemble equivalent. Both EPT-2 and EPT-2e results are documented in peer-reviewed technical reports on arXiv (2507.09703 for EPT-2; 2410.15076 for EPT-1.5).
What does integration with Jua for Energy look like for a quant development team?
Integration starts with pip install jua. The Python SDK installs from PyPI in seconds and provides programmatic access to all 25+ models on the Jua platform through a single unified schema. This includes 10 proprietary EPT-family models plus 15 third-party NWP and AI models. The REST API exposes the same model fleet via standard endpoints with Apache Arrow support for large payloads, which suits continental, multi-variable, multi-model backtests at the data volumes quant strategies demand. Hindcast data is available across multiple Jua and third-party models for backtesting systematic strategies against years of historical forecasts. ENTSO-E grid data integrates directly for European power-market context. The developer dashboard is at developer.jua.ai and full API documentation is at docs.jua.ai. Integration that takes a quant team a quarter to build from raw AI weather research subscriptions stands up in days on the Jua platform because the ingestion pipeline, ensemble logic, and benchmarking harness are already built.
Does Jua for Energy replace an existing ECMWF subscription?
Jua for Energy runs alongside an ECMWF subscription, not instead of it. Most serious customers keep their ECMWF HRES and ENS feeds and add Jua for Energy as the layer that replaces the plumbing around those feeds. This layer replaces the in-house grib pipeline, the manual benchmarking, the morning-briefing production, and the dashboard stitching. ECMWF AIFS, ECMWF’s own AI model, runs natively on the Jua platform alongside EPT-2, EPT-2e, NOAA GFS, Microsoft Aurora, GFS GraphCast, DWD ICON, and the rest of the 25+ model fleet. All of these models sit under a single schema and a single API. The practical result is that a trader who previously monitored nine separate screens and waited for a manual briefing now has a single workspace. Every model, including ECMWF, appears on the same surface, refreshed up to 24 times per day, with divergence and correction alerts firing automatically when models disagree or revise. The ECMWF signal stays in the stack. The fragmented workflow around it does not.