In my work in electricity access and related issues, an issue that often comes up, and often frustrates me, is the lack of good open source tools. I’ve been part of discussions where various planners are obliged to choose proprietary systems that come with significant lock-in, simply because the alternatives aren’t as capable, or they aren’t aware of them. Apart from being expensive and closed source, these tools are typically incapable of being adapted to a team’s existing processes and workflows.
There are existing open source tools (including one that I was extensively involved in) in this category, but none of them are open source in a meaningful way, and all have significant and non-trivial shortcomings. So building from these two developments, I’ve started to make inroads on this issue by creating openelec. In contrast to the other tools, it is truly open source, modular, and has an evolving but sensible API that allows it to be plugged into a variety of front-ends, such as Jupyter, QGIS or a web interface. It is built with proper network analysis and optimisation at its core, with the same components used for different scales (national, local) and objectives (private, public). It is easy to add data points as available and replace the decision calculus (currently CAPEX) with any other, such as LCOE or social goals. It can be made to run in multiple time steps of any granularity and with any prioritisation algorithm.
I discussed most of the model development in my other blog posts (one and two). The next steps were mostly merging the two models, improving some functionality and working to improve the code and documentation and work towards a more flexible and user-friendly API. Currently, openelec provides a very straight-forward mechanism for the following main planning goals:
For advanced users and modifying/adding functionality, it is probably easiest to use openelec via Jupyter notebooks or direct scripting. I provided simple instructions on the GitHub repository to pip install or git clone the openelec code. The base data requirements are also provided in the repository.
For more general users, a web interface poses the lowest barrier to entry and no installation requirements. To this end, I created a very simple Flask app (basically just an HTTP layer over the openelec API) and got it up and running on AWS Lambda using serverless. This means I pay nothing for hosting costs while no one is using the app, but it scales seamlessly when suddenly loads of people are running my pretty resource intensive optimisation algorithms. I put this to the test during the EMP-A workshop in Cape Town in January, where suddenly 30 demanding users were simultaneously running the model.
The front end provides a simple interface to the model (coded in JavaScript) that exposes most of the functionality, but obviously doesn’t allow any extensions or modifications. To play with this interface (the easiest way to understand what openelec is for), please visit openelec.me. You can also watch the video below with a quick overview of the main model features.
For more routine use, and in internet constrained environments, a QGIS Plugin is probably most useful - I’m working on it now!
I’m still working on getting the code as developer-friendly as possible, but code contributions, suggestions and ideas are very welcome! It’s all completely open source and I have no intention of trying to monetise it. Please also get in touch if you’d like to use openelec in whatever capacity and need help doing so.