Separate pyomo model from bid determination

Description

Separate optimization model from determination of power profiles

1. create abstract model at the start of determine_bids

2. pass this model to the function that determines power profiles; this function initializes a concrete model and adds the cost objective (including expected price)

This should make it easier to use persistent solvers. We may go back to using a concrete model in step 1, but for now this works.

I started with a class that manages the Pyomo optimization model. This is based on expected changes in the future for performance (#131).

The design idea is as follows:

• Broadly, a "bidding strategy can load off the model to the manager and ask it to solve in the best/fastest way possible".
• The OptimizationModelManager maintains the state of the model (whether an instance exists, whether the model is solved).
• The OptimizationModelManager should allow to change flexibly how a concrete model is solved
  • The bidding strategy can pass an abstract model and instantiate with specific data. In the future, we may dynamically instantiate a model or update parameters if a model_instance exists (see #131).
  • should be allow to re-use model instance (with updating parameters) (future)
  • should allow to use persistent solvers if possible (future)
• The OptimizationModelManager should be "general" and not tied to specific attribute names used in a particular Pyomo model

Changes to MultiProfileBiddingStrategy

• The bidding strategy now has a manager attribute, which is an instance of OptimizationModelManager.
• The bidding strategy creates an abstract model at the start of determine_bids with _create_model, passes this to the manager. For each profile, it calls the manager to initialize a new concrete model.
• _create_model now returns an abstract model with the objective function added.
• These changes mean that per bidding round, the cost objective is only added once to the model. On my laptop, speed tests suggest we this could speed up bid determination by almost 100ms (from 980ms to 890ms), but there was some variability in the measured timings.

Smaller changes to MultiProfileBiddingStrategy

• add property bidding_window
• use decorator syntax for cost objective declaration, which I think is the recommended way I found some unexpected behavior when using declarator the syntax, and for simplicity and consistency switched back to not using decorators.
• make pure function get_expected_price in utils.py, and add a simple test for it.

Other changes

• mark some tests, particularly in multi profile bidding strategy, as integration -- I found 5-6 seconds too long on the pre-commit hook, and now it's back at 1-2 seconds.
• created script profiles_bidding.py that profiles the bid determination. I think I would like to keep this script for now, but not sure about where. I've put it into a new folder dev.; we might also collect the notebooks in there?
• I refactored some tests for the multiprofile strategy. There are now more tests on creating the abstract model, and fewer on creating the concrete model, but they have been replaced by tests for creating a concrete model in tests in tests of the optimization model manager.

Notes

• Sander suggested to use the data argument in create_instance to initialize model.time. I tried that but gave up after a few hours; found no good docs either (pyomo docs, online search, books, AI). @C.DohDinga 's example helped to make this work. Thanks!

Todo

• Decide on decorator syntax (consistency vs inofficial(?) style guide)
• Performance/abstract vs concrete models
• Keep performance profiling script somewhere in the repo?

Related Issues

Issues related to this MR, but not resolved by it:

• related to #77
• related to #97
• related to #131
• related to #31

Checklist

• Formatting matches prescribed style
• Tests pass
• Code coverage does not decrease
• New tests have been added for new code
• Relevant documentation has been updated or added
• User-facing changes have been listed in [CHANGELOG.md]