Display the Hybrid heat pump as one entity in front-end

[grdw]

RIght now the Hybrid heat pump is split up into two pieces. We would like to display it as one technology. The thing is, I know how this would work in the front-end. However, I have no idea what the damages will be during the calculation (I guess, it would be significant).

Current situation

Front-end -> Calculator:

HHP (e) -> HHP (e)
HHP (g) -> HHP (g)

Front-end -> Calculator

HHP -> HHP (e)
    -> HHP (g)

---

Things that need to be edited:

• [x] Import needs to change to a single HHP
• [x] Split the HHP when calculating

[antw]

This would definitely be nice. Perhaps it could be handled similarly to base loads, where a single front-end technology is split into two separate parts before being handed off to the calculation?

The complicating factor in this case is that the two parts use different carriers. This means that technology_component_behavior would likely need to become something more detailed:

behavior: hhp

components:
  electric:
    behavior: hhp_electricity
    carrier: electricity
    position_relative_to_buffer: buffering
  gas:
    behavior: hhp_gas
    carrier: gas
    position_relative_to_buffer: boosting

# etc...

... where each "component" would inherit the attributes of the main technology.

[grdw]

I'm having multiple questions stating from the content that's in the separate parts of the hybrid heat pumps:

Summarized content of the Hybrids that spawn questions (I filterd out all the obvious things):

---
carrier: hybrid
color: "#57A753"
behavior: buffer
visible: false

Content of the electricity part:

---
behavior: hhp_electricity
carrier: electricity
color: "#9ED2A1"
defaults:
  capacity: 4.9
  initial_investment: 3235.0
  om_costs_per_year: 96.7
  performance_coefficient: 4.5
  position_relative_to_buffer: buffering
  technical_lifetime: 15

expandable: false
export_to: households_space_heater_hybrid_heatpump_air_water_electricity_share

Content of the gas part:

---
behavior: hhp_gas
carrier: gas
color: "#80C37D"
defaults:
  capacity: 22.0
  initial_investment: 1500.0
  om_costs_per_year: 156.2
  performance_coefficient: 1.067
  position_relative_to_buffer: boosting
  technical_lifetime: 15

What are we going to do with the color attributes, and the export_to for the electricity part. Could we also add those to the components or wouldn't that make any sense?

Also the defaults, what do we need to do with those, are we're going to merge them (i.e. sum both, or throw them out and use the attributes of the main hhp)? @ChaelKruip or are the defaults based of the things that we extract from the main hybrid heat pump from ETEngine?

[antw]

What are we going to do with the color attributes, and the export_to for the electricity part. Could we also add those to the components or wouldn't that make any sense?

I suppose we could. I understand your concern, especially with the defaults; costs and lifetime would be shared between both components, but the capacity, performance coefficient, and "position relative to buffer" are different for each component. This does feel a bit inelegant.

I wish I had a better idea to offer. 😧

[grdw]

Couldn't we keep the information concerning defaults in both components and associate the components from the hybrid heat pump.

---
carrier: hybrid
color: "#57A753"
behavior: hhp

components:
  - electric
  - gas

In Technology:

class Technology
  ...
  def components
    attributes[:components].map do |part|
      Technology.find_by_key("#{ key }_#{ part }")
    end
  end
  ...
end

And in Network::Technologies

def self.from_installed(installed, profile, options = {})
  # expand the hybrid heat pump in two technologies?
  # installed.technology.components.map do |technology|
  #   ? 
  # end
end

This would take some changes to the calculator I guess but I don't know how hard that'd be. The only issue I see here is that you can't really simply edit the costs of a single component of the Hybrid heat pump or the capacity for that matter.

[antw]

Couldn't we keep the information concerning defaults in both components and associate the components from the hybrid heat pump.

I like that. But could we do without the magic name, and perhaps just specify the full keys like this?

components:
  - households_water_heater_hybrid_heatpump_air_water_electricity_electricity
  - households_water_heater_hybrid_heatpump_air_water_electricity_gas

The only issue I see here is that you can't really simply edit the costs of a single component of the Hybrid heat pump or the capacity for that matter.

That is also a good point. There would need to a form template specific to the HHPs which would allow you to edit these. I guess each form element would have to specify which component it relates to:

// Pseudo code.

// Sets capacity on the electric component
%input(type="text" name="capacity" data-component="households_..._electricity")

// Sets capacity on the gas component
%input(type="text" name="capacity" data-component="households_..._gas")

// Sets capacity on all components
%input(type="text" name="capacity" data-component="all")

I imagine this is quite a bit of work.

This would take some changes to the calculator I guess but I don't know how hard that'd be.

It would be nice if this could be handled before the calculator, by hooking into something like InstalledTechnology#each_profile_curve. Perhaps the time has come to replace that with something bigger, like InstalledTechnology#network_components. This would return an array of InstalledTechnology instances for use in the calculation. A "normal" technology would just return itself:

def network_components
  [self]
end

A technology with split profiles (base loads) would return two components: one for the inflexible component and one for the flexible:

def network_components
  profile_curve.each_pair.map { ... }
end

While the heat pumps would have to do something else:

def network_components
  components.map do |key|
    attributes = component_attributes(key) # Determines the attributes for the component
    InstalledTechnology.new(attributes.merge(type: key))
  end
end

If that's not possible, we can look into making the calculator do it; but it would be preferable to not have to give it that responsibility.

[grdw]

But could we do without the magic name, and perhaps just specify the full keys like this?

Yes

I imagine this is quite a bit of work.

Well, yes. You'd have to start saving the data like:

{
  name: "HHP",
  components: {
    electricity: { capacity: 1.0 },
    gas: { capacity: 1.0 }
  }
}

So this takes changes in the way the data is parsed. Also this puts extra pressure on the technology_profile field. I haven't seen any LES going out of bounds when it comes to size but this might.

To prevent this we might, Uglify the data before it goes into the database (with the 26 variables for busy developers) and than Beautify when we access the charts again. However, this is a bit of a nice to have.

but it would be preferable to not have to give it that responsibility.

I agree 👍

[grdw]

I guess each form element would have to specify which component it relates to:

Must it be possible to define a capacity for the HHP, the electricity part of the HHP and the gas part of the HHP? Or is it ok, to just do it for the electricity part of the HHP and the gas part of the HHP, considering both pieces as one of a whole. Or am I misunderstanding the behavior of the HHP, this way?

[ChaelKruip]

Or is it ok, to just do it for the electricity part of the HHP and the gas part of the HHP, considering both pieces as one of a whole.

Only this. The HHP as a whole does not have a capacity. Only the parts.

[grdw]

The hybrid heat pump looks like this in the front-end. As far as I understood it from @ChaelKruip's input. This is only the front-end, now it's time for the Javacript and the back-end.

[ChaelKruip]

The hybrid heat pump looks like this in the front-end.

Very nice! The only thing that worries me a bit is the efficiency of the gas-part. 1.067 is what ETE tells us, but ETM-SA does not take efficiencies/COP into account except for heat pumps. So that value should be 1.0 right @antw?

[antw]

but ETM-SA does not take efficiencies/COP into account except for heat pumps. So that value should be 1.0 right @antw?

The classes for the HHP components are descendants of Buffer, therefore they support CoP/efficiency.

[ChaelKruip]

The classes for the HHP components are descendants of Buffer, therefore they support CoP/efficiency.

Nice! Than we can use 1.067 for the gas-part 👍

[grdw]

I've the feeling that I'm almost there. There's still one thing that needs to be solving and that's the money 💵 . The hybrid part holds all the investment variables but the business case uses the two loose components which in retrospect don't inherit any of the investment variables yet. The simple solution is, give the electricity or gas part all the investment related variables (om_cost_per_year, technical_lifetime, initial_investment etc.). But that can be ugly, also since I don't really know which of the parts would get those investment variables (either gas or electricity). All I know is it can't be both, because than a HHP would cost twice as much as ETEngine says it would be.

As one wise and notorious philosopher once said: mo money mo problems.

[ChaelKruip]

The hybrid part holds all the investment variables but the business case uses the two loose components...

I think that the business case should take costs of the (total) hybrid thing into account. Is that not the most obvious solution @grdw?

[antw]

Since the costs are for the combined unit, can't they be assigned to the top-level HHP technology rather than the individual components?

[antw]

Since the costs are for the combined unit, can't they be assigned to the top-level HHP technology rather than the individual components?

I realise now why that's easier said than done; the costs are taken from the technologies assigned to the networks, whereas the top-level tech isn't assigned to a network (but the individual components are).

Perhaps TechnologyCosts can be changed to use TestingGround#technology_profile instead?

[grdw]

Perhaps TechnologyCosts can be changed to use TestingGround#technology_profile instead?

Was already thinking that 👯

[grdw]

I managed to solve it like this. I think the PR is all good. So if somebody could check it out.