Closed dennisquintel closed 11 years ago
dennisquintel
commented
11 years ago It's also remarkable that the value of the loss share can differ, looking at the output, take e.g.:
...
Loss share found: 1.0309278350515465 for energy_power_hv_network_electricity
Loss share found: 1.0204081632653061 for energy_power_hv_network_electricity
...
Loss share found: 2.9411764705882346 for energy_power_hv_network_electricity
...
antw
commented
11 years ago @dennisschoenmakers I'm not too familiar with RecursiveFactor, but I'll look into it. What script did you use to generate the output above?
dennisquintel
commented
11 years ago I just used the Rails logger in the recursive_factor method...
Rails.logger.warn("Loss share found: #{loss_share} for #{key}")
hasclass
commented
11 years ago loss (10)----\
-- B (110) --->
A (100 )------/I think loss_share was used for above scenario. loss_share takes into account the loss created by B. Otherwise this information gets lost and A would give a wrong number.
antw
commented
11 years ago It's also remarkable that the value of the loss share can differ, looking at the output [...]
I can't reproduce that behaviour locally with ETengine's master branch. Here's what I get after adding the Rails.logger.warn line to the top of recursive_factor, on a brand new NL/2050 scenario:
Loss share found: 1.0539743186709545 for energy_power_hv_network_electricity
Loss share found: 1.0539743186709545 for energy_power_hv_network_electricity
Loss share found: 1.0539743186709545 for energy_power_hv_network_electricity
Loss share found: 1.0539743186709545 for energy_power_hv_network_electricityThis converter appears 26 times, and every time the value is the same.
As for the loss_share method, it appears to be used to adjust the values returned by recursive factor to include energy which leaves a converter as loss, as opposed to a useful form of energy such as electricity or heat. It is used here in the recursive_factor function:
demanding_share * loss_share * converter_share * child_valueAn example: (view on GitHub for it to not look ugly)
┌──────────┐ ┌──────────┐
| CONSUMER | <─ electricity ─ | SUPPLIER |
└──────────┘ ┌─ └──────────┘
lossSupplier has an output conversion for electricity of 0.8, and loss of 0.2, and the supplier has demand of 100 (so the electricity link carries 80 energy to the consumer).
┌───────────────┐ ┌────────────────┐
| CONSUMER (80) | <─ electricity (80) ─ | SUPPLIER (100) |
└───────────────┘ ┌─ └────────────────┘
loss (20)So... when loss_share is called on the supplier, this is the calculation:
1.0 / (1.0 - self.share_of_losses)
# => 1.0 / (1.0 - 0.2)
# => 1.251.25 is the amount by which you must multiply the link "share" value (called "demanding_share" in RecursiveFactor) in order to pretend that the supplier has no loss (80 * 1.25 == 100). Why is this needed? ... I don't know. Perhaps because loss slots rarely have an outgoing link, and without loss_share losses wouldn't be included in calculations? I'm honestly not sure; I'll keep researching. :disappointed:
I think it might be confusing because of the name: perhaps a better alternative would be loss_compensation or loss_compensation_factor. And that's to say nothing of the right-hand (parent/supplier) node being called "child" in the recursive_factor method...
dennisquintel
commented
11 years ago 1.25 is the amount by which you must multiply the link "share" value (called "demanding_share" in RecursiveFactor) in order to pretend that the supplier has no loss (80 * 1.25 == 100). Why is this needed? ... I don't know.
First of all, the name loss share is kind of confusing indeed. I agree that it should be renamed to something like loss_compensation_factor).
┌───────────────┐ ┌────────────────┐
| CONSUMER (80) | <─ electricity (80) ─ | SUPPLIER (100) |
└───────────────┘ ┌─ └────────────────┘
loss (20)When asking for the primary_co2_emission of CONSUMER, losses will have to be taken into account, since that is intrinsic to the definition of primary_demand. In other words: the difference between primary demand and final demand is that primary demand takes losses into account. Image that a society's (final) demand is 100 PJ, due to a very old and crappy electricity network, that final demand leads to primary demand of 1.000 PJ, and 900 PJ is 'wasted' though losses at intermediate steps.
In the example above, the loss_share would be 1.25, so the primary_demand of CONSUMER is equal to 80 * 1.25 = 100 PJ.
Currently, RecursiveFactor::Base#recursive_factor multiplies the values at the level of the CONSUMER. It might be an alternative to sum the values at the level of the SUPPLIER, eliminating the need for this factor.
Currently, the recursive_factor method uses something called the loss_share.
@ChaelKruip and me where yet unable to determine exactly what it is, except that it's values can be 0 (for when the supplying converter consists merely of loss) or between 1 and infinity, also see the examples that we draw up here.
Question still remains: what is it's purpose? Why does it need to be bigger than 1 for the
recursive_factorto work (e.g. forco2_emissions).Including @hasclass and @antw since they might know a bit more.
Examples of _lossshares from a random scenario: