Life-Cycle Analysis · theory: applied category theory

I'll try to make here a short post about some of the mathematical aspects of our DSL (it's called LCAAC, for LCA as Code), ending with the ones I struggle with. For the sake of brevity, I'll probably skip the big picture (e.g., what is LCA about exactly, or why we chose not to go for a GUI-based tool) and do a lot of hand waving.

"Static" LCA

Syntax

In LCA, you analyze your product by describing how it is produced. For instance, to produce 1 kg of bread, you need 1 kg of flour, and 1 l of water. Also, cooking the breadrequires 1 kWh of electricity from some power station. Another process produces 1 kg of flour by consuming 1 kWh of electricity from the same power station. Here's the code:

process bakery {
    products {
        1 kg bread
    }
    inputs {
        1 kg flour
        1 kWh electricity
    }
}

process mill {
    products {
        1 kg flour
    }
    inputs {
        1 kWh electricity
    }
}

process power_station {
    products {
        1 kWh electricity
    }
    impacts {
        1 kg co2
    }
}

This fits particularly well with the formalism of attributed C-Sets or structured cospans(not really surprising since I first experimented with Catlab.jl).My "LCA" (syntactical) category has finite sets of products/indicators as objects,and processes as morphisms. In the code above, the processes are implicitly composedby matching on product names.

Note also that it is possible to have circular dependencies between processes: this occurs when we have recycling processes.

Semantics

The classic big question is: what is the impact of 1 kg of bread in terms of co2? The example above is so simple that it's not hard to see that it must be 2 kg of co2.

But, for the general case, what we do behind the scene reduces to running a functor from this "LCA" category to the category of linear relations. There are actually two functors, depending on whether you focus on processes or products (like Kirchoff's voltage vs current stuff). Here's one way.

Let

\phi_{bread}

(resp.

\phi_{flour}

, etc.) the quantity of co2 per kg of bread (per kg of flour, etc.). Each process is interpreted as a conservation equation, e.g.:

1~\texttt{kg}\cdot\phi_{bread} - 1~\texttt{kg}\cdot\phi_{flour} - 1~\texttt{kWh}\cdot\phi_{electricity} = 0

Combining everything, I get a linear system that relates

\phi_{bread}

\phi_{co2}

(and possibly other variables depending the system's rank).

Dynamic LCA

So far, it is relatively easy because our models are static.But, in LCAAC, processes are parametrized, and composition may depend onthe value of some parameters.

Syntax

In the example below, the bakery process has two parameters: a geographic location, and the efficiency of the power generation process. It produces 1 kg bread,and requires 1 kWh of electricity. But here the connection is explicit:the electricity comes from the process power_station, thereby passing the efficiency value.But also, depending on where the bakery is located ("FR" or "DE"), a different case will be selected.After all, the impact of 1 kWh of electricity depends on the electricity mix of your country.

process bakery {
    params {
        geo = "FR" // default value for geography
        efficiency = 80 percent // default value for power generation
    }
    products {
        1 kg bread
    }
    inputs {
        1 kWh electricity from power_station( efficiency = efficiency ) match geo = geo
    }
}

process power_station {
    labels {
        geo = "FR"
    }
    params {
        efficiency = 100 percent
    }
    products {
        1 kWh * efficiency electricity
    }
    impacts {
        1 kg co2
    }
}

process power_station {
    labels {
        geo = "DE"
    }
    params {
        efficiency = 100 percent
    }
    products {
        1 kWh * efficiency electricity
    }
    impacts {
        2 kg co2
    }
}

Semantics

Now, I will be even more hand-wavy. The code cannot represent a static composition of processes as before, because parameter values are known at run time. The way I picture it (and implemented it) is inspired by game semantics. There are two players: the Learner (who wants to know the impact of1 kg of bread) and the Oracle (who knows all about the processes in the world).The interaction goes as follows:

At the end of the interaction, the Learner is given a (static) set of processes connected together along products. She can analyze the system the way she prefers.

Conclusion

Ok, it is much longer than I expected. There are other funny topics I haven't covered(sensitivity/uncertainty analysis, type checking, black-boxing a group of processes, etc.), but what I struggle with is formalizing the semantics of the dynamic thingy. It feels a bit too "operational" to my taste. A nice-to-have property for instance would be a type system that would allow me to guarantee, under certain circumstances, the termination of learner-oracle interaction. This kind of things.

John Baez (Feb 15 2024 at 21:10):

Thanks! So far it sounds like the basic idea is that for each product (e.g. a kilogram of bread) you have a process that makes it and then a finite collection of products used as inputs to this process (e.g. 1 kilogram of flour and 1 kWh of electricity).

John Baez (Feb 15 2024 at 21:15):

Are all the processes you care about many-input, one-output processes as in this particular example? Or are some of them many-input, many-output processes? As you must know, n real life processes typically have multiple outputs - including some considered as "waste", which can still in fact be used for other processes as in circular manufacturing.

Peva Blanchard (Feb 15 2024 at 22:21):

Multi-input multi-output processes do occur indeed, and this is a very big question in LCA. The general advice is: "try to avoid multi-output processes". The solution will depend on the "physics" of the problem, but also on "fair" allocation of responsibilities.

For instance, maybe physics will tell you that your multi-output process can be split into sub-processes. A big factory producing different brands of products while consuming different kinds of things can surely be decomposed. But there are cases where it is not obvious.

The classic example is the "cow" process. From a cow, you can produce meat and milk. But the cow also requires food, treatment, housing etc. Let's say that all of these inputs amount to 100 kg CO2 eq. Physics-wise, there is no obvious way to split the cow into "meat production" and "milk production" subprocesses.

Thus, the decision to allocate, e.g., 80 kg CO2 eq to the meat, and 20 kg CO2 eq, is normative: it relies on arguments that try to justify what is "fair". For instance, analysts look at the economic value of the products, or incentives for producers, etc. This is also the kind of place where there is opportunity for green washing, so it is very important that these choices are made explicit and transparent.

In LCAAC, the analyst can describe a multi-output process, but must specify explicitly the allocation ratios. Behind the scene, this two-output process is then rewritten as two single-output processes, each of them with inputs scaled by the corresponding allocation ratio.

Waste treatment is quite funny. Take a factory that produces 100 cars, but also 1 ton of waste. You could be tempted to write a multi-output process e.g. like

X \rightarrow 100~\texttt{cars} + 1~\texttt{ton waste}

But this waste has low economic value, so the factory owner cannot really sell it. He has to treat its waste, e.g., incinerating them. But incinerating 1 ton of waste clearly has an environmental impact, and the factory should be responsible for it!

So what the analyst does is taking the "dual" of the waste: the factory does not produce waste, but requires "anti-waste", aka, waste treatment. Something like

X + 1~\texttt{ton waste treatment} \rightarrow 100~\texttt{cars}

. So the environmental impact of a car produced by this factory includes the impact of treating the waste.

Cases like circular manufacturing you mention are modelled with variants of these techniques (explicit allocation factors, dualization).

It's true that in the first examples I gave, it looks like describing physical processes. But LCA is more about delineating environmental responsibilities.

John Baez (Feb 17 2024 at 00:52):

What does that mean? Avoiding them in the mathematics, or avoiding them in real life?

There are very few processes in real life that don't have multiple outputs, as long as we don't deliberately ignore some of the outputs like waste heat, carbon dioxide, and other forms of waste. These outputs may have negative value, but they're still economically important.

I've been running around giving talks like this, where I argue that to save the planet we need to stop ignoring outputs that we consider "waste":

John Baez (Feb 17 2024 at 00:55):

Okay, so that's about mathematically avoiding treating processes with lots of outputs as primitives, by breaking them into sub-processes when possible. That makes sense to me.

John Baez (Feb 17 2024 at 00:59):

John Baez (Feb 17 2024 at 01:02):

The idea of "dualizing" waste to convert an output to an input is indeed a classic string diagram trick - nice! But I don't see why we should avoid talking about the process

if that's really what's going on. E.g. lots of industrial processes spew carbon dioxide into the air or hot water into rivers. We can argue that they shouldn't, but as long as they do, it's something I want to model.

John Baez (Feb 17 2024 at 01:03):

Perhaps my motives are different from those of most people engaging in life cycle analysis.

John Baez (Feb 17 2024 at 01:17):

But if it's a matter of avoiding multi-output processes because they are mathematically annoying in some way, I'd like to understand why they are.

John Baez (Feb 17 2024 at 01:18):

davidad (David Dalrymple) (Feb 17 2024 at 08:45):

It seems to me like this LCAAC is really a way of defining Petri nets. The processes are transitions, the products are places, and the legs are arcs. In your “static” case, the semantics of Petri nets as linear relations has been studied by John and his former student Blake Pollard https://arxiv.org/pdf/1704.02051.pdf

davidad (David Dalrymple) (Feb 17 2024 at 08:59):

In the dynamic case there are two big differences. One is that you no longer want to assume that every transition runs at the same constant rate - instead you want to discover a particular trace that results in a particular product from a certain initial condition. The algorithm you described is a lot like “backward reachability”. Related semantics have been studied by John with a different student, Jade Master, e.g. https://arxiv.org/abs/1808.05415

davidad (David Dalrymple) (Feb 17 2024 at 09:05):

The other big difference in the dynamic case is that the transitions have labels and params. I think this is really a way of expressing the type of Transitions as—instead of a finite set—an algebraic data type. For example power_station(efficiency=100%) is a transition but so is power_station(efficiency=99.9%). There is a sort of infinite (although hopefully compact) space of transitions which could be defined as a coproduct of products. This is a bit unusual in the Petri net world. The reachability semantics becomes confused because it’s as if the scheduler can choose the parameters freely.

davidad (David Dalrymple) (Feb 17 2024 at 09:10):

Here’s how I would suggest resolving it. Use Coloured Petri Nets, in which each token has a “color” (funny name but it’s just a state vector/value). Then, to each parameterized transition, associate a place where the tokens have colors that determine the parameters. For example, there could be just one power_station_run transition, but it requires an input from a power_station place, and in that place you have some finite multiset of tokens like {(efficiency=80%, geo=“DE”)↦2, (efficiency=90%, geo=“DE”)↦1, (efficiency=90%, geo=“FR”)↦3}. Then, when the scheduler choose to fire the power_station_run transition, they also choose which of the available tokens to pick up as the particular power station parameters to use. When the transition fires, it should deposit the power station parameters back in the power_station place (probably unchanged, although for some processes it might be useful to model the aging of the processing device by making the parameters a little worse with each use).

davidad (David Dalrymple) (Feb 17 2024 at 09:20):

Peva Blanchard (Feb 17 2024 at 16:37):

Thank you for all the inputs! I never thought about LCA models as Petri nets. I'll definitely check out the links.

Peva Blanchard (Feb 17 2024 at 17:19):

I think I see where the confusion comes from: I forgot to talk about the difference in LCA between the technosphere and the biosphere. Let me refine the definitions I gave at the beginning.

The technosphere refers to the set of goods and services are exchanged, produced and consumed by humans. A "product", in the LCA jargon, is synonym for a such a good or service.

The biosphere, on the other hand, stands for "Nature", or the environment. It is the place where chemical substances are released or captured.

A process (a.k.a. activity in the LCA jargon) describes a sort of balance sheet. It lists all the exchanges with the technosphere, and with the biosphere. In my first post, I used the term "leg", but LCA people usually use the word "exchange".

For instance, let's refine a bit the "bakery" process. The process produces 1 kg of bread, and requires 1 kg of flour, and 1 kWh of electricity. These are the exchanges with the technosphere: I need to buy the flour and the electricity, and I plan to sell the bread. But, it is possible that my oven is leaking some chemical, say, carbon monoxide in the environment. This is an exchange with the biosphere.

process bakery {
  products {
    1 kg bread
  }
  inputs {
    1 kg flour
    1 kWh electricity
  }
  emissions {
    100 g carbon_monoxide
  }
}

So in principle, every process has exchanges with the technosphere and biosphere. Now, let's say you want to assess the impact of producing 1 kg of bread with respect to climate change. You first start by computing the inventory of all the substances that were released to (or captured from) the biosphere. So you count 100 g of carbon monoxide from the bakery process. But, maybe the processes that produce flour and electricity also release carbon monoxide, or methane, or carbon dioxide, and so on. You need to add everything.

process bakery_reduced {
  products {
    1 kg bread
  }
  emissions {
    150 g carbon_monoxide
    300 mg methane
    200 g carbon_dioxide
  }
}

The last step is to compute the climate change impact. For that, we rely on the work of chemists/physicists/etc. who run the experiments and characterized each substance with respect to climate change (aka global warming potential). For instance

and so on. It's like giving a price on each substance. You combine those prices with the bill of materials to get your impact.

Peva Blanchard (Feb 17 2024 at 17:30):

You can see LCA as a way to build the bill, to make explicit for a given product (technosphere) how much it costs with respect to, e.g., climate change.

So you're right: processes do have multiple outputs. But the slogan "try to avoid multi-product process" actually refers to products from the technosphere. You can see the issue of multiple (technosphere) products in the example of the cow, or waste treatment. The modelling choices introduce normative decisions, which are difficult to justify, especially when you can't rely on physics.

So the slogan really means "try to avoid putting yourself in a situation where you introduce unjustified normative decisions".

John Baez (Feb 17 2024 at 23:12):

This is extremely helpful! Thanks! It sounds exactly right if products are treated discretely, e.g. you can only have no cows, one cow, two cows, three cows, etc. Furthermore, we've already worked out a category of "open" Petri nets that make the ideas of treating Petri nets like string diagrams, and "dualizing inputs to become outputs", precise:

Even better, AlgebraicJulia is already set up to handle Petri nets, though these are slightly different than the Petri nets discussed above - they are instead Joachim Kock's "whole-grain Petri nets":

Luckily, the difference is unimportant enough that we can gloss over it for now. But if we ever need to get into it there's a whole paper about these nuances:

John Baez (Feb 17 2024 at 23:15):

it would be more convenient to use a slight generalization of Petri nets where instead of natural numbers we can use real numbers to describe amounts of products. Luckily @Jade Master has already worked out the theory of these, and various other generalized Petri nets:

John Baez (Feb 17 2024 at 23:19):

I know this is way too many references to absorb - but in summary, the good news is that the theory and a lot of relevant software is already there!

John Baez (Feb 17 2024 at 23:21):

@Peva Blanchard's idea about one Petri net describing processes in the biosphere and another describing processes in the technosphere (where we ignore inputs and outputs that we don't give a damn about until the planet starts dying :upside_down:) should be quite nice to describe using category theory.

John Baez (Feb 17 2024 at 23:22):

Peva Blanchard (Feb 18 2024 at 08:39):

Peva Blanchard (Feb 18 2024 at 08:58):

Yes ! There is actually a 3rd sphere, the sociosphere, in a sub-field of LCA called "Social LCA".

Less of an introduction, Bo Weidema made a series of videos on specific modelling kinds in LCA. The first video of the series explains well the different intentions.

John Baez (Feb 18 2024 at 17:54):

Thanks! I'll learn about this stuff. I feel this subject is really important and is well suited to a category-theoretic description. But could you remind me why you want to apply category theory? Is there some particular problem in the subject that's bugging you?

Peva Blanchard (Feb 18 2024 at 23:42):

Oh, this one is not easy to answer, because there is a bundle of problems that are bugging me, but I'll give it a try.

Just a little bit more of context before. First you have to know that it is very hard to perform, in the real-world, lifecycle assessments that are fully meaningful, correct, reproducible, and traceable. Recall that, in principle, an LCA study requires to build the inventory of all the substances exchanged with the biosphere. By "all", I mean all the emissions from all the processes in the whole value chain for all the lifecycle phases of your product.

And then people assemble everything into a joyful mixture of Excel sheets, proprietary software and copy-pasted values...

I believe software engineering practices (using the right abstractions, as code approach, testing, etc.) can help tame this complexity; whence the DSL. Besides making sure that the DSL features are meaningful, I have three "ongoing" questioning.

How to separate "model" and "data"

Many processes found in databases are just variants of one another. The database size could be reduced by one or two orders of magnitude if they just used parametrized processes.

That's why in LCAAC, you see parametrized processes. Currently, it is a very basic form so far: process parameters values are passed down from parent to children. It's not ideal: there is no reason for a process to know about all the parameters of all its potential children.

But most importantly, parameters, possibly from different processes, must be coherent altogether. Indeed, data for parameters is very often presented as an instance of database schema (in the sense of Spivak). For instance, let's say that I have a parametrized model of an IT server, and a parametrized model of datacenter. You collected the data for all the servers in a table SERVER, and the data for all the different datacenters in a table DATACENTER, with the constraint that each server belongs to exactly one datacenter.

Now you want to assess the environmental of one datacenter. For that you need to invoke the corresponding model, with the appropriate data, and also all the servers that belong to that datacenter, each of them with them with the appropriate data, each of them correctly plugged in the datacenter process. I did find an ad-hoc solution in the DSL, but it feels wrong.

On this topic, I think ACT may help, because it looks like I want something like a "functor" out of the "parameter database schema" to the "LCA category" (really not sure if it makes sense). I have in mind the way CQL specifies data migration using functors.

Distribute the model parts

As mentioned above, in principle, LCA requires you to model the whole supply/value chain. So we need to split the job. Here, your work on open systems also clicks in. It is theoretically possible to decompose the chain in multiple open systems that you plug in together. Now, you can imagine each actor in the supply chain managing its own LCA model and exposing the endpoints.

Now the difficulty lies in ensuring that the "plugging in" is correct. In LCAAC, we have basic checks, e.g. the physical dimensions of the requested quantity must match that of the product. But, the matching conditions could be more involved, e.g., matching on the specific variant of the circular footprint formula, etc. On this topic, it is mostly about finding a relevant type system.

On the sideways, another interesting venue is confidentiality. Most industrial actors will rarely be open to sharing the details of their manufacturing processes, and it is really a big issue in LCA. This is more of a political issue, but I'm still interested in finding ways of still being able to run the LCA without seeing the details, in the spirit of the zero-knowledge proofs. For instance, is it possible to black-box an open system, using it and still have guarantees on the impossibility to infer the inner details?

Decision-oriented results

So far, I just explained how to compute, e.g., the total impact, with respect to climate change, of a given quantity of product. But, in LCA there are at least three kinds of questions at the end:

Uncertainty analysis is a bit tricky. Of course, I could use independent random numbers in the exchanges (and that's what most software do), and then compute usual statistics. But, to me the independence conditions on the random quantities should be defined explicitly by the analyst.

I had quite some fun with sensitivity analysis. A basic solution consisted in replacing the real numbers in the exchanges with dual numbers (one infinitesimal per parameter).

Contribution analysis is somehow about counting all the paths in a specific subset of paths when I unfold my products and processes. For instance, when assessing the impact of 1 kg of bread, computing the contribution due to deforestation: deforestation is usually to a whole set of processes, so we want to compute the "size" of all the paths that traverse those processes. The implementations I've seen were always specific to a particular impact group. I believe though we could have a query language to select a "logical combination of subsets of paths", thereby being able to compute any contribution decomposition.

Voilà. Again, my response turned out much longer than I expected. But, these are the main topics that occupy my mind currently. I don't know if CT/ACT will be the right answer to every issue, but some topics seem very similar. (It could also be that I see nails everywhere because of my hammer-like nature).

Stream: theory: applied category theory

Topic: Life-Cycle Analysis

Peva Blanchard (Feb 14 2024 at 23:20):

"Static" LCA

Syntax

Semantics

Dynamic LCA

Syntax

Semantics

Conclusion

John Baez (Feb 15 2024 at 21:10):

John Baez (Feb 15 2024 at 21:15):

Peva Blanchard (Feb 15 2024 at 22:21):

John Baez (Feb 17 2024 at 00:52):

John Baez (Feb 17 2024 at 00:55):

John Baez (Feb 17 2024 at 00:59):

John Baez (Feb 17 2024 at 01:02):

John Baez (Feb 17 2024 at 01:03):

John Baez (Feb 17 2024 at 01:17):

John Baez (Feb 17 2024 at 01:18):

davidad (David Dalrymple) (Feb 17 2024 at 08:45):

davidad (David Dalrymple) (Feb 17 2024 at 08:59):

davidad (David Dalrymple) (Feb 17 2024 at 09:05):

davidad (David Dalrymple) (Feb 17 2024 at 09:10):

davidad (David Dalrymple) (Feb 17 2024 at 09:20):

Peva Blanchard (Feb 17 2024 at 16:37):

Peva Blanchard (Feb 17 2024 at 17:19):

Peva Blanchard (Feb 17 2024 at 17:30):

John Baez (Feb 17 2024 at 23:12):

John Baez (Feb 17 2024 at 23:15):

John Baez (Feb 17 2024 at 23:19):

John Baez (Feb 17 2024 at 23:21):

John Baez (Feb 17 2024 at 23:22):

Peva Blanchard (Feb 18 2024 at 08:39):

Peva Blanchard (Feb 18 2024 at 08:58):

John Baez (Feb 18 2024 at 17:54):

Peva Blanchard (Feb 18 2024 at 23:42):

How to separate "model" and "data"

Distribute the model parts

Decision-oriented results