shift fuel switching penalties and secondary energy share deviations out of the welfare equation and into the tax system

[robertpietzcker]

Currently, there are two penalties (for fuel switching and for different origin-shares of SE types) listed in the welfare equation - after $ifthen "%cm_INCONV_PENALTY_FESwitch%" == "on" and after $ifthen not "%cm_seFeSectorShareDevMethod%" == "off"

q02_welfare(regi) ..
  v02_welfare(regi) 
  =e=
    sum(ttot$( ttot.val ge 2005 ),
      pm_welf(ttot)
    * pm_ts(ttot)
    / ((1 + pm_prtp(regi)) ** (pm_ttot_val(ttot) - 2005))
    * ( ( pm_pop(ttot,regi) 
        * ( ( ( ( vm_cons(ttot,regi)
            / pm_pop(ttot,regi)
        )
         ** (1 - 1 / pm_ies(regi))
          - 1
          )
        / (1 - 1 / pm_ies(regi))
        )$( pm_ies(regi) ne 1 )
      + log(vm_cons(ttot,regi) / pm_pop(ttot,regi))$( pm_ies(regi) eq 1 )
          )
        )
$ifthen %cm_INCONV_PENALTY% == "on"
      - v02_inconvPen(ttot,regi)
      - v02_inconvPenSolidsBuild(ttot,regi)
$endif
$ifthen "%cm_INCONV_PENALTY_FESwitch%" == "on"
        !! inconvenience cost for fuel switching in FE between fossil,
        !! biogenic, synthetic solids, liquids and gases across sectors and
        !! emissions markets
      - sum((entySe,entyFe,te,sector,emiMkt)$(
                                    se2fe(entySe,entyFe,te)
                                AND entyFe2Sector(entyFe,sector) 
                                AND sector2emiMkt(sector,emiMkt) 
                                AND (entySeBio(entySe) OR  entySeFos(entySe)) ),
          v02_NegInconvPenFeBioSwitch(ttot,regi,entySe,entyFe,sector,emiMkt)
          + v02_PosInconvPenFeBioSwitch(ttot,regi,entySe,entyFe,sector,emiMkt)
          )
          / 1e3	!! heuristically determined rescaling factor so the dampening doesn't dominate the transformation
$endif
$ifthen not "%cm_seFeSectorShareDevMethod%" == "off"
        !! penalizing secondary energy share deviation in sectors  
        - vm_penSeFeSectorShareDevCost(ttot,regi)
$endif
      )
    )
;

They were likely copied from the original inconvPenalty formulation (the two lines after $ifthen %cm_INCONV_PENALTY% == "on")

However, to my understanding, only the two original inconvPen lines should be in the welfare equation, and the others should be moved to module 21 - taxes.

The reason that the local air pollution inconvPen was put in the welfare equation is that they are explicitly meant to INCREASE in relevance as income increases - to represent that for rich people, local health is worth much more in monetary terms than for poor people.

This is not the case for the two newer implementations - they should just provide a monetary incentive that stays the same in comparison to the energy price, no matter whether we are looking at a reach region or not. So they should be shifted to the normal tax-type treatment in module 21, if I am not mistaken.

any thoughts on this, @fschreyer @Renato-Rodrigues @fpiontek @johanneskoch94 ?

(nothing urgent, just something that might be good to clean up at some point in time)

[Renato-Rodrigues]

I think we can use the same formulation as taxes to compensate for the penalization terms in between iterations, but I am not sure about adding them to the tax module and to the vm_taxrev term.

Maybe a better solution would be to add an alternative variable and equation to deal with the penalties compensations by themselves, so we have how to check their convergence independently of taxes, and do not pollute even more the taxes code with yet another source of abstraction besides the pseudo taxes we already have.

[robertpietzcker]

Could you explain what speaks against adding them to the module 21?
I don't immediately see how this would "pollute" the current module given that the module already has different types of incentives represented there.

So I think in this process
https://github.com/remindmodel/development_issues/issues/439
there will anyway be a clearer separation of different types of incentives, and I think these share deviation costs fit under the "or constrain some unwanted model behavior" aspect (using Laurin's words)

In principle they can also go somewhere else, but I don't directly see a module they would fit in better, and I am not sure this is worth adding another module?

[Renato-Rodrigues]

I'm not fully up to speed on the tax rework yet, so this might already be handled, but I'd prefer to separate the incentives convergence check from the real-world taxes convergence check, and both from the pseudo-taxes convergence check.

This can definitely be implemented within the tax module, but I wouldn’t limit vm_taxrev to checking convergence for all three formulations. Instead, using a dedicated convergence check for each would make debugging easier in non-converging runs.

[LaviniaBaumstark]

will this be addressed in REMIND v3.6.0? Is this still an isue? @robertpietzcker

[Renato-Rodrigues]

This isn’t urgent.
It should be addressed together with the decision on the tax refactoring.