India Energy Security Scenarios, 2047

Student Name: Aditya GuptaRoll Number: 2011009

BTP report submitted in partial fulfillment of the requirementsfor the Degree of B.Tech. in Computer Science & Engineering

on 23rd April, 2014

BTP Track: Engineering / Development

BTP AdvisorsDr. H B Acharya

Mr. Anil Jain

Indraprastha Institute of Information TechnologyNew Delhi

Student’s Declaration

I hereby declare that the work presented in the report entitled “India Energy SecuirtyScenarios, 2047” submitted by me for the partial fulfillment of the requirements for thedegree of Bachelor of Technology in Computer Science & Engineering at Indraprastha Instituteof Information Technology, Delhi, is an authentic record of my work carried out under guidanceof 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 myknowledge.

.............................. Place & Date: .............................H. B. Acharya

2

Abstract

At current rates of energy supply, demand, and infrastructure development, India would be84% dependent on imports for its energy needs by the year 2047. Indian policymakers face thechallenge of avoiding such a scenario while balancing emissions, flows, costs, land-use, and thepressure of inelastic demand.

The Planning Commission of India, in response to this need, has decided to adapt the approachof the Department of Energy and Climate Change in the UK: Tom Counsel’s Twenty-FiftyEnergy 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 areracing 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 thePlanning Commission. The project was time critical as the mission had to be deployed in 3-4months. The core team’s responsibility ranged from receiving a working open-source projectto understanding, compiling, and re-engineering it; most of the 6-7 team members handled thepolicy-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, WebDevelopment, Ubuntu-Linux, VMWare, IE, CSS3, thin

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

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

Acknowledgments

My sincerest thanks go to Shrestha, my teammate and guide, who not only introduced me toa half year old project and communicated the technical requirements to me, but also stayedpatient and supportive while I picked up the required technology. She went out of her way tocoordinate with me while I attended college, went out of station, wrote exams, and even hada broken laptop. Racing against deadlines and brainstorming strategies together has been anincredible 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, havegiven 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 toundertake this project without sacrificing a semester had it not been for his guidance. I feel hissupport has been very important to my success in this endeavour, and indeed, in many more.

i

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1of the Planning Commission2Department of Energy and Climate Change, UK. Credits: Tom Counsel and team3though we received support from the DECC and NIC4Not developed or designed. Installed and used the “sharethis” plugin.

14

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

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