Digital twins for water

We build water digital twins, end to end.

A water digital twin is a calibrated model of your aquifer, river or network, kept current with the data you have, from monitoring wells and SCADA to satellite observations, and wrapped in the tools your team uses to decide. Where live sensors exist, we connect them. Where they do not yet, the twin starts from the data you have and updates as monitoring grows.

It is also called a water decision support system (DSS). Smart Bhujal builds every layer of the twin in-house, from the satellite pixel to the dashboard your team opens each morning, and delivers it remotely to institutions wherever they are.

What you receive

The four layers of a water digital twin

  1. Remote sensing and AIThe data layer, for places with no gauges
  2. Numerical modelingThe physics layer, so the twin can be trusted
  3. Software and AI agentsThe decision layer, the part your team opens
  4. Monitoring and sensorsThe ground truth layer, so it stays current

One decision your team can act on

What you receive

What does a water digital twin project deliver?

A water digital twin project delivers four things: a working dashboard, the calibrated models underneath it, the data pipelines that feed it and the monitoring integration that keeps it current. Each is a deliverable in its own right, not a slide deck, and each is documented so that your team can run the twin after we step back.

A dashboard your team actually opens

The interface is the product as far as the user is concerned, so it is designed around the decision rather than around the database schema.

  • Custom application built around the decision
  • Interactive dashboards and visualisation
  • Scenario and what-if tools
  • User access management

Models that hold up under questioning

Every model is calibrated against measurements and documented, because an institutional buyer has to defend the result to a board, a funder or a regulator.

  • Calibrated flow, flood, network or quality models
  • Trained machine learning models
  • Model performance report
  • Scenario simulation capability

Data pipelines that keep running

A digital twin only stays current if data reaches it without someone copying a spreadsheet every Monday, so the pipeline is part of the build rather than an afterthought.

  • Data cleaning and transformation
  • Database and API integration
  • Prediction API endpoints
  • Automated and scheduled reporting

Monitoring wired in, not bolted on

New observation is what separates a digital twin from a one-off study, so monitoring is integrated at the same time as the rest of the stack, starting from whatever records you already keep.

  • Sensor and telemetry integration
  • SCADA protocol support
  • Alert and notification configuration
  • Historical data analysis and export

The four layers

What are the four layers of a water digital twin?

The four layers of a water digital twin are remote sensing, numerical modeling, software and monitoring. Most twins fail at a seam between them: a dashboard bolted onto a model nobody calibrated, or a model with no new data reaching it. We build all four layers in-house, so the seams are ours to get right rather than someone else's to argue about.

01

Remote sensing and AI

The data layer, for places with no gauges

We build the pipeline that turns satellite and sensor archives into a usable signal over your area of interest: surface and groundwater change, vegetation stress and anomalies, over any time window you choose. This is the layer that matters most where ground observation is sparse, because it gives a twin something to run on before a single new instrument is installed.

Satellite imagery pipelinesNDVI and vegetation indicesChange detectionTrained ML models
02

Numerical modeling

The physics layer, so the twin can be trusted

We build physics-based simulations of how water actually moves through aquifers, floodplains, drainage and distribution networks, calibrated against measurements from your site. A dashboard that only plots history cannot answer a scenario question. A calibrated model can, which is why the model sits underneath the interface rather than beside it.

MODFLOWHEC-RASEPANETSWMM
03

Software and AI agents

The decision layer, the part your team opens

We build the application itself: the dashboard, the scenario tools, the APIs and the AI agents that put the model and the data to work. This is where a digital twin stops being an analysis and becomes an operational tool that a named person uses on a named day to make a named decision.

Decision dashboardsScenario toolsAI agentsAPIs and integrations
04

Monitoring and sensors

The ground truth layer, so it stays current

We build the integration that keeps the twin anchored to what is happening in the field: telemetry ingestion, IoT metering, SCADA protocol support, alerting and quality control on incoming data. Where live sensors exist, we connect them. Where they do not yet, the twin starts from the data you have and updates as monitoring grows. Without this layer, a twin is a snapshot that quietly goes stale.

IoT meteringTelemetry ingestionSCADA integrationAlerts and QA/QC

Delivered remotely

Can a water digital twin be built remotely?

Yes. A digital twin is built and delivered over a network, which makes the location of the buyer irrelevant to the quality of the result. Drilling, pump testing and floodplain survey need people on the ground. Data pipelines, calibrated models and the software on top of them do not, and pretending otherwise only adds travel to the invoice.

The inputs travel

Satellite archives, hydrological records, telemetry feeds and existing model files are all digital. They reach a build team over a network in the same condition they left, which is not true of a borehole, a pump test or a floodplain survey.

The output is software

