Posts: 12
Threads: 4
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Apr 2021
Hello,
I am trying to read the capacity and activity units directly from either DD or GDX files that are created by Veda from my model files in Excel.
In Veda2.0, the capacity units appear as the are specified in the Excel model files. However, there is no PRC_CAPUNT data in the GDX or DD files. PRC_ACTUNT and PRC_COMUNT do appear in both the DD and GDX files.
What files does Veda2.0 use to read the unit information that is presented in the interface? From what I can see, it does not use the DD or GDX files. Is there another file that is created and saved that contains the PRC_CAPUNT information?
Also, is there a reason why the PRC_CAPUNT is not written by Veda to DD/GDX as it does the other units?
Thanks
Iris
Posts: 1,914
Threads: 25
Likes Received: 50 in 43 posts
Likes Given: 13
Joined: Jun 2010
Although I am not a VEDA expert, I would like to give some answers related to TIMES:
1) PRC_CAPUNT is not used by TIMES for anything, and therefore, for TIMES, writing it to the DD files would be useless. And the main purpose of the DD files is, in fact, to provide the model input data for TIMES.
2) The conversion from the capacity unit to the activity unit is defined by PRC_CAPACT. Therefore, the capacity unit is implicitly known whenever the activity unit is known, even though no name is attached to the capacity unit. Therefore, PRC_CAPUNT would be essentially redundant, and thereby also error-prone. If the label given to it by PRC_CAPUNT would be inconsistent with PRC_CAPACT, what would you do? TIMES only makes use of PRC_CAPACT, and therefore the model results would be guaranteed consistent only with the capacity unit implied by PRC_CAPACT, and not necessarily with PRC_CAPUNT.
Posts: 12
Threads: 4
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Apr 2021
Thank you @antt-l.
I am aware that TIMES does not use the unit information. I am working on automated reporting of TIMES results and need the unit information for that. I was hoping to read the information from text files or gdx files rather than excel spreadsheets.
Posts: 1,914
Threads: 25
Likes Received: 50 in 43 posts
Likes Given: 13
Joined: Jun 2010
04-08-2022, 06:17 PM
(This post was last modified: 04-08-2022, 07:31 PM by Antti-L.)
Well, as said, you can read it indirectly, but more reliably, by reading PRC_CAPACT and PRC_ACTUNT.
For example, if the activity unit is PJ, and PRC_CAPACT=31.536, the capacity unit is known to be 31.536 PJ/a. That will also be guaranteed consistent with the results (unlike PRC_CAPUNT), because TIMES only uses these consistent pieces of unit information.
And, looking up automatically any desired labels for those correct capacity units would also be trivial, for example "GJ/s", "GW", or "GWh/h" for 31.536 PJ/a. So you could easily assign any desired display label for each individual unit, if you like.
Posts: 12
Threads: 4
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Apr 2021
Thank you @Antti-L. I agree that that approach could work. It does require an up-to-date lookup table between the transformations and labels. But that shouldn't be hard to obtain.
However, it would still be good to know how Veda handles the prc_capunt, and why it is not written. If anyone on the list might have some thoughts, I'd be glad to hear/
Posts: 1,914
Threads: 25
Likes Received: 50 in 43 posts
Likes Given: 13
Joined: Jun 2010
04-08-2022, 09:36 PM
(This post was last modified: 04-08-2022, 09:52 PM by Antti-L.)
Well, if you can still accept my thoughts, here is my understanding:
PRC_CAPUNT is a TIMES attribute. Not all TIMES attributes are supported by VEDA. You can see the list of TIMES attributes supported by VEDA2 from Information → TIMES Attributes. I cannot see PRC_CAPUNT there, and so my conclusion is that it is not supported at all by VEDA, and therefore cannot be handled in any way, nor written into the DD files. However, I admit I cannot see PRC_ACTUNT there either, and so I could be also mistaken.
Nonetheless, in ~FI_Process tables there is a column Tcap, which has alias names "capacityunit" and "capacity_unit" (according to Information → VEDA Tags). Perhaps you refer to the contents of this column in ~FI_Process tables instead of the PRC_CAPUNT attribute? If so, the answer to the second question ("why it is not written") would be that there is no TIMES attribute supported by VEDA which would facilitate writing this column into the TIMES input files. I myself don't have any idea whether Veda handles this column in any way, but the VEDA developers should be able to tell you that.
Posts: 1,040
Threads: 41
Likes Received: 16 in 13 posts
Likes Given: 22
Joined: May 2010
Reputation:
16
Writing PRC_CAPUNT was discontinued at some point, most probably because it is redundant in TIMES model specification. So, the TCap col of _Process table is not used right now, but it will be accessible in the Reports feature soon.
Posts: 1,914
Threads: 25
Likes Received: 50 in 43 posts
Likes Given: 13
Joined: Jun 2010
Thanks Amit!
> Writing PRC_CAPUNT was discontinued at some point [...]
That's interesting. I searched all the DD files on my PC for PRC_CAPUNT, and found no VEDA-generated DD files that contain PRC_CAPUNT. I must have completely missed the versions that have been writing it, even though the oldest VEDA DD files I have archived date back to 2004.
Posts: 1,040
Threads: 41
Likes Received: 16 in 13 posts
Likes Given: 22
Joined: May 2010
Reputation:
16
Truly impressed, with your archiving, and even more that you can search that archive so easily.
As you know, there is a table that controls writing of these statements, and I found a "suspended" entry for PRC_CAPUNT. I assumed that it would have been active for some time before being suspended. As you also know, things were quite, let's say, "informal" in VEDA_FE/BE. I have no way of finding out when a particular change was made. But I will be able to tell you exactly when a change like this is made with Veda2.0
Posts: 12
Threads: 4
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Apr 2021
Thanks both for your help with this
Posts: 2
Threads: 0
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Dec 2023
Hi,
Please allow me to reactivate this treat. In part, I want to ask @iris to what degree the approach of using PRC_CAPACT worked. In part, I want to say that it would be a significant quality-of-life improvement if the information on capacity units (Tcap) for each TIMES process were included in the TIMES GDX-result file, for example, by reviving the PRC_CAPUNT parameter. In terms of quality-of-life improvement, it is comparable to the feature that allows you to store user-defined groupings of processes within the PRC_GMAP parameter within the GDX file, as it would make it possible to automate the assignment of units (Tcap) within a post-reporting script run as part of the VTrun.cmd file.
So in short, what I really would like for Christmas is a continuation of the writing Tcap information into the PRC_CAPUNT parameter in the gdx-file :-)
Best seasonal wishes,
Kristoffer
Posts: 1,914
Threads: 25
Likes Received: 50 in 43 posts
Likes Given: 13
Joined: Jun 2010
20-12-2023, 09:32 PM
(This post was last modified: 20-12-2023, 10:00 PM by Antti-L.)
If this request is implemented, one must also decide/design what happens if Tcap is left blank. Currently it has no impact on the model whether left blank or not. I think the reasonable choice would be to continue ignoring the Tcap column if left blank, and no error should be issued (because I think it is quite common to leave it blank, as the Tcap information is redundant, and may even be inconsistent with the model).
So, I would suggest that PRC_CAPUNT would be written out only when Tcap is filled in with a valid non-empty label, but no error would be issued if that is not the case.
Another possibility would be to auto-generate the capacity unit for each process from PRC_ACTUNT and PRC_CAPACT. It would be easy to implement either in TIMES or VEDA, but would just require a conversion table (and some rules to break ties if several pairs (TCap, TAct) have exactly the same conversion, plus a tolerance).
Posts: 1,914
Threads: 25
Likes Received: 50 in 43 posts
Likes Given: 13
Joined: Jun 2010
As there were no responses, I made an experimental implementation into TIMES, for auto-generating the capacity unit for each process from PRC_ACTUNT and PRC_CAPACT. I think it works quite well, even if only the most common conversions (energy and material, based on SI units) are provided. In my tests (e.g with DK-TIMES), only some demand processes (notably transports) were excluded, unless either a more complete conversion table or PRC_CAPUNT info was provided. This approach would thus also be able to combine the more reliable PRC_CAPACT data with the less reliable PRC_CAPUNT info.
Posts: 2
Threads: 0
Likes Received: 0 in 0 posts
Likes Given: 0
Joined: Dec 2023
Hi Antti,
Thank you for going above and beyond.
Regarding concrete features, generating PRC_CAPUNT based on Tcap (leaving out empty or non-valid Tcap) would work well for my reporting needs. However, I guess that one challenge is determining what a valid capacity unit is. For example, I have defined Tcap for some technologies as "Number of heating installations".
Using a conversion table between different capacity and activity units is a great way to make modelling in TIMES more explicit, and it may also allow testing for inconsistencies between PRC_CAPACT and PRC_CAPUNT (induced by the model user).
Below, I have tried to illustrate the conversion table for household heating technologies assuming:
1) capacity units are measured in the number of heating installations and
2) each heating technology (e.g., heat pump or gas boiler) delivers 18 MWh of energy service each year to a single-family house.
Conversion table: Household heating technology
Tact: "PJ"
CAP2ACT: "6.48e-05"
Tcap: "Number of heating installations"
Thank you for all your great work!
Kristoffer
Posts: 1,914
Threads: 25
Likes Received: 50 in 43 posts
Likes Given: 13
Joined: Jun 2010
> I guess that one challenge is determining what a valid capacity unit is.
Indeed. If your activity unit is PJ, and PRC_CAPACT = 6.48e-05, your implied "capacity unit" (representing the heating system capacity of one single-family house) would be only 2.05 kW. And if I understood correctly, such a heating system should deliver all the space heat and hot water energy services for the house? I would think the peak capacity requirement in a SFH should, however, be considerably higher than 2 kW. Therefore, it seems that you may be embedding an annual utilization factor into the unit conversion (PRC_CAPACT). I think I would myself rather keep the utilization factor as a separate parameter, because while PRC_CAPACT is a constant, utilization factors can change over time, depending e.g. on system vintage and building energy efficiency. Nonetheless, of course it is all up to the modeller to choose...
Anyway, the experimental implementation would be able to handle also such unusual unit conventions.
|