Flexible objective function

[spine-o-bot]

In GitLab by @Poncelet on Jun 20, 2018, 12:25

Further elaborate the objective function. Ideally, allow for other types of objective function except cost minimization (e.g., emission minimization, multi-objective, etc.)

[spine-o-bot]

In GitLab by @jkiviluo on Jun 21, 2018, 08:33

Maybe it should be possible to
A) add new terms to the base objective function
B) use an alternative objective function that is part of the Spine Model
C) use an alternative objective function defined by the user as input 'data'

[spine-o-bot]

In GitLab by @DillonJ on Jun 22, 2018, 08:20

Similar to what Juha is suggesting above, I think we should:

• Have some options regarding typical problem objectives that would have the effect of turning terms on/off
• Similar to a generic constraint, allow for the user to create generic objective function terms to be added to the objective function.

[spine-o-bot]

In GitLab by @manuelma on Nov 18, 2019, 10:28

I think it's time to start working on this. Shouldn't be too difficult with the current state of things.

[DillonJ]

Piece of cake... we create parameters.... unit_flow_objective_coefficient etc... the relationships should be there already

[mihlema]

We should probably implement this now, if we decide it should be part of SpineOpt. As @jkiviluo mentioned before, we can include/exclude cost terms. At the moment we only support the minimization of the total system costs. What we don't support minimize emissions, multi-objective. Assuming we'd want to add minimization of emissions, we'd need to implement the following

• a method parameter on the model object, indicating the objective function
  • e.g. total_emissions -> true
  • Note: we could also have a parameter list, however this might close the door on multi-objective optimization, where both total_emissions and total_costs should be true.
• corresponding objective function gets evaluate in code (set_objective!)
  • Note: this can also be a combination of different objectives (see below)
• add the function total_emissions:
  • tag commodity associated with minimizing emissions:
    • e.g. parameter minimize_emissions (default: false)
  • add CO2 equivalent parameter to commodity object class

For multiobjective optimization, our best shot might be to use weighted sums (+scaling factors). Hence, we'd need (for each objective function):

• weight_{total_costs, total_emissions}
• scale_{total_costs, total_emissions}

At a first glance, this seems doable. Any thoughts? @DillonJ @manuelma @jkiviluo

[clizbe]

Closing because stale.