Time-explicit LCA of an electric vehicle¶

This notebook shows how to use bw_timex with a cradle-to-grave case study of an electric vehicle. The case study is simplified, not meant to reflect the complexity of electric mobility but to demonstrate hot to use bw_timex.

More information on the inner workings of bw_timex can be found here.

Prospective databases¶

Using Ecoinvent v3.9 and premise, we created a set of prospective databases with projections for the future electricity sectors using the SSP2-RCP19 pathway from the IAM IMAGE. We selected this pathway to simply demonstrate some future development in this case study, and many other models and pathways are available. In the documentation of premise, you can find instructions for the creation of prospective background databases.

Case study setup¶

Let's create a new foreground database to store the EV process:

Getting the input processes of the EV from the background database:

Creating the EV activity:

Here are some parameter assumptions for the EV:

Based on these parameters, we create the following exchanges:

We need to add the temporal distributions at the exchanges level. See bw_temporalis documentation for more information on TemporalDistribution. Timedelta, which we use below, describes relative temporal relations, e.g. 2 years earlier.

Let's explore what a TemporalDistribution looks like:

We now add the temporal information to the inputs of our EV. We add temporal distributions to all exchanges, but you don't have to.

LCA using bw_timex¶

As usual, we need to select a method:

bw_timex needs to know the representative time of the databases:

Now, we can instantiate a TimexLCA. It has a similar structure as bw2calc.LCA, but with the additional argument database_date_dict.

Not sure about the required inputs? Check the documentation using ?

Let's create a TimexLCA object for our EV life cycle:

Next, we build a timeline of the exchanges. To do this, we can call the build_timeline() method, which does the graph traversal and creates a timeline dataframe from the results. The exchanges (rows of the dataframe) are aggregated to the resolution specified in the argument temporal_grouping. There are also many more options to specify the timeline creation and graph traversal process. Here are the most important ones:

• temporal_grouping: temporal resolution to which processes will be aggregated,"year" (default), "month", "day" or "hour"
• interpolation_type: How the best fitting background database is selected: "linear"(default), "closest"
• edge_filter_function: Custom filter function specifying when to stop the graph traversal.
• cutoff: stops graph traversal for nodes below this contribution to the static impact score.
• max_calc: stops graph traversal if this number of nodes has been traversed

For all these options, we provide sensible default values. Of course you can always just check the docstrings to see all your options and our assumptions for default values.

So, let's build the timeline:

The interpolation weights in the timeline (right most column above) specify the share of the amount of an exchange to be sourced from the respective database. None means that the exchange is in the foreground supply chain, and not at the intersection with the background system.

Next, we calculate the time-explicit LCI. Here we have the option to expand the technosphere matrix, in case we want to have further access to the standard BW matrix based functions, or if we want just the dynamic inventory. The TimexLCA.lci() function takes care of all the relinking if necessary, based on the information from the timeline. For the expanded matrix set expand_matrix=True (default).

Taking a look at the dynamic_inventory that was now created, we can see that it has more rows (emissions) than our usual biosphere3 flows. Instead of one row for each emission in the biosphere database we now get one row for each emission at each point in time.

The standard, non-dynamic inventory has far less rows because the temporal resolution is missing. Looking at the timeline again, we see that we have processes at 21 different points in time, which should exactly match the ratio of the dimensions of our two inventories:

If we are only interested in the new overall time-explicit scores and don't care about the timing of the emissions, we can set build_dynamic_biosphere=False (default is True), which saves time and memory. In that case, you only get the TimexLCA.inventory, but not the TimexLCA.dynamic_inventory.

In case the timing of emissions is not important, one can directly calculate the LCIA the "standard way" using static characterization methods. Per default, the following calculates the static lcia score based on the impact method chosen in the very beginning:

Dynamic Characterization¶

In addition to the standard static characterization, the time-explicit, dynamic inventory generated by a TimexLCA allows for dynamic characterization. Users can provide their own dynamic characterization functions and link them to corresponding biosphere flows (see example on dynamic characterization), or use the ones we provide out of the box.

We provide two different metrics for dynamic LCIA of Climate Change: Radiative forcing [W/m2] and Global Warming Potential (GWP) [kg CO2-eq]. For both of these metrics, we have parameterized dynamic characterization functions for all GHG's that IPCC AR6 provides data for.

For the dynamic characterization, users can also choose the length of the considered time horizon (time_horizon) and whether it is a fixed time horizon (fixed_time_horizon). Fixed means that the time horizon for all emissions (no matter when they occur) starts counting at the time of the functional unit, resulting in shorter time horizons for emissions occuring later. If the time horizon is not fixed (this is what conventional impact assessment factors assume), it starts counting from the timing of the emission.

Radiative forcing¶

Let's characterize our dynamic inventory, regarding radiative forcing with a fixed time horizon and the default time horizon length of 100 years:

The method call returns a dataframe of all the individual emissions at their respective timesteps, but we can also just look at the overall score:

To visualize the results, we provide a simple plotting functions:

Without summing up the emissions within the activity, one can see that there are also negative emissions in the system, which stem from the premise-induced BECCS in the future electricity production:

There is also a flag to plot the cumulative radiative forcing:

GWP¶

Similar options are available for the metric GWP, which compares the radiative forcing of a GHG to that of CO2 over a certain time horizon (commonly 100 years, but it can be set flexibly in time_horizon).

Plotting the GWP results over time:

Cumulative:

Comparison of time-explicit results to static results¶

It's helpful to understand how the time-explicit results differ from those using static assessments.

We compare the time-explicit results with those of an LCA for the year 2020 and 2040 for the standard GWP100 metric (time horizon=100 and no fixed time horizon). This means we neglect the additional differences of the time-explicit results that would arise from using dynamic LCIA.

Time-explicit scores:

The 2020 (static) score has already been calculated by TimexLCA in the beginning, originally to set the priorities for the graph traversal. But we can still access the score:

However, further down we also want to look at what part of the life cycle has what contribution. To get this info, we need some more calculations:

Similarly, we calculate the 2040 (prospective) scores by just changing the database the exchanges point to:

Lets compare the overall scores:

To better understand what's going on, let's plot the scores as a waterfall chart based on timing of emission. Also, we can look at the "first-level contributions":

One can see that the time-explicit results (in the middle) are somewhere in between the static and the prospective results. This makes sense as at each timestep, the underlying processes are sourced from progressively "cleaner" background databases, reaching a lower impact than if they are only sourced from the current database, but not so low as the prospective results, which are fully sourced from the most decarbonized database. Notably, the electricity consumption in the use-phase, modelled uniformly over the lifetime of the EV, contributes less and less to the score in the later years, since the electricity becomes cleaner in the future databases.