Gases|Hydrogen variables are somewhat misleading

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

For example FE|Industry|Gases|Hydrogen could be interpreted as hydrogen gas being used in industry, and not syngas. Are we married to that variable name? Can we still change it? Because I think that will only get worse over time

[fschreyer]

Well, our convention is that if you have two energy carriers separated by a bar the first one is the energy carrier denoted by the variable, the second one is the origin the first energy carrier was produced from. I find this quite clear and it helps to track the energy flows in REMIND. I would be open to alternatives, though:

FE|Industry|Gases|Synthetic (coal-to-gas is also synthetic, but not accounted here but under Gases|Fossil, might be confusing, too)
FE|Industry|Gases|Synthetic from Hydrogen (a bit long)

Navigate IAM template and other projects have Gases|Electricity. But strictly speaking, this is not what our variable denotes since the hydrogen does not have to be from electricity.

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

FE|Industry|Gases|Synthetic from Hydrogen (a bit long)

But explicit. Having just wasted half a day chasing a non-existent bug, I am in favour of clarity over brevity.

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

Also, there is some level of inconsistency with the Carbon Management|Storage|Industry Energy|Synfuel and Carbon Management|Carbon Capture|Industry|Energy|Synfuel (plus sub-variables of that), which where introduced in #51.

To reiterate:

• x|Gases|Hydrogen is misleading, because it can easily interpreted as hydrogen being included as one type of gas
• having different naming schemes (FE|Industry|Gases|Hydrogen but Carbon Management|Carbon Capture|Industry|Energy|Synfuel) is very bothersome during analysis, since it leads to lots of code to deal with edge cases
• they are also just called …syn inside the REMIND code, with the explanatory note "from H2"

I really would appreciate this being addressed soon. Whom do we have to rope into this discussion in order to move forward with it?

[fschreyer]

Well, I would say the ultimate solution for not being confused by variable names that others introduced is that we develop a list of definitions of REMIND variables. Maybe when I have more time on my hand, I could imagine pushing such a process.

On the naming schemes regarding synthetic fuels. I don't have a too strong opinion on the exact naming as long as it is not too long which would cause issues with legend entries compare scenarios and other scripts. I prefer shorter sublabels and I would say one should add sufficient text in the part of the reporting where they are calculated for others to understand them. That's where I would usually look for if I don't understand a variable.

What would be your suggestion for renaming?

As these variables are only for our internal use, I don't think we need to rope in much more people. Maybe @amerfort as someone from the carbon management team who has worked on this, too. But, let's not make it a too complicated process.

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

What would be your suggestion for renaming?

…|Synfuel. Short, same as on the GAMS and Carbon Management side.

[Renato-Rodrigues]

Maybe you could ask Robert and Gunnar about their opinions (maybe using an email or the REMIND meeting?), as I remember vaguely having this discussion when I implemented the SE carrier split in the GAMS code, and there were some opinions regarding those naming conventions that avoided using the same convention used in the GAMS code.

[fschreyer]

Renato, sry for getting a bit picky here but I implemented this split and the variables and I don't think we should bother everyone with internal variable naming of this kind. I would be fine with FE|Liquids|Synfuel etc. if Michaja prefers that and would like to do the renaming.

[Renato-Rodrigues]

I think it is important checking with them as this already have different nomenclature interpretations for AR6, NAVIGATE and REMIND variables templates. Deciding for some convergence regarding this is important from my point of view, or at least checking what is the decision regarding these naming conventions in current projects is relevant to make a decision.

You indeed implemented the synfuel split, but as I mentioned above my message was referring to the SE carrier split which was a requirement to do proper fe emissions accounting in the model, and it was done during the REMIND-EU development. The discussions I referred above were related with talks done during this time, more than four years ago.

[Renato-Rodrigues]

Just to give you an example, in ECEMF we decided upon using the naming convention Gases|Electricity instead for example. And maybe we could consider splitting what is originated from process that require electricity as input, from the ones that don't, before assigning everything to the same variable.

The synfuel does not need to be originated from electricity in the theoretical point of view, but economically and speaking from the model point of view it makes sense that is done this way, no? I must admit my knowledge is not that deep on this, so I would be all ears to hear a better explanation about it.