507 add cross border flows to scenarios #522
Conversation
…g on the direction
…o 507-add-cross-border-flows-to-scenarios
|
@tiernan-buckley-ufr in the future run the |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #522 +/- ##
==========================================
+ Coverage 77.52% 77.62% +0.10%
==========================================
Files 50 51 +1
Lines 6812 6852 +40
==========================================
+ Hits 5281 5319 +38
- Misses 1531 1533 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
…ort) is reflected in the sign of the power, and that the price is assigned as expected
| if direction == "import": | ||
| self.volume = abs(self.forecaster[self.id]) # import is positive | ||
| elif direction == "export": | ||
| self.volume = -abs(self.forecaster[self.id]) # export is negative |
There was a problem hiding this comment.
why do we have to set a direction here?
Wouldn't it be better to have one exchange unit which bids in both directions instead?
| { | ||
| "max_power": self.max_power, | ||
| "min_power": self.min_power, | ||
| "unit_type": "demand" if self.direction == "export" else "power_plant", |
There was a problem hiding this comment.
isn't that more like a new unit_type "prosumer", if we would have it merged as one?
Otherwise we can model them separate as demand and powerplant as of now..?
There was a problem hiding this comment.
this is done this way so we can also see them in the database without changing anything there
|
@maurerle you are correct, that the same behavior can be achieved with a power plant and demand unit. But this is not a very straight forward implementation, and for users I believe it would be more beneficial to have a straight forward way to do these things such as simply representing import or export. Regarding the direction parameter, the thought was to have the direction defined exactly, so that the behavior is not dependent on the input time series, because for example data downloaded from SMARD has negative values for export and positive for import (or other way around). But some people may prepare all data with positive values. And the explicit control over the direction using the "direction" argument allows for a precise control and less prone to error |
Pull Request
Related Issue
Closes #507
Description
This update adds a new type of unit, "Exchanges", corresponding to the commercial exchanges (imports/exports), allowing imports and exports to be added to the market dynamics.
Exports are treated as a form of demand and are set as a bid just below the (price-inelastic) demand bid price to ensure they are realised, and imports are treated as a form of generation set near to the min. bid price to ensure they are realised.
In example 1a, an "exchanges_df.csv" is added to the inputs containing import and export values that are fractions of the demand_df values. A corresponding "exchanges_units.csv" is made configuring how the exchanges participate in the market.
In example 3, "exchanges_df.csv" contains German commercial exchanges for the year 2019, and "exchanges_units.csv" configures how the exchanges participate in the market.
Changes Proposed
Testing
For example 3, the accepted bid prices with and without exchanges were modelled and compared with historical prices for 2019 to see if including exchanges improves the accuracy of the model.
For January:
For April:
For July:
For January a significant increase in accuracy is seen, for April a marginal increase, and for July a slight decrease is seen.
Checklist
Please check all applicable items:
docfolder updates)pyproject.tomldoc/release_notes.rstof the upcoming release is included