quintel / etmoses

Online decision support tool to create local energy situations for neighbourhoods, cities and regions with a time resolution of 15 minutes created and maintained by Quintel – Not maintained
https://moses.energytransitionmodel.com
MIT License
11 stars 3 forks source link

How would I expand the network calculation with hybrids? #1381

Closed grdw closed 8 years ago

grdw commented 8 years ago

It's now only able to take electricity, gas and heat as a carrier. The thing I'm having trouble with is that the hybrid consists of two parts, a gas part and an electricity part but the main InstalledTechnology object is a hybrid carrier... So I'm a bit clueless. I could fish out the corresponding component for a hybrid technology but than I miss all the investment attributes) of the main hybrid technology.

I'd like some class like:

# This is just some poor sketch... 
class Network
  class Technologies
    class Hybrid
      def initialize(hybrid)
        @hybrid = hybrid
      end

      def gas_part
        @hybrid.attributes.merge(component_for_carrier(:gas).attributes)      
      end

      def electricity_part
        @hybrid.attributes.merge(component_for_carrier(:electricty).attributes)      
      end

      private

      def component_for_carrier(carrier)
        @hybrid.components.detect do |component|
          component.carrier == carrier
        end
      end
    end
  end
end

And than implement it somewhere in the calculation code? But I would have no clue where and how to be honest.

antw commented 8 years ago

I'm not sure why you'd want to do this? I thought the idea was that InstalledTechnology would be able to split itself up into the individual components, that way the Network would need almost no changes (after all, the gas and electric components are basically two completely separate technologies inside one box). The pseudo-code above looks more like an InstalledTechnology subclass than a Network::Technology.

There would have to be some changes to the network builders (such as here, here, and here) so that these components are included in the list of installed technologies. Something like:

node.set(:installed_techs, techs.flat_map do do |tech|
  # Get the individual components of each technology:
  tech.components.select { |t| t.carrier == :electricity }
end.compact)
antw commented 8 years ago

I should add: by the time you get to the Network::Technologies, it is already too late to deal with different carriers. A technology belongs to the electricity, gas, or heat networks, and has no knowledge that other networks even exist (power-to-gas is an exception, but even that needs to be told about the gas network before the calculation happens).

I think the suggestion of having a hybrid Network::Technology which acts on multiple networks isn't possible currently, and likely isn't desirable due to the added complexity.

grdw commented 8 years ago

I'm not sure why you'd want to do this? I thought the idea was that InstalledTechnology would be able to split itself up into the individual components

Hmm, allow me to rephrase the question to; where does that happen in the code currently? I can't seem to find the each_profile_curve method being used anywhere except the definition of itself.

and likely isn't desirable due to the added complexity.

Yes. I get that.

antw commented 8 years ago

I can't seem to find the each_profile_curve method being used anywhere except the definition of itself.

It seems that each_profile_curve is no longer used. Instead, InstalledTechnology#profile_curve is called here.

grdw commented 8 years ago

Instead, InstalledTechnology#profile_curve is called here.

Thanks! I think I know how to solve it from here.

grdw commented 8 years ago

The idea is now to decorate right before calculating. I'm almost there I guess, there are only some attributes missing in the components that are needed from the parent element but that's rather easy from this point.

grdw commented 8 years ago

Staging: screen shot 2016-08-18 at 15 36 22

Local: screen shot 2016-08-18 at 15 36 27

I spot a difference between staging and local? @ChaelKruip do you know what might be going on here? It looks as though the gas part is not doing anything.

antw commented 8 years ago

Try enabling the P2H strategy and see if that makes any difference. Perhaps the recent changes with that strategy upset the HHP...

grdw commented 8 years ago

With P2H enabled.

Staging: screen shot 2016-08-18 at 15 41 41

Local: screen shot 2016-08-18 at 15 41 46

grdw commented 8 years ago

Ho, nvm. My units were not similar. ...

grdw commented 8 years ago

If I however synchronise the units of the buffer (so both 1)

Staging: screen shot 2016-08-18 at 15 44 57

Local: screen shot 2016-08-18 at 15 45 02

antw commented 8 years ago

You might want to cherry-pick 4bf9e7dd on to your branch; that should ensure it's not CoP/efficiency-related.

grdw commented 8 years ago

When cherry-picking your commit (4bf9e7d) it turned from

screen shot 2016-08-18 at 15 45 02

to:

screen shot 2016-08-18 at 16 11 10

grdw commented 8 years ago

The number are mismatching due to: https://github.com/quintel/etmoses/issues/1382 I do think it's odd that the gas is off on staging but the gas is on locally. Why would that be?

antw commented 8 years ago

I looked into this and I believe the (extra) gas consumption is due to #1261. I don't think this pull request is responsible for the problem.

grdw commented 8 years ago

Closing continuing the discussion in #1368