Different results in 2.0.3 and 2.0.4

Question

Hi, 

I have noticed that when I calculate the results for the exact same product system, I get very different results depending on if I do it in openLCA 2.0.3 or openLCA 2.0.4. I would say that 2.0.3 has more reasonable results.

Have anyone else noticed this? 

2.0.3:

2.0.4:

(I am using database ecoinvent 3.9.1 cutoff and impact assessment method ReCiPe midpoint (H))

Thanks! 

/Elin 

Answer 1

Yes, good observation, we had a bit of tinkering with the impact direction and this is now good and corrected in version 2.0.4 we believe. So please use this (and we need to apologise since this caused some confusion). Whether the 2.0.3 or 2.0.4 results are more credible I cannot tell from your system results, of course, you can check a more expanded view of the contribution tree e.g..

Best wishes,

Andreas

Answer 2

I assume that it has to do with (maybe) differences in the model and not with openLCA. The method that is used is from the ecoinvent methods implementation (known by the openLCA category name "climate change - global warming potential (GWP100)") which yields the same results as ecoQuery in these openLCA versions and the ecoinvent methods in openLCA do not yet use the new impact direction feature.

Answer 3

Hi! 

Thank you for your answers, we have some new input and questions regarding this issue.

We have used ecoinvent 3.9.1 in 2.0.4,  employing different impact assessment methods (openLCA - IPCC 2021 and ecoinvent - ReCiPe 2016 v1.03, endpoint (H)), and encountered issues with negative values in both.  Upon closer examination of the contribution analysis, we find NaN, infinity and negative infinity, see pictures. The anomalies seem to originate from "treatment of road wear emissions", "treatment of tyre wear emissions" and "treatment of brake wear emissions". Some of the recurrent elementary flows are particulate matter , see pictures. 

While we understand that this may be an implementation issue within ecoinvent, do you have any insights into what might be causing this? Could it be related to a new coupling, calculation, or similar feature implemented in the latest impact direction feature, for example?

Thank you!

Comments

Hi, thank you for your input. I have answered above in a new comment.

Answer 4

Hi Conrad, I answer here so that I can include pictures.

Here is the complete contribution analysis tree leading up to the NaN and infinity answers, maybe this helps. The impacts are very small by themselves, but all these negative values together add up to -12% for PC for example. 

I performed "direct calculation" on the process showing NaN (market for cable, connector for computer, without plugs | cable, connector for computer, without plugs | Cutoff, U) and it showed all negative, and in contribution analysis also shows NaN and infinity. Could this process be the one that is causing all the issues? 

Comments

Maybe better send us a mail, since the issue will be in your own foreground model and not in the ecoinvent database or the software itself. I can calculate "market for cable, connector for computer, without plugs | cable, connector for computer, without plugs | Cutoff, U" without any issues and with correct results. The problem is that even when you have mistakes in your own foreground system like exchanges divided by 0 or set to 0 or too many parameters in your own model which are set to 0, this will also influence other results, since a calculation will always calculate the whole database (the whole matrix).