Set FE|Non-energy use variables to zero if they have negative values

[pweigmann]

Due to they way they are calculated, some variables like FE|w/o Non-energy Use|Industry|Chemicals|Liquids|+|Hydrogen (EJ/yr) could become negative. This is avoided by setting them to zero in case they are < 0.

[fbenke-pik]

Could this adjustment cause problems with the variables not summing up as indicated by the plus notation? If so, are we ok with that? (the reporting would yield a warning in this case as we now have summation checks based on plus notation) Or should instead the calculation of this variable be done in a different way?

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

Due to they way they are calculated, some variables […] could become negative.

Then we should fix how these variables are calculated.

Can you give a specific example (including gdx file) where a variable is computed as having a negative value?

[pweigmann]

Due to they way they are calculated, some variables […] could become negative.

Then we should fix how these variables are calculated.

Can you give a specific example (including gdx file) where a variable is computed as having a negative value?

This is one example: /p/tmp/schreyer/Modeling/remind/ariadne/output/Bal_2023-08-21_15.26.32/fulldata.gdx. From what I understood from the code, we are calculating non-energy variables based on fixed values from 2020 - so depending on our run it would be quite difficult to ensure that we never go negative when subtracting. Happy about input for a better way to calculate it.

Also, as it is a temporary calculation, this fix was thought as also just a temporary fix to avoid negative values in our project reportings.

Could this adjustment cause problems with the variables not summing up as indicated by the plus notation? If so, are we ok with that? (the reporting would yield a warning in this case as we now have summation checks based on plus notation) Or should instead the calculation of this variable be done in a different way?

That is true, I didn't think about it. Another argument for a different calculation.

[0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q]

Is that required for a project now?
The changes to the non-energy FE stuff are likely to come down soon. So this is likely to go away anyhow with them being merged. If not, the "temporary calculation" will stick around and the fix deserves to be at least checked for consistency.

[pweigmann]

Is that required for a project now? The changes to the non-energy FE stuff are likely to come down soon. So this is likely to go away anyhow with them being merged. If not, the "temporary calculation" will stick around and the fix deserves to be at least checked for consistency.

Yes, we would prefer to not have the negative FE values in our Ariadne reporting.

I had some time today to look deeper into the calculations and I am not sure about a solution that would avoid the possibility of getting negative values.

From my understanding, we load the data from the reference run and scale it up here. The next step makes sure that the non-energy FE per carrier is not bigger than the regular FE per carrier, but as all non-energy is part of the chemicals subsector maybe should we instead compare against FE|Industry|Chemicals|+|<carrier>? At least that is the subtraction done later here which causes the negative FE|w/o Non-energy Use|Industry|Chemicals|Liquids (EJ/yr). I have to admit, I am not overseeing the effects this would have on the other steps of the scaling by sources etc.

Any opinion @0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q ?

Alternatively, keeping my current dirty fix might be a pragmatic solution until we soon have the proper feedstock implementation. Consistency in our variables is nice, but if that means they add up to negative FE values...

(from the .mif of the run linked above)