When using polyviz with bw25, two problems occurred:
The type checks for the activities failed, as in bw25, activities are not of type bw2data.backends.peewee.Activity anymore, but bw2data.backends.Activity. I generalised this to check if the provided activity is one of both in 837f2077be4e0647f3e362bca376a7a50caaa85b.
In the recursive calculations, calling redo_lcia() caused an error. Unlike bw2, bw25 does not automatically remap the inventory dicts back from integer ids to (xx, yy) keys. I am not sure if there is a better solution from bw25-side, but simply calling bw25's remap_inventory_dicts() resolved the issue 837f2077be4e0647f3e362bca376a7a50caaa85b.
I am sure there are more elegant solutions for both problems, I'm sorry if I overlooked something obvious. Nevertheless, I thought I'd share this because, at least for me, polyviz is now working with both bw2 and bw25.
When using polyviz with bw25, two problems occurred:
I am sure there are more elegant solutions for both problems, I'm sorry if I overlooked something obvious. Nevertheless, I thought I'd share this because, at least for me, polyviz is now working with both bw2 and bw25.