How FLARE works: core concepts • FLAREr

This vignette explains the ideas behind FLARE without assuming a background in data assimilation or numerical modelling. It answers three questions: what FLARE is trying to do, how it does it, and why each component exists. For a hands-on walkthrough of running FLARE see the FLAREr example vignette. For a reference to every configuration option see the FLAREr configuration vignette.

What FLARE is trying to do

Lakes and reservoirs vary continuously in temperature, dissolved oxygen, nutrients, algae, and many other variables. Managers and scientists need to know not just what is happening now but what will happen in the coming days — to issue recreational advisories, schedule monitoring, or trigger interventions.

FLARE generates probabilistic forecasts: instead of one predicted value it produces a distribution of possible futures, so that a user can see not just the most likely outcome but also how uncertain it is. This distinction matters in practice. A forecast that says “temperature will be 22 °C” is less useful than one that says “temperature will most likely be between 20 and 24 °C, with a 10% chance it exceeds 25 °C.”

FLARE does this by running a large number of model simulations in parallel — an ensemble — where each member represents a plausible realisation of the lake’s future given current knowledge. The spread of the ensemble is the forecast uncertainty.

Where uncertainty comes from

A lake forecast is uncertain for several distinct reasons, and FLARE tracks each one explicitly.

Initial condition uncertainty. To forecast forward you need to know where the lake is right now. Sensors measure some variables at some depths, but they are imperfect and sparse. Even with good sensors you cannot know the full three-dimensional state of the lake. FLARE represents this uncertainty as an ensemble of slightly different starting states.

Meteorological uncertainty. Wind, air temperature, short- and long-wave radiation, humidity, and rain all drive what happens at the lake surface. Over a forecast horizon of days, weather is inherently uncertain. FLARE uses ensemble weather forecasts (e.g. from GEFS or Open-Meteo) so that each ensemble member is forced by a different plausible weather trajectory.

Parameter uncertainty. The process model contains parameters — numbers like sediment heat flux, light extinction, or mixing coefficients — that cannot be measured directly and are estimated by fitting the model to data. Each ensemble member can carry a different parameter value, and FLARE updates those values as new observations arrive.

Process uncertainty. Even a perfect model with perfect inputs would not perfectly capture every turbulent eddy or biological interaction. This irreducible model error is represented by adding small random perturbations to the model state at each timestep.

Observation uncertainty. Sensors have noise. When FLARE uses observations to update the model state, it accounts for the fact that the measurement itself may not perfectly reflect the true lake condition.

Activating or deactivating each source of uncertainty is controlled by the uncertainty: block in configure_flare.yml. This makes it straightforward to run experiments that isolate the contribution of each source to total forecast uncertainty.

The process model: GLM

FLARE is model-agnostic in principle, but its default process model is the General Lake Model (GLM; Hipsey et al. 2019). GLM is a one-dimensional hydrodynamic model, meaning it resolves the lake along the vertical axis — it simulates how temperature, salinity, and density vary with depth — but it treats the lake as horizontally uniform. This is a good approximation for many lakes and reservoirs, and it keeps the model fast enough to run hundreds of ensemble members in real time.

For water quality applications, GLM is coupled with the Aquatic Ecosystem Dynamics (AED) library, which adds biogeochemical cycles: nutrients, dissolved oxygen, phytoplankton, and more. The combined model is often referred to as GLM-AED.

Each day, GLM takes a set of inputs — weather forcing, inflows, and outflows — and advances the lake state forward by 24 hours, producing modelled temperature and other water quality variables at each depth. FLARE runs one independent copy of GLM per ensemble member.

Data assimilation: connecting model and observations

The core innovation of FLARE is data assimilation (DA): a mathematical procedure that optimally combines model predictions with real-world observations to produce an updated estimate of the lake state.

Without DA, a model gradually drifts away from reality because small errors accumulate. With DA, each time an observation arrives the model is pulled back toward what was actually measured, in proportion to the relative uncertainty of the model and the observation. If the sensor is trusted more than the model, the update is large; if the model is more certain than the sensor, the update is small.

