operatemode 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
operatemode is more realistic in only knowing near-term operating conditions, whereas
planmode considers perfect foresight.
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
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!
resource=...then you shouldn't have to worry about what value you've set for
energy_capacity_maxetc., because the technology will just use all the available resource (hence why the energy capacity constraints are ignored in the optimisation).
energy_cap_minwork 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
@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)
pip installin 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
model.inputs.energy_cap_equalsto see if there is a rogue infinite or NaN value. NaN values will default to inf (as that is the default for
model.inputsgives you two different arrays between loading the model with
operate(i.e. without ever telling the model to run the optimisation)?
energy_cap_equalsfor 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 appliedfor every single supply_plus tech I have, in every region, even if for most of them I specifically stated "forse_resource: False".