My undegraduate BTech Project report on assisting the Planning Commission of India (now, Niti Aayog) in building the first version of the IESS-2047 web calculator on energy sustainability. Made in collaboration with Department of Energy and Climate Change UK, under the guidance of Shrestha Chowdhary (Young professional) and Mr. Anil Jain (Advisor, Enegry, IAS, 86) - Planning Commission. The report focuses on the engineering aspects of the webtool and the early-stage development journey.The project had a successful release on 28th of February, 2014 at Leela Hotel, New Delhi.

1. India Energy Security Scenarios, 2047
Student Name: Aditya Gupta
Roll Number: 2011009
BTP report submitted in partial fulfillment of the requirements
for the Degree of B.Tech. in Computer Science & Engineering
on 23rd April, 2014
BTP Track: Engineering / Development
BTP Advisors
Dr. H B Acharya
Mr. Anil Jain
Indraprastha Institute of Information Technology
New Delhi

2. Student’s Declaration
I hereby declare that the work presented in the report entitled “India Energy Secuirty
Scenarios, 2047” submitted by me for the partial fulfillment of the requirements for the
degree of Bachelor of Technology in Computer Science & Engineering at Indraprastha Institute
of Information Technology, Delhi, is an authentic record of my work carried out under guidance
of H. B. Acharya. Due acknowledgements have been given in the report to all material used.
This work has not been submitted anywhere else for the reward of any other degree.
.............................. Place & Date: .............................
Aditya Gupta
Certificate
This is to certify that the above statement made by the candidate is correct to the best of my
knowledge.
.............................. Place & Date: .............................
H. B. Acharya
2

3. Abstract
At current rates of energy supply, demand, and infrastructure development, India would be
84% dependent on imports for its energy needs by the year 2047. Indian policymakers face the
challenge of avoiding such a scenario while balancing emissions, flows, costs, land-use, and the
pressure of inelastic demand.
The Planning Commission of India, in response to this need, has decided to adapt the approach
of the Department of Energy and Climate Change in the UK: Tom Counsel’s Twenty-Fifty
Energy Mapping Webtool. [It may be noted that since the tool’s original release in 2008, today,
Brazil, China, South Africa and various other countries have also decided to adopt it, and are
racing to deploy their own customized versions.]
In this report, I describe my B. Tech project, which involved adapting, deploying and main-
taining portions of the web application for this energy mapping tool as per the needs of the
Planning Commission. The project was time critical as the mission had to be deployed in 3-4
months. The core team’s responsibility ranged from receiving a working open-source project
to understanding, compiling, and re-engineering it; most of the 6-7 team members handled the
policy-related model and data, while the code was handled by Shrestha Choudhary (Young Pro-
fessional, PCI) and me, with generous support from the NIC and DECC, UK.
Keywords: Sinatra, Ruby, CoffeeScript, HAML, ERB, C, ExceltoC, Highcharts, JQuery, Web
Development, Ubuntu-Linux, VMWare, IE, CSS3, thin

4. Work Distribution
Week 3, Dec 2013
1. Setting up the project environment (rvm, thin)
2. Reading and learning tools and technologies (Ruby, Sinatra, Excel, CoffeeScript)
Week 4, Dec 2013
1. Fixing adapted Excel Database / Remodelling backend
2. First Independent Sankey model created
3. Static backend for frontend testing (mini-excel)
4. Model Update
Week 1, Jan 2014
1. Broken Excel References Fixed
2. Data/Backend Ruby-Gem fixes, Debugging (jsondiff)
3. Formally Drafting Setup Steps for the IT Team
4. Model Update
Week 2, Jan 2014
1. Fixing backend models (Excel, Server, References)
2. Link updation on adapted project
3. Sankey debugging
4. Introducing India map on Land Requirements
5. Adding legends to highcharts
6. Model Update
Week 3, Jan 2014
1. Prototyping and Testing several message boxes
2. Made and Revised Land Charts
3. Designed and added first new topbar
4. Touch ups and re-designing
5. Model Update
Week 4, Jan 2014
1. Built prototypes for Quizzes for Users
2. CSS revamp (Responsive Design)
3. Fixed Chart Axes / Labelling
1

