Flow Forecast: A PyTorch Framework for Time Series Forecasting, Classification and Anomaly Detection
Deep learning PyTorch library for time series forecasting, classification, and anomaly detection (originally for flood forecasting).
At a glance
- What is it?
- Flow Forecast bundles seventeen deep learning architectures for time series under one training and configuration layer, with roots in river flow and flash flood forecasting. It is broad and GPL-3.0 licensed, and the breadth is also where its costs sit.
- Who is it for?
- Adopt Flow Forecast if you need to compare several deep architectures (Informer, DLinear, Crossformer, TSMixer, Transformer XL) on the same time series dataset without writing four separate training loops, and if GPL-3.0 fits your distribution model.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem Flow Forecast Was Built To Solve
River flow and flash flood forecasting is a multivariate time series problem with an awkward shape. The target is a stream's future flow or height in cfs or feet, and the inputs are things like current flow, temperature and precipitation. The README notes that snow pack data and a surrounding soil moisture index are planned additions. Anyone who has worked on this kind of data knows the pattern: a researcher reads a transformer paper, reimplements the model, writes a training loop, and three months later someone else does the same for a different architecture. Comparison across models becomes impossible because every implementation splits and scales the data differently.
Flow Forecast positions itself as the shared layer under that work. Its README calls it the only true end-to-end deep learning for time series framework and says it was the first time series framework to support transformer based models. Those are the project's own claims, not verified benchmarks. What is verifiable from the repository is the model list: seventeen entries spanning LSTM, GRU, DA-RNN, DeepAR, DSANet, several transformer variants, DLinear, NLinear, Crossformer, TSMixer, Anomaly Transformer and Inverted Transformer. The intended user is someone who wants to move between those architectures without rewriting the surrounding pipeline, and who is comfortable reading a wiki rather than a polished API reference.
What The Model Catalogue Actually Contains
The list is not a set of minor variants. It includes the full original transformer with eight encoder and decoder blocks, which the README states requires passing the target in at inference. That is a real constraint: this model is not a pure forecasting model you can run forward without the thing you are trying to predict. The CustomTransformerDecoder uses n encoder blocks with a linear decoder and is described as suitable for forecasting, classification or anomaly detection, which makes it the more practical default for a single pipeline serving multiple tasks.
Elsewhere the catalogue is deliberately uneven in complexity. SimpleLinearModel is described as essentially a linear regression model with a few more layers, and the README recommends it for rapid prototyping of features and interpretability. DLinear and NLinear come from the AAAI paper asking whether transformers are effective for time series forecasting, so the framework ships both the architectures that paper argues against and the simpler ones it argues for. DSANet is included with additional optional parameters beyond the paper. The GRU entry has an optional probabilistic output layer. Anomaly Transformer and TSMixer cover the anomaly detection and mixing angles respectively.
That spread is the point. It also means the framework cannot tune every model equally well; a single configuration layer spanning linear models and full transformers will fit some of them more naturally than others.
Installation And The Configuration Surface
The README gives exactly one installation command: pip install flood-forecast. Note the package name does not match the repository name, which is a common source of confusion when searching for the project. The README then points to the Confluence wiki for detailed information on training models, and to a separate tutorials repository, AIStream-Peelout/flow_tutorials, for additional examples. The ReadTheDocs instance exists and carries a documentation badge, but the README's own links for training go to Confluence rather than ReadTheDocs.
This matters for anyone evaluating the project. The material supplied here does not include the specific configuration keys used in training runs. What can be confirmed is where they would live: the wiki page titled Training Models, and the flow_tutorials repository. If you need to know the exact key names for sequence length, forecast horizon or model selection before adopting, that is the first thing to open, and it is not something this review can quote because the keys are not in the README. Treat the absence of a configuration reference in the README as a signal about the documentation split: install instructions are in the repository, training instructions are elsewhere.
Integrations And Serving
The README lists two integrations: Google Cloud Platform, linked to a wiki page on cloud provider integration, and Weights and Biases. It also claims model serving capabilities, though the README does not name a serving component or link to one. That claim sits in the opening paragraph alongside interpretability metrics, and neither is expanded on in the text available here. If serving is part of your evaluation, the wiki is the place to confirm what actually exists rather than assuming the opening sentence describes a deployment tool.
The Weights and Biases integration is the more concrete of the two, since W&B is a named third party with a known role in experiment tracking. The GCP integration points to a wiki page rather than a module in the repository, which suggests it may be more of a recipe than a packaged adapter. The honest reading is that this is a training and experimentation framework first, with deployment handled outside it.
Where Flow Forecast Is The Wrong Tool
The release history is the clearest limitation. The most recent release is forecast_1.0_beta from January 2024, labelled beta. Before that, the releases jump back to June 2022 with FF-3.10.4 and a bug fix release the day before. Meanwhile the repository shows a push in September 2026. That gap means the tagged releases do not describe the current state of master, and anyone pinning to a release is pinning to code that is years behind the branch. For a production forecasting service that needs a stable, versioned dependency, this is a genuine problem rather than a cosmetic one.
The second limitation is scope. If your problem is univariate, low-frequency, or small enough that a linear model or a gradient boosted tree handles it, the framework's value proposition (a shared training layer across seventeen deep architectures) does not apply. You would be installing a deep learning stack to run a linear regression. The README itself acknowledges this indirectly by recommending SimpleLinearModel for rapid prototyping, which is a reasonable entry point but also a sign that the heavy models are not always the right answer.
The third is the full transformer's requirement to pass the target in at inference. That makes it unusable for genuine forecasting without a workaround, and it is the kind of detail that is easy to miss until you are deep into a training run.
How It Compares To A General Forecasting Library
The natural comparison is a general purpose time series library rather than a single competing framework. Most general libraries concentrate on statistical and classical machine learning methods (exponential smoothing, ARIMA family, gradient boosting on lagged features) and treat deep learning as an optional extra, often through a single LSTM wrapper. Flow Forecast inverts that: deep architectures are the catalogue, and everything else is the scaffolding around them.
The practical difference shows up when you want to test whether a transformer beats a linear model on your data. In a general library you would likely implement the transformer yourself. In Flow Forecast both DLinear and several transformer variants are already present, and the README frames DLinear and NLinear as coming from the paper questioning transformer effectiveness, so the framework carries the counterargument inside it. The trade-off is depth of documentation per model. A general library with three model families can document each thoroughly; a framework with seventeen entries, several of them ported from different papers with their own optional parameters, spreads its documentation thinner. DSANet's additional optional parameters and the GRU's optional probabilistic layer are examples where you will need the source or the wiki, not the README.
Licence And Maintenance Cost
Flow Forecast is GPL-3.0. That is a copyleft licence, and it is a stronger constraint than the permissive licences most Python data libraries use. If you link the library into a distributed application, the licence terms apply to that distribution in ways that MIT or Apache-2.0 would not. This is not legal advice, and the specific obligations depend on how you integrate the code, so anyone shipping a product that depends on flow-forecast should have the licence reviewed rather than assuming a pip install is the end of the question.
Maintenance is the other cost. The README states that Task-TS from CoronaWhy primarily maintains the repository and that pull requests are welcome. The release cadence tells its own story: a 1.0 beta in January 2024, and before that a pair of releases in June 2022. The repository is not archived and shows recent pushes, so it is alive, but the gap between tags and commits means upgrade cost is not measured in version numbers. Upgrading means tracking master or pinning to a beta, and either choice carries risk. There is also a citation requirement: if you use the data or code, the README asks you to cite the FlowDB paper by Godfried, Mahajan, Wang, Li and Tiwari, and to cite the original authors of whichever models you use. That is an obligation to track alongside the licence.
Editorial conclusion
Adopt Flow Forecast if you need to compare several deep architectures (Informer, DLinear, Crossformer, TSMixer, Transformer XL) on the same time series dataset without writing four separate training loops, and if GPL-3.0 fits your distribution model. Do not adopt it if you need a stable, versioned API for a production forecasting service; the last release is 1.0 beta from January 2024, while commits continued through September 2026, so the tagged releases do not track the code. Before committing, install flood-forecast in a clean environment, run one model from the README list on your own data, and confirm that the configuration keys your pipeline depends on are documented in the Confluence wiki rather than only in the source.
Community notes