SysIdentPy: NARMAX Model Building in Python, From FROLS to Neural NARX
A Python Package For System Identification Using NARMAX Models
At a glance
- What is it?
- SysIdentPy is a BSD-3-Clause Python library that builds NARMAX and related model families on top of NumPy. It is aimed at engineers and researchers who need to select model terms and estimate parameters for nonlinear dynamical systems rather than fit a generic regressor.
- Who is it for?
- Adopt SysIdentPy if your problem is genuinely a NARMAX one: you have input and output records from a dynamical system, you want a sparse polynomial or basis-function model, and you need structure selection algorithms such as FROLS or MetaMSS rather than a black-box regressor.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 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 SysIdentPy addresses is model structure, not curve fitting
Most Python forecasting libraries assume you already know the functional form of your model. You pick an estimator, hand it lagged features, and it fits coefficients. SysIdentPy starts one step earlier. The README describes it as a module for system identification using NARMAX models, and the feature table lists model structure selection as a first-class capability alongside parameter estimation. That ordering matters. In a NARMAX workflow the hard question is which lagged inputs, lagged outputs, and cross terms belong in the model at all, and the library ships dedicated algorithms for that decision: FROLS, MetaMSS, AOLS, UOFR, Entropic Regression, RMSS, and the Orthogonal Floating Search family (OSF, OIF, OOS/O2S).
The intended user is someone working with dynamical systems rather than generic time series. The README frames the package as a way to build variations of NARMAX, naming NARX, NAR, NARMA, NFIR, ARMAX, ARX, and ARMA as members of the same family. If your data has a real input signal driving a physical or simulated process, and you want a model whose terms you can read, this is the target case. The README also points to a companion book, Nonlinear System Identification, for readers who need the theory behind the algorithms.
How the pieces fit: basis functions, structure selection, then estimation
The architecture visible in the README is a pipeline of interchangeable stages. First, basis functions define the candidate term space. The README states you can use up to 8 different basis functions, set linear and nonlinear ones, and ensemble them to get custom NARMAX models. Second, a structure selection algorithm chooses which candidate terms survive. Third, a parameter estimation method fits the coefficients of the surviving terms. The README claims more than 15 estimation methods, and notes that structure selection methods can be combined with different estimation techniques.
That separation is the design decision worth noting. Because structure selection and estimation are decoupled, you can hold the term set fixed and swap estimators to compare them, or hold the estimator fixed and compare which structure selection method produces a sparser model. The README also mentions multiobjective parameter estimation, where affine information is used to estimate parameters while minimizing different objective functions. For reproducing published results, the SimulateNARMAX class is described as the mechanism for testing published models under different estimation methods.
A second axis is the neural path. The README lists Neural NARX as a feature and names PyTorch as a dependency for building NARX neural networks. So the library spans classical orthogonal least squares style identification and a neural variant within the same API surface, which is unusual for a system identification package.
Installing SysIdentPy and the dependencies you actually pull in
Installation is a single command according to the README:
pip install sysidentpy
The stated requirements are Python 3.10 or newer, NumPy 1.19.2 or newer, Matplotlib 3.3.2 or newer, PyTorch 1.7.1 or newer, and SciPy 1.8.0 or newer. The README notes compatibility with Linux, Windows, and macOS, and warns that some examples need extra packages such as pandas.
The PyTorch requirement deserves attention before you install. If you only intend to use the classical NARMAX estimators, PyTorch is still listed among the requirements, which means the dependency footprint is larger than a NumPy-only identification library would suggest. The README does not describe an optional extra that omits it, so treat PyTorch as part of the install unless the packaging says otherwise on PyPI.
For the experimental Array API support, the README gives two configuration entry points: set_config(array_api_dispatch=True) or config_context(array_api_dispatch=True). Those are the keys to remember if you want to try a non-NumPy backend.
Array API support is opt-in and uneven across backends
The README is explicit that Array API support is experimental and opt-in, following the approach used by SciPy and scikit-learn. Coverage is described in tiers. Backend-native support currently includes the supported model structure selection algorithms, simulation, metrics, utilities, and the Polynomial, Fourier, and Bilinear basis functions. Automated coverage is described as strongest for NumPy, PyTorch, and array_api_strict, with CuPy and JAX remaining experimental compatibility targets.
The limitation that matters most is in the prediction path. On non-NumPy backends, the README states that 1-step prediction stays backend-native, but sequential prediction (when steps_ahead is None or steps_ahead is greater than 1) runs through a NumPy/CPU fallback and converts predictions back to the original namespace and device. In practice that means a GPU array can go in and come back out, with a CPU round trip in the middle for multi-step simulation. If your reason for choosing a CuPy or JAX backend is to keep long simulations on device, this is the constraint to check against the dispatch guide before you design around it.
The README directs readers to the Array API dispatch guide for the exact support matrix and current limitations. That phrasing implies the matrix is finer grained than the summary here, and it is the document to read rather than infer from the feature list.
Where SysIdentPy is the wrong tool
The package assumes a NARMAX-shaped problem. If your task is univariate forecasting with no meaningful exogenous input, the NARX and NFIR machinery buys you nothing, and you would be carrying a PyTorch dependency and a system identification vocabulary for a job a simpler autoregressive model handles. The README does list NAR, NARMA, ARMA, and AR among the supported variants, so purely output-driven models exist, but the selection algorithms are designed around the richer term space that inputs create.
A second boundary is the experimental status of the Array API path. Anything that depends on sequential prediction on CuPy or JAX is, per the README, going through a NumPy fallback today. Building a latency-sensitive pipeline on that path means building on a documented temporary behaviour.
A third consideration is scope of validation. The README describes the algorithms and the companion book, but it does not present accuracy comparisons against alternative identification libraries. Nothing in the supplied material lets you conclude that FROLS in SysIdentPy will select a better term set than another implementation of the same algorithm. The value proposition here is breadth of methods in one API, not a demonstrated accuracy advantage.
Compared with reaching for a general regression library
The obvious alternative is to build the same model by hand with scikit-learn or statsmodels: generate lagged features with a helper, run Lasso or orthogonal matching pursuit for sparsity, and fit coefficients with linear regression. That approach is viable and it avoids the PyTorch dependency. The difference is in what you get for free. SysIdentPy supplies the term generation for NARMAX families, the orthogonalization-based selection methods (FROLS and the Orthogonal Floating Search variants), and simulation of the identified model as a dynamical system rather than as a sequence of independent predictions.
The last point is the real distinction. A generic regressor trained on lagged features predicts one step ahead well and then degrades when you feed its own outputs back in, because nothing in the fitting procedure accounts for the recursive structure. SysIdentPy's simulation path is built around that recursion, and the SimulateNARMAX class exists specifically to run identified models as dynamical systems. If your deliverable is a model you can simulate open loop, that difference is the reason to prefer this package over assembling the same pipeline yourself. If your deliverable is one-step-ahead accuracy on a held-out window, the two approaches converge and the lighter one wins.
Maintenance, releases, and the licence in practice
The repository is not archived and the last push recorded is 2026-08-12. The release cadence visible in the supplied material is three releases over roughly eight months: v0.7.0 on 2025-11-30, v0.8.0 on 2026-03-28, and v0.9.0 on 2026-06-13. That is a steady minor-version rhythm, which suggests the API is still moving. The README describes Array API support as experimental, and that feature is exactly the kind of thing that changes between minor versions. Pin your version and read the release notes before upgrading if you depend on the dispatch behaviour.
On licence, SysIdentPy is distributed under the 3-Clause BSD licence, and the README states this directly. That is a permissive licence, which generally means you can use, modify, and redistribute the code including in closed products, subject to the conditions in the licence text itself. This is not legal advice; read the LICENSE file and your organisation's policy. The practical point is that the permissive terms remove the licensing question from your adoption decision, leaving the technical fit as the thing to evaluate. The package also carries a JOSS DOI (10.21105/joss.02384), which gives you a citable reference for the software itself.
Editorial conclusion
Adopt SysIdentPy if your problem is genuinely a NARMAX one: you have input and output records from a dynamical system, you want a sparse polynomial or basis-function model, and you need structure selection algorithms such as FROLS or MetaMSS rather than a black-box regressor. Do not adopt it if you only need one-step forecasting of a stationary series, or if you expect sequential multi-step prediction to run natively on CuPy or JAX, because the README states that path falls back to NumPy on CPU. Before committing, verify three things against your own data: that your Python version is 3.10 or newer, that the basis function and estimator combination you intend to use is covered by the Array API support matrix, and that the simulation path you need is the one documented for your backend.
Community notes