5. 4. Updates to Per Capita Emissions Charts
5. Adding in Pathways
6. Linking to Sector-Wise Documents
7. Built Website Tour
8. Model Update
Week 1, Feb 2014
1. Fixed Redirects and URLs
2. Built Emissions Intensity Chart
3. Rebuilt Website Tour
4. Built and Removed Site Loader
5. Added Social Media Sharing Tool (sharethis)
6. Reorganized Policy Handles on Frontend
7. CSS and Frontend Cleanup
8. Reorganized the help pdfs
9. Debugged Sankey
10. Model Update
Week 2, Feb 2014
1. Bugfix on Emissions Chart
2. First Launch Postponed
Week 3, Feb 2014
1. Bugfix on URLs/Pathways
2. IE Compatibility Debugging
28th Feb: Official Launch at the Leela Hotel, New Delhi
Week 1-2, March 2014 [On Break]
March 2014
1. Model Update
2. Compatibility with Internet Explorer (back to version 8).
3. Debugging and Frontend Housekeeping
4. Frontend Updates and Bugfixes
April 2014
1. Research on possible technologies for India IESS (Highcharts, D3, Raphael), ver-
sus China and UK Energy Mapping tools
2. Research on actual re-implementation of charts using alternate engines (D3, Am-
Charts, Google Charts), evaluation for new implementation.
2

6. Acknowledgments
My sincerest thanks go to Shrestha, my teammate and guide, who not only introduced me to
a half year old project and communicated the technical requirements to me, but also stayed
patient and supportive while I picked up the required technology. She went out of her way to
coordinate with me while I attended college, went out of station, wrote exams, and even had
a broken laptop. Racing against deadlines and brainstorming strategies together has been an
incredible experience.
I would next like to thank my external advisor, Mr. Anil Jain, who assigned me to this project.
His vision for this project, and his willingness to entrust me with such a responsibility, have
given me an incredible opportunity, and I am most grateful.
Lastly, I would like to most sincerely thank Dr. H B Acharya. I would not have been able to
undertake this project without sacrificing a semester had it not been for his guidance. I feel his
support has been very important to my success in this endeavour, and indeed, in many more.
i

7. Contents
1 Introduction and Problem 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 The Webtool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Involved Parties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Architecture and Challenges 4
2.1 Backend and challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Explanation for Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Backend Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Frontend and challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Frontend Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Other Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 User Guide 11
3.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 How to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Contribution and Feedback 14
4.1 Key Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5 Conclusion 16
ii

8. Chapter 1
Introduction and Problem
1.1 Motivation
The 12th Five Year Plan (2012 to 2017) aims at faster, inclusive and more sustainable growth,
but does not adequately address the action in the energy sector required to support the same.
Sustaining a growth rate of 7.4% under business-as-usual policies over the next 35 years will not
only cause our import dependence to grow from the already alarming figure of 31% to 84.5%,
but also cause severe consequences in terms of balance of payments, land-requirements, emission
rates and general sustainability. Moreover, energy imports may be worth limiting in the interest
of national energy security.
Energy policy is, therefore, a major challenge for the Planning Commission in the upcoming
years.
Following the model of UK’s Department of Energy and Climate Change (DECC), the planning
commission of India, under the leadership of Dr. Montek Singh Ahluwalia, decided to imple-
ment its own adaptation of the Energy Pathways 2050 Calculator. This was achieved through
a DECC and PCI partnership, a reflection of the growing synergy between the Government of
India and that of the UK.
1

