The good

The existing software has a lot of very nice aspects, and is widely used by people who want to work outside the existing restrictions of most LCA software. A lot of the good parts of Brightway2 come from building on top of awesome work by others - this is the magic of open source software - and it turned out to be an especially good choice to write scientific software in Python, as there is a lot of great stuff happening in this community. Brightway2 has great mathematical performance (Brightway2 has certainly done far more LCA calculations than all other LCA software combined), and although there isn't a great graphical interface, the command line does allow for some remarkable expressiveness. Here is a quick example that decreases the transportation requirements of every activity in ecoinvent by ten percent:

for activity in Database("some ecoinvent"):
    for exchange in activity.technosphere():
        if exchange.input['name'].startswith("transport,"):
            exchange['amount'] *= 0.9
            exchange.save()

Of course, in real life you would have to check to make sure that you aren't doing stupid things to special cases - and ecoinvent loves their special cases - but you get the general idea.

Brightway2 also has projects. Each project has its own version of its data, and each project is just a subdirectory. This means that for each project you work on, be it a client study or a paper, you can preserve your work without worrying about other projects modifying the background databases or other data. Because each project is a subdirectory, you can also store them on Dropbox or easily ship one to a Docker container.

Finally, Brightway2 and Python are flexible and have few built-in limitations. This allows you to play around, and quickly implement new ideas. For example, the code supporting the following graph creation was written in only two hours:

Database("ecoinvent 3.3 cutoff").graph_technosphere()

Ecoinvent 3.3 cutoff technosphere matrix

The bad

Brightway2 has evolved a lot since the first commit in October 2012. The way data was stored in databases changed completely, for example. Project management only came in 2015; before that, you specified a data directory in an environment variable. There is still a lot of cruft from earlier approaches in the code base, and not all functions have been updated to the latest approach. LCIA methods, for instance, are still stored in files instead of in a database.

The ugly

{('ecoinvent 3.2 consequential', 'b7ec253b142868afdbf7039818b41059'): 22887,
 ('ecoinvent 3.2 cutoff (ocelot)', 'c6035426edb25dff5e2cac9faa04d294'): 68215,
 ('biosphere3', 'b6349d15-124b-473b-86b5-da63e0060c1a'): 3098,
 ('ecoinvent 3.2 apos', '700099b63130bdd8a315ba3737ba7e25'): 34268,
 ...}

Smaller changes

• Instead of projects.set_current(), we will have projects.select() and projects.create().
• Instead of binary data in the default database backend, Brightway version 3 will use JSON.
• No more write locks in the default backend. All data will be stored in a SQLite database and multiple threads can read and write at the same time.

New plugin architecture & common API

There will be a plugin architecture building on top of stevedore, and a common API that will allow new plugins to "just work". This common API will define common entry points, and dispatch the new information. A plugin that provided search capabilities, for example, would tie into the entry points for an activity being changed, and when an activity changed, this entry point would call the function in the search library that would update the data in the search index for the altered activity. However, certain configurations of Brightway will not need or use the common API, and it will be possible to have a completely different user interface and database, and only use the functions in the calculation and analysis packages.

No more mapping in the default backend

Instead of a mapping dictionary, we can instead use the fact that our database already has integer ids for each database row in the activity table. We don't need a separate mapping object and file, and all the code this requires. Similar analysis applies to the geomapping dictionary as well, which will also be stored in a new database table for locations.

Redefining LCA object construction

Currently building an LCA object requires brightway2-calc to import brightway2-data to read the mapping, and to figure out the dependency graph between databases. In the new version there will be a helper function in the equivalent of brightway2-data to prepare the input arguments to any brightway2-calc calculation. The new calculation library will be truly independent of the underlying data store, and will instead just load arrays from a file or web resource, build the required matrices, and do the calculations.

Splitting the LCI processed array into technosphere and biosphere arrays

Currently, the technosphere and biosphere exchanges in an LCI database are stored as one processed array, which has to be treated differently from all other processed arrays when building matrices. brightway2-calc neeeds to know how to split this array into two components, the technosphere and biosphere arrays, and then alter the signs on some of the values in the technosphere array based on the type of exchange. In the next generation, the data backends will instead generate two processed arrays with the correct signs, and all the special case code in brightway2-calc can be removed.