0 votes
153 views

Given the push toward LCIA methods that operate over geo-temporal attributes of each exchange, as well as the occasionally difficult task of uniquely identifying an Exchange within a Process (i.e., Exchange.internalId is mutable, and Exchange.flow can be duplicated), has any consideration been given toward altering the Exchange class to have an *.@id attribute rather than *.internalId?

in openLCA by (140 points)

2 Answers

+1 vote
by (146k points)
edited by
true, however the exchanges table is the heaviest in a calculation and adding UUIDs there would increase the weight (so to say); maybe it could make sense to directly evaluate the impacts per exchange (which would allow also nonlinear impacts), and specifically for time, the system dynamics addition to recent openLCA is quite powerful. If you see a chance for a joint project, let us know!

edit: and related to the edges package, the access for LCIA methods to both elementary and all other flows that edges provides is possible in openLCA already, since beginning. But there is more to explore and elaborate, certainly.
+1 vote
by (14.3k points)
Within openLCA, the internalId of an exchange is not mutable. The requirement is that it is unique within a process. The process contains a field, lastInternalId, which tracks this value; it is always incremented so that an exchange never receives the same internalId twice. The pair (process.id, exchange.internalId) is unique (and is used in product system links).

An exchange is not a standalone entity in openLCA; it always exists within a process. That process provides the context (such as location, industry sector, etc.) that could be used for this "edge-based impact assessment" (very interesting, thank you for sharing the link). In fact, this is already done with the regionalization feature in openLCA: if not defined for the exchange, openLCA uses the location of the process and matches it with regionalized characterization factors.

And yes, there is more to explore (such as handling sector-specific CFs). However, I do not currently see how UUIDs for exchanges would help here.
by (140 points)
Ah, thank you for clarifying! Based on this and Andreas' answers, I now understand why UUIDs are not necessary for exchanges.

The root of my confusion stems from a JSON diff I generated recently: I noticed a change in the .internalId values of every exchange on processes from the "U.S._electricity_baseline_v1.2025-06.0" library (embedded on USLCI), following the "Remove library (experimental)"> "Keep all" procedure. This led me to jump to the conclusion that .internalId was mutable, but I'm glad to hear that is not supposed to be the case.
...