Tricks for reporting LCA inventory data
Information overload
I am reading a LCA report from an institution that I will not mention by authors that I will not mention and it is a total mess.
The authors have managed to write 100+ pages without being able to clearly explain what they did. If I had to replicate their results, it would take me a week of work just to put together the information.
This situation is not uncommon unfortunately. The problem with many LCA reports of all types (scientific papers, scientific reports, student projects) is that either the inventory data are not reported, or the authors are overloading the reader with information. For information overload I mean filling the document with tables and text, numerous and disorganised, and even irrelevant, so that even if the data are actually there it’s impossible to make sense of them with reasonable effort. Neither omitting data nor making them impossible to understand corresponds to what I consider transparent, complete, and clear documentation (which is what I would expect from any LCA report).
It is just so important to document the modelling done in an LCA study in a way that is easily understandable (and ideally also reproducible, but that is a different story). Bad writing is a sign of bad thinking. So when I read a LCA report that is not reporting the data in an organised way I have difficulties in taking the analysis seriously. Readers must be put in the condition to understand in detail and reasonably quickly what was done in the study. And for what was done I mean what is the product system.
I have been writing about LCA reporting already here and here. Now I continue on the same topic and describe some good practices for documenting and communicating the foreground part of product systems. These tricks work for me1 and I believe are clear and straightforward. My intended audience is people who have to document their LCA work in reports: scientists, consultants, students. This is not a post about how to manage, structure, share, or format LCA databases.
What I mean for foreground system
I mean basically everything in the LCA inventory that is not database. This means the activities that you define, build, and link by yourself. The basic structure of your product system. The information that you manually put into a LCA software. The qualitative and quantitative primary data that you have collected yourself. And so on.
It’s easier to show this than to describe it in words. Usually to understand what the authors of a LCA study actually did one needs to see at least some tables with the data and ideally a figure with a flow chart (not strictly necessary, but nice-to-have). This sounds simple and close to obvious but take 10 LCA studies at random and you’ll understand why it is not so obvious. So let’s start with the qualitative part and the figure of the foreground system.
Flow chart for the foreground system
Keep it simple.
Activities are boxes.
Products are arrows.
Everything has a name.
At least one product output per activity.
No background activities, no exchanges.
That’s it.
Here an example using draw.io.
Foreground system in tables
Tables are consistent with the flow chart. This means same names and same numbers. This also seems obvious but it is not, check with existing published studies. One table per foreground activity. So in our case, three tables.
Here below the first table.
| Activity A | Amount | Unit | Type | Notes |
| Product a | 1 | kg | Output | Reference flow |
| Product b | 0.5 | kg | Input | cf. Table 2 |
| Product c | 0.6 | kg | Input | cf. Table 3 |
Table 1. Inventory of activity A, data from Pizzol M (2017)
It’s important to refer to the other inventory tables. It is also useful to add sources in case of secondary data. Here I put everything in a generic column called Notes.
Background system (database activities used)
Most LCA studies rely on a LCA database. This means that some background activities are selected among the datasets available in the database and linked to the product system. Obviously nobody should (nor can) report the entire database or even single datasets from the database. What readers are interested in is which activities were chosen from the database. E.g. if you have modelled PET plastic production, which database did you use? Which dataset from this database? Was is a market mix? Or PET production from a specific supplier, e.g. China? The reader needs to know.
To document this, one needs as a minimum to include in the tables the exact names or code of the database activities used in the modelling so that these can be identified univocally. And specify the database version used. You don’t know the names of the background activities or database version because your LCA software doesn’t allow to see that? Uhmm…that’s like putting a paper bag over your head while driving on a motorway. Find out how to get this info with your software or change software.
Here the second table (db = database).
| Activity B | Amount | Unit | Type | Notes |
| Product b | 0.5 | kg | Output | Reference flow |
| Product d | 2 | kg | Input | Name/code of db activity D |
| Env. exchange x | 1 | kg | Air | - |
Table 2. Inventory of activity B, data from Pizzol M (2017), foreground activities from 'db_name', 'db_version'
And the third table. We are done.
| Activity C | Amount | Unit | Type | Notes |
| Product c | 0.6 | kg | Output | Reference flow |
| Product e | 3 | kWh | Input | Name/code of db activity E |
| Product f | 2 | kg | Input | Name/code of db activity F |
Table 3. Inventory of activity C, data from Pizzol M (2017), foreground activities from 'db_name', 'db_version'
Just to make myself completely clear, this corresponds to the figure below where stuff in blue is database activities and environmental exchanges.
Special cases?
Substitution, partitioning, scenarios, etc. Are these special cases? No. The suggestions above are probably sufficient to document almost all situations. I never use it, but when using the partitioning method I strongly recommend providing both the original and allocated dataset and the used allocation factors alongside the tables. When using the substitution method, it helps to signal what is the substituted co-product, e.g. with a minus sign or a written note. For scenarios, I would add the scenario name to the activity name e.g. Activity A scenario I.
My foreground system is too big for tables
Maybe you have a lot of scenarios, or activities with a substantial amount of exchanges, or somehow you feel this is unhandy, or you have a page limit for your report, or you simply have done a huge LCA. In these cases I would organise the data in a separate file to add as supplementary material.
One can e.g. use a compact matrix to describe the system, as Heijungs and Suh (2002)2 would probably do (minus signs indicate input, plus sign indicate output). Notice the nice 3 x 3 foreground technology matrix.
| Activity A | Activity B | Activity C | |
| product a (kg) | 1 | ||
| product b (kg) | -0.5 | 0.5 | |
| product c (kg) | -0.6 | 0.6 | |
| Name/code of db activity D (kg) | -2 | ||
| Name/code of db activity E (kWh) | -3 | ||
| Name/code of db activity F (kg) | -2 | ||
| Env exchange to Air x (kg) | 1 |
Or make a sort of long dataframe or list. It’s somehow similar to this Brightway2 example.
| Activity | Exchange | Amount | Unit | Type | Notes |
| A | a | 1 | kg | Output | Reference flow |
| A | b | 0.5 | kg | Input | Foreground |
| A | c | 0.6 | kg | Input | Foreground |
| B | b | 0.5 | kg | Output | Reference flow |
| B | d | 2 | kg | Input | Name/code of db activity |
| B | x | 1 | kg | Air | Environmental |
| C | c | 0.6 | kg | Output | Reference flow |
| C | e | 3 | kWh | Input | Name/code of db activity |
| C | f | 2 | kg | Input | Name/code of db activity |
You find here an example of Excel file with the same foreground system above in these two different styles.
My foreground system is too big for Excel
Then you probably don’t need to read this post and you know better than me how to document your analysis.
Shareable material
Do you care about others? Make your foreground data available to them in a way that reduces their effort in reproducing your results. For example, here the Pickled Herring product system that we used as teaching material at Aalborg University for many years. We document the system both using the SimaPro matrix .xlsx version and the corresponding SimaPro .csv version. The former is useful for understanding the system at a glance, the latter is useful for reproducing it as the students can import the data directly into their computer. Similar export/import options should be possible for other LCA software I believe (I haven’t checked this but really I hope so).
More advanced stuff
What about geography, uncertainty, and all other info? I don’t see why this can’t be reported in table format too…There are many different LCA software around and different data formats, which one to use? For software-ready data sharing, I would use the format my software allows. In the future hopefully there will be more options to convert between data formats of different software. What about ecoSpold formats? ecoSpold is for databases and LCA software as far as I know, not for scientific reporting. So not relevant here. Is this ISO compliant? No idea. Is this important? What I care about is that the information reported is understandable (i.e. transparent, complete, and clear). Are there other ways of doing this, it looks so manual? Most of reporting work is manual work. However, certainly there are other ways of doing good documentation and structuring tables etc. These are examples that work for me and I think would suffice for many LCAs. Ideally it would be good to develop (open) tools and solutions to automatise some of this reporting to avoid transcription mistakes. Please get in touch if you have any suggestion or material to share in this sense. Is there research work going on in this area? The most interesting work on this topic (that I am aware of, at least) is the research effort within the LCA Interest Group of SETAC North America and its guidelines for inventory model description and revision. Hopefully the group will publish something in the future that can provide more robust and extensive guidance than this post on the topic of foreground inventory documentation. EDIT FEBRUARY 2018: The SETAC NA group just published a position paper on this topic.