Add elastic demand

[nick-harder]

Pull Request

Description

This PR introduces an elastic demand bidding strategy by @gugrimm.

Changes Proposed

• Developed a new bidding strategy
• Adjusted how an empty demand_df is treated. Now it is filled out with zeros and logs a warning instead of raising an error
• Added extra parameters to the demand unit
• Fixed how actual dispatch for the demand unit is calculated. Now it uses the output["energy"] instead of simply relying on the volume as it was before. The volume might not be fully fulfilled, and this would lead to wrong data logging. Now this is fixed.

Testing

Added tests for the new bidding strategy. Also added checks inside the demand unit in case elasticity is provided.

Checklist

Please check all applicable items:

• Code changes are sufficiently documented (docstrings, inline comments, doc folder updates)
• New unit tests added for new features or bug fixes
• Existing tests pass with the changes
• Reinforcement learning examples are operational (for DRL-related changes)
• Code tested with both local and Docker databases
• Code follows project style guidelines and best practices
• Changes are backwards compatible, or deprecation notices added
• New dependencies added to pyproject.toml
• A note for the release notes doc/release_notes.rst of the upcoming release is included
• Consent to release this PR's code under the GNU Affero General Public License v3.0

Additional Notes (if applicable)

[Any additional information, concerns, or areas you want reviewers to focus on]

Screenshots (if applicable)

[Add screenshots to demonstrate visual changes]

[codecov]

Codecov Report

Attention: Patch coverage is 91.83673% with 4 lines in your changes missing coverage. Please review.

Project coverage is 79.67%. Comparing base (c035460) to head (f80927f).
Report is 29 commits behind head on main.

Files with missing lines	Patch %	Lines
assume/scenario/loader_csv.py	0.00%	2 Missing ⚠️
assume/strategies/naive_strategies.py	93.54%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #575      +/-   ##
==========================================
+ Coverage   79.51%   79.67%   +0.16%     
==========================================
  Files          52       52              
  Lines        7342     7416      +74     
==========================================
+ Hits         5838     5909      +71     
- Misses       1504     1507       +3     

Flag	Coverage Δ
pytest	79.67% <91.83%> (+0.16%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Copilot reviewed 6 out of 7 changed files in this pull request and generated no comments.

Files not reviewed (1)

• docs/source/release_notes.rst: Language not supported

Comments suppressed due to low confidence (2)

tests/test_naive_strategies.py:104

• The variables 'start' and 'end' are used without an apparent definition in this test. Ensure they are defined or imported so that the test runs as intended.

product_tuples = [(start, end, None)]

assume/strategies/naive_strategies.py:437

• Silently continuing when ratio <= 0 in the isoelastic branch might result in fewer bids than expected. Consider handling this condition explicitly to ensure the expected bid count is always generated or to provide a clear error message.

if ratio <= 0:

[kim-mskw]

Can you elabortae a bit on the find_first_block_bid() function? How can Power * price be a volume?
Also with first you mean highest yes?

[nick-harder]

@gugrimm could you please add a better explanation for the way the first bid is derived as Kim suggested?

[gugrimm]

The thing with the units is: this is not physics and units do not necessarly need to fit. It took me a while to understand, but what we are looking is a relation between quantity and price, a behavioral relationship based on some economic theory. As far as i understand, in this case units do not match dimensions, unlike in physics where units of an equation always fit. In our case the behavioral relationship must be enriched with knowledge "of the x and y axis" to make sense in real world...

remove self approval

[kim-mskw]

Thanks for the clarification. I think I got it now. It works like this right?

[kim-mskw]

Looks good! Two small things.
Should we maybe rename it to flexible_demand? As the other strategy is called inflexible, or we switch it to inelastic?
And can you maybe add documentation to this demand type?

[gugrimm]

The picture you drew is exactly how it works, yes! I don't get why you call it "isometric" demand - probably a mistake? "Isoelastic" is the correct term.
In the naming I believe we should use elastic and inelastic. Both terms show this has sth to do with economics / marginal utility, or at least these are the terms used in the literature I read on elasticities. Flexible and inflexible on the other hand side refers to time-shifts (as I understand it). So our demand side agents are "flexible" in my understanding. I changed the docu accordingly.
I documented the bidding strategy in the PR #559 .