## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
Bryn Pickering
@brynpickering
it requires the timestamps (in the left hand column) to be the same. I.e. you're defining your timeseries at the same point in time for all of your datasets
alex
@alexsescu

Hi everyone again. I have problems when plotting solutions. The model comes to a solution and generates the folder results.csv although it gives me error as follows:

Saving CSV results to directory: results.csv
Saving HTML file with plots to: plots.html

Error in _get_var_data:
too many indices for array

Bryn Pickering
@brynpickering
Could you post this (alongside a full error log) as a GitHub issue on our page? It will need some investigation to work out why that pops up!
alex
@alexsescu
@brynpickering done! the issue is " calliope - ploting problems #189 "
Bryn Pickering
@brynpickering
Thanks @alexsescu
alex
@alexsescu
Hi everyone again. I have problems now with the interest_rate variable. The error says this File"C:\Program_Files\Anaconda3\envs\calliope\lib\site-packages\calliope\core\preprocess\locations.py", line 404, in compute_depreciation_rates
interest = tech_config.costs[cost].get_key('interest_rate', None)
AttributeError: 'NoneType' object has no attribute 'get_key'
I have removed all interest_rate definitions and it continues giving me error, has anyone had problems with this? It is the first time it happens to me running the code :/
Bryn Pickering
@brynpickering

which version of Calliope are you using? I would advise adding all interest_rate values in. The easiest way to do this for different cost classes is to override the parent technology groups with an interest rate for each cost class, e.g.:

tech_groups:
supply.costs.monetary.interest_rate: 0  # this might need to be non-zero
supply.costs.carbon.interest_rate: 0
supply_plus.costs.monetary.interest_rate: 0
supply_plus.costs.carbon.interest_rate: 0

It's important to know that there is a depreciation cost computed for your technologies, as it impacts the balance of investment and operational costs in the objective function. Hence why it tends to run into errors when they are removed...

alex
@alexsescu
I am using 0.6.3. I have been running the model without problems until last weekend in regards to this issue about interest rates. I have set them as your examples in the tech_groups definition.
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