Add support for the UC_ATTR attribute

[olejandro]

@Antti-L any chance I could use your expertise on the following issue?

Our TIMES-Ireland Model benchmark has the following entry:

SET UC_ATTR
/
'IE'.'UC_Max_SNSP'.LHS.UCN.DAYNITE
/;

As far as I can see in the docs, DAYNITE is not part of UC_NAME set, but since GAMS doesn't throw a domain violation error while processing the corresponding input file, I guess, it must be. What am I missing?

[Antti-L]

Ah... it is just the workaround for UC_TSL under VEDA. Years ago, that seemed to provide an easier way to have VEDA support available for UC_TSL, as compared to requesting implementation of that new SET attribute in VEDA. Therefore it was decided to implement such a workaround: One can use tslvl as a UC_NAME in UC_ATTR, to define a constraint ts-dynamic (or "pseudo-dynamic") on the desired level.

[olejandro]

Ok, thanks! I've now added that possibility as well.

How about N, CUM+, YES, ANNUL, FLO_COST, FLO_DELIV, FLO_SUB, FLO_TAX, NCAP_COST, NCAP_ITAX, and NCAP_ISUB? Should all of them be also allowed?

[Antti-L]

How about N, CUM+, YES, ANNUL, FLO_COST, FLO_DELIV, FLO_SUB, FLO_TAX, NCAP_COST, NCAP_ITAX, and NCAP_ISUB? Should all of them be also allowed?

Of these, YES is a documented modifier for users to use, and so must be allowed. N, CUM+ and ANNUL are internal, and should best not be allowed. The rest are old-style user cost modifiers (not documented, but they do still work), and someone might use them.

[Antti-L]

I see the following column list: columns = [ "uc_n", "description", "region", "reg_action", "ts_action", "uc_attr", "group_type", "side", ]

I can see reg_action is apparently related toR_EACH / R_SUM, but I am curious about this "ts_action". I would have expected it to be related to TS_EACH / TS_SUM, but it doesn't seem to be, because in the code I see startswith("T_"). So, does this mean there is no timeslice action, and the ts_action is about periods, i.e. T_EACH / T_SUCC / T_SUM ?

[olejandro]

Thanks @Antti-L. I've opened an issue to handle timeslice action. Will also rename the "actions" to avoid confusion between periods and timeslices. Unfortunately neither TS_EACH nor TS_SUM appear in our benchmarks, so we don't have a test for it. If you happen to have a simple model that covers the case (and possibly more) and you are willing to share it, I'd be happy to include it in the benchmarks.