From 79f27b37ce8efad3e775514b71971f0860ef3b6d Mon Sep 17 00:00:00 2001 From: spyrostz Date: Wed, 3 Jun 2026 10:08:11 +0200 Subject: [PATCH 1/2] Updated mkdocs and all dependencies to latest versions. --- wiki/.circleci/config.yml | 8 +++----- wiki/mkdocs.yml | 3 +-- wiki/readthedocs.yml | 11 ++++++----- wiki/requirements.txt | 9 ++++----- 4 files changed, 14 insertions(+), 17 deletions(-) diff --git a/wiki/.circleci/config.yml b/wiki/.circleci/config.yml index 1126644288..7820854df2 100644 --- a/wiki/.circleci/config.yml +++ b/wiki/.circleci/config.yml @@ -3,14 +3,12 @@ version: 2 jobs: tests: docker: - - image: python:3.6-alpine3.9 + - image: python:3.12-alpine steps: - checkout - run: command: | - pip install virtualenv - - python3.6 -mvirtualenv --no-site-packages --no-download . + python3 -m venv . source bin/activate @@ -30,7 +28,7 @@ jobs: command: | pip install pylinkvalidator html5lib - sed -i -e 's/\(decode("ascii")\)/\1.replace(" ", "%20")/g' /usr/local/lib/python3.6/site-packages/pylinkvalidator/urlutil.py + sed -i -e 's/\(decode("ascii")\)/\1.replace(" ", "%20")/g' /usr/local/lib/python3.12/site-packages/pylinkvalidator/urlutil.py pylinkvalidate.py --parser=html5lib -P http://localhost:8000 diff --git a/wiki/mkdocs.yml b/wiki/mkdocs.yml index 4afeba6b4e..671aa646ae 100644 --- a/wiki/mkdocs.yml +++ b/wiki/mkdocs.yml @@ -183,7 +183,6 @@ markdown_extensions: - toc: permalink: true toc_depth: 4 - - mdtooltips - attr_list - md_in_html - pymdownx.arithmatex: @@ -198,6 +197,6 @@ plugins: - redirects: redirect_maps: # When trying to reach the root page, redirect to the documentation page - '': 'https://gridsingularity.github.io/gsy-e/documentation/' + 'index.md': 'https://gridsingularity.github.io/gsy-e/documentation/' 'blockchain-installation.md': 'gsy-node.md' 'two-sided-pay-as-bid.md': 'https://gridsingularity.github.io/gsy-e/market-types/#two-sided-pay-as-bid-market' diff --git a/wiki/readthedocs.yml b/wiki/readthedocs.yml index 0222114323..d575dbda4c 100644 --- a/wiki/readthedocs.yml +++ b/wiki/readthedocs.yml @@ -1,13 +1,14 @@ +version: 2 + build: - image: latest + os: ubuntu-22.04 + tools: + python: "3.12" python: - version: 3.7 install: - requirements: requirements.txt -version: 2 -mkdocs: +mkdocs: configuration: mkdocs.yml fail_on_warning: false - diff --git a/wiki/requirements.txt b/wiki/requirements.txt index ec1c0fbe2b..e14e6f9f78 100644 --- a/wiki/requirements.txt +++ b/wiki/requirements.txt @@ -1,6 +1,5 @@ -md-tooltips==1.3.1 -mkdocs-redirects==1.0.4 -mkdocs==1.3.0 -pymdown-extensions==10.4 -markdown==3.2.1 +mkdocs-redirects==1.2.2 +mkdocs==1.6.1 +pymdown-extensions==10.21.3 +markdown==3.10.2 mkdocs-exclude-search==0.6.6 From fd848d343b134bc226f4b8a0b3ce0e1f051b7710 Mon Sep 17 00:00:00 2001 From: spyrostz Date: Wed, 3 Jun 2026 10:12:45 +0200 Subject: [PATCH 2/2] Corrected trading-agents-and-strategies page link. --- wiki/docs/assets-installation.md | 2 +- wiki/docs/battery.md | 2 +- wiki/docs/community-settings.md | 4 ++-- wiki/docs/configuration.md | 2 +- wiki/docs/general-settings.md | 2 +- wiki/docs/heat-pumps-general.md | 2 +- wiki/docs/model-storage.md | 2 +- wiki/docs/releases.md | 2 +- wiki/docs/setup-configuration.md | 2 +- wiki/docs/solar-panels.md | 4 ++-- wiki/docs/technical-approach.md | 2 +- 11 files changed, 13 insertions(+), 13 deletions(-) diff --git a/wiki/docs/assets-installation.md b/wiki/docs/assets-installation.md index 9634a55d5f..bd5358d5a5 100644 --- a/wiki/docs/assets-installation.md +++ b/wiki/docs/assets-installation.md @@ -47,7 +47,7 @@ For example, a user can input 5 hrs_per_day and give a wider range for hrs_of_da - If there is sufficient energy at affordable rates, the load will consume in the first 5 hours, i.e. from 02:00 until 07:00, with no energy demand unmatched. - In case energy prices are too high during the time-interval from 04:00 to 16:00, the load will consume from 02:00 until 04:00, turn off, and consume from 16:00 until 18:00, resulting in one hour of energy demand unmatched. -For information on changes in buying and selling rates, please see: [Trading strategies](trading-agents-and-strategies) +For information on changes in buying and selling rates, please see: [Trading strategies](trading-agents-and-strategies.md) ## Batteries diff --git a/wiki/docs/battery.md b/wiki/docs/battery.md index aa7b1bbc09..b82b6fdc12 100644 --- a/wiki/docs/battery.md +++ b/wiki/docs/battery.md @@ -43,7 +43,7 @@ Note: The default setting of the battery component is 100% energy conversion eff In general all bids and offers follow the physical constraint of the set `max_abs_battery_power_kW value. The accumulated energy per market slot cannot exceed this power value times the length of the market slot, in hours. Energy sold and bought cancel each other out, meaning that if 2kWh are both sold and bought in the same market slot, the relative power remains 0kW. -For the buying rate increase and selling rate decrease behaviour, please see the [Trading Strategies page](trading-agents-and-strategies). +For the buying rate increase and selling rate decrease behaviour, please see the [Trading Strategies page](trading-agents-and-strategies.md). ###Buying energy in the [One-Sided Market](market-types.md#one-sided-pay-as-offer-market) diff --git a/wiki/docs/community-settings.md b/wiki/docs/community-settings.md index 4b35f28881..954d22ff6c 100644 --- a/wiki/docs/community-settings.md +++ b/wiki/docs/community-settings.md @@ -33,9 +33,9 @@ In the advanced tab, there are settings referring to the market type information 1. Description: add an optional description of the simulated community 2. Spot market type: select either the one-sided or the two-sided market type - - In the [One-Sided Pay-as-Offer spot market](market-types.md#one-sided-pay-as-offer-market), agents representing energy producers, including prosumers (sellers), post offers in the market with an energy price determined by the assets' [trading strategy](trading-agents-and-strategies) + - In the [One-Sided Pay-as-Offer spot market](market-types.md#one-sided-pay-as-offer-market), agents representing energy producers, including prosumers (sellers), post offers in the market with an energy price determined by the assets' [trading strategy](trading-agents-and-strategies.md) - In the two-sided spot market, where buyers are able to place bids in the market alongside the offers placed by sellers, users can choose the [Two-Sided Pay-as-Bid Market](market-types.md#two-sided-pay-as-bid-market) or the [Two-Sided Pay-as-Clear Market](market-types.md#two-sided-pay-as-clear-market) -3. Matching algorithm: select pay-as-bid, pay-as-clear or an external [trading algorithm](trading-agents-and-strategies) +3. Matching algorithm: select pay-as-bid, pay-as-clear or an external [trading algorithm](trading-agents-and-strategies.md) 4. Spot markets number: set the number of active spot markets where the energy assets represented by trading agents can trade 5. Spot market length: set the [length of the spot market](market-types.md#market-slots) in minutes 6. Tick length: set the [length of ticks](market-types.md#market-ticks) in seconds diff --git a/wiki/docs/configuration.md b/wiki/docs/configuration.md index b323811637..31f672d311 100644 --- a/wiki/docs/configuration.md +++ b/wiki/docs/configuration.md @@ -1 +1 @@ -There are four different types of energy assets a user can currently configure when modelling energy communities on Grid Singularity’s web-based simulation user interface, the [Singularity Map](https://gridsingularity.com/singularity-map){target=_blank} - [solar panels (PVs)](solar-panels.md), [consumption (load) profiles](consumption.md), [batteries (storages)](battery.md) and [heat pumps](heat-pumps-general.md). Each simulated community can consist of at least two participating members (homes representing households, buildings or other community members) and up to 1000 digital agents representing assets and/or homes. Simulation users can model an energy community quickly by adding template homes and assets using the express options, or they can configure the technical details and trading parameters by exploring the advanced options for each asset. Each asset within a community can [trade energy](trading-agents-and-strategies) with other assets, as well as with the external suppliers via grid network (also termed the grid market). By default, assets shall buy/sell energy locally, interacting with their neighbours, and only in case of any gaps in the local market (either caused by insufficient energy production / consumption in the community, or by inefficient or not affordable trading settings), purchase the energy from the external energy supplier (usually a utility). Trading occurs in [market slots](market-types.md#market-slots), which are by default 15-minute time slots in which energy assets can exchange energy at market rates. The market slot length can be changed by a user to reflect the spot market length of any region of the world. Users can set custom market rates based on a smart trading algorithm that can be applied to any asset, or use default rates when adding assets to their communities, with the latter conditioned upon the provided [Market Maker](model-market-maker.md) (utility) rate and any applicable feed-in-tariff. +There are four different types of energy assets a user can currently configure when modelling energy communities on Grid Singularity’s web-based simulation user interface, the [Singularity Map](https://gridsingularity.com/singularity-map){target=_blank} - [solar panels (PVs)](solar-panels.md), [consumption (load) profiles](consumption.md), [batteries (storages)](battery.md) and [heat pumps](heat-pumps-general.md). Each simulated community can consist of at least two participating members (homes representing households, buildings or other community members) and up to 1000 digital agents representing assets and/or homes. Simulation users can model an energy community quickly by adding template homes and assets using the express options, or they can configure the technical details and trading parameters by exploring the advanced options for each asset. Each asset within a community can [trade energy](trading-agents-and-strategies.md) with other assets, as well as with the external suppliers via grid network (also termed the grid market). By default, assets shall buy/sell energy locally, interacting with their neighbours, and only in case of any gaps in the local market (either caused by insufficient energy production / consumption in the community, or by inefficient or not affordable trading settings), purchase the energy from the external energy supplier (usually a utility). Trading occurs in [market slots](market-types.md#market-slots), which are by default 15-minute time slots in which energy assets can exchange energy at market rates. The market slot length can be changed by a user to reflect the spot market length of any region of the world. Users can set custom market rates based on a smart trading algorithm that can be applied to any asset, or use default rates when adding assets to their communities, with the latter conditioned upon the provided [Market Maker](model-market-maker.md) (utility) rate and any applicable feed-in-tariff. diff --git a/wiki/docs/general-settings.md b/wiki/docs/general-settings.md index 82f30c719a..304e2e90af 100644 --- a/wiki/docs/general-settings.md +++ b/wiki/docs/general-settings.md @@ -41,7 +41,7 @@ Once the modelling is completed, the user goes to the [Results page](results.md) ## Backend Simulation Configuration -In the backend, the simulation process is slightly different. There is no need to login to set up a simulation. The user first needs to download the code from our Github Repository (Installation Instructions for [Linux](linux-installation-instructions.md), [Mac](ios-installation-instructions.md) and [Windows](vm-installation-instructions.md)). In the setup-file (in Python programming language), general and [trading strategy](trading-agents-and-strategies) settings can be defined. Examples can be found in the relevant [Grid Singularity GitHub](https://github.com/gridsingularity/gsy-e/tree/master/src/gsy_e/setup){target=_blank} folder. +In the backend, the simulation process is slightly different. There is no need to login to set up a simulation. The user first needs to download the code from our Github Repository (Installation Instructions for [Linux](linux-installation-instructions.md), [Mac](ios-installation-instructions.md) and [Windows](vm-installation-instructions.md)). In the setup-file (in Python programming language), general and [trading strategy](trading-agents-and-strategies.md) settings can be defined. Examples can be found in the relevant [Grid Singularity GitHub](https://github.com/gridsingularity/gsy-e/tree/master/src/gsy_e/setup){target=_blank} folder. This is the most basic skeleton for a setup-file: diff --git a/wiki/docs/heat-pumps-general.md b/wiki/docs/heat-pumps-general.md index 1be33e6eff..a87cddb4b9 100644 --- a/wiki/docs/heat-pumps-general.md +++ b/wiki/docs/heat-pumps-general.md @@ -4,6 +4,6 @@ A heat pump is an energy asset used to heat water and premises by extracting hea For homes (or other energy community participants) that are connected to district heating we have developed a digital twin of a heat pump that mimics and replaces the heat demand currently satisfied by a district heating network, modelled as a virtual heat pump (VHP) with storage and a related trading strategy. This VHP implementation is [available exclusively in the backend source code](virtual-heat-pump.md), since it will likely be used exclusively by energy researchers to simulate how district heating could be replaced by a heat pump to compare their respective performance. Inversely, the VHP can also be used to calculate the heat demand of homes or other energy community participants, and consequently enable the simulation of a district heating connection that would satisfy this heat demand as opposed to electricity assets. -Finally, for simulations that simply want to account for the district heating connection without considering a potential replacement with heat pumps, the digital twin of the district heating supply for the measured heat demand can be modelled as a "heat market maker", i.e. digital trading agent with a specific [trading strategy](trading-agents-and-strategies) representing the district heating provider, which will only sell heat energy to the heat demand digital twin of the respective community member. The selling price of this market maker will be the district heating price that the heat consumer currently pays, in cents/kWh. The heat demand digital twin, in turn, is modelled as a load with a “consumption profile” defined by the measured heat demand in kWh. Thus, the “heat market maker” will only be used in order to cover the heat demand of the heat load, accounting for the monetary cost of heating. +Finally, for simulations that simply want to account for the district heating connection without considering a potential replacement with heat pumps, the digital twin of the district heating supply for the measured heat demand can be modelled as a "heat market maker", i.e. digital trading agent with a specific [trading strategy](trading-agents-and-strategies.md) representing the district heating provider, which will only sell heat energy to the heat demand digital twin of the respective community member. The selling price of this market maker will be the district heating price that the heat consumer currently pays, in cents/kWh. The heat demand digital twin, in turn, is modelled as a load with a “consumption profile” defined by the measured heat demand in kWh. Thus, the “heat market maker” will only be used in order to cover the heat demand of the heat load, accounting for the monetary cost of heating. The heat pump and the virtual heat pump development has been undertaken in the framework of the [HYPERGRYD Project](https://hypergryd.eu/){target=_blank}, funded by the European Union’s H2020 Programme under Grant Agreement No. 101036656. diff --git a/wiki/docs/model-storage.md b/wiki/docs/model-storage.md index cc91574712..859c2e318a 100644 --- a/wiki/docs/model-storage.md +++ b/wiki/docs/model-storage.md @@ -57,7 +57,7 @@ As an example, considering an `initial_selling_rate` of 30 cents/kWh and a `fina In general all bids and offers follow the physical constraint of the set `max_abs_battery_power_kW` value. The accumulated energy per market slot cannot exceed this power value times the length of the market slot. Energy sold and bought cancel each other out, meaning that if 2kWh are both sold and bought in the same market slot, the relative power remains 0kW. -For the buying rate increase and selling rate decrease behaviour, please see the [Trading Strategies page](trading-agents-and-strategies). +For the buying rate increase and selling rate decrease behaviour, please see the [Trading Strategies page](trading-agents-and-strategies.md). ###Buying Energy in [One-Sided Market](market-types.md#one-sided-pay-as-offer-market): diff --git a/wiki/docs/releases.md b/wiki/docs/releases.md index e16081a50d..9e092c514d 100644 --- a/wiki/docs/releases.md +++ b/wiki/docs/releases.md @@ -74,7 +74,7 @@ The following features were implemented : * [Grid fees](grid-fee-accounting.md#constant-grid-fee-calculation) integrated in the Results page - [Energy Pricing](results.md#energy-pricing) graph for each market * Total grid fees reported in the Scoreboard page that demonstrates market performance metrics for each collaboration simulation. * Net Energy calculation added to Results page - [Energy Trade Profile](results.md#energy-trade-profile) graph in order to calculate the peak energy at a market node in the simulation. The current peak imports and exports were previously calculated based on the cumulative trades, but are now calculated from the net energy consumption, which can be a net import or export. -* Updated load final selling rate and PV initial buying rate in the [template strategies](trading-agents-and-strategies) now take the total grid fees into account in addition to the market maker (usually utility) rate. +* Updated load final selling rate and PV initial buying rate in the [template strategies](trading-agents-and-strategies.md) now take the total grid fees into account in addition to the market maker (usually utility) rate. * Users can now run three simulations and/or collaborations at once (previous limit was two) diff --git a/wiki/docs/setup-configuration.md b/wiki/docs/setup-configuration.md index c09e923fc8..d2c8e30836 100644 --- a/wiki/docs/setup-configuration.md +++ b/wiki/docs/setup-configuration.md @@ -1,6 +1,6 @@ ##Backend Simulation Configuration -In the backend, the simulation process is slightly different compared to the user interface simulations. There is no need to login to set up a simulation. The user first needs to download the code from our Github Repository (Installation Instructions for [Linux](linux-installation-instructions.md), [Mac](ios-installation-instructions.md) and [Windows](vm-installation-instructions.md)). In the setup-file (in Python programming language), general and [trading strategy](trading-agents-and-strategies) settings can be defined. Examples can be found in the relevant [Grid Singularity GitHub](https://github.com/gridsingularity/gsy-e/tree/master/src/gsy_e/setup){target=_blank} folder. +In the backend, the simulation process is slightly different compared to the user interface simulations. There is no need to login to set up a simulation. The user first needs to download the code from our Github Repository (Installation Instructions for [Linux](linux-installation-instructions.md), [Mac](ios-installation-instructions.md) and [Windows](vm-installation-instructions.md)). In the setup-file (in Python programming language), general and [trading strategy](trading-agents-and-strategies.md) settings can be defined. Examples can be found in the relevant [Grid Singularity GitHub](https://github.com/gridsingularity/gsy-e/tree/master/src/gsy_e/setup){target=_blank} folder. This is the most basic skeleton for a setup-file: diff --git a/wiki/docs/solar-panels.md b/wiki/docs/solar-panels.md index 83ddb1047b..d8054e93e7 100644 --- a/wiki/docs/solar-panels.md +++ b/wiki/docs/solar-panels.md @@ -32,10 +32,10 @@ In the advanced PV configuration mode, there are settings referring to the Capac 3. Upload own / custom generation profile in the form of a [csv file](data-requirements.md). 2. Trading Strategy - 3. Initial selling rate: set the initial (and [consequently the maximum](trading-agents-and-strategies)) rate that the PV offers at the beginning of each market slot in cents/kWh by selecting the [Market Maker](grid-market-settings.md) rate or by entering your own custom rate as ‘user input’ + 3. Initial selling rate: set the initial (and [consequently the maximum](trading-agents-and-strategies.md)) rate that the PV offers at the beginning of each market slot in cents/kWh by selecting the [Market Maker](grid-market-settings.md) rate or by entering your own custom rate as ‘user input’ 4. Final selling rate: set the final rate that the PV offers at the end of each market slot in cents/kWh 5. Rate decrease: enter a value for the explicit rate decrease increment update interval in cents/kWh - 6. Linear pricing: If activated, the rate decrease per amount of time (update interval) is calculated automatically in a way that the price decreases linearly over the market slot time. The rate is calculated starting at the Initial selling rate at the start of the market slot and ending at the Final selling rate at the end of the market slot, while updating the rate at each Update Interval: `energy_rate_decrease_per_update = (initial_selling_rate - final_selling_rate) / max(int((slot_length / update_interval) -1), 1)`; note: you can derive the [bidding behavior](trading-agents-and-strategies) from a linear fitted curve of a selling rate ranging from initial_selling_rate to final_selling_rate within the bidding interval. + 6. Linear pricing: If activated, the rate decrease per amount of time (update interval) is calculated automatically in a way that the price decreases linearly over the market slot time. The rate is calculated starting at the Initial selling rate at the start of the market slot and ending at the Final selling rate at the end of the market slot, while updating the rate at each Update Interval: `energy_rate_decrease_per_update = (initial_selling_rate - final_selling_rate) / max(int((slot_length / update_interval) -1), 1)`; note: you can derive the [bidding behavior](trading-agents-and-strategies.md) from a linear fitted curve of a selling rate ranging from initial_selling_rate to final_selling_rate within the bidding interval. 7. Update interval: set the frequency at which the rate is updated 3. Orientation: If the Local Generation Profile (Custom PV) is selected, the parameters describing the orientation of the solar panels can be set in the basic or advanced mode: diff --git a/wiki/docs/technical-approach.md b/wiki/docs/technical-approach.md index 2e86e576ca..c148879195 100644 --- a/wiki/docs/technical-approach.md +++ b/wiki/docs/technical-approach.md @@ -10,7 +10,7 @@ The Grid Singularity Medium Channel features several studies that assess the [fi ***Figure***. *Grid Aware Markets: Trading agents place bids and offers on behalf of assets via the Asset API. Agents trade based on user preferences such as energy source and preferred trading partner. Grid Operators implement dynamic grid tariffs in energy markets through the Grid Operator API.* -Grid Singularity facilitates an individual or energy asset-centred, bottom-up market design by connecting aggregators and grid operators, through an application interface ([Asset API](asset-api-template-script.md) and [Grid Operator API](grid-operator-api-template-script.md), respectively). More specifically, aggregators connect distributed energy assets of a community (including households, businesses and other energy users), while grid operators account for grid costs and access local flexibility for advanced grid management. Connected energy assets are digitally represented by [trading agents](trading-agents-and-strategies) pursuing trading strategies currently based on price but with a capability to be based on more advanced user preferences, such as consuming only renewable energy or trading with a preferred partner, achieving diverse [degrees of freedom](trading-agents-and-strategies.md#bidoffer-attributes-and-requirements-for-trading-preferences-degrees-of-freedom). +Grid Singularity facilitates an individual or energy asset-centred, bottom-up market design by connecting aggregators and grid operators, through an application interface ([Asset API](asset-api-template-script.md) and [Grid Operator API](grid-operator-api-template-script.md), respectively). More specifically, aggregators connect distributed energy assets of a community (including households, businesses and other energy users), while grid operators account for grid costs and access local flexibility for advanced grid management. Connected energy assets are digitally represented by [trading agents](trading-agents-and-strategies.md) pursuing trading strategies currently based on price but with a capability to be based on more advanced user preferences, such as consuming only renewable energy or trading with a preferred partner, achieving diverse [degrees of freedom](trading-agents-and-strategies.md#bidoffer-attributes-and-requirements-for-trading-preferences-degrees-of-freedom). Assets are typically grouped inside homes based on the owner and trade in a community market. Multiple communities can be connected inside higher markets depending on the geographical reach of the peer-to-peer system and voltage architecture of the grid.