Ramping constraint for conversion and conversion_plus about calliope HOT 5 CLOSED

Since version 0.5.0 of Calliope, there's been some backward incompatible changes to technology definitions, once of which involved changing from having carrier and source_carrier to having carrier_in and carrier_out. This wasn't updated in the optional constraints, but I've now dealt with it in commit 0a0c1c0.

You'll need to wait until version 0.5.3 is released to see these changes, or get yourself a local version of Calliope 0.5.2dev, by following the instructions here: https://calliope.readthedocs.io/en/stable/user/develop.html#installing-a-development-version

from calliope.

Thanks Bryn,

I downloaded the development version. The ramping seemed to work at a first glance but I tried putting a e_ramping: 0 to a conversion technology.

    test_ramp:
        name: 'Conversion tech'
        parent: conversion
        export: true
        carrier_in: gas
        carrier_out: heat
        constraints:
            e_cap.max: 30
            e_eff: 0.6399
            e_ramping: 0
            e_cap_min_use: 0.3
        costs:
            monetary:
                e_cap: 120
                om_var: 2.7

I was expecting a constant output. But the output value change once per day:

Thanks!

from calliope.

Are you using operational mode for this? The ramping constraint currently does not apply to the first timestep of the optimisation, which would allow the conversion tech here to choose a maximum capacity and then stick at that for the duration of the operating period. Due to the rolling horizon nature of operational mode (which is currently not working properly), there is a new first timestep at each new run, which would allow the production to reset each day to that day's maximum.

If it isn't that, then you'll need to try out some other configurations to see what crops up.

from calliope.

Yes it was in operational mode. I tested it in plan mode and it is staying constant during the whole simulation => it is working in plan mode

Thanks for your answer

from calliope.

Glad to hear it. Operational mode needs a complete overhaul, but doing that requires us to work on some backend stuff first. Once we've settled on a robust backend to create and run the optimisation, we can get back to fixing operational mode properly!

from calliope.