Conversation
Introduces an API-driven loader with ENTSO-E client, fuel price fetching, technology mappings, and tests so DE/EU scenarios can be built without CSV inputs. Assisted-by: Cursor:composer-2.5
Replace the incorrect fuel spread fallback with instrat CO2 data or 70 €/tCO2 so oil and other fossils share the same carbon cost input. Assisted-by: Cursor:composer-2.5
…via availability. Wind and solar bid full nameplate capacity from capacity.csv with hourly gen/cap availability; all other technologies use full block capacity and availability 1. Assisted-by: Cursor:composer-2.5
reinecfi
left a comment
reinecfi
left a comment
There was a problem hiding this comment.
I really like the idea of this addition. For me the changes look fine in general. Only documentation in general and especially for the the amount of hardcoded values / defaults could be improved for better understanding.
| return hourly | ||
|
|
||
|
|
||
| class InstratFuelPrices: |
There was a problem hiding this comment.
This maybe overkill for now: I feel like InstratFuelPrices has some similarities to EntsoeInterface. I wonder if we want to have a standardised way / Interface / common base class to incorporate new data from outside of ASSUME via API or downloads
| "waste": (22.0, 18.0), | ||
| "nuclear": (9.0, 7.0), | ||
| } | ||
|
|
There was a problem hiding this comment.
There is a lot of default values here that I don't really understand. As a user I would be interested if there is some reasoning behind them.
| f"demand_{country}", | ||
| { | ||
| "min_power": 0, | ||
| "max_power": -demand.max(), |
There was a problem hiding this comment.
In this line we seem sure about the sign of the demand.
Below in line 142 it seems like we are not sure about the sign of the demand (otherwise we would not need abs)
DemandForecaster(index, demand=-abs(demand))
Should we add abs() to the max_power as well?
| "max_power_charge": -abs(block_capacity), | ||
| "max_power_discharge": block_capacity, | ||
| "capacity": block_capacity * DEFAULT_STORAGE_HOURS, | ||
| "max_soc": 1.0, |
There was a problem hiding this comment.
A lot of hardcoded values that are either specified directly (like max_soc) or are imported from somewhere else (like additional_cost_charge). Maybe bundle them at one place or make them configurable?
2 participants
Description
Adds an ENTSO-E Transparency Platform scenario loader to build country-level ASSUME scenarios from API data (no CSV plant lists).
Thanks to @mthede who inspired this as a simpler version which does not rely on data from OEDS
This is using a similar approach as AMIRIS to use minimum and maximum prices and splits the generation capacity into useful unit sizes with linear interpolated prices.
New code
assume/scenario/loader_entsoe.py—load_entsoe()and dev__main__assume/scenario/entsoe_helper/— ENTSO-E client (cached under~/.assume/entsoe/), instrat.pl fuel/CO₂ prices, PSR → technology mappingstests/test_loader_entsoe.py(18 tests)docs/source/scenario_loader.rst,assume.scenario.rstdocs/dev/entsoe_loader_handoff.mdBehaviour
max_power= installed capacity, hourlyavailability= generation / capacityavailability = 1Dependency: optional extra
assume-framework[entsoe](entsoe-py,yfinance). RequiresENTSOE_API_KEY.Checklist
docfolder updates etc.)Screenshot
entsoe_DE_2024)