Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design support for LCIA method families and complete methods #84

Open
cmutel opened this issue Jul 1, 2021 · 0 comments
Open

Design support for LCIA method families and complete methods #84

cmutel opened this issue Jul 1, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@cmutel
Copy link
Member

cmutel commented Jul 1, 2021

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:

  1. Input arguments to the LCA class that allow for labelled sectional inputs. Essentially, though the form will be different, it would be something like:
lca = bw2calc.MultiLCA([({functional unit}, data_objs, label), ...])

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?
  1. 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.

  1. 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant