Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    alex
    @alexsescu
    supply_electricity_renewable:
        essentials:
            parent: supply
        costs:
            monetary:
                interest_rate: 0.0432
    
    supply_electricity_nuclear:
        essentials:
            parent: supply
        costs:
            monetary:
                interest_rate: 0.0432
    
    supply_electricity_fossil:
        essentials:
            parent: supply
        costs:
            monetary:
                interest_rate: 0.0432
    
    storage:
        costs:
            monetary:
                interest_rate: 0.0432
    Bryn Pickering
    @brynpickering
    Turns out that this was caused by a spurious empty cost class (i.e. the cost class was defined, but no costs were given for it), in case anyone else comes across this error. We'll work on making it a more obvious error in future
    alex
    @alexsescu
    Thanks bryn!
    alex
    @alexsescu
    Hi everyone again. I am modelling the Spanish electric grid so i know all installed capacities and generation units. Thus, in regards to the option of run.mode.plan or run.mode.operate, is there any difference in the results of hourly production by energy source?
    I have checked that the main difference lies in LCOE calculation (operation mode does not consider investment and O&M_fix costs)
    Bryn Pickering
    @brynpickering
    You're right, if you know all your capacities, the primary difference is that operate mode doesn't consider any fixed/investment costs or decision variables. Additionally, it runs on a rolling horizon. This can mean that storage results will be different, because the optimisation doesn't know anything about conditions beyond your time horizon. The idea is that operate mode is more realistic in only knowing near-term operating conditions, whereas plan mode considers perfect foresight.
    alex
    @alexsescu
    Good morning again. I have questions about operate and planning mode when running the models
    -operate mode: i have loaded for every technology hourly (as timeseries) the capacity available as resource: file=capacities.csv:cap_coal, for example. The problem is that in operate mode, calliope shows me that " * Energy capacity constraint removed from Z1::coal as force_resource is applied", but i have explicitly written force_resource: false even to avoid the problem but it still persists.
    do you know how could i solve this? i.e., providing hourly availability for resources in operate mode?
    Andrea B.
    @abart89

    Hello everyone. I'm having an issue with the energy_cap_min constraint on a technology's size.
    I'm trying to give a technology some kind of economy of scale, making it more efficient and less expensive while its size increases. I then made three ranges of rated power for such technology (small, medium and large) limiting its size within the range with energy_cap_min and enegy_cap_max and putting a fake purchase cost with purchase in order to trigger a binary variable making it possible to purchase 0 kW of such technology. In code:

        chiller_electric_large:
            constraints:
                energy_cap_min: 5001
                energy_cap_max: 12000
            costs:
                monetary:
                    purchase: 1
                    energy_cap: 750
                    interest_rate: 0.10

    For some reason the algorithm places a size of the technology which is outside the boundaries (like 90 something kW) in some of my locations. Am I not getting right how the parameters work (maybe purchase overwrites cost*size) or it can be something else? Many thanks!

    Bryn Pickering
    @brynpickering
    @alexsescu if you set the capacity by using force_resource and resource=... then you shouldn't have to worry about what value you've set for energy_capacity_max etc., because the technology will just use all the available resource (hence why the energy capacity constraints are ignored in the optimisation).
    Bryn Pickering
    @brynpickering
    @abart89 you're approach is exactly what I would do in order to make energy_cap_min work in the way you'd like. I've jsut checked the constraints, and everything is in place as I'd expect. Can you check (looking at model.inputs) that there are no location specific overrides being applied in some places, without you realising? You can check something like model.get_formatted_array('energy_cap_min').loc[{'techs': 'chiller_electric_large'}]
    Francesco Lombardi
    @FLomb
    Hi guys, quick question. If I am trying to make changes to the code on a branch I created, how can I "run" the branch instead of the master?
    GiorgioBalestrieri
    @GiorgioBalestrieri

    @FLomb based on the fact that there is a setup file, it should be pip-installable. You can install directly from GitHub (or any other git remote repo) using pip install git+<clone link to the repo>, you should be able to get the clone link to a specific branch.

    Otherwise, if you have it locally, you can just cd into the project folder and run pip install -e ./ (-e means it will be updated each time you update the source code, it's convenient if you are actively developing your version)

    A good idea might be to create a separate conda environment for that, if you are relying on Anaconda
    Francesco Lombardi
    @FLomb
    thanks for the hint, I tried to install it based on my local copy, but it doesn't seem to work properly. Maybe 'cause I'm managing multiple branches in the same folder through GitHub Desktop and only the master gets recognised when using pip install?
    GiorgioBalestrieri
    @GiorgioBalestrieri
    @FLomb if you use pip install in the local folder, it should install whatever branch you have checked out, so just make sure you checkout the branch you want to use. Also make sure that you don't have calliope already installed through conda or something like that, and remember to add *.egg-info/ to your .gitignore
    Francesco Lombardi
    @FLomb
    @GiorgioBalestrieri of course I have calliope already installed through conda, but I created a new environment for the clean "branch" installation. The thing is that it didn't install the branch, even though of course I checked out having the correct branch displayed in the local folder before installing.
    Francesco Lombardi
    @FLomb
    Hi guys, I'm moving from single-node to multi-node and I'm getting weird warnings like:
    • Not building the link CNOR,CSUD because one or both of its locations have been removed from the model by setting exists: false
    which apparently are also the cause of a subsequent Python KeyError
    is there something very basic that I'm missing to make locations "exist"?
    apparently the problem only occurs for some random locations. But all of them are defined in the same way
    Bryn Pickering
    @brynpickering
    It could be that one of CNOR or CSUD hasn't actually been defined in the model, so Calliope thinks that the user has deleted the location (whereas it just hasn't been defined). If those locations are definitely in the model, you could try explicitly setting them to exist (which is the default anyway), e.g. locations.CNOR.exists: true
    Francesco Lombardi
    @FLomb
    Thanks Bryn, I managed to fix it, there was a typo in a location definition. Now it works, but still there is something weird happening: everything works fine if running in "planning" mode, but if trying to run in "operational" mode (as I normally always do) it returns an error saying that I need to specify I finite capacity on each of the defined transmission lines. Which of course I did define, using finite numbers (which just work as expected in planning mode). Any hints? It's possible that there is still something wrong in how I defined such techs (considering that I used to work on a single-node model before), but it is quite weird that I have no problem if running in planning mode.
    a finite capacity*
    Bryn Pickering
    @brynpickering
    Operation mode is quite rigid in its requirements, since it is so easy to define an optimisation problem which is unphysical. All capacity maximum values are set as the decision variable value, instead of acting as a maximum. So any infinite capacity won't work. The easiest thing here is to check model.inputs.energy_cap_max and/or model.inputs.energy_cap_equals to see if there is a rogue infinite or NaN value. NaN values will default to inf (as that is the default for energy_cap_max)
    Francesco Lombardi
    @FLomb
    yes, in fact (in line with the warning and error) the energy_cap of transmission lines (and demands also) is set to "nan". The question is: why? I have defined finite capacity numbers
    Also, making the same test in plan mode, transmission lines are no more set to "nan". They are given the specified capacity limit
    there's just something that makes he remove cap_equals constraints on tramission lines in operation mode
    it*
    Bryn Pickering
    @brynpickering
    demands shouldn't be a problem, since capacity doesn't really make sense for them. For transmission lines, this reminds me of a problem that came up before. Are you setting the transmission capacities at a technology or a link level?
    Francesco Lombardi
    @FLomb
    well, for the "big" transmission lines between bidding zones I'm setting the capacities at link level. Conversely, for the "small" lines that are conceived as free transmission I am setting a capacity constraint at tech level, the same for all of them, and it's like a big number because I originally wanted it to be "inf", but then I put like 10GW to try overcome this error, without success
    I think the latter lines are those giving the problem
    Bryn Pickering
    @brynpickering
    There's no reason for the inputs dataset to have different values for different solving modes, since there is nothing in the code that changes until after the model is sent to the solver. Are you sure that model.inputs gives you two different arrays between loading the model with plan vs operate(i.e. without ever telling the model to run the optimisation)?
    Francesco Lombardi
    @FLomb
    yes, absolutely. Anyway, I just tried to follow your hint and specify capacities at link level; also, I realised I was using energy_cap_max instead of energy_cap_equals for the "big" lineas (even if Calliope should automatically set that to equals if running in operation mode, shouldn't it?). Well, after these two changes, it is happy to solve the model. The only thing that is still problematic is that it does the following: Resource capacity constraint removed from SICI::hydro_dam as force_resource is applied for every single supply_plus tech I have, in every region, even if for most of them I specifically stated "forse_resource: False".
    lines*
    accordingly, results vary between plan and operate because supply_plus are free to supply much more than they should
    this is something I used to have also in single-node
    and that I avoided by applying some further tricks on those techs I wanted to keep under control in terms of resource (i.e. applying also a resource_cap_equals constraint, which I cannot do anymore 'cause I'm using timeseries for these techs now).
    well, I guess I could still hack it in a similar way by applying twice the timeseries to both "resource" and "resource_cap_equals", but it's not super elegant to see
    Francesco Lombardi
    @FLomb
    Ok, I managed to keep it under control
    Francesco Lombardi
    @FLomb
    Hi guys, urgent issue: sometimes ago we were discussing about having variable COPs for heat pumps in a Calliope model, and @brynpickering said this is currently already possible by simply assigning a csv file with a time-step-dependent COP. Now, has anybody actually tried that? Because I get a quite explicit error saying that "ValueError: can only convert an array of size 1 to a Python scalar". Which means, I think, that the code is conceived to take only a scalar for the "efficiency" constraint of a conversion_plus.
    some time ago*
    Francesco Lombardi
    @FLomb
    even though, looking at Calliope's code it seems indeed conceived for taking time-step-dependent efficiencies: (this is from the conversion_plus constraints code) energy_eff = get_param(backend_model, 'energy_eff', (loc_tech, timestep))
    and also the documentation reports that this should be possible without problems
    Francesco Lombardi
    @FLomb
    could there be a bug? Should I open an issue?
    Bryn Pickering
    @brynpickering
    It doesn't look like it's a problem with it accepting timeseries per se
    I would open an issue with the full error log, then we can dig into it some more. Can you confirm that this also happens when assigning a timeseries to energy_eff for the urban scale model chp?
    Francesco Lombardi
    @FLomb
    uhm, actually it doesn't. I tried to put a timeseries for that and it works without error. The output seems reasonable (I put a timeseries with efficiency of 0.2 for every time step and the result is that it doesn't choose to use the chp at all anymore)
    but let me try to put something greater than 1 as for HPs