FORECAST-Sites - A technology diffusion model to simulate industry transformation scenarios with high spatial resolution for energy-intensive industry branches

This repository contains the complete model code of the FORECAST-Sites modelling approach for technology diffusion scenarios for energy-intensive industries. The provided model framework is related to the following publication in the journal Scientific Reports: Scientific Reports - Neuwirth et al. 2024

The development of the framework was conducted within the Horizon Europe project Transience under grant agreement No. 101137606. Within this repository also a first part of Fraunhofer ISI IndustrialSiteDatabase for European primary steel and basic chemical (high value chemicals (HVC), ammonia, and methanol) is published to directly start exporting scenarios for those industry branches.

Table of Contents

1. Introduction
2. Features
3. Installation
4. Usage
5. Configuration
6. Visualization
7. Contributing
8. Badges
9. Architecture
10. Contact
11. Notes

Introduction

Welcome to the Technology Diffusion Model in Energy-Intensive Industries repository. This project aims to provide a comprehensive model for studying the diffusion of new technologies within energy-intensive sectors such as steel, cement, and chemical industries. The model helps in understanding how new technologies are adopted over time and their impact on energy consumption and greenhouse gas emissions.

Features

• Site-specific investments: Models the site-specific investments based on techno-economic decisions according to scenario assumptions.
• Energy demand development: Shows the spatially highly resolved development and correlation of process adoption and energy usage.
• Industrial process diffusion: Evaluates the possible ramp-up of climate-neutral industry processes according to energy price projections and scenario frameworks.
• Customizable Parameters: Allows customization for different industries and scenario assumptions, such as energy price projections and different policies.
• Visualization Tools: Provides jupyter notebooks for results visualization and analysis by generation graphs and charts for better data interpretation.

Installation

The installation of the model follows typical Git and Python based schemes.

Prerequisites

• Python 3.12 or higher
• Nodejs 23.5.0 or higher
• Git
• Python package requirements (see pyproject.toml file)
• Node package requirements (see web/package.json)

Steps

1. Clone the repository: git clone https://github.com/fraunhofer-isi/forecast-sites.git

2. Navigate to the project directory: cd forecast-sites

3. Install the required python packages: pip install .[dev]

4. Install the required nodejs packages:

   cd web
   npm install
   

Usage

1. Configure the model parameters in the following way:

• Navigate to the input folder
• Open the input.sqlite database
• Manipulate or change the industry site and process information by by navigating through the different tables
  • Techno-economic process information can be seen and changed in the table product_process_mapping

2. Configure the modelled products and regions you want to simulate:

• Open the main.py file
• Change id_product and id_region according to your wishes
• Activate or deactivate the consideration of hydrogen infrastructure according to plans from the European Hydrogen Backbone initiative
• Select simulation mode: deterministic or monte-carlo?

3. Configure scenario parameters like CO2-#:

• Open the main.py file
• Change the values and the interpolation functions between your adjusted start and end year of the simulation accordingly

4. Start program

python src/main.py

Configuration

The input.sqlite database and tables allows you to customize several parameters:

• industry site information: Add, adjust or delete industry sites with their necessary information on:
  • Geolocation (longitude, latitude) within the site table,
  • Production units (production output, age, product, and process) within the production unit table.
• process information:
  • Capital expenditures (CAPEX) in the table product_process_mapping
  • Operational expenditures (OPEX) in the table product_process_mapping
  • Specific energy, steam and feedstock consumptions (SEC) in the table product_process_mapping
  • Lifetime in the table product_process_mapping
  • Optional: efficiency gains over years, process emission factors, etc, in the table product_process_mapping
  • Energy carrier and respective shares on energy (process_energy_carrier_mapping), steam ( process_steam_mapping), and feedstock (process_feedstock_mapping) demand
  • Energy carrier emission factors and projections in energy_carrier_emission
• scenario information:
  • Energy carrier price pathways in energy_carrier_cost
  • Pipeline/infrastructure information in the file pipelines.py

Visualization

To visualize the results, the model is provided by a live-visualization based on the mesa package on a openstreetmap within an automatically opened tab in the browser. All results are saved within the output folder as output.sqlite and individual Excel files.

The runtime of the model is generally quite short and depends on the amount of regions, sites, and products modelled. For modelling primary steel and basic chemicals in entire Europe, the runtime is approximately 10 minutes.

Contributing

We welcome contributions to enhance the model or add new features. Please follow these steps:

1. Fork the repository.
2. Create a new branch: git checkout -b feature-branch.
3. Make your changes and commit them: git commit -am 'Add new feature'.
4. Push to the branch: git push origin feature-branch.
5. Create a Pull Request.

Badges

Click on some badge to navigate to the corresponding quality assurance workflow:

Formatting & linting

Checks Python code formatting with ruff

Checks Python folder and file names to be snake_case.

Checks JavaScript code formatting with ESlint

Test coverage

Determines Python test coverage with pytest-cov

Determines JavaScript test coverage with jest

License compliance

Checks Python license compatibility with LicenseCheck

Checks JavaScript license compatibility with license-checker

Creates copyright & license annotations with reuse

Checks for REUSE compliance with reuse

Dependency updates & security checks

Updates dependencies with renovate

Discovers vulnerabilities with CodeQL

Architecture

This section describes the frameworks and design patterns used in the code.

Mesa

mesa is a python framework for agent-based modeling. mesa-geo and mesa_viz_tornado are related extensions.

The concepts and features of mesa help us to structure the code and visualize results. See modeling modules for a description of the Mesa-concepts "model", "agent", and "space" if you are not already familiar with them.

If you do not want to use mesa, you can disable its usage by setting is_using_mesa to False in main.py.

TODO: clarify/update usage without mesa.

Our class MesaSimulation inherits from mesa.Model and implements following workflow functions:

• run: runs the whole simulation by looping over a time span and calling the step function for each step in time.
• step: represents a single step in the simulation.

For each step, mesa delegates the actual work to agents. In our case, the agents are instances of the class SiteAgent. Each SiteAgent wraps a Site and further delegates work to its underlying elements. Also see the Hierarchy described below.

Our class MesaSimulation also includes a custom implementation of the Visitor pattern, separating the hierarchical structure from its post-processing.

If you are interested in the evaluating part of the mesa workflow, see section Data collection below.

Hierarchy

The FORECAST-Sites model consists of a hierarchical structure and its elements are:

• Region
• Site
• ProductionUnit
• Product
• Process

Region

The class Region represents a geographical region. Each region can have several Sites. Furthermore, each region knows about region specific properties like energy carrier prices and Co2 cost.

The mesa framework does not consider regions in its original workflow. Our model considers regions while creating the agents, see function _create_site_agents in MesaSimulation and while processing them. Each agent knows what region it belongs to.

Site

The class Site represents an industrial site. Each site can have several ProductionUnits.

In order to consider sites in the mesa framework, they are wrapped by the class SiteAgent, implementing mesa- and mesa-geo specific functionality.

Production Unit

The class ProductionUnit represents a production unit.

Each ProductionUnit is responsible to produce one distinct Product based on an associated Process.

The Product and its produced amount are fixed, while the associated Process might change over time.

A ProductionUnit maps from a Product to a currently applied Process. It also knows about the previously used Process.

Furthermore, it has knowledge about the timing of investments.

A ProductionUnit is responsible for optimizing the process, see function optimize_process. It does not know about alternative Processes itself, but is able to ask its Product about them.

Product

The class Product represents a product. Each Product knows what Processes can be used to produce it. It is also able to determine the corresponding cost and emission.

Process

The class Process represents a process. Each Process includes data related to its energy demands, investment lifecycle, cost and emissions.

Construction

The factory method pattern is used to separate the construction logic for the model Hierarchy from the model itself. The construction works as follows:

• main.py applies a RegionFactory to create Regions. A region specific DataInterface is passed to the region and its subsequent entities, so that they are able to initialize themselves with the necessary data from input.sqlite.

• Each Region applies a SiteFactory to create corresponding Sites, including their ProductionUnits based on ProductionUnitFactory. The Region also applies an EnergyCarrierFactory to create EnergyCarriers.

• The ProductionUnitFactory applies a ProcessFactory and a ProductFactory to create corresponding entities for the initialization of the ProductionUnits.

Once that Hierarchy has been created, the MesaSimulation creates a SiteAgent for each Site. (The MesaSimulation itself is created by the class MesaServer.)

Visitor pattern

The Visitor design pattern allows us to separate our model Hierarchy from its processing. It enables us to add new operations without touching the existing model classes.

Currently main.py creates instances of TabularResultVisitor and ShapeFileVisitor to process the model results. You can add new visitors by inheriting from Visitor and implementing its standardized functions (for example visit_region).

As part of each simulation step, all the visitors will be passed down the model hierarchy to visit all the elements and interact with them. Also see the step function in MesaSimulation and the accept functions in Region, Site, and so on. At the end of the simulation, the finalize function of each visitor will be called.

Data collection

The mesa concept of DataCollector and reporters serves a similar purpose as our Visitor pattern but differs in its details.

If you are interested in the mesa data collection workflow, you can take the property agent_count as en example. Also see the related methods _create_data_collector in MesasSimulation and _create_visualization_elements in MesaServer.

Also see related visualization classes

• MapModule (custom implementation for leaflet maps) and
• ChartVisualization from mesa-viz-tornado.

Contact

For any questions or feedback, please contact the project maintainer at Marius.Neuwirth@isi.fraunhofer.de.

Licenses

This project is free and open source software:

• It is licensed under the GNU Affero General Public License v3 or later (AGPLv3+) - see LICENSE.
• It uses third-party open source modules, see
  
  • pyproject.toml
  • THIRDPARTY.md
  • package.json
  • web/THIRDPARTY.md.

Notes

PUBLISHING NOTES

This project has received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement No. 101137606.