> 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.
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.