UC_CAP for Heat Pumps

[JasonMcGuire]

I am looking for help on a user constraint as I am unsure if I have applied it correctly. 

The heat pumps in this model have different costs and efficiency depending on the energy rating of the dwelling they serve. For example, in an A, B1 and B2 energy-rated dwelling, the heat pump capital cost is less (less emitter upgrade), and efficiency is greater (lower heat loss) than others. Heat Pump-AB serves AB dwellings, and Heat Pump-C serves C dwellings, and so on. The exception is if a B3 or lower energy-rated dwelling has building fabric upgrades, which are on par with B2 standard dwellings then Heat Pump-AB can serve them too. I am running different scenarios which will look at the level of the Heat Loss Indicator (HLI) which allows for a Heat Pump-AB operation.

I have attempted to constrain the share of heat pumps-AB for each dwelling energy rating.  For example, below 51.4% of C dwellings do not need a fabric upgrade to avail of a Heat pump-AB, beyond this a C-rated dwelling must either get a building fabric upgrade to avail of a Heat pump-AB or get heat pump-C.  

Hopefully, this makes sense. See attached, UC_CAP_Apartment, which is the user constraint I applied for apartments (each building archetype has its own user constraint).
   


Here is an example of the Heat Pumps allowed, notice that Heat Pump AB can serve any energy dwelling, but Heat Pump C can serve C dwellings only.
   


My question is does this user constraint do what I think it does? Thanks for any comment/ suggestions on this.

Jason

Additionally, here is what VEDA sees:
   
   

[Antti-L]

I had a quick look at the captures, and have only the following question:
The UC constraint is based on capacities.  The capacity of the heat pump system appears to be in GW, but is the capacity of R-BLD_Apt_* in fact also in GW (heat / cool)?  In my models, the capacity of buildings is expressed either as the volume of heated space (in Mm2 or Mm3), or in some cases the number of apartments, and so in such case the constraint would not work as such.  Otherwise I did not spot any issues, however, I think the constraint does not actually limit the share of heat pumps-AB for each dwelling energy rating, but only the aggregate capacity for all energy ratings?  It seems you did not wish to limit the market share of R*_HPN*-AB in the RSDSH_Apt-C supply (or capacity) separately to at most 51.4%?  But I could well be missing something...

One remark about the efficiencies: The parameters seem strange to me: ACT_EFF(RSDELC)=4.61 and ACT_EFF(RSDSC_Apt)=4.14 (in 2050). Unless I am missing something, the combined efficiency for cooling would thus be 4.61 × 4.14 ≈ 19 ?  But there are hidden dimensions, and so I cannot see whether there are timeslice-specific values...  In addition, would be curious to see also the FLO_SHAR commodity and Lim_type dimensions.

[JasonMcGuire]

Hello Antti,

I appreciate your response. It appears that there might be a conflict, given that the Heat Pump capacity is measured in GW, whereas the apartment capacity is quantified in terms of the number of units. Considering your feedback, do you have any recommendations for resolving this issue without altering the unit measure for the apartment capacity?
Regarding your observation that the constraint may not be limiting the share of heat pumps-AB for each individual energy rating but rather for all energy ratings collectively, I thank you for pointing this out. It wasn't my aim, prehaps I need to create a distinct user constraint for each energy rating.
To clarify, I indeed wish to cap the market capacity of R*_HPN*-AB in the RSDSH_Apt-C at 51.4%.
Your input about efficiencies has been useful, and I plan to delve into it further. Thank you.

[Antti-L]

Well, as I don't quite know the details in the modeling approach, it is a bit difficult to make suggestions. For example, if there are also efficiencies (from the heat inputs to the activity) defined for the R-BLD_Apt_* processes, that would further complicate the use of capacities.

However, as you said that 51.4% of C dwellings do not need a fabric upgrade to avail of a Heat pump-AB, that sounds like you perhaps could simply constrain the heat pump-AB output RSDSH_Apt-C to be at most 51.4% of the input of space heat into C dwellings (and similarly for dwellings of other ratings)? Does that make sense?

[Antti-L]

Because of my curiosity about the FLO_SHAR remained unsatisfied, I downloaded the Times Ireland model from Github and tried to see if it includes a similar model structure and similar heat pump technology. Indeed, it seems that there was a very closely similar technology R-HC_Apt_ELC_HPN2-AB, for which multiple FLO_SHAR parameters were defined for the RSDAHT commodity. Despite some differences in those parameters, that made me suspect that the two FLO_SHAR parameters shown in your screen capture, defined for the commodity groups RSDSC_Apt and RSDSH_Apt-AB, are possibly also both defined for the commodity RSDAHT, with Lim_type=FX.  If this is the case, please note that doing so would likely cause the flows of RSDSC_Apt and RSDSH_Apt-AB to be equal in all timeslices, which in my view would not make sense (assuming I have understood how the process should work).

[olexandr]

Thanks a lot Annti for looking into TIM and providing feedback on the constraint. On the HP units issue, there seems to be an error in units in the process declaration table. It is been a while since I've last opened the model, but I believe it should be kUnits instead of GW. @Jason could you check and confirm?

On the HP modelling, let me review what the approach was and come back...

[JasonMcGuire]

Thanks, Antti and Olex, for your comments. 

Olex, I've reviewed the process declaration tables. The heat pump capacity is denoted in GW. This then contributes to the residential space heat energy service (RSDSH-*), which is an Input VDA flop measured in  PJ/'000 dwellings. The building demand (R-BLD) is subsequently measured in '000 dwellings. At the moment, I don't see an issue, but I could be missing something.

Antti,  Regarding your user constraint suggestion to limit the heat pump-AB output RSDSH_Apt-C to a maximum of 51.4%. To ensure I'm on the same page, is this the configuration you're suggesting?
   

This is where I grab all the Heat Pumps for C dwellings and only allow the capacity to reach 0.51 – I think this is what you mean?

Also, apologies for not getting back earlier to address your curiosity about the FLO_SHAR. Thanks for flagging potential issues. I've been working with a slightly different model ((https://github.com/MaREI-EPMG/times-irel...-HLI-study ) and I checked some timeslices in the results and they show only a small fraction of RSDAHT in going to cooling (RSDSC*) while the majority or all goes to heating (RSDSH*) – maybe this is a good bug?

I'll set up a user constraint as described and report back with the results here.

Thanks again,
Jason

[Antti-L]

> Antti,  Regarding your user constraint suggestion to limit the heat pump-AB output RSDSH_Apt-C to a maximum of 51.4%. To ensure I'm on the same page, is this the configuration you're suggesting?

No, I cannot see what you are trying to do in that new constraint; it seems you are just limiting the capacity of R-*Apt_ELC_HPN*-C to zero?

I was suggesting simply to constrain the heat pump-AB output RSDSH_Apt-C to be at most 51.4% of the input of space heat into C dwellings (and similarly for dwellings of other ratings). So, the constraint would operate on flows (heat pump output, and building input, on the ANNUAL level, or if desired, by each timeslice), and not capacity.

> I checked some timeslices in the results and they show only a small fraction of RSDAHT in going to cooling (RSDSC*) while the majority or all goes to heating (RSDSH*) – maybe this is a good bug?

That makes me curious again.  In your earlier screenshot, you had the following FLO_SHAR (2050):
   FLO_SHAR(r,2050,R-HC_Apt_ELC_HPN2-AB,RSDAHT, RSDSC_Apt,ANNUAL,FX) = 0.78;  and
   FLO_SHAR(r,2050,R-HC_Apt_ELC_HPN2-AB,RSDAHT, RSDSH_Apt-AB,ANNUAL,FX) = 0.78;

These should generate two equations for each timeslice, saying:

   VAR_FLO(RSDAHT, TS)  =  0.78 × VAR_FLO(RSDSC_Apt, TS)
   VAR_FLO(RSDAHT, TS)  =  0.78 × VAR_FLO(RSDSH_Apt-AB, TS)

As you can see, those would directly imply that the flows of RSDSC_Apt and  RSDSH_Apt-AB should be equal, would you agree? However, if you find that not being at all the case in the results, I would be curious to investigate it and see what is going on.    The more important to look at it if you think there is a bug...

[JasonMcGuire]

Hello everyone,

I'd like to provide an update on the current status of the model and the changes I've made.

I've introduced some new technologies. The original HeatPump-C, designed for C-rated dwellings, remains unchanged. However, I've added a new technology called Heat Pump-ABC. Previously, Heat Pump-AB was used for C-rated dwellings below the heat loss threshold. Heat Pump-ABC is functionally identical to Heat Pump-AB but specifically caters to the heat demand in C-rated dwellings, it is HeatPump-ABC which has been constrainted. This change has simplified the constraint, as HeatPump-AB is now exclusively for AB-rated dwellings.

   

Additionally, I've tackled the concern raised by Antti about potential issues stemming from a single ambient heat commodity covering both heating and cooling. To address this, I've introduced separate commodities for cooling, space heating, and water heating. This adjustment is aimed at avoiding conflicts and has the potential to offer valuable insights in our results!

Thanks for your help!
Jason