Efficiently calculating inventory flows

Why would one calculate inventory flows?

In the beginning, there was nothing. Some stuff happened, and eventually life cycle analysis came into being. At first, we didn't have the tools to really translate inventory values into damages, so it wasn't quite life cycle assessment, but the characteristic equation looked quite similar:

\begin{equation*}
inventory = BA^{-1}f
\end{equation*}

The matrix B has dimensions biosphere flows (i.e. substances released to or consumed from air, water, soil) by activities, and f is a column vector, so the inventory is a column vector of biosphere flows.

However, sometimes we don't want biosphere flows, but technosphere flows, like the total amount of steel used to build a car.

Examining the supply array

We can get this information by manually examining the supply array (i.e. the solution to \(A^{-1}f\)):

Note that I have done my best to find the activities that were actually steel production, as opposed to activities that already had steel as an input. However, it is certainly possible that I made some mistakes, and the numbers presented here may be inaccurate. The general conclusions should be valid, though.

Custom flows and LCIA methods

However, this isn't so elegant. Another way, and one that I prefer, is to add new biosphere flows for the quantities we are interested in. There are a couple reasons to prefer this approach:

It fits into the standard LCA calculation framework for contribution analysis and graph traversal.

It allows us to weight some quantities more than others - for example, instead of summing the total biomass, you could sum it's exergetic value, or each alloying element in each kind of steel.

It can be easily shared with others, just like any other LCIA method.

On the other hand, it does require making modifications to the background database, which is normally avoided when possible.

Avoiding double counting

Imagine a system like the one above, where you wanted to calculate the steel needed for the electricity, coal, and steel production separately. Because there are loops in this graph, doing three separate calculations would lead to double counting: the steel for electricity would include the steel for the coal, but we also calculate the steel for the coal by itself. Similarly, demand for coal induces demand for electricity through steel production.

There are a number of ways to avoid double counting, including an approach that I wrote about earlier that uses Wurst to break these dependencies. However, this approach writes a complete new database, which is relatively expensive, especially done more than once. Instead, we can solve this problem by directly modifying the technosphere matrix.

A simplified example

In this case, I hope we can all agree that to produce one unit of output from A, we need 5 units of steel.

If we built a technosphere matrix, it would look like this:

To be able to separate calculate the steel demand for A and B, we need to sever the connection between them:

To generalize this procedure, we use the following algorithm.

Given a set of activities for which we want to calculate separate material flows, \({activities}\), and a technosphere matrix \(A\), with rows \(i\) and columns \(j\), we can construct a new \(\hat{A}\) for each activity \(\alpha\) in \({activities}\):

Implementation in Brightway

Brightway exposes the relevant matrices, so this approach is relatively easy to implement:

defwithout_double_counting(lca,activity_of_interest,activities_to_exclude):"""Calculate a new LCIA score for ``activity_of_interest`` but excluding contributions from ``activities_to_exclude``. * ``lca`` is an ``LCA`` object for which LCI and LCIA have already been calculated * ``activity_of_interest`` is a demand dictionary, e.g. {some_activity: amount} * ``activities_to_exclude`` is an iterable of activity objects or keys Returns the LCIA score. """asserthasattr(lca,"characterized_inventory"),"Must do LCI and LCIA first"tm_original=lca.technosphere_matrix.copy()to_key=lambdax:xifisinstance(x,tuple)elsex.keyexclude=set([to_key(o)foroinactivities_to_exclude]).difference(set([to_key(o)foroinactivity_of_interest]))foractivityinexclude:row=lca.product_dict[activity]col=lca.activity_dict[activity]production_amount=lca.technosphere_matrix[row,col]lca.technosphere_matrix[row,:]*=0lca.technosphere_matrix[row,col]=production_amountlca.redo_lcia(activity_of_interest)lca.technosphere_matrix=tm_originalreturnlca.score

Example: Car components

We can apply our function to the car example calculated earlier. The two primary components in the car are the glider and the engine, and we want to know how much steel is in each of them, as well as how much residual steel is needed for everything else. We first calculate how much glider and engine we need for a 1000 kilogram car:

How can there be more than one kilogram of steel in one kilogram of glider?

According to ecoinvent 3.5, cutoff system model, one needs 1.136 kilograms of steel to make one kilogram of glider. How is this possible? One explanation could that there is steel needed in the various infrastructure elements used to make the glider, such as the factory, the iron ore mine, and the transportation grid. However, the main driver of this result is the cutoff system model, which "cuts off" credit for recycling. If we look into the processes used for glider production which have the highest steel losses (see the notebook for details), we see that we have losses in steel working activities, such as:

steel production, chromium steel 18/8, hot rolled: 7.7% loss

steel production, low-alloyed, hot rolled: 6.1%

It is the compounding of these losses that add up to 13.6%.

Of course, this steel does not just disappear - it is gathered, sorted, and recycled. But in the cutoff system model, there is no credit for producing recyclable materials, so they are removed from the supply chain graph. Ironically, this removal is mathematically the same as our procedure to avoid double counting. The cutoff model also has another somewhat ironic effect - a lot of our steel comes from electric arc furnaces, which are consuming recyclable iron scrap, which is itself cut off from iron production. Though we tend to use the cutoff system model as our default ecoinvent variant, it is clear that it is not a great choice when tracing material flows.

Example: Truck transport without light duty vehicles

Light duty vehicles (LDVs) have gross vehicle weights (i.e. the weight of the truck and its cargo) of less than 8 tons. They also have a different usage pattern than heavier trucks, as there are a number of service vehicles included in this weight class. Many models therefore separate light and heavy duty vehicles.

In ecoinvent, this weight class is labelled "3.5-7.5 ton."

We can see the steel input for all truck transport (measured in ton-kilometers), and separately for LDVs, following out pattern above:

As expected, in this particular case the marginal steel input is quite small, as LDVs only contribute 3% of ton-kilometers, and have proportionately small amounts of truck mass.

Example: Demand for activities coming from an external model

We are currently working on providing steel and other inputs to the REMIND integrated assessment model (IAM). In this case, the numbers for total transport demand, electricity production, and other quantities come from the IAM, not from our examination of the supply chain. In this case, the calculations are actually even easier, as we can skip the step of looking up demands in the supply array. The only tricky thing is how to map REMIND demands to many ecoinvent activities. There are 76 lorry transport activities in ecoinvent, for example. Probably the most sensible approach is to take a weighted average using their production volumes, which are provided by ecoinvent:

Conclusions

The choice of ecoinvent system model plays a large role in material flow results. We (or, at least, I) need to think more about whether the allocation at point of substitution (APOS) system model would be adequate for material flow analysis, or if we need to develop a new system model.

We have previously used Wurst to create entirely new databases with the modifications we want. Here, we manipulate the technosphere matrix directly instead. Direct manipulation is more computationally efficient, but would not work well for some research questions. It is more transparent to have each type of manipulation isolated as a separate, testable function, and changes using Wurst can use additional metadata not otherwise available in the technosphere matrix. It can also be useful to have a copy of the modified database to share or inspect later. Though the research question and project audience will drive the ultimate choice of method, the availability of high-quality, flexible, and user-friendly open source LCA software is what makes such choices possible in the first place.