What we hand over is an application, a set of models and the pipelines feeding them. It is deployed to your infrastructure or to a cloud account you control, and reviewed in the same browser wherever your team sits.

The review loop is short

Digital twin work is iterative: you look at a screen, you say that is not the question we ask, and the screen changes. That loop runs over a call and a shared environment, which is how software has been built across time zones for two decades.

Local expertise stays local

We do not replace the hydrogeologist who knows your basin or the engineer who signs off on site. We build the twin that carries their judgement into a tool the rest of the organisation can use, working alongside whoever holds that ground knowledge.

What our clients say

“They transform ideas and raw datasets into high-quality AI-powered dashboards and decision-support systems, and do it fast.”
FA

Faiz Alam

Client · International Water Management Institute

Who this is for

Who is a water digital twin for?

A water digital twin suits any organisation that has to make the same water decision repeatedly and has to justify it to someone else. That is usually a research institute, a development programme, a utility, a funder or a university department, and the common thread is that the answer has to be defensible rather than merely presentable.

Research institutes and CGIAR centres

Research groups sitting on rich datasets and publication-grade methods that need the result to become a tool a partner ministry or a field programme can operate without the original author present.

Development agencies and programmes

Programme teams accountable for water outcomes across many districts or basins, who need one view that consolidates monitoring, modelling and reporting instead of a folder of consultant deliverables.

Water authorities and utilities

Operators of real networks and real aquifers who need abstraction, leakage, demand and quality questions answered on an operating rhythm rather than once per study cycle.

Foundations and NGOs

Funders and implementers who have to show what changed, where, and whether the intervention worked, and who need that evidence to be reproducible rather than assembled by hand for every report.

University programmes

Departments and research programmes that need a modelling or remote sensing method turned into a maintained, documented system that outlives the student cohort which built the prototype.

How is a water digital twin built?

A twin is built in the order that keeps it honest: the decision first, the design second, and calibration as a gate rather than a final polish. Working the other way round produces a handsome interface sitting on a model nobody has checked.

  1. Start from the decision

    We establish what you are trying to decide, who decides it and on what cadence, before we ask what data exists. The decision determines the model and the model determines the data, in that order.

  2. Design the twin

    Decision workflow analysis produces the design of the twin: which layers are needed, what each one has to output, and what the interface has to show to close the loop.

  3. Build the stack

    Data pipelines, models, application and integrations are built together rather than sequentially, so the interface is tested against real model output from early on.

  4. Calibrate against ground truth

    Models are checked against measurements. A model that has not been compared with observation is an opinion with a mesh, so calibration is a gate rather than a final polish.

  5. Hand over and support

    Deployment, documentation and training sessions transfer the twin to your team, with maintenance and support available afterwards.

How we work

Three rules we do not bend.

01

Start from the decision

We ask what you are trying to decide before we ask what data you have. A dashboard nobody acts on is a cost, not an asset.

02

Physics first, AI where it earns its place

We use MODFLOW, HEC-RAS, EPANET and SWMM where physics is the right tool, and machine learning where it genuinely beats them: forecasting, anomaly detection, downscaling and filling gaps.

03

Calibrated, or it is a guess

Every twin is anchored to ground truth and recalibrated as new observations arrive, which is why monitoring is part of the stack rather than an afterthought.

More on the team and where these came from is on the about page.

Questions

Frequently asked questions

A water digital twin is a calibrated model of your aquifer, river or network, kept current with the data you have, from monitoring wells and SCADA to satellite observations, and wrapped in the tools your team uses to decide. It is not a report and it is not a map layer. It answers a standing question, such as how much can safely be abstracted this season or where a network is losing water, and it answers it again as new data arrives.

A digital twin project delivers the application itself, user documentation, training sessions, and source code and deployment. Where the twin includes machine learning, that extends to trained models, prediction API endpoints, a model performance report and integration documentation. Where it connects to live monitoring, it extends to the dashboard, alert configuration, data export and user access management.

No, because every input and every output of this work is digital. Satellite archives, hydrological records, telemetry and existing model files all transfer over a network unchanged, and what we hand back is software deployed to infrastructure you control. That is the difference between building a digital twin and running a site investigation, which does need people on the ground.

Yes. Our clients include the International Water Management Institute, an international water research organisation, alongside universities, state programmes and private operators. Because the work is delivered remotely, the location of the institution is not a constraint on the engagement.

We build on standard, peer-reviewed engines rather than proprietary black boxes: MODFLOW for groundwater flow, HEC-RAS for rivers and floodplains, EPANET for distribution networks and SWMM for urban drainage. Using established engines means an external reviewer can interrogate the result, which matters when a funder or a regulator asks how a number was produced.

