Hello everyone, is it possible to constraint some conversion system to be supplied ONLY by energy production of a defined set of technologies? currently, I would like to assess a scenario with green hydrogen production, i.e. hydrogen production only with electricity produced by RES, rather than a generic electricity carrier.
Hi, what I would do then would be to differentiate electricity carriers. For instance, you could say that renewabes produce "renewable electricity", whilst other things produce "electricity". Your electrolyser would only be allowed to operate with an input of "renewable electricity", making sure that you produce green hydrogen only. At the same time, you should define a new, "dummy" technology to convert "renewable electricity" into generic "electricity", with no cost and unitary efficiency, so that renewables are also enabled to feed the generic "electricty" demand like all other techs
Good evening, I am developing a model of the African continent based on a Calliope, but I have incurred in some issues regarding costs results. I am modelling the power system as it is, so I am not including investment costs, to optimize the operation of the existing power stations. For some technologies I have only fixed O&M costs, for which I used the setting om _annual, which should be annual fixed opex for unit of installed capacity. Anyhow, these costs result null when investment costs are not considered. Did I misunderstand the nature of this setting or is there an issue in its definition?
Thank you very much
Hi, wow, looks like an ambitious attempt! (: is this part of some bigger project? Anyway, if you are defining some om_annual
that should work fine without any investment cost. A different thing is the om_fractional_investment
, which is based on investment cost. However, for any fixed cost, including om_annual
, you need to have a lifetime
and an interest_rate
defined as well.
Thank you @FLomb! I have modeled a community of several households. Each household has solar panels and a small buffer storage. All households share heat pumps, one of which fills a large hot water storage tank. They also share a battery and a large seasonal hydrogen storage tank, which is charged by an electrolyzer and discharged by a fuel cell. The goal is to store the part of the PV electricity that is not used for daily needs and the battery for the dark season, so that greenhouse gas emissions are minimized.
In Planning Mode, I get a typical seasonal storage curve optimized over a year, which means in April the hydrogen storage is fully discharged, in October fully charged. I would like to get a similar storage curve in operation mode with a window of 48h and a horizon of 24h as in planning mode, which I have not yet succeeded in doing. My idea so far is to define artificial om_con via a timeseries in the charge period negative for the electrolyzer, in the discharge period negative for the fuel cell as an incentive, however it is hard to set the amount of om_con correctly. Do you have any ideas how to better implement seasonal operation in operation mode?
Are the units for available resource (resource) kWh | kWh/m^2 | kWh/kW or are they actually kW*timestep | kW*timestep/m^2 | kW*timestep/kW for problems with non-hourly timesteps. For example if I pass in 400 for a supply tech's resource Calliope would assume that the supply is outputting 400 kW over whatever the model timestep is rather than producing 400 kWh during each timestep. With a 15min timestep that would be 400kWh for a whole hour vs 400 kWh every 15 min for the hour totaling 1600 kWh. I've looked through the constraint definition code and don't see a reference to the timestep weights for resource so my assumption is that no scaling is happening according to the timesteps. It feels a little pedantic but seems like the units for that constraint should either be kW*timestep | kW*timestep/m^2 | kW*timestep/kW or just kW | kW/m^2 | kW/kW to better describe the behavior of the parameter when the model timestep isn't hourly. In a similar vein, I'm wondering if the units for the ramp rate (energy_ramping) should be documented as %/timestep rather than %/hour.
For more context we're working on some dynamic resampling of input timeseries to support quickly switching between model timesteps without having to manually resample each input timeseries and had to do some digging to make sure we understood how those parameters worked.