General Overview

MicroGridsPy folder is structured to promote ease of navigation and modularity. The directory hierarchy is organized as follows, with each folder serving a distinct purpose within the project. This structure supports the separation of code, data inputs, environmental configurations, and results, thereby facilitating a clean workflow and project management.

The top-level directory contains the project metadata files such as licensing information, authorship, and general documentation. The codebase is compartmentalized under the ‘Code’ directory, further divided into subdirectories that house various components of the model. These include demand archetypes, environmental data, input parameters, and the core modeling scripts.

Temporary files and results generated by the model execution are stored in ‘tmp’ and ‘Results’ folders, respectively, and user interfaces or scripts for interaction are located within the ‘User Interface’ folder.

Below is the detailed folder structure:

MicroGridsPy-SESAM
├── .spyproject
│   └── ...
├── Code
│   ├── __pycache__
│   │   └── ...
│   ├── Demand_archetypes
│   │   └── ...
│   ├── Environments
│   │   └── ...
│   ├── Inputs
│   │   └── ...
│   ├── Model
│   │   └── ...
│   ├── Results
│   │   └── ...
│   ├── tmp
│   │   └── ...
│   └── User Interface
│   │   └── app_main.py
│   │   └── ...
|   └── README.txt
├── .gitignore
├── AUTHORS
├── LICENSE
├── MGPy Logo.png
├── pubs_list.md
└── README.md

Terminology

The general terminology defined here is used throughout the documentation and the model code and configuration files:

  • Periods: units of time for which the model performs calculations, defining the temporal resolution of the model. For example, if ‘Periods’ is set to 8760, which corresponds to the number of hours in a year, implies that the model calculates energy generation, consumption, and other factors on an hourly basis. Having a high temporal resolution (many periods) allows for a more detailed and accurate simulation of the mini-grid’s performance, which is critical for designing an efficient and reliable system. However, more periods also mean more data to process and potentially longer computation times, so there’s a trade-off between model detail and computational efficiency.

  • Investment Steps: Total number of investment steps during project duration. Based on the setp duration of each investment decision in which the project lifetime will be split. (refer to Advanced Features)

  • Scenarios: Number of scenarios to consider within the optimisation due to the uncertainty associated with the energy generation from renewable sources and the fluctuating energy demand in rural villages. To address this issue, various scenarios are explored aimed at minimizing the overall energy cost for consumers. This involves the creation of diverse and realistic scenarios for both solar power output and energy consumption.

  • Years: Total duration of the project in years.

  • RES_Sources: Number of Renewable Energy Sources (RES) types to consider in the simulation.

  • Generator_Types: Number of different types of gensets that can be installed in the mini-grid.

Parameter name

Symbol

Periods

t

Steps

ut

Scenarios

s

Years

yt

RES_Sources

r

Generator_Types

g

As more generally in constrained optimisation, the following terms are also used:

  • Parameter: a fixed coefficient that enters into model equations

  • Variable: a variable coefficient (decision variable) that enters into model equations

  • Set: an index in the algebraic formulation of the equations

  • Constraint: an equality or inequality expression that constrains one or several variables

  • Model: mathematical framework representing an energy system, including its elements and operational rules. There are two types: * Concrete Model: This type of model is directly built with specific data. It’s akin to a pre-filled template where the data determines the model’s structure and content. * Abstract Model: This is a more flexible template without initial data. It defines the model’s potential structure, and data is applied separately. Ideal for scenarios where the model’s structure is constant but the data varies.

Inputs

MicroGridsPy models are defined, mainly, through .py files, which are both human-readable and computer-readable, .csv files (simple tabular format) for time series and .dat files for data inputs. All the input files are collected inside a single directory called ‘Inputs’. The layout of that directory typically looks roughly like this:

  • Parameters.dat: it contains the primary configuration and parameters of the model. It includes system characteristics, economic parameters, and technology-specific data.

  • Time Series

    • Demand.csv: it contains the electricity demand data in a time series format. It reflects the energy consumption pattern of the grid or area being modeled.

    • RES Time Series.csv: it holds the renewable energy sources’ (RES) generation data. It includes time series data for sources like solar and wind, reflecting their varying generation over time.

    • Grid Availability.csv: it provides data on the availability of the grid (matrix of 0 and 1). It includes information about grid downtime, which is crucial for planning backup or alternative energy sources.

    • Direct Emissions.csv: it contains data related to emissions directly associated with the energy system’s operation. It’s essential for assessing the environmental impact of the minigrid.

    • WT Power Curve.csv: it details the power curve of wind turbines (WT). It specifies the relationship between wind speed and the generated power, crucial for modeling wind energy production.

Each of these files plays a pivotal role in the modeling process, providing necessary data inputs for an accurate representation and analysis of the energy system. They could be directly imported exogenously or simulate and generate endogenously within the model (refer to Advanced Features)

Warning

The Parameters.dat file is a critical and sensitive part of the Pyomo model, as it is directly read and used by the model. However, it should not be manually edited unless for active development of the model. Incorrect modifications can lead to significant errors or unexpected behavior in the optimization process. To ensure accuracy and avoid mistakes, the Python user-friendly interface should be used for data input. This interface is designed to guide users step-by-step, performing data validation and generating the Parameters.dat file correctly.