Simplify the benders data structure

[manuelma]

So currently, to use benders decomposition one needs to specify a new model object to represent the benders master problem, and give it model_type_benders as type. But in addition, one also needs to create all the model__temporal_block, model__investment_temporal_block and so on, for the 'benders' model object. Is there a case where these would difer from the ones for the 'standard' model object? My impression is that the opposite is true: one needs to replicate the exact same relationships in the 'standard' and the 'benders' object, otherwise funny things may happen.

If my impression is true, I would like to consider triggering the benders decomposition differently, by a parameter in the 'standard' model object itself. @DillonJ what do you think?

[DillonJ]

Hi @manuelma

This is probably the way you would want to do it alright - except perhaps you would like to have a stochastic master problem where, for example, investment costs vary by scenario. I'm not sure we support that right now though.

The main thing is that the benders master problem should cover the full window of the underlying operational (standard) model.

The other thing is that perhaps we want the entire structure to roll, say yearly investment windows and we could control that sort of thing with the master problem model object.

Right now, what you are saying probably holds for a simple case with a single, deterministic yearly investment window and, say, a daily rolling operational model.

Is there a way where we can do as you suggest, but still leave it open to manually specify the structure so we leave the door open to these sorts of developments in the future, for example, in pre-processing?

[manuelma]

Thank you @DillonJ

The thing is, I must be missing something because I don't immediately see how having an additional model object helps with any of those potential developments. To my undestanding, if we need a different temporal or stochastic structure for investments we would do it using the xxx__investment_temporal_block and xxx__investment_stochastic_structure, not by specifying different temporal and stochastic structures for the benders model object.

At the moment, it is a lot more difficult for the user to setup benders than it could be, so the question for me would be whether those potential benefits are worth it?

We can think about it I guess.

[DillonJ]

@manuelma that's a good point - the investment temporal structure should/could be independent of the model. However, it is conceivable that one might want some investments in the sub problems and some others in the master problem - but that feels like very expert usage.

That said, the rolling structure is a possible issue - since that is a property of the model object. If you wanted bi-level rolling - but of course we could do that using parameters instead (e.g. master_problem_roll_forward).

Definitely feels like we should make it easier for the user as it's difficult now to get it right

[manuelma]

So here is what I would like to do. To activate benders decomposition, the user just needs to select model_type_benders for their current (unique) model object. That's it.

With this, they bypass all the trouble of creating a new model object, specifying the appropriate parameters and relationships. I found myself doing it by choosing "Duplicate object" in the DB editor which might still be ok, but definitely leaves one wondering "why?"

Also, I like the idea of using parameters for any extra functionality required such as a rolling master problem.

What do you think? @DillonJ @mihlema @jkiviluo ?

[DillonJ]

This sounds like it has nice benefits @manuelma. Considering the multi-period investments branch that is currently being worked on... how would you propose, in this new approach, to define the rolling structure of the higher level master investment problem?

[manuelma]

master_problem_roll_forward sounds just fine. Whatever additional functionality is needed can just be a parameter I think?

[DillonJ]

We had a requirement to define model__temporal_block because of the multi-model implementation in SpineOpt. Now that we no longer have a need for multiple model objects, should we / can we remove the necessity to define model__temporal_block

@manuelma @tarskul

[manuelma]

It's been done in #811.