The MRIO framework

The basic building blocks of EE MRIO models are (1) domestic input-output (IO) tables linked with (2) detailed bilateral trade data and extended with (3) environmental accounts [36].

The first building block, the domestic IO tables, depict the inter-industry relationship within an economy. These are typically square tables with column/row indices for all industries within a country. One column in these tables describes the inputs (products from other industries) required by one specific industry (or more general product production process) to produce its output. Arranging these column vectors into a two-dimensional matrix, the rows then depict all users of the output of a specific industry. Thus, the column of an IO table describes an industry in its role as user of products while the corresponding row describes its role as supplier.

In most cases these tables are further extended by sections representing the value added of each industry, taxes and subsidies as well as final consumption (private and government consumers as well as capital formation). Input-output tables following the United Nations System of National Accounts, UN SNA [31], system are inherently complete and consistent, thus capturing all economic activity within a country where the sum over all inputs into industries (including imports) equals the output of all industries (including exports). The data for domestic input output tables are typically gathered by industry surveys conducted by national statistical agencies as the tables form an integral part of the national accounts.

The pivotal point to derive global multi regional input output tables from these domestic ones is to connect them through detailed description of bilateral trade flows. These connect each industry/product sector of a specific country with all other sectors of all other countries, thus describing how the output of one sector (as export) is used as input (through imports) in any other country. Similar to domestic IO tables, global MRIOs are inherently complete and consistent, thus capturing all global trade flows and economic activity with two caveats: often multiple countries are aggregated to world regions and the tables usually only describe the official economy (thus reported economic activity) and exclude any shadow economic or financial flows due to criminal activity.

Since global MRIOs allow the tracking of products through the global supply chain they have been proven to be an ideal tool to also track the environmental burden associated with the production processes along the supply chains. In order to do so, one conceptually regards environmental effects like land use, emissions or material use as required inputs into the production process of a certain product. This links the environmental consequences due to the production of a product to the product itself. Fundamentally, these opens up two contrasting perspectives: Production-based environmental accounts, which describe the environmental consequences at the place of production and the consumption-based environmental accounts, which assigns the environmental consequences of production to the final consumer of the product. The later are also known as various kinds of footprints and became a stable tool to describe the environmental performance of countries [3, 7, 30].

The mathematical handling of these tables is described further below in the section “Mathematical Background”.

Current status for MRIO analysis software

In contrast to other Industrial Ecology methodologies like Life Cycle Assessment (e.g. Brightway [16], openLCA [18]) or Material Flow Analysis (e.g. STAN [1]), few generally available analysis packages for (Multi-Regional) Input-Output tables are available [19]. One of the very few well documented and stand-alone packages for IO analysis, PyIO [17], is not available for Python 3 and does not provide parsers for current MRIO databases (the package has not been updated since 2011 but is still available at http://www.real.illinois.edu/pyio). Another framework, the MRIOLab suite [2, 11] takes a different approach: it provides a virtual lab for the compilation of MRIO tables and thereby streamlining the compilation of MRIO tables. The MRIOLab also includes functions for MRIO analysis. These, however, are not well suited for the analysis of MRIO tables compiled independent of the MRIOLab since the tables can not fully reproduced within the MRIOLab [22, 23]. As a consequence of the lack of a generic MRIO analysis toolkit, MRIO analysis today relies on often ad-hoc produced scripts and functions. This hinders reproducibility of results and the reuse of previous coding efforts. Here I present the open source tool Pymrio, a Python 3 package, which aims to close this method gap for EE MRIO analysis.

The article proceeds with a description of the architecture of Pymrio, including the mathematical background and implementation details. This is followed by a short tutorial with a simple use case for Pymrio. This tutorial is also available as a Jupyter notebook. The reuse potential and future development plans are pointed out at the end of the article.

Mathematical Background

This section gives an overview about the mathematical background of EE MRIO analysis as used in Pymrio.

The focus of this section is on the specifics of the multi-regional aspects of input-output analysis. Note, however, that Pymrio can also be used for analysing simple single country input-output tables. Readers unfamiliar with input-output analysis are referred to the standard textbook for input-output analysis by Miller and Blair [15]. Exercises of this book are also used in the online documentation which also highlights how Pymrio can be used for teaching of input-output methods (https://pymrio.readthedocs.io/en/latest/notebooks/pymrio_directly_assign_attributes.html).

Generally, mathematical routines implemented in Pymrio follow the equations described below. If, however, a more computationally efficient mechanism was available this was preferred. In these cases, the original formula remains as comment in the source code. Mostly, this was the case when instead of a matrix multiplication with a diagonalized vector the operation can be efficiently executed using numpy broadcasting mechanisms [32].

The Input-Output analysis implemented in Pymrio follows the classic Leontief demand-style modeling [12]. To do so, MRIO tables describe the global inter-industries flows within and across countries for k countries with a transaction matrix Z:

Each submatrix on the main diagonal (Z_i,i) represents the domestic interactions for each industry n. The off diagonal matrices (Z_i,j) describe the trade from region i to region j (with i, j = 1, ⋯, k) for each industry. Accordingly, global final demand can be represented by

with final demand satisfied by domestic production in the main diagonal (Y_i,i) and direct import to final demand from country i to j by Y_i,j.

The global economy can thus be described by:

with e representing the summation vector (column vector with 1’s of appropriate dimension) and x the gross output.

The direct requirement matrix A is given by multiplication of Z with the diagonalized and inverted gross output x:

Based on the linear economy assumption of the IO model, gross output x can then be determined for any arbitrary vector of final demand y by multiplying with the total requirement matrix (Leontief matrix) L.

IO systems can be extended with various extensions (satellite accounts). Among others these can represent factors of production (e.g. value added, employment) and environmental stressors associated with production. These direct factors, contained in matrix F, can be normalized to the output per sector x by

Multipliers (total, direct and indirect, requirement factors for one unit of output) are then obtained by

Total requirements (footprints in case of environmental requirements) for any given final demand vector y are given by

Setting the domestically satisfied final demand Y_i,i to zero (Y_t = Y – Y_i,j | i = j) allows to calculate the factors of production occurring abroad (embodied in imports)

The factors of production occurring domestically to satisfy final demand in other countries is given by:

where $\hspace{0.33em}\widehat{}\hspace{0.33em}$M19 \documentclass[10pt]{article} \usepackage{wasysym} \usepackage[substack]{amsmath} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage[mathscr]{eucal} \usepackage{mathrsfs} \usepackage{pmc} \usepackage[Euler]{upgreek} \pagestyle{empty} \oddsidemargin -1.0in \begin{document} \[ \;\widehat {}\; \] \end{document} indicates diagonalization of the resulting column-vector of the term underneath.

If parts of the environmental stressors occurring during the final use of product, these can be represented by F_Y (e.g. household emissions). These need to be added to the total production- and consumption-based accounts to obtain the total impacts per country. Total territorial requirements/emissions per region i are therefore given by summing over the stressors per sector (0⋯m) plus the stressors directly linked to final consumption for all final demand categories (0⋯w) of that region.

Similarly, total requirements (footprints in case of environmental requirements) per region i are given by summing the detailed footprint accounts and adding the aggregated final demand stressors.

Internally, the summations are implemented with the group-by functionality provided by the Pandas package [14].

Aggregation

For the aggregation of the MRIO system the matrix B_k defines the aggregation matrix for regions and B_n the aggregation matrix for sectors.

With w and x defining the aggregated number of countries and sectors, respectively. Entries b are set to 1 if the sector/country of the column belong to the aggregated sector/region in the corresponding row and zero otherwise. The complete aggregation matrix B is given by the Kronecker product of B_k and B_n:

This effectively arranges the sector aggregation matrix B_n as defined by the region aggregation matrix B_k. Thus, for each 0 entry in B_k a block B_n * 0 is inserted in B and each 1 corresponds to B_n * 1 in B.

The aggregated IO system can then be obtained by

and

with I defined as the identity matrix with the size equal to the number of final demand categories per country.

Factors of production are aggregated by

and stressors occurring during final demand by

Implementation

The main design principle of Pymrio is based on the concept that an EE MRIO system can be effectively represented as an object in an Object-Oriented Programming (OOP) language. In Pymrio, such an EE MRIO object consists of a core component describing the economic relationships grouped with a various number of components describing the environmental and/or social extensions (satellite accounts, see Figure 1). All components of the main object are in turn represented as objects, allowing to implement specific methods for each sub-component.

This architecture described above was implemented in Python 3.7. The various tables of the MRIO system are stored in Pandas DataFrames [14], therefore building upon a well-tested data-science framework. As a consequence, besides the specific methods implemented by Pymrio, the full functionality of Pandas and the underlying NumPy framework [32] can be used to modify the MRIO data.

Methods implemented in Pymrio which go beyond basic Pandas functionality are accompanied by a corresponding test harness which ensures the formal correctness of the method. The full source code is hosted on a public code repository together with an extensive documentation and tutorials https://github.com/konstantinstadler/pymrio. Pymrio is openly available under the GNU General Public License v3.0.

Parsing and Storage

To date, no standard way of storing MRIO databases has been defined. For example, the WIOD database [29] is provided as xlsx tables, whereas Eora [10] and EXIOBASE [28] use (compressed) csv tables. For the two latter, however, the approach differs as Eora26 uses pure numerical tables with separate files describing the headers, whereas EXIOBASE uses csv tables which include the headers. To ease the use of different MRIO systems, Pymrio include parsers for the different formats. After parsing a MRIO system, Pymrio stores all data in a consistent way. For each component (core system and extension) data is stored in a separate folder. While the storage-format of the actual numerical data can be defined by the user, each storage folder also contains a json file (file_parameters.json) which contains information about the used format. Using the common json file format for storing the file meta data allows to easily and automatically import the data in other programming environments. By default, each table is stored as a tab-separated text file format, including row and column headers. The folder with the economic core also contains a file named “metadata.json” which includes information about version, name and system (industry-by-industry or product-by-product) as well as a record of modifications to the particular MRIO system (including when it was downloaded, applied aggregations, removal/addition of extensions, etc.).

Usage

The following section provides a quick start guide for using Pymrio beginning at the installation followed by a basic input-output calculation example. For the example here, the WIOD MRIO database [29] is used. However, after downloading and parsing the database the same methods are available for any EE MRIO system.

An interactive Jupyter notebook with the following code tutorial can be downloaded at https://git.io/fjjUk. As the code example here only show the code inputs, refer to the notebook to see the output of a specific command. An cloud-based virtual environment with the code example can be run in the BinderHub available at https://cutt.ly/vwmOpA3.

Pymrio is a Python [21] package, Python version ≥ 3.7 is required. The Pymrio package is hosted on PyPI [20] and the Anaconda Cloud [5]. Therefore, you can either use

pip install pymrio –upgrade

or

conda install -c conda-forge pymrio

to install Pymrio and all required packages.

Pymrio can then be used in any Python programming environment.

Throughout the code examples below, it is assumed that Pymrio is imported as follows:

import pymrio

First, the Pymrio MRIO download function is used to get the WIOD MRIO data-base with:

raw_wiod_path = ‘/tmp/wiod/raw’
pymrio.download_wiod2013(storage_folder=raw_
wiod_path, years=[2008])

This downloads the 2008 MRIO table from WIOD. Omitting the year parameter would result in a download of all years. The function returns a Pymrio meta data object, which gives information about the WIOD version, system (in this case industry-by-industry) and records about from where the data was received (see SI cell 6).

To parse the database into a Pymrio object use:

wiod = pymrio.parse_wiod(raw_wiod_path, year=2008)

The available data can be explored by for example

wiod.get_sectors()
wiod.get_regions()

The transaction matrix can be inspected with

wiod.Z

which returns a panda DataFrame with the recorded monetary flows.

WIOD includes several extensions, which are stored as sub-objects (see Figure 1) in Pymrio. For example, in order to see the AIR emissions provided by WIOD:

wiod.AIR.F

WIOD, however, does neither provide any normalized data (A-matrix, satellite account coefficient data) nor any consumption-based accounts (footprints).

In order to calculate them, one could go through all the missing data and compute each account.

Pymrio provides the required functions, for example to calculate the A-matrix:

x = pymrio.calc_x(Z=wiod.Z, Y=wiod.Y)
A = pymrio.calc_A(Z=wiod.Z, x=x)

Alternatively, Pymrio provides a function which identifies all missing accounts and calculates them:

wiod.calc_all()

At this point, a basic EE MRIO analysis is accomplished. For example, the regional consumption-based accounts of the AIR emissions are now given by:

wiod.AIR.D_cba_reg

Units are stored separately in

wiod.AIR.unit

Pymrio can be linked with the country converter coco [27] to ease the aggregation of MRIO and results into different classifications. Using the country converter, WIOD can easily be aggregated into EU and non-EU countries with singling out Germany and the UK by:

import country_converter as coco
wiod.aggregate(region_agg = coco.agg_conc(
     original_countries=‘WIOD’,
     aggregates=[{‘DEU’: ‘DEU’, ‘GBR’:’GBR’},
     ‘EU’],
     missing_countries=‘Other’,
     merge_multiple_string=None))
wiod.rename_regions({‘EU’:‘Rest⊔of⊔EU’}

To visualize the results for example for CH₄ the matplotlib framework [4] can be used (Figure 2):

import matplotlib.pyplot as plt
with plt.style.context(‘ggplot’):
    wiod.AIR.plot_account(‘CH4’)
    plt.savefig(‘airch4.png’, dpi=300)
    plt.show()

To calculate the source (in terms of regions and sectors) of a certain stressor or impact driven by consumption, one needs to diagonalize this stressor/impact.

This can be done with Pymrio by:

diag_CH4 = wiod.AIR.diag_stressor(‘CH4’)

and be reassigned to the aggregated WIOD system:

wiod.CH4_source = diag_CH4

In the next step the automatic calculation routine of Pymrio is called again to compute the missing accounts in this new extension:

wiod.calc_all()

The diagonalized CH4 data now shows the source and destination of the specified stressor (CH₄):

wiod.CH4_source.D_cba

In this square consumption-based accounts matrix, every column represents the amount of stressors occurring in each region – sector driven by the consumption stated in the column header. Conversely, each row states where the stressor impacts occurring in the row are distributed to (from where they are driven).

If only one specific aspect of the source is of interest for the analysis, the footprint matrix can easily be aggregated with the standard Pandas groupby function. For example, to aggregate to the source and receiving region of the stressor:

CH4_source_reg = wiod.CH4_source.D_cba.groupby(
   level=‘region’, axis=0).sum().groupby(
   level=‘region’, axis=1).sum()

Which can then be visualised using the seaborn heatmap [35] with (Figure 3):

import seaborn as sns
CH4_source_reg.columns.name = ‘Receiving⊔region’
CH4_source_reg.index.name = ‘Souce⊔region’
sns.heatmap(CH4_source_reg, vmax=5E6,
            annot=True, cmap=‘YlOrRd’,
            linewidths=0.1,
            cbar_kws={‘label’:
            ‘CH4⊔emissions⊔({})’.format(
                wiod.CH4_source.unit.unit[0])})
plt.show()

Storing the MRIO database can be done with

storage_path = ‘/tmp/wiod/aly’
wiod.save_all(storage_path)

from where it can be received subsequently by:

wiod = pymrio.load_all(storage_path)

The meta attribute of Pymrio mentioned at the beginning kept track of all modifications of the system. This can be shown with:

wiod.meta

Custom notes can be added to the history with:

wiod.meta.note(“Custom⊔note”)

The history of the meta data can be filtered for specific entries like:

wiod.meta.file_io_history

This tutorial gave a short overview about the basic functionality of Pymrio. For more information about the capabilities of Pymrio check the online documentation at http://pymrio.readthedocs.io [26].

Archive

Name: Zenodo

Persistent identifier: https://doi.org/10.5281/zenodo.1146054

Licence: GPL v3

Publisher: Konstantin Stadler

Version published: 0.4.5 and earlier versions. The DOI above always resolves to the latest version, previous versions can be identified with separate DOIs (see versions sections on the Zenodo repository page).

Date published: 21/03/21 (version 0.4.5)

Code repository

Name: Github (Pymrio is also hosted on pypi and anaconda cloud)

Persistent identifier: https://github.com/konstantinstadler/pymrio

Licence: GPL v3

Date published: 21/03/21 (version 0.4.5)

Emulation environment

Name: MyBinder Jupyter Notebook of the tutorial included above

Persistent identifier: https://mybinder.org/v2/gh/konstantinstadler/pymrio_article/master?filepath=%2Fnotebook%2Fpymrio-tutorial-for-wiod.ipyn

Licence: CC BY 4.0

Date published: 18/01/18