9. 1.2. THE WEBTOOL
1.2 The Webtool
The IESS 2047 calculator (http://164.100.44.147/pathways) is a tool to aid policy making.
The calculator consists of a dashboard and computes projections based on thirty-eight features
of policy, across:
• 6 Demand Sectors: Transport, Industry, Agriculture, Buildings, Cooking and Telecom
• 3 Conventional Energy Supply Sectors: Coal, Oil and Gas
• and 8 Renewable and Clean Energy Sectors: Hydro, Onshore Wind, Offshore Wind,
Bio-Energy, Solar Photovoltaic, Concentrated Solar Power, Nuclear and Municipal Solid
Waste
Each of these features can be chosen to have a level, as seen below:
Figure 1.1: Various Levels for Policy
1. Least Effort
2. Determined Effort
3. Aggressive Effort
4. (near impossible) Heroic Effort
The dashboard dynamically provides real-time sector-wise graphs illustrating the repercussions
of chosen policy pathways from 2012 to 2047 with a five-year interval resolution. The features
of interest displayed are:
Figure 1.2: Sector-Wise Energy Supply Chart for
chosen policies
1. Energy Supply
2. Energy Demand
3. Import Dependence
4. Electricity Supply
5. Electricity Demand
6. Overgeneration/Exports
7. Oil, Gas and Coal Imports
8. Import Costs
9. CO2 Emissions
10. Per Capita Emissions
11. Emission Intensity
12. Energy Flows (Sankey)
13. Land Area
The calculator also suggests and auto-assigns some predefined pathways like ”Least Effort”,
“Maximum Effort” and “Minimum Emissions”.
2

10. 1.3. INVOLVED PARTIES
A quick glance at the deployed links (of the India and UK versions) reveals significant differences
between the calculators. The same may also be observed across the other deployed versions:
• China: http://2050pathway-en.chinaenergyoutlook.org/
• South Africa: http://2050.lateral.co.za/
The differences are of two principal types: differences in the structure of the model, and in the
web application itself.
The primary reason for the model changes is that the scope of energy supply, demand, policy
change and government objectives varies significantly between countries. In India, for example,
there is a full-fledged biofuels energy sector - and correspondingly high demands for household
cooking and agricultural industries - which is not seen in the UK calculator.
In the web application, in order to ensure good performance while delivering all the requested
features (such as interactive charts), we made several design and technology decisions: for
example, the charts are rendered using Highcharts (as opposed to D3), and we developed our
own UI as well as a social media library. These changes are discussed in detail in the Architecture
and Challenges chapter.
1.3 Involved Parties
As of April 2014, versions of the Energy Calculator have been launched by the Governments of
Belgium, China, South Korea, Taiwan, India and South Africa, while twelve other countries are
working on deploying their versions. The original calculator was designed and developed by Dr.
Tom Counsel from DECC. The original repository may be found here:
Frontend: https://github.com/decc/twenty-fifty
Backend: http://github.com/decc/decc_2050_model
Deployed: http://2050-calculator-tool.decc.gov.uk/pathways/
After seven months of in-depth industry research, debate and development, the first version of
the India Energy Security Scenarios was launched by the Indian Planning Commission on 28th
February, 2014. The link may be found below:
Deployed: http://164.100.44.147/pathways
Official Link: www.indiaenergy.gov.in
3

11. Chapter 2
Architecture and Challenges
2.1 Backend and challenges
2.1.1 Backend
The following image depicts the backend and database architecture of the project.
Figure 2.1: The Backend Architecture
4

12. 2.1. BACKEND AND CHALLENGESCHAPTER 2. ARCHITECTURE AND CHALLENGES
In the interest of complete user transparency, the entire database sits within an editable Excel
file. The Excel itself contains graphs and figures that can be cross checked against those shown
on the webtool. It is available at http://indiaenergy.gov.in/doc/IESS_2047_Version1_
server.xlsx
The Excel spreadsheet is read into a Ruby Project via Dr. Tom Counsel’s “Excel to Code”
library. Several Ruby scripts (model choice, model result, etc.) use the library to read the
Excel and develop a Ruby ORM for the Excel file: the entire data (and Excel formulas) is
translated into C code, which is then packaged (checked, tested and bundled into a Ruby gem)
and made available to the frontend. The motivation for this mapping is to increase the speed
of access compared to directly accessing the Excel sheets.
2.1.2 Explanation for Architecture
The duplication of data in the backend was necessitated by the need for transparency: as the
users (policy experts) are comfortable with Excel, the data had to be stored as an Excel sheet.
Transparency is not limited to the data, but includes the spreadsheet formulas that specify the
relationships between data values. Even the responsive changes on charts seen at the frontend
through, in sequence:
highcharts ⇐= CoffeeScript ⇐= json ⇐= rubyORM ⇐= gem ⇐= C − blob ⇐= excel
actually utilize the relationships and procedures defined in the Excel. Thus the backend
maintains full transparency, allowing the user to verify the data as well as the formulas used in
the project at the Excel level. This implies that a single click on the webpage invokes
a C procedure that replicates the corresponding procedure specified in the Excel
sheet.
Figure 2.2: Overview of the data specification function before re-pack into the Excel database.
5

13. 2.1. BACKEND AND CHALLENGESCHAPTER 2. ARCHITECTURE AND CHALLENGES
2.1.3 Backend Challenges
Due to the constraint that the Excel sheet procedures had to be recompiled with each modifi-
cation to the data, updates originally took 1-2 hours to re-compile and reflect in the frontend.
After several iterations of bugfixes, repairs of broken links and references, updated libraries and
pruning of data, the same was reduced to about 30-40 minutes.
Over the 3-4 month span of my engagement, daily updates were made to the Excel sheet; the
final version at the time of deployment was 3.1 megabytes in size, and had up to 60 worksheets
with an average of 200 rows of data in each; its intermediate versions (jumping between 3 to 6
megabytes) were of the same complexity.
Navigating the Excel file posed a constant challenge, as did verifying that changes were reflected
in the frontend. The frontend javascripts had a strong case-sensitive dependence on the
Excel entries. A broken Ruby gem would take down substantial portions of the frontend,
and the Excel-to-C compilation console output was so verbose (line by line verification of 18
megabytes of C) that failure was not only very costly, but also hard to debug.
One of my immediate contributions to the project was to devise a mini-fied Excel version (with-
out formulae) for a “quick and dirty” compile, to allow front-end development while database
changes were underway. This made it possible to progress on the frontend development while
the team members more involved in policy and data collection updated the Excel in parallel.
Figure 2.3: The big challenges with the Excel model: Broken References, Formulae, and Divided by 0
errors. These arrested all webtool development.
6

14. 2.2. FRONTEND AND CHALLENGESCHAPTER 2. ARCHITECTURE AND CHALLENGES
2.2 Frontend and challenges
2.2.1 Frontend
The following diagram best depicts the frontend architecture:
Figure 2.4: The Frontend Architecture
The frontend has virtually no Ruby code. Ruby mainly unpacks the gem and uses the Sinatra
framework. However, the entire webtool is limited to one HAML file representing a webpage, and
several highcharts and perspectives are loaded in and out using dedicated coffeescript scripts to
fit the purpose. The same have been shown in the diagram above. Over and above this, regular
CSS is not used. There are about 20 files of SCSS code for shaping the look of the website.
The Coffeescript scripts contain Highcharts code that pick up data from the unpacked gem and
inject it into the charts in realtime. The buttons are programmed to trigger update events in a
centralized Coffeescript script (pathways.js).
7

15. 2.2. FRONTEND AND CHALLENGESCHAPTER 2. ARCHITECTURE AND CHALLENGES
2.2.2 Frontend Challenges
The use of a wide variety of new technologies and sparse documentation for the same made
navigating or altering the code very difficult. For example, the axis labels were hard coded
into the library import settings, rather than view-based requirements. The compact legends on
the graphs (not found on the UK website) were difficult to fit in, especially with an additional
information box.
We are happy to note that the speed of the web application could be improved dramatically (ap-
proximately 8x, from 1.2s to 150 ms) by finding and removing inefficiencies in the rake/thinserver
code involving development related redirects. It may be noted that it is quite possible more such
optimizations remain to be found.
Serious challenges were posed by the need to achieve compatibility with older versions of Internet
Explorer. Many necessary changes were undocumented, and had to be determined by trial and
error: for example, removing trailing commas and adding placeholder href ’#’ keys in locations
lost in several thousand lines of code. Firebug and the IE11 developer tools made this task
(among many others) possible, but we were surprised by the lack of documentation for browsers
that are still supported and have wide market share.
IE debugging is critical for any government project. Despite the onset of modern web browsers,
many machines of the Indian Government use IE8 for legacy purposes. Since the project was
specifically designed for a Linux/Unix host (and wont setup on a windows system), a Network
Bridge over a virtual machine running ubuntu, and the thin server was required to make it
appear (to Windows) that IE was opening a weblink from the local network.
Figure 2.5: The deceptive hash character and broken pathway urls were among the many frontend
problems faced.
8

16. 2.3. OTHER CHALLENGES CHAPTER 2. ARCHITECTURE AND CHALLENGES
2.3 Other Challenges
In addition to the challenges posed by the problem itself, as discussed in the previous sections,
• 2-3 hour long compiles
• verbatim case-sensitive dependencies of the frontend (errors like divided by zero, local
references)...
• a requirement for IE8 compatible code
• extremely specific environment requirements (e.g., Ruby 1.9.3p484, gem2.2 and a specific
RVM version on Ubuntu)
certain logistical challenges also hampered development.
The limited availability of machines, internet ports and desks at the planning commission office
made on-site coordination and teamwork difficult. For a long duration in March, I was without
a usable machine due to a laptop crash.The team was new to many best-practices in technology:
for instance, we used no version control system for the server (the code was internally managed
by a two member development team).
Further, I had received no training or formal introduction to the project architecture. My lack
of experience in the relevant technology kept me from contributing significantly for the first two
weeks of my engagement.
Development was greatly delayed by degrees of separation: communication with the policy team,
the reviewers of the frontend, the DECC developers for support, and scheduling mismatches with
the senior officials to clear doubts, all introduced long waits when work was forced to stop. Apart
from issues of my own availability (as I had to balance the needs of the project with four courses
in college), team members were often out of station.
We should add in closing, however, that despite these challenges, it has been an incredible
journey to come through and finally deliver the project without any known major glitches,
bugs, or shortcomings.
9

17. 2.4. TECHNOLOGY CHAPTER 2. ARCHITECTURE AND CHALLENGES
2.4 Technology
Figure 2.6: List of used libraries and
javascript plugins on top, code for indi-
vidual views below running on RubyMine.
The pathways file invokes these views,
each having their own setup, teardown
and updateResults functions.
The following technologies were used:
• Ruby (with Bundler)
• CoffeeScript
• HAML (and ERB) for templating
• Sinatra Web Framework
• Thin Server, and Rack
• HighCharts
• D3 and Related Visualization Libraries
– JQPlots
– AmCharts
– Google Developer Charts
– gRaphael
– mbostock — D3.js — NVD Charts
– D3.js - Rickshaw
• Excel to C database
2.5 Software
The IESS 2047 calculator was developed making
extensive use of both open source software, and
aid from several developers, most notably those
of DECC who very kindly gave us considerable
support. A list of the projects we made use of follows.
• RubyMine
• jsondiff
• sharethis
• VMPlayer, with bridged network
• CoffeeScript-JS Converters
• CSSDeck
• jsFiddle
• IE8 Developer Tools
• Firebug
• Wine/PlayOnLinux
10

18. Chapter 3
User Guide
We present a brief user guide in this chapter; a more comprehensive version may be found at
http://indiaenergy.gov.in/about_howto.php.
3.1 Purpose
The purpose of IESS 2047 is to be able to see the quinquennial repercussions of various degrees of
policy changes (through 38 handles) across demand, conventional and renewable energy supply
sectors and industries of India.
These repercussions range from emissions, land requirements, supply/demand imbalances and
import requirements, costs, energy flows, etc. The same are mapped to 2047, to mark the
centennial of Indian independence.
Target use cases for the tool include the following.
1. To aid policymakers in putting policy ideas into context.
2. To spread awareness about the:
• Magnitude
• Complexity
• and Trade-offs
of the Energy Policy Challenges that face the nation.
It must be noted that the tool does not encourage or discourage any particular policy,
i.e. any particular pathway (a tuple specifying the values set for the 38 handles).
The user can examine their own pathways and compare them on their merit. The entire backend,
data and relationships are openly available through the shared Excel sheet.
11

19. 3.2. HOW TO USE CHAPTER 3. USER GUIDE
3.2 How to Use
1. The tool is available at www.indiaenergy.gov.in.
2. To use, the user clicks on the link to the online webtool version: http://164.100.44.147/.
[A link to the offline backend pdf model is provided as well.]
3. The lower part of the page provides the 38 handles on Policy revolving energy demand,
renewable and conventional energy supply.
Figure 3.1: Various scenario levers, ranging from Least effort(1) to Heroic Effort(2)
4. The user sets their choice of number to indicate policy/scenario preference for the corre-
sponding industry or sector.
Figure 3.2: Various levers as choices.
As the policies are varied as shown to the
right, the Highcharts graphs on the top change
dynamically, reflecting the projected impact
on energy demand, supply and import depen-
dence from 2012 - 2047 in response.
If the user requires detailed information on
how the impact for every sector is calculated, or what the underlying assumptions are, clicking
the corresponding blue question mark will open the one-page explanation (in PDF format).
12

20. 3.2. HOW TO USE CHAPTER 3. USER GUIDE
Figure 3.3: Various perspectives and dimensions of Energy scenario implications
5. The various topbar links allow the user to observe the impact of a given policy on Electricity,
Energy Security, Emissions, Energy Flows and Land Requirements. [The chosen policy remains
consistent across views and need not be re-entered with each change.]
6. For the user’s convenience, predefined pathways (combinations of lever combinations) are pro-
vided, and may be selected from the topbar as shown in Figure 4.5.
7. The Highcharts graphs are highly interactive (as shown in Figure 4.4). The difference between
the stacked area and the total Demand corresponds to the Lighting and Appliances Sector,
which has been switched “off” from the view in the legend. There is also a textbox that provides
additional relevant information.
8. The “Share” tab lets the user share their “pathway” across social media.
Figure 3.4: Example Graph and Results Figure 3.5: Pre-defined pathways
13

21. Chapter 4
Contribution and Feedback
In this project, which involved adapting an India specific version1 of the 2050 Calculator of the
DECC2, my formal role as an intern was to contribute to the project-wide frontend devel-
opment, and general engineering. However, as one of only two developers for the Planning
Commission team3, my role rapidly grew more significant; as expanded upon in the “Work
Distribution”, I participated in adapting the model to Indian conditions as well as handling a
wide variety of technical problems. A complete list of my responsibilities in this project would
include backend model specification, cleanup, extensive bugfixing and optimization, compilation
and setup specification.
4.1 Key Contributions
My key and primary contributions are as listed:
• Development of Information Visualization for the Webtool
– Dynamic Graphs using Highcharts
– Energy Flows Sankey Diagram
• Design and development of the
– topbar (and general site layout/appearance),
– help box
– social media library4
– loader (unused),
– site tour (unused)
– javascript user quiz (unused)
• Complete model specification, backend debugging and coding
• Minified Excel for development process optimization
• Code Optimization by redirect removal
• Responsive and extensive SCSS, frontend design and cleanups
• IE Debugging
• Compilation and Setup
1
of the Planning Commission
2
Department of Energy and Climate Change, UK. Credits: Tom Counsel and team
3
though we received support from the DECC and NIC
4
Not developed or designed. Installed and used the “sharethis” plugin.
14

22. 4.2. FEEDBACK CHAPTER 4. CONTRIBUTION AND FEEDBACK
4.2 Feedback
The user feedback process used by the Planning Commission was informal and based on rapid
feedback and prototyping. There was no formally documented feedback, but weekly meetings
were held with the user/client (administrators in the Planning Commission), and the tool de-
veloped in response to their suggestions. The formal user feedback is, therefore, limited to the
final certification, which is attached as a separate document.
However, we are happy to report that we have received very positive informal feedback from
several of the dignitaries to whom the tool was demonstrated.
Sir James Bevan, the Honourable British High Commissioner to the Republic of India, was
favorably impressed by how in only seven months, a small team of 6-7 young professionals of
the Planning Commission of India, led by Mr. Anil Jain (Advisor Energy), “...reimagined,
re-engineered, and reinvented the webtool...”
The endeavour has also received praise from the Hon. Minister for Energy, Dr. Farooque
Abdullah, who publicly re-emphasized its need and encouraged political parties to use it as a
decision making tool.
15

23. Chapter 5
Conclusion
This report began by explaining what the India Energy Security Scenarios 2047 Calculator is,
who was involved in making it and why. It then discussed the frontend and backend architecture
of the project, as well as the major challenges faced in developing the webtool and adapting it
to use the available data. The report then provides a user guide for the tool, and concludes by
specifying my contribution, its reception and recognition at the Planning Commission of India.
New versions for the IESS 2047 Project and webtool are in the pipeline, but the detailed timeline
has not been determined. Policy experts are working on updating both the structure and content
of the data (as an Excel sheet), which will require corresponding updates to the model schema
as well as to the front-end (such as which features to expose etc.) The development team, in
addition to taking over responsibility for maintenance and bugfixing, are also considering major
redesigns with new charting and visualization libraries, such as:
Figure 5.1: Unused AmCharts Prototype.
• JQPlots
• AmCharts
• Google Developer Charts
• gRaphael
• mbostock — D3.js — NVD Charts
• D3.js - Rickshaw
16