It is currently harder than it needs to be do a "complete" LCIA:
There is no logical relationship between characterization, normalization, and weighting in the code, so users have to design their own data storage or just keep track themselves
It is difficult to calculate multiple impact categories for a given method. Again, manual aggregation work is needed
We need it to be easy to users to get a more complete LCIA picture. Specifically, we need:
Input arguments to the LCA class that allow for labelled sectional inputs. Essentially, though the form will be different, it would be something like:
It might also make sense to have this input spec support multiple labelled functional units as well?
Key questions:
One key assumption is whether or not we only build one technosphere matrix which covers all possible functional units. One can imagine a lot of benefits from this approach, but also cases where it would be problematic.
What should the labels be like? Are they generated from the names of the methods or method families? Are they human-readable?
Is there a better way to specify input arguments which allows for kwargs?
Specification of how data is stored in the MultiLCA class
If the input arguments are lists, than we can store the supply_array, inventory, and characterized_inventory matrices as lists as well. Maybe we no longer need to store the characterized_inventory at all if we are running into memory problems, could calculate it dynamically (matrix multiplication is fast). To be complete, we should also have a solution for normalization and weighting as well.
How do we store information about method families in bw2data?
We need to be explicit about assumptions, e.g. do we require normalization and weighting to be consistently there or not? Do we automatically traverse all "sub-methods", or require them to be manually added?
Do we need a new metadata store, similar to methods, normalizations, and weightings? The alternative is to add extra data to methods, but this seems suboptimal even when typing this sentence.
@StpdFox @bsteubing @dgdekoning I know you have thought about this for the AB, please provide some input!
@tngTUDOR You know about things, maybe you also have some inputs
It is currently harder than it needs to be do a "complete" LCIA:
We need it to be easy to users to get a more complete LCIA picture. Specifically, we need:
It might also make sense to have this input spec support multiple labelled functional units as well?
Key questions:
MultiLCAclassIf the input arguments are lists, than we can store the
supply_array,inventory, andcharacterized_inventorymatrices as lists as well. Maybe we no longer need to store thecharacterized_inventoryat all if we are running into memory problems, could calculate it dynamically (matrix multiplication is fast). To be complete, we should also have a solution for normalization and weighting as well.bw2data?We need to be explicit about assumptions, e.g. do we require normalization and weighting to be consistently there or not? Do we automatically traverse all "sub-methods", or require them to be manually added?
Do we need a new metadata store, similar to
methods,normalizations, andweightings? The alternative is to add extra data tomethods, but this seems suboptimal even when typing this sentence.@StpdFox @bsteubing @dgdekoning I know you have thought about this for the AB, please provide some input!
@tngTUDOR You know about things, maybe you also have some inputs