Both, but not interchangeably. Groundwater and floods obey equations that have been calibrated against field data for decades, so physics is the default. Machine learning is used where it genuinely outperforms physics: forecasting, anomaly detection, downscaling and filling gaps in sparse records. A method is chosen because it is the right tool, not because it is fashionable.

Yes. Sensor and telemetry integration, SCADA protocol support, database integration and API development for third-party systems are all part of the standard scope. A digital twin usually earns its value by consolidating sources that already exist inside an organisation but have never been brought into one view.

Then the model or the platform becomes an input rather than something to rebuild. We can build the twin around what already exists, wiring an established model or database into a dashboard, an API and the monitoring data you hold. Rebuilding a working model is a cost with no return, and the budget is better spent on the layer that is missing.

Source code and deployment are listed among the deliverables of a digital twin engagement, so the twin is handed over rather than held out of reach. The specific licensing and ownership terms are set out in the contract for each project.

A water digital twin needs a decision to serve and the data you already hold, which is usually enough to begin: monitoring well records, river gauges, network and SCADA history, existing model files, or satellite archives where there are no gauges. Where live sensors exist, we connect them. Where they do not yet, the twin starts from the data you have and updates as monitoring grows.

It starts with the decision, not with the data. Send us the question your organisation is trying to answer, who has to answer it and what data already exists, and the first conversation is about whether a digital twin is genuinely the right instrument for it. If it is not, we will say so.

Reference architecture

A water digital twin, end to end.

From raw observations to a decision your team can act on: physics and AI models converging on one calibrated twin. Where live sensors exist, we connect them. Where they do not yet, the twin starts from the data you have and updates as monitoring grows.

Choosing the tools

Which package should the modelling layer run on?

Most of these packages do the same job well enough that the choice comes down to the shape of your problem rather than the quality of the software. Written for the person who has to justify the decision rather than the person who has already made it.

Flood Modelling Software: Free vs Paid

HEC-RAS is free, capable and accepted almost everywhere, which makes it the right default. Here is where MIKE, TUFLOW and Delft3D genuinely earn a licence fee instead.

HEC-RAS vs MIKE for River and Flood Modelling

HEC-RAS is free and the easier of the two to learn, so start there. MIKE earns its licence on regulated rivers, moving beds and tidal reaches. Here is how to tell which problem you have.

InfoWorks ICM vs TUFLOW for 1D-2D Flood Modelling

Both couple a 1D network to a 2D surface and both are used on serious flood studies. They differ in what they assume you are modelling, and that assumption decides which one fights you.

Physics Models vs Machine Learning for Water

The two are good at different jobs, and the interesting question is not which wins but which part of your problem belongs to each. Here is the line we draw and why.

Stormwater Modeling Software Compared

Most stormwater software is an environment wrapped around one of a few engines, and the most common engine is free. Here is what EPA SWMM, PCSWMM, InfoWorks ICM, MIKE+ and the rest each add.

PCSWMM vs EPA SWMM: Is the Free One Enough?

They are not really competitors. EPA SWMM is the free computational engine, PCSWMM is a commercial environment built around it. The question is whether you need what the environment adds.

InfoWorks WS Pro vs InfoWorks ICM

They share a name and a database server, but they model different networks. WS Pro is for the pipes that deliver drinking water; ICM is for the sewers, drains and rivers that take water away.

SWMM vs HydroCAD for Stormwater Design

HydroCAD is the everyday tool for site detention design in the US; SWMM is the free EPA model for drainage networks. Here is where each one fits, and when a site job outgrows HydroCAD.

SWMM vs HEC-RAS and HEC-HMS: Which to Use

SWMM, HEC-RAS and HEC-HMS overlap less than their names suggest. One is for pipes and urban catchments, one for rivers and floodplains, and one only for hydrology. Here is how to pick, and when to use two.

Real Time Control vs Passive Detention for Urban Stormwater

A detention basin sized for a design storm holds back the same volume whatever the forecast says. Adding telemetry and an actuated outlet can roughly double its useful storage, and it introduces a failure mode the passive version does not have.

Groundwater Modelling Software Compared

Most groundwater modelling software is an interface around MODFLOW, and MODFLOW is free. Here is what GMS, Visual MODFLOW Flex, Groundwater Vistas and FEFLOW each add, and when the free tools are enough.

FEFLOW vs MODFLOW: How to Choose

The honest answer is that the two codes are good at different things, and the deciding factor is usually the geometry of your problem rather than the quality of the software. Here is the line between them.

Groundwater Contamination Modeling Software Compared

Flow and transport are two different models, and most of the pain in contaminant work comes from treating them as one. Here is what MT3D, RT3D, SEAWAT and PHT3D each do.

Water Network Design Software Compared

EPANET is free and its solver is the one the commercial packages are measured against. Here is what WaterGEMS, InfoWorks WS Pro and Synergi actually add on top of it.

EPANET vs SWMM: Which One Do You Need?

Both are free, both come from the US EPA and both draw a network of links and nodes, so they are easy to confuse. They solve different problems: pressurised supply against gravity drainage.

Digital Twin vs Simulation Model in Water

Every digital twin of a water network has a simulation model inside it, but most simulation models are not twins. The difference is the live data link, and it decides cost, use and who maintains it.

Digital Twin Software for Water Utilities Compared

Products sold as water digital twins fall into two kinds: a hydraulic model kept live with sensor data, and analytics on the sensor data with no model at all. Here is which is which.

DMA Leak Detection Software Compared

Night flow analysis finds the district losing water. It does not tell you where the pipe is, and it does not care which platform you bought. Here is what actually separates the options for a mid-sized utility.

InfoWorks ICM and WS Pro Alternatives

InfoWorks WS Pro and ICM are strong platforms priced for large utilities. If you are a smaller consultancy or a mid-sized utility, here is what professionals actually use instead, and where the tradeoff bites.

Water Quality Modelling Software Compared

The water body chooses the model more than the budget does. Here is which water quality software fits a river, a stratified reservoir, an estuary and a catchment, and which of them are free.

WASP vs QUAL2K: Which One Fits

Both are free EPA water quality models and they are built for different water bodies. QUAL2K is a river reach tool, WASP is a general transport framework. Picking wrongly costs weeks.

WEAP vs MIKE HYDRO Basin

Basin allocation models encode who gets water and in what order, which makes them as much a negotiation tool as a technical one. That shapes which package is the right one.

Open Source vs Commercial Water Modelling Software

The free packages are not the cheap option for beginners. EPANET, SWMM and MODFLOW are the reference implementations that several commercial products are built on top of. What you pay for is everything around the solver.

Go deeper

The layers, in detail

Software and AI services

The full catalogue of what goes into a twin: custom software, ML models, dashboards and analytics.

Solutions by sector

How the same stack is applied to agriculture, municipal networks, industry, mining and the environment.

Groundwater modeling

MODFLOW-based aquifer simulation, the physics layer underneath most groundwater digital twins.

Surface water and flood modeling

HEC-RAS and hydrological modelling for floodplains, catchments and river systems.

Water distribution modeling

EPANET network simulation for utilities managing pressure, losses and supply reliability.

GWPilot

Our own groundwater tool, and a working example of the decision layer we build for clients.

Working with US clients

HEC-RAS flood modeling, MODFLOW groundwater simulation and FEMA studies, delivered remotely to clients in the United States.

Working with GCC clients

Groundwater management, dewatering and non-revenue water reduction for utilities and operators across the UAE, Saudi Arabia and Qatar.

TimescaleDB vs InfluxDB for Water Telemetry

Most water monitoring projects do not have a time series problem yet, and PostgreSQL will carry them further than expected. Here is where that changes and what to move to.

Power BI vs a Custom Water Dashboard

A BI tool will get you to a working water dashboard faster and cheaper than anything bespoke. Here is the specific point at which that stops being true.

Automating Water Network Analysis: Scripted Runs vs the GUI

Most hydraulic modelling time is not spent thinking. It is spent opening a file, changing one demand, running it, and writing the result into a spreadsheet, eighty times. That part is a solved problem and almost nobody solves it.

Open Source vs Commercial Water Modelling Software

The free packages are not the cheap option for beginners. EPANET, SWMM and MODFLOW are the reference implementations that several commercial products are built on top of. What you pay for is everything around the solver.

AI Agents vs Dashboards for Water Operations

A dashboard answers the question you thought to ask when it was built. An agent answers the one you have now. That difference decides which is worth building, and it is not always the agent.

LLM Agents vs Rule-Based Automation in Water Networks

SCADA rules have run water networks for decades and are not obsolete. The question is which decisions belong in a deterministic rule and which belong to something that can reason about a situation it has not seen.

AI Agents vs Digital Twins for Water Utilities

A digital twin simulates the network. An agent reasons about it. Utilities are sold both as the same modernisation, and the budgets involved are different by an order of magnitude.

RAG vs Fine-Tuning for Water Utility Knowledge

Utilities hold decades of design reports, O and M manuals and incident records. Making that searchable by an AI system is a choice between two architectures, and for this kind of content one of them is usually wrong.

Copilot vs Autonomous Agent in Water Operations

The interesting question about an agent is not how clever it is but how much it is allowed to do without asking. In water operations that answer should be conservative, and for defensible reasons.

Tell us the decision you are trying to make.

Not the dataset, not the software you think you need. The decision. If a digital twin is the right instrument for it, we will describe what that twin would have to contain. If it is not, we will tell you that instead.

contact@smartbhujal.com