Ghosh varaible naming and structure

[konstantinstadler]

This is a discussion thread for the Ghosh naming stuff.
First, a copy from @Kajwan comment in the pull request #146 👍🏽
"
I was planning to do some restructuring of the Ghosh implementation. My main intention is to:

• Ensure that the Ghosh implementation mirrors the Leontief implementation. I.e., M_Ghosh = G S rather than M_down = S (G' - I), which is not the Ghosh multipliers.
• Calculate income-based impact accounts using the Ghosh multipliers.
• Not sure if it makes sense to have M_down, when we don't have M_up. Furthermore, those two multipliers are not complementary, and the language of M_down and M_up makes it sound like they are. A solution could be to have could be to have M_Ghosh_downstream = (G-I) S and M_Leontief_upstream = S (L-I)
• Update the terminology and math docs accordingly.

Let me know if you have any thoughts.
"

@Beckebanze , I want to add you to that discussion

[konstantinstadler]

My main concern is that, if we rename the "Classical" M multipliers, we break several downstream packages.
I would suggest to perhaps have an "alias" from M_Leontief_upstream to M, but M should still be the classical stuff.

Connected to that, see:
https://pymrio.readthedocs.io/en/latest/terminology.html

[Kajwan]

The classical M multiplier will remain the same, i.e., M = S L.
The issue is, that in the current implementation, we have M_down = (G-I) S, which is not the correct Ghosh multiplier.
What we need to implement is proper Ghosh multiplier M_Ghosh = G S.

The question, do we keep, what @Beckebanze has termed M_down = (G-I) S, or do we only include the M_Ghosh multiplier.
If we decide to keep it, I believe that we have to do 2 things:

1. Rename it to M_Ghosh_downstream (or just M_Ghosh_down).
2. Implement an equivalent multiplier for the Leontief model, i.e., M_Leontief_upstream = S (L-I).

[Beckebanze]

Hi, sorry for the late response.
The context for having introduced M_down is so that M + M_down include upstream, scope 1 and downstream. M (being M_Leontief) and M_Ghosh cannot be added, as this would double count scope 1, so having at least one multiplier that excludes scope 1 is helpful.

My suggestion is to implement the following:
M = S L
M_Gosh = G S
M_up = S (L-I)
M_down = (G - I) S

In this way, it is possible to keep the current summing M + M_down, while also facilitating easy summing of all scope 3 by M_up + M_down

[Beckebanze]

See also #165 (comment). Most important is that the change in the definition of G is clearly communicated when released.

[Kajwan]

Hi Felix (and Konstantin),

I see why it is useful to have M_down predefined. However, I do not think the definition of M_up and M_down are appropriate. They give the impression that they are complementary (mutually exclusive) factors, when that is in reality not the case. They not only run risk of double counting impacts, but also allocate impacts according to very different allocation principles.

We could call them something else. Perhaps M_Ghosh_indirect and M_Leontief_indirect?

/ Kajwan