FLARE does this for the full ensemble simultaneously, updating not just the mean state but also the covariance structure (i.e. which depths and variables move together). This is what allows it to propagate information from a surface temperature sensor down through unmeasured depths.

The analysis cycle

FLARE alternates between two phases on each day of the simulation.

Forecast step. Each ensemble member runs GLM forward one day using its weather forcing and inflows. The result is a set of predicted lake states — one per ensemble member — for the next day. This is the prior distribution: what the model expects before seeing any observations.

Analysis step. If observations are available for that day, FLARE compares each ensemble member’s prediction to the observations. Members that predicted well receive higher weight; those that predicted poorly receive lower weight. The ensemble is adjusted — shifted and reshaped — to be consistent with both the model prediction and the observation. This adjusted ensemble is the posterior distribution: the updated best estimate of the lake state.

The posterior then becomes the initial condition for the next forecast step. The cycle repeats daily.

                 ┌──────────────────────────────────────────┐
                 │         Analysis cycle (daily)           │
                 │                                          │
  Prior          │  Run GLM ─────► Predicted states         │
  ensemble ─────►│                      │                   │
                 │              Compare to observations      │
                 │                      │                   │
                 │              Update ensemble              │
                 │                      │                   │
                 │              Posterior ensemble ─────────►│ Next step
                 └──────────────────────────────────────────┘

Hindcast and forecast periods

A FLARE run is divided into two consecutive periods:

Hindcast period (start_datetime to forecast_start_datetime). GLM is forced with historical observed weather and inflows. Observations are assimilated at every daily step. The purpose is to bring the model state as close as possible to reality before the forecast begins. The hindcast is not shown to end users as a “forecast” — it is the warm-up that sets the initial conditions for the “forecast”. The length of the hindcast period is also refered to as the “lookback period”. The length of the lookback determined what observations are assimilated by allowing data assimilation to “see” observations there are not collected in real-time.

Forecast period (forecast_start_datetime + forecast_horizon days). GLM is forced with ensemble weather and inflow/outflow forecasts. No new observations are assimilated (the future has not happened yet). The ensemble spreads out over the forecast horizon as uncertainty accumulates. The output of this period is the actual forecast product.

Data assimilation methods

FLAREr performs data assimilation using the Ensemble Kalman Filter (enkf). It approximates the covariance of the model state using the spread of the ensemble, then computes an update that is optimal under the assumption that the prior and observation errors are Gaussian. To account for sampling noise with small ensembles, it adds a small random perturbation to each observation before computing the update (the “stochastic” variant). This is the method used in Thomas et al. 2020 and 2023.

Open loop (none). No data assimilation is performed. The ensemble is propagated forward by GLM without any observational correction. Useful for benchmarking the value of DA or for scenarios where no observations are available.

Parameter estimation

Beyond updating model states, FLARE can simultaneously estimate model parameters. Each ensemble member carries its own parameter values (e.g. sediment temperature, light extinction, or inflow mixing coefficients), and the same DA update that adjusts the state also adjusts the parameters — exploiting correlations between the model state and parameters that arise naturally in the ensemble.

This joint state-parameter estimation means FLARE learns which parameter values produce predictions that match observations, and those values are carried forward into the forecast. Over many days, the parameter distribution narrows toward values that are consistent with the lake being observed.

Four strategies control how parameter uncertainty evolves between analysis steps (par_fit_method in configure_flare.yml):

perturb: adds fresh random noise (SD = perturb_par) to each parameter every step, preventing the distribution from collapsing.
perturb_const: rescales the ensemble spread to a fixed standard deviation (perturb_par) around the current mean each step.
inflate: after each DA update, multiplies each parameter’s ensemble deviations from the mean by its perturb_par value (≥ 1), counteracting the tendency of the EnKF to over-shrink parameter uncertainty without injecting random noise.
perturb_init: each ensemble member draws a different initial parameter value but that value is held fixed throughout — no DA update and no ongoing perturbation. Useful for propagating initial parameter uncertainty without letting observations constrain it.

The augmented state vector

Internally, FLARE combines model states, non-depth-resolved variables, and parameters into a single augmented state vector that is updated in one operation. For a lake with S state variables at D depths and P parameters, the augmented state for each ensemble member has S × D + P elements.

This joint update is what lets FLARE propagate a surface temperature observation all the way to changes in a sediment heat flux parameter — because the ensemble captures how correlated those quantities are across members.

Non-depth-resolved variables (Secchi depth, lake surface elevation) are appended to the state vector using custom observation operators that convert between model variables (e.g. light extinction coefficient) and the measurement scale.

Localisation and covariance inflation

Two numerical techniques help the EnKF-family methods work reliably with limited ensemble sizes.

Localisation reduces the influence of observations on model state elements that are physically far away, where correlations in the ensemble are likely to be spurious rather than physically meaningful. The localization_distance parameter in configure_flare.yml sets the length scale over which this tapering occurs.

Covariance inflation counteracts the tendency of ensemble Kalman methods to underestimate uncertainty over time (a phenomenon called “filter inbreeding”). FLARE supports two independent inflation mechanisms:

Parameter inflation (par_fit_method: inflate): after each DA update, each parameter’s ensemble deviations from its mean are multiplied by the per-parameter perturb_par value in the parameter configuration file (≥ 1).
State inflation (use_inflation_factor: TRUE): after each DA update, every state variable’s ensemble deviations from their mean are multiplied by inflation_factor from configure_flare.yml. Both mechanisms can be active simultaneously.

Output structure

Each FLARE run writes a parquet dataset partitioned by date and site. Every row represents variable from one ensemble member at one depth at one time:

column	description
`datetime`	date and time of the prediction
`reference_datetime`	when the forecast was issued
`depth`	depth in metres
`variable`	state or parameter name
`prediction`	modelled value
`parameter`	ensemble member index
`variable_type`	`"state"` or `"parameter"`
`forecast`	`1` = forecast period, `0` = hindcast period
`log_weight`	internal bookkeeping column, always `0` for the EnKF

The separation of forecast and hindcast rows in a single file means you can always retrieve what the model predicted before it saw observations (for forecast evaluation) as well as the DA-updated hindcast (for understanding past conditions).

Forecast evaluation — comparing predictions against later observations — is handled by the companion score4cast package, which computes probabilistic skill metrics such as the Continuous Ranked Probability Score (CRPS).

A run in summary

Putting it all together, a single call to run_flare() does the following:

Read configuration. Load configure_run.yml and configure_flare.yml to define timing, paths, and model settings.
Prepare drivers. Assemble ensemble meteorological and inflow files for both the hindcast and forecast periods.
Initialise the ensemble. Either from default values, from observed profiles, or from a previous run’s restart file.
Run the analysis cycle. For each day from start_datetime to the end of the forecast horizon: run GLM for every ensemble member, assimilate observations if in the hindcast period, propagate the updated ensemble forward.
Write output. Save the full ensemble trajectory as a parquet dataset and save a restart zip file for the next run.
Update the run configuration. Advance start_datetime and forecast_start_datetime by one day so the next call picks up where this one left off.

In an operational deployment, step 6 means that run_flare() can be called on a daily schedule — each run initialises from the previous run’s restart file, assimilates any new observations that arrived overnight, and issues a fresh forecast.

Key references

Foundational FLARE papers

Thomas, R.Q., R.J. Figueiredo, V. Daneshmand, B.J. Bookout, L.K. Puckett, and C.C. Carey. (2020). A near-term iterative forecasting system successfully predicts reservoir hydrodynamics and partitions uncertainty in real time. Water Resources Research, 56, e2019WR026138. https://doi.org/10.1029/2019WR026138
Carey, C.C., W.M. Woelmer, M.E. Lofton, R.J. Figueiredo, B.J. Bookout, R.S. Corrigan, V. Daneshmand, A.G. Hounshell, D.W. Howard, A.S. Lewis, R.P. McClure, H.L. Wander, N.K. Ward, and R.Q. Thomas. (2022). Advancing lake and reservoir water quality management with near-term, iterative ecological forecasting. Inland Waters, 12, 107–120. https://doi.org/10.1080/20442041.2020.1816421
Thomas, R.Q., R.P. McClure, T.N. Moore, W.M. Woelmer, C. Boettiger, R.J. Figueiredo, R.T. Hensley, and C.C. Carey. (2023). Near-term forecasts of NEON lakes reveal gradients of environmental predictability across the U.S. Frontiers in Ecology and Environment, 21, 220–226. https://doi.org/10.1002/fee.2623

