Adaptation to ecoinvent 3.9.1 + Atmospheric aerosol loading

[gpuigsamper]

• Fix elementary flows terminology to use the method in ecoinvent 3.9.1
• Introduces the Atmospheric aerosol loading planetary boundary into the LCIA method

A new release could be done on the basis of these changes (tag, v0.9.1).

TODO:

• Adapt the method to new versions of the ecoinvent database

[vtulus]

@gpuigsamper would we want to enable backwards compatibility?

This could be straightforward to implement: leave the old elementary flows, and each version of ecoinvent would pick the ones that it needs. Is that so? (My thinking is a little bit rusty) 😅

[gpuigsamper]

Hi @vtulus !

Yes, that would be exactly the idea.
Were you thinking of using new branches, or realeases (with tags) for each ecoinvent version?

[vtulus]

I think it is better if the methods are compatible with any ecoinvent version, so the user does not have to think which method to install when.

Do you think that's possible?
I was thinking the other day, if the elementary flows for ecoinvent v3.9.1 would not rename an existing flow (for older versions), but instead be simply added to the list of flows, then each version would pick the flows that are compatible with it. Is my thinking correct?

[gpuigsamper]

That would be ideal @vtulus , so users do not have to worry about versions!

However, with the current implementation this is not be possible since it raises an error of unlinked exchanges. We will need to modify the add_aesa_pbs function.

AESAmethods/src/aesa_pbs/aesa_pbs.py

Line 20 in 704511a

def add_aesa_pbs(verbose=True):

[vtulus]

💯 yes, you're right!

Do you see any solution for that?

[gpuigsamper]

Yes ! Fast solution is to drop unlinked characterization factors before writing the LCIA method. Ideally printing the unlinked CFs, so users are aware. This works well for me.

Would it be necessary to check if CFs to be drop are among those that change between ecoinvent versions? We could incorporate that by keeping track of eliminated or modified elementary flows before droping the CFs.
What do you think @vtulus?

[vtulus]

We basically depend on the default biosphere.
I'm wondering how they deal with it in BW.
The biosphere is installed by default and it works with any version of ecoinvent. Are the default LCIA methods installed automatically too?
This is to say that we probably need to do something similar, i.e., have the AESA methods aligned with the current biosphere flows and probably, anything we had in the past should be obsolete, because no one would use an old biosphere. Or would they?
Maybe we should issue a warning that biosphere should be updated.

[gpuigsamper]

There are some changes in the biosphere between ecoinvent 3.8 and 3.9. This makes that the updated biosphere for ecoinvent 3.9 is not compatible with older versions of ecoinvent.
As such, specific versions of bw2io must be used for ecoinvent <=3.9 (v0.8.6). We can now use the ecoinvent_interface, which directly writes the ecoinvent database and its corresponding biosphere.

LCIA methods are installed with the biosphere, enabling a matching between elementary flows and CFs. From my side, I think it would be necessary to support the utilization of the method in different ecoinvent versions. From my understanding, we can either stick to the idea of providing different files to particular ecoinvent versions, or map the changes in the biosphere between different ecoinvent versions.
This same issue has been reported by other LCIA method developers (see Corrections section), where they provide different files for each ecoinvent version.

[gpuigsamper]

Regarding the mapping of elementary flows across different ecoinvent versions, I think we could rely on the ecoinvent_migrate package to carry out the translation of elementary flows in the LCIA method. This could avoid having different versions for each ecoinvent version. I have opened an issue on this aspect in my fork.