Tax credits implementation for low-carbon technologies

[Antti-L]

> option 5 shouldn't have worked

Yes, by design it does work (just tested and indeed it worked). Do you find that undesirable?

> FIN instead of ENV for the PTC commodity

Sure that's ok, but the drawback is, as you noted, that you have to manually add it to the topology.

> didn't use LimType N

Sure that's ok, but the drawback is some unnecessary processing (and it would then not work with negative values, but such is not the case here), and the risk of re-using that dummy commodity for a dummy input flow elsewhere (avoided with the 'N' type)

> actual amount of PTC as FLO_EMIS; FLO_SUB = 1

Sure that's a nearly equivalent alternative. Some difference may be induced with subsidies changing over time, due to dense vs. sparse interpolation.

> I guess, this is because ENV and FIN commodities are treated differently by Veda?

Possibly so, but VEDA should not be adding either to the topology. It is TIMES adding ENV flows defined with FLO_EMIS to the topology as OUT, unless it is already in the topology.

[olexandr]

Super, thanks!

Regarding I/E, table 9 in docs states that <=0, 1, 2, 11 are the valid options for SHAPE and MULTI. Should I open an issue in the docs repo on github to get it updated?

Ok, good to know that "it is TIMES adding ENV flows defined with FLO_EMIS to the topology as OUT, unless it is already in the topology". Would it make sense to treat FIN and MAT similarly?

[Antti-L]

In my view it is, in general, too error prone to add commodities into the process topology just on the basis of a parameter being defined.  ENV commodities can be considered an exception, because they are usually not taking part in the main process transformation.  So, mostly the user has to define the topology explicitly, which is in my view a good thing. If you disagree, and other users too, that can of course be reconsidered.

[olexandr]

Thanks Annti! I generally prefer explicit .