search

pik-piam / edgeTransport

A detailed transport sector model.
5 stars 15 forks source link

Duplicated variables #221

Closed jmuessel closed 1 year ago

jmuessel commented 1 year ago

We now avoid duplicated variables by adding an "edge" to the variable description to distinguish variables reported by edgeT from variables reported by remind2. E.g. FE|Transport|Pass|Road|LDV -> FE|Transport edge|Pass|Road|LDV.

I changed the described variable names in transport CompScen as well.

Furthermore, I made the MIP package export some functions required to execute the function showLinePlotsByVariable() in the file csEDGET_02_energy_services.Rmd (see PR for the MIP package from today, 31.03.2023)

The duplicated variables that received an additional suffix in the toolsReportEdgeT() function are: ES|Transport|Pass, FE|Transport, FE|Transport|Electricity, FE|Transport|Gases, FE|Transport|Hydrogen, FE|Transport|Liquids, FE|Transport|Freight, FE|Transport|Freight|Electricity, FE|Transport|Freight|Gases, FE|Transport|Freight|Hydrogen, FE|Transport|Freight|Liquids, FE|Transport|Pass, FE|Transport|Pass|Electricity, FE|Transport|Pass|Gases, FE|Transport|Pass|Hydrogen, FE|Transport|Pass|Liquids, FE|Transport|w/o Bunkers, FE|Transport|w/o Bunkers|Electricity, FE|Transport|w/o Bunkers|Gases, FE|Transport|w/o Bunkers|Hydrogen, FE|Transport|w/o Bunkers|Liquids, ES|Transport|Road, ES|Transport|Freight

Renato-Rodrigues commented 1 year ago

Thank you very much!

One question although, could you explain why did you prefer to add the tag Transport edge only to the duplicated variables instead of all edge generated variables? If someone uses a mix of the non-tagged edge transport variables and normal remind reporting variables, they would without knowing add inconsistences in variable sums to project reports and paper results. I would say that adding this tag to all edge transport variables is a much more consistent solution, so I would like to know the reasoning against doing that.

jmuessel commented 1 year ago

@Renato-Rodrigues, your suggestion would indeed be more concise. Still, it would require a lot of work because all projects' variable mappings would have to be changed. Furthermore, Michaja raised the issue of other (REMIND) scripts accessing the variables and that one would have to change the variable name here as well - which would probably lead to a lot of errors. https://mattermost.pik-potsdam.de/rd3/pl/rx71kkstptdu9ytg5mbdrjrjpy

Given this amount of work and the potential for making mistakes, while changing variable names in so many scripts, we decided to live with this inconsistency for now. Do you agree with this compromise or do have a smart and easily executable idea?

Thank you for your time :)

jmuessel commented 1 year ago

I just realized that both of you are on holiday. I decided to merge it now as I talked with Johanna about what I did and feel comfortable doing this without you reviewing it. Hope that is ok, otherwise, hit me up after you return from your holidays.

Renato-Rodrigues commented 1 year ago

@jmuessel I completely agree with your merging as a partial solution, but I would create an issue to follow up changing the other variable names from edge-t also as soon as possible. The piam Interfaces library was created exactly because cases such as this, so we can allow consistent variable renaming in remind reportings.

You only need to follow these steps at the same time:

  1. Create a PR adding the additional edge tag to all remaining transport edge variables.
  2. Adapt the mappings in the piamInterfaces R library accordingly if those variable are used there (you can talk with Oliver or Falk if you are not familiar with the piamInterfaces library).
  3. Warn at a REMIND meeting that anybody that uses edge-t extended results will need to adapt their own personal scripts to use the new naming convention from this version onward.
  4. Merge everything together.