Dublicates?

[janis]

Happy New Year! I have the following issue. In VEDA2 v4.2.1.0 another SETS and SCENARIO entry appears at commodity TOTN2O and TOTCH4. Those two commodities listed in Manage Duplicates. Please see pics below. I cannot find any file where they are redefined. What should I do next? Starting from scratch does not help.

[AKanudia]

The open files button on Manage Duplicates should take you to those locations. Remember that the duplication could be within the same table and file too.. not just across files.

[janis]

Absolutely correct, but pressing the files button on Manage Duplicates opens one file (in this case BY_Trans.xlsx) containing the mentioned commodities defined only once. It feels like VEDA sees it in a place I can't see, especially when I look at the scenario name "_VA_BASE" and the set entry "-NRG" for the mentioned commodities.
I would be very happy about any thoughts and ideas on this matter.
Thanks!

[AKanudia]

Do you have commodity definitions in BY_Trans? In principle, the ~FI_Comm tag is supported only in BY, SubRES, SysSettings. If you do, move them to SysSettings and test.

[janis]

I apologize for the rewrite, but the file is VT_LV_all_v1.xlsx (not BY_Trans.xlsx).

[Antti-L]

Maybe it could then help if you can show the table in VT_LV_all_v1.xlsx, where they are defined?

[janis]

Oh yes, here is the table! I sent Amit the same file as well.

[Antti-L]

Ok, looks fine to me.
I guess it is the mysterious _VA_BASE probably the key here, and Amit should be able to tell where that is coming from.

[rohit]

TOTN2O, TOTCH4 and other such TIMES internal commodities (DEMO,ACT,NRGI etc.) are stored with the reserved _VA_BASE scenario name.
_VA_BASE is a system-generated scenario used as a container for these system-level commodities; it is not a user scenario.
Because these are managed by the system, they should be excluded from the duplicate detection logic.

We will fix this logic in the next update so these false positives are filtered out.
For now, you can safely ignore these warnings as they do not affect the .dd files or the model results.

[janis]

Okey, I see. Intrestiglly, but why not TOTCO2 or other commodities? It seemed to work until March of last year (tonight, I can't say for sure what version of VEDAS it was. .

I assume this will also fix the SET entries for TOTN2O and TOTCH4? I discovered this in this way - my excel result queries breakes and the reason was that these commodities did not appear in the results because they were defined in the Sets_Latvia.xlsx file via cset_set=ENV.

[Antti-L]

> they were defined in the Sets_Latvia.xlsx file via cset_set=ENV.

Ok, it seems now we have the explanation to the strange issue!

[janis]

Is it currently possible to somehow select these commodities in the Sets_Latvia.xlsx file so that they are located under a specific SETNAME untill the next update? Because I really don't want to change my result queries, but I needed the results yesterday  .

[Antti-L]

I tried to reproduce your issue in a test model, but I could not get TOTCH4 appear in the _VA_BASE scenario, but instead, I managed to get TOTN2O appear as such!

And yes, I did also manage to reproduce the strange issue that when I have these commodities in the model, they do not seem to appear in any VEDA commodity set that I define, such that has the CSet_CN mask TOTC*,TOTN*, and therefore obviously the set should contain those commodities as its members.  It is very strange indeed.

Moreover, @Rohit was not correct in saying that TOTN2O, TOTCH4 would be some kind of TIMES internal commodities; they are definitely not such. The TIMES code does not at all contain these strings anywhere. However, it looks like they seem to be some kind of VEDA reserved system commodities?  But why would they be such?

I agree that it would be nice to know what is going on here.

[janis]

I think it might be related to this thread https://forum.kanors-emr.org/showthread.php?tid=1508 if the guys had changed something in VEDA in relation to it.

[Antti-L]

@Rohit :
> For now, you can safely ignore these warnings as they do not affect the .dd files or the model results.

This is not quite true either.  I have a scenario file where I define COM_AGGs from TOTCH4 and TOTN2O to GHG and NONCO2.  In earlier versions of VEDA they were written out correctly into the DD file, but in VEDA v4.2.1.0 they are getting ignored, apparently basically due to an issue closely related to the one reported above.  All other COM_AGGs between ENV commodities work, but those where the source commodity is TOTCH4 or TOTN2O do NOT work in v4.2.1.0. They have been defined as ENV commodities in the model.

This also means that my models no longer work correctly under v4.2.1.0.

Why has the handling of TOTCH4 and TOTN2O been changed in VEDA?  Note that they are not at all TIMES internal commodities, but user-defined commodities in many TIMES models, and so it seems strange that they now seem to be getting some kind of special (and erroneous) handling under VEDA, are they?