STOCK: handling dependencies

[olejandro]

If a process is defined in BASE, Veda won't add STOCK=0 if there is more than 1 year for which STOCK is defined (either in BASE or e.g. via an insert table in a scenario file). However, deleting a scenario file which specifies STOCK for additional years from a synchronised model won't trigger addition of STOCK=0. Currently one needs to manually resynchronise the corresponding VT file.

[olejandro]

@akanudia

[akanudia]

The STOCK=0 entries you are looking for should reappear when any file is synchronized. I think you have tested the case where scenario deletion was the only operation, in which case the synchronization queries don't run at all.

We could detect this case and run some of the synchronization queries automatically, but I am less inclined, because STOCK is basically a legacy attribute that was brought in to support models that were built under MARKAL. PASTI has several advantages over STOCK.

[olejandro]

Thanks @akanudia! You are right. I observed this behaviour when scenario deletion was the only operation. I then re-synchronized the file which defined the process (incl. dependencies) to check whether the entries reappeared.

The purpose of opening this issue was just to report the observation. Since I do not have an overview of how many models use STOCK or how many modellers use scenario deletion operation in Veda, it is hard for me to judge how important this is.

[Antti-L]

Note that TIMES will add PRC_RESID=0 at the lifetime time-distance, if there is only one data point specified for PRC_RESID. VEDA is doing the same thing for both PRC_RESID and STOCK (aliases in VEDA), primarily to make that more transparent to the user: the user will see the added data point in Browse and Items detail, which is a good thing. I am also not sure whether they would produce exactly the same trajectory in all cases (due to e.g. non-integer lifetimes), but at least very close.

For defining residual capacity profiles for many bulk technologies, using PRC_RESID (equivalent to RESID in Markal, CAPA-RES in EFOM) indeed has clear advantages over NCAP_PASTI, because you can much more easily define the correct phase-out of the existing capacity stock than with NCAP_PASTI. And in most cases adding PRC_RESID=0 at the lifetime distance makes good sense, if there was only one data point. Of course, NCAP_PASTI has also its own advantages, as Amit mentioned.

[olejandro]

Thanks @Antti-L ! That's really good to know. So basically, the only effect this issue (i.e. not running of synchronization queries) has is "visual". I.e. the user won't see PRC_RESID=0 in Browse, but TIMES will take care of adding it.