Applications of FLARE

Wander, H.L., R.Q. Thomas, T.N. Moore, M.E. Lofton, A. Breef-Pilz, and C.C. Carey. (2024). Data assimilation experiments inform monitoring needs for near-term ecological forecasts in a eutrophic reservoir. Ecosphere, 15, e4752. https://doi.org/10.1002/ecs2.4752
Woelmer, W.M., R.Q. Thomas, F. Olsson, B.G. Steele, K.C. Weathers, and C.C. Carey. (2024). Process-based forecasts of lake water temperature and dissolved oxygen outperform null models, with variability over time and depth. Ecological Informatics, 83,
1. https://doi.org/10.1016/j.ecoinf.2024.102825
Olsson, F., T.N. Moore, C.C. Carey, A. Breef-Pilz, and R.Q. Thomas. (2024). A multi-model ensemble of baseline and process-based models improves the predictive skill of near-term lake forecasts. Water Resources Research, 60, e2023WR035901. https://doi.org/10.1029/2023WR035901
Olsson, F., C.C. Carey, C. Boettiger, G. Harrison, R. Ladwig, M.F. Lapeyrolerie, A.S.L. Lewis, M.E. Lofton, F. Motealegre-Mora, J.S. Rebaey, C.J. Robbins, X. Yang, and R.Q. Thomas. (2025). What can we learn from 100,000 freshwater forecasts? A synthesis from the NEON Ecological Forecasting Challenge. Ecological Applications, 35, e70004. https://doi.org/10.1002/eap.70004
Páiz, R., R.Q. Thomas, C.C. Carey, E. de Eyto, A. Delany, R. Poole, P. Nixon, M. Dillane, I.D. Jones, D.C. Pierson, V. McCarthy, S. Linnane, and E. Jennings. (2025). Near-term lake water temperature forecasts can be used to anticipate the ecological dynamics of freshwater species. Ecosphere, 16, e70335. https://doi.org/10.1002/ecs2.70335
Carey, C.C., R.S.D. Calder, R.J. Figueiredo, R.B. Gramacy, M.E. Lofton, M.E. Schreiber, and R.Q. Thomas. (2025). A framework for developing a real-time lake phytoplankton forecasting system to support water quality management in the face of global change. Ambio, 25, 475–487. https://doi.org/10.1007/s13280-024-02076-7
Holthuijzen, M.F., R.B. Gramacy, C.C. Carey, D.M. Higdon, and R.Q. Thomas. (2025). Synthesizing data products, mathematical models, and observational measurements for lake temperature forecasting. Annals of Applied Statistics, 19, 1127–1146. https://doi.org/10.1214/25-AOAS2027
Howard, D.W., M.E. Lofton, R.Q. Thomas, A.D. Delany, A. Breef-Pilz, and C.C. Carey. (2026). Near-term forecasts of dissolved organic matter exhibit consistent patterns of accuracy across multiple freshwater reservoirs. Journal of Geophysical Research: Biogeosciences, 131, e2025JG009064. https://doi.org/10.1029/2025JG009064

Broader ecological forecasting context

Lofton, M.E., D.W. Howard, R.Q. Thomas, and C.C. Carey. (2023). Progress and opportunities in advancing near-term forecasting of freshwater quality. Global Change Biology, 29, 1691–1714. https://doi.org/10.1111/gcb.16590
Dietze, M., E.P. White, and co-authors. (2024). Near-term ecological forecasting for climate change action. Nature Climate Change, 14, 1236–1244. https://doi.org/10.1038/s41558-024-02182-0

Process model

Hipsey, M.R., et al. (2019). A General Lake Model (GLM 3.0) for linking with high-frequency sensor data from the Global Lake Ecological Observatory Network (GLEON). Geoscientific Model Development, 12, 473–523. https://doi.org/10.5194/gmd-12-473-2019