RES curtailment penalty functionality

[David Radu]

Hello everyone,

Very quick question here. Are you aware of any straightforward way within the framework to penalize curtailment (p_max_pu*p_nom - p) of RES generators in the objective function? I haven't explored much by now, I was hoping to narrow down a bit the options based on your previous experience with the issue.

Thank you!

David

[Tom Brown]

Hi David,

If other generators have a high marginal cost, there is an implicit
penalty because you have to use e.g. backup gas / coal to cover the
energy not supplied by zero-marginal cost renewables.

Other alternatives:

i) increase p_min_pu (but this may cause infeasibility if there is too much)

ii) give the wind/solar negative marginal cost to maximise production

Best,

Tom

--
Karlsruhe Institute of Technology (KIT)
Institute for Automation and Applied Informatics (IAI)

Tom Brown (he/him)
Research Group Leader, Energy System Modelling

Phone: +49 721 608 25737
Fax: +49 721 608 22602
Group website: https://www.iai.kit.edu/english/ESM.php
Personal website: https://nworbmot.org/

Visitor Address:
Office 309
Campus North Building 445
Hermann-von-Helmholtz-Platz 1
76344 Eggenstein-Leopoldshafen

[David Radu]

Hi Tom,

Thanks a lot for the prompt reply.

I agree with your stand on the implicit penalty for RES curtailment. However, we are currently in a testing phase in which we would like to explore the effect of explicitly penalizing it.

Though the first option you suggest makes sense, it is also quite sensitive to the values you choose and does not let you a lot of room to play (as it is not hard to end up with infeasibilities during winter time assuming flat p_min_pu profiles). The second option is also interesting, but I fear you lose the physical meaning of the objective if you pursue this path.

After I posted the question here, I have had a short offline chat with Fabian H. on the same issue. His stand was to try using the extra_functionality to expand the objective with linear penalty terms for curtailment (per RES generator and snapshot). And it seems like all works fine, so it could be seen as a third option. However, this leads us to a follow-up question. We had already implemented another extra_functionality in the model (a system-wide non-synchronous penetration share) and I could not figure out a way to impose multiple extra_functionalities (SNSP & curtailment penalty) at the same time. Is this expected behavior or have we missed something?

Regards,

David

[Fabian Neumann]

Hi David,

there's a workaround for multiple extra_functionalities. You define a
collecting function:

```
def _extra_functionality(network, snapshots):
my_extra_functionality_1(network, snapshots)
my_extra_functionality_2(network, snapshots)

n.lopf(extra_functionality=_extra_functionality
```

Best wishes,

Fabian N

On 29/05/2020 14:59, David Radu wrote:
> Hi Tom,
>
> Thanks a lot for the prompt reply.
>
> I agree with your stand on the implicit penalty for RES curtailment.
> However, we are currently in a testing phase in which we would like to
> explore the effect of explicitly penalizing it.
>
> Though the first option you suggest makes sense, it is also quite
> sensitive to the values you choose and does not let you a lot of room to
> play (as it is not hard to end up with infeasibilities during winter
> time assuming flat p_min_pu profiles). The second option is also
> interesting, but I fear you lose the physical meaning of the objective
> if you pursue this path.
>
> After I posted the question here, I have had a short offline chat with
> Fabian H. on the same issue. His stand was to try using the
> extra_functionality to expand the objective with linear penalty terms
> for curtailment (per RES generator and snapshot). And it seems like all
> works fine, so it could be seen as a third option. However, this leads
> us to a follow-up question. We had already implemented another
> extra_functionality in the model (a system-wide non-synchronous

> penetration share) and I could not figure out a way to impose *multiple
> extra_functionalities* (SNSP & curtailment penalty) at the same time. Is

> --
> You received this message because you are subscribed to the Google
> Groups "pypsa" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pypsa+un...@googlegroups.com
> <mailto:pypsa+un...@googlegroups.com>.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/pypsa/ee66bb77-7ed5-4b64-a9be-dfe1d3f08d0a%40googlegroups.com
> <https://groups.google.com/d/msgid/pypsa/ee66bb77-7ed5-4b64-a9be-dfe1d3f08d0a%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Karlsruhe Institute of Technology (KIT)
Institute for Automation and Applied Informatics (IAI)

Fabian Neumann (he/him)
PhD Student in Energy System Modelling

Phone: +49 721 608 25707 | Mobile: +49 171 2943831 |
Group: www.iai.kit.edu/english/esm.php | Personal: www.neumann.fyi |
Github: @fneum | Twitter: @fneum_

Learn about nearly-optimal power system models:
https://arxiv.org/abs/1910.01891

KIT Campus North, Building 445, Office 304
Hermann-von-Helmholtz-Platz 1
76344 Eggenstein-Leopoldshafen

KIT – The Research University in the Helmholtz Association

[David Radu]

Hi Fabian,

Makes sense, thanks for pointing it out.

Regards,

David

> an email to py...@googlegroups.com
> <mailto:py...@googlegroups.com>.