To find the optimum way of connecting all these buildings to a mini-grid system,we turn to network theory, and in particular, the minimum spanning tree. This is the set of lines that connects a group of points with the minimum total distance (or other cost function). For the village of Sipungu, this looks as follows, where each blue dot is a building (very small ones filtered) and the green point a randomly chosen location for the solar PV installation. I haven’t yet extensive testing on speed with larger datasets, but my solution for now is a combination of a k-neighbors graph and scipy’s built-in minimum_spanning_tree function.
Our goal then is to determine, based on some criteria, which of these connections to maintain. The first step is to direct the network from the PV installation outwards, so that the model knows where to start in looking for connections to drop or keep. We don’t want to accidentally disconnect the PV system itself! This is a process not dissimilar to the stream ordering used in my hydrological modelling. Conceptually they fall in with a broad range of physical, mathematical and social problems where network theory is applied.
There are a number of different ways to cost-optimise this network; I chose a brute force approach to find the configuration with the highest net present value, i.e. the most money for the developer, taking into account the future income streams and costs. This sounds like a ruthless way of thinking, but for more mini-grids to get built and more people to get access to electricity, they need to be sustainable. The hope is that once the system is running, demand will increase and more households will become profitable to connect.
The algorithm starts with the complete network, and considers which single deletion of a line a connecting two households provide the biggest boost to profitability. For example, a very small household far away from any others -lots of wire, but not much demand or electricity sold. It then repeats this process over and over again until there are no more profitable configurations to be found and that is the optimum network!
I contrived the following main parameters for the village of Sipungu, along with some heuristics for determining the number of people based on building size.
The resultant optimised network is shown below, where about 80% of the buildings are connected by the algorithm. The remaining little clusters are deemed to not be worth connecting, based on the capital outlay required and expected returns based on the demand and tariff above. So with this new data and this model, we already have an estimate of the costs involved and how the mini-grid might end up looking (noting, of course that the real network will follow real-world constraints like the existing road).
Note that I mentioned the model optimises for NPV. With these parameters, the NPV of this development was calculated to be USD -815,000 – in the optimum case!So either the developer needs to cut costs, or charge higher tariffs, or hope for higher demand. This leads me to another extremely useful feature of this type of model: easy scaling. It’s as easy to model Sipungu village as it is to model hundreds of villages.
So I did. To explore the relationship between village density and economics, and to understand tariffs needed for project profitability, I modelled 100 Tanzanian villages, considering for each one different combinations of costs, demand and village coverage (percentage of households electrified). In the chart below,each point represents a model run, with demand on the horizontal axis (6 kWh,from the example above, is marked by a vertical red line) and the required tariff for a 6-year payback on the vertical.
As you can see, there are not many villages that can sustain a mini-grid at that demand level and tariff. Even at extremely high demand levels, around 0.24USD/kWh is still needed for projects to be feasible. However, grid electricity in Tanzania is below 0.10 USD/kWh, so this is unlikely to be possible for poor rural villages. One possible solution: subsidies.
A web app interface to the model would make it a lot more accessibly to non-coders. So I set out to create a basic app that would allow a user to select a village and the desired input parameters, and get an interactive map and summary results in-browser.
Flask is a Python web framework – it transforms data and code into web pages and APIs. I selected it for this project because it is lightweight and easy. A basic Flask app looks as follows. The
@app.route() tells Flask that this method should be run when someone accesses the base URL of the website, and the
'Hello World!' returned is what will be displayed in the user’s browser.
from flask import Flask app = Flask(__name__) @app.route('/') def hello(): return 'Hello World!'
Most of the time you want your result to look better than that, so you use anHTML template, into which Flask inserts results as follows using the module render_template. I set up a template with buttons and selectors for the model parameters, and a big window where the mapped results can be displayed. When the user first arrives, they are greeted with an overview map of Tanzania and a selector list on the left. Once they’ve chosen a village, selected the generator site, and inserts the other parameters, they are shown the mapped results – as in the example below for Nakiu.
Or below for the slightly larger village of Uwemba.
from flask import jsonify @app.route('/run_model') def run_model(): args=request.args # model code here # or calls to external module results = ... return jsonify(result=results)
This approach means that the entire web page rarely or never has to reload,which makes the user experience much faster and more dynamic.
Then there’s only one thing left to do: push it to a server where it can run without keeping my laptop hot. I used a simple git set up to push the latest model and app to a Google cloud instance, and use
supervisor to keep the Flask app up and running. I won’t post all of the code here, but it’s available at my GitHub repo.