Closed grdw closed 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)
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.
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.
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.
Instead, InstalledTechnology#profile_curve is called here.
Thanks! I think I know how to solve it from here.
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.
Staging:
Local:
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.
Try enabling the P2H strategy and see if that makes any difference. Perhaps the recent changes with that strategy upset the HHP...
With P2H enabled.
Staging:
Local:
Ho, nvm. My units were not similar. ...
If I however synchronise the units of the buffer (so both 1)
Staging:
Local:
You might want to cherry-pick 4bf9e7dd on to your branch; that should ensure it's not CoP/efficiency-related.
When cherry-picking your commit (4bf9e7d) it turned from
to:
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?
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.
Closing continuing the discussion in #1368
It's now only able to take
electricity
,gas
andheat
as a carrier. The thing I'm having trouble with is that the hybrid consists of two parts, agas
part and anelectricity
part but the mainInstalledTechnology
object is ahybrid
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:
And than implement it somewhere in the calculation code? But I would have no clue where and how to be honest.