Filtering out invalid flows specified in `UC_T`

[olejandro]

          The remaining regression on `Ireland` is due to the tool currently not filtering out non-valid combinations of processes and commodities specified in `UC_T`, e.g. for `UC_FLO`.

Originally posted by @olejandro in https://github.com/etsap-TIMES/xl2times/issues/148#issuecomment-1857234704

[Antti-L]

@olejandro : Yes, by default topology check is enabled under UC_T (while it is by default not enabled under TFM_*). However, with Top_Check=N you can also disable the topology check under UC_T in VEDA (for individual rows or all), and so I think that should eventually be supported by xl2times as well.

[olejandro]

@Antti-L, do you see any reason for not doing topology check always in both UC_T and TFM_*, other than it requiring extra processing time?

[Antti-L]

Of course, at least for TFM_*, because for many attributes the commodity specified does not need to be in the process topology. And yes, I have had a real need for disabling topology check under UC_T, but cannot remember now in what context it was.

[olejandro]

Of course, at least for TFM_*, because for many attributes the commodity specified does not need to be in the process topology.

Is this because it is later added to the topology by TIMES? Could you give an example where a topology check in TFM_* would be undesirable?

[Antti-L]

Is this because it is later added to the topology by TIMES?

In some cases, yes, for example, FLO_EMIS can be used for defining any emission flows, and so a topology check would basically prevent using the attribute for its main purpose. Indeed, in that case TIMES does add it to the topology, unless it is already there. But there are other attributes where the commodity is not, and should not be added to the topology.

• Expects only a Commodity: FLO_CUM, FLO_EMIS. FLO_EFF, FLO_MARK, FLO_SHAR, IRE_FLOSUM, NCAP_ICOM, NCAP_OCOM, NCAP_COM, NCAP_CLAG, PRC_MARK, STG_SIFT, UC_CUMFLO, BS_BNDPRS, BS_RMAX, BS_STIME: Commodity need not be, and/or should not be in the topology
• Expects a CG: ACT_EFF, NCAP_AFC, PRC_ACTFLO : using commodity 'ACT' is valid and must never be added to topology
• Indirectly also FLO_COST, FLO_DELIV, FLO_TAX, FLO_SUB

[olejandro]

Thanks @Antti-L. Would you say that the concept of topology check is broader than just checking against TOP? I am asking, because of the attrabites that include CG as index rather than commodity in the example above.

[Antti-L]

Sorry, I don't see what you are implying by your question.

VEDA does the check only against the process topology, which, however, includes also TOP_IRE, and probably even some flows defined by FLO_EMIS (at least the variant ENV_ACT), for which VEDA may internally define topology entries. So, when a commodity is specified in CSet_CN, the topology check is NOT performed under TFM_*, unless requested by Top_Check. If requested, it is of course performed also for commodities defined for e.g. PRC_ACTFLO, which has a CG index. It checks that the commodity is in the process topology, as an Input, or an Output, or both, depending on what the user requests.

[olejandro]

Thanks @Antti-L. Your example for PRC_ACTFLO more or less answers my question. A few more clarifications:

• In case of a CG containing more than 1 commodity, should one check whether any of the commodities are in the process topology?
• Should it matter for the topology check whether a CG is specified in a commodity column or in other_indexes?

It checks that the commodity is in the process topology, as an Input, or an Output, or both, depending on what the user requests.

• How does one control it? I thought it would only check whether a flow is valid, but would not distinguish between input/output flows.

Also, do you think one can catergorise attributes on those for which the topology check should always / never be performed and those for which it should be user controlled?

I believe it is okay to deviate on some of these from Veda if it e.g. reduces the size of the QA log or improves user experience.

[Antti-L]

In case of a CG containing more than 1 commodity, should one check whether any of the commodities are in the process topology?

• I don't think VEDA does any check for the members of CGs;
• I don't thinkxl2times should do such either, but if deemed useful enough, checking that at least one member of the CG qualifies (according to the Top_Check rule) might possibly be useful when the user has explicitly requested a topology check.

Should it matter for the topology check whether a CG is specified in a commodity column or in other_indexes?

I don't think VEDA does any Topology check for labels specified in Other_Indexes. But yes, doing that might also be considered, but then in my view under the following rules (assuming user has requested Top_Check, or the attribute has been qualified for checking it by default):

• If the label is a commodity, perform the Top_Check as requested, and reject the label if it is not in the topology;
• If the label is not a commodity, but the attribute expects a commodity, reject the label;
• If the label is not a commodity, and the attribute accepts any CG, either do nothing, or check that the label is a predefined CG (predefined by VEDA or TIMES) or a UDCG

How does one control it? I thought it would only check whether a flow is valid, but would not distinguish between input/output flows.

Valid entries for Top_Check: I / O / A / N / Blank

• I => will retain those PRC/COM combinations where the COM is an input to the process PRC;
• O => same but COM must be an Output;
• A => COM must be either Input or Output;
• N => no topology check is performed;
• Default: TFM_* : N ; UC_T : A

do you think one can catergorise attributes on those for which the topology check should always / never be performed and those for which it should be user controlled?

I am not sure of too much benefit. I think the current defaults and the user control are basically fine. But ok, I think the following could be categorized for "always": NCAP_MSPRF, FLO_FEQ, FLO_FR, IRE_PRICE, NCAP_VALU, STGIN_BND, STGOUT_BND. "Never" for the BS_*.

[olejandro]

Thanks a lot for this input @Antti-L