Refactoring type checks and technosphere/biosphere split
Opened this issue · 2 comments
Feature request
In bw2data, type checks are used for the following:
- To check for common typos, to prevent future frustration (see whitelist values)
- To determine which edges go in which matrix, and what sign they should have
In current Brightway the labels used are configurable, i.e. nothing is hard coded. To maximize flexibility and reduce the potential for frustrating errors, we actually don't need to label nodes at all - rather, we let things be according to the context that they are used in. This means we don't have to worry about whether a node is a process, a product, or a chimaera.
The edge labels can be divided into three classes:
- biosphere_edge_types
- technosphere_negative_edge_types
- technosphere_positive_edge_types
But I think you could join these last two for your purposes.
I am trying to get the refactoring branch usable in 2.5, and building on FOSS data, namely the USEEIO. This is easy to install:
import bw2io as bi
bi.remote.install_project('USEEIO-1.1', project_name="something")However, I can't create a calculation setup - when I try to drag a node of type product into the "Reference flows" table (CSActivityTable), the drop event is not accepted. I think this is because of the getattr(event.source(), "technosphere", False) check, though I am not 100% certain.
My immediate problem is that this is stopping me from being able to create test fixtures to give to my colleagues so they can hack hack hack the night away; I would love to know where this "technosphere" attribute is attached, so that we can make that a bit more robust. I originally thought it was this line: "biosphere" if self.database == config.biosphere else "technosphere", but that doesn't appear true in this case.
In the medium term, I am really uncomfortable with the widespread use of bw2data.config.biosphere and the very concept that a given database is either technosphere or biosphere. This will just break for many, many people. A Database is a collection of nodes, and membership in a given Database says nothing about type or any other attribute. It's much better to let the ducks wander around here; if a node only has edges with types biosphere_edge_types, then it is should be blocked from being used as a product in a calculation setup. Otherwise, let everything in, and catch OutsideTechnosphere at calculation time.
Here's another example of how the current approach can break things:
In lca_setup.py, we currently check for the node type, and raise an error if the node type is not process:
if act.get("type", "process") != "process":
raise TypeError("Activity is not of type 'process'")However, this is precisely incorrect - the functional unit is of products, not processes; the only processes that are valid here are chimaeras which act as both product and process at the same time.
Quick comment from mobile to get you on your way. The technosphere attribute in question is attached to the ActivitiesBiosphereModel here and is derived from a function in bwutils.commontasks called is_technosphere_db