Mapping in Simapro-9-ecoinvent-3.8-manual-matches possibly not correct

[muelleram]

I might have spotted an issue for the mapping of biosphere flows between Simapro and BW for ecoinvent3.8 with the new randonneur_data+ SimaProBlockCSVImporter functionality. Let me explain below, but I am also happy to follow up with the original database and notebooks by mail, if that is helpful/

I tried to isolate the problem and I think it stems from the Simapro-9-ecoinvent-3.8-manual-matches.json and a too strict/early mapping there.
While I get unlinked exchanges for multiple environmental flows (see list below), I want exemplify it for "Arsenic".

Ecoinvent-3.8-biosphere has the biosphere flows "Arsenic", and "Arsenic, ion" for multiple compartments, see:

For the "air"-compartments, there is only "Arsenic".

Before applying randonneur, my processes contain "Arsenic" to air from Simapro (with the air-compartment connotation from Simapro)

After mapping with randonneur, these Arsenic flows are all turned into "Arsenic, ion", because of the mapping in Simapro-9-ecoinvent-3.8-manual-matches.json l1.782:

Their compartment connotation is also changed to fit with the Ecoinvent way.

However, "Arsenic, ion" does not have an "air" compartment in Ecoinvent-3.8-biosphere (see first screenshot), so this biosphere flow remains unlinked.

What I think would be correct, is to not map "Arsenic", and "Arsenic, ion" in Simapro-9-ecoinvent-3.8, as "Arsenic" still exists in the ecoinvent-3.8-biosphere. It diasappears only in ecoinvent-3.9-biosphere and the mapping between ecoinvent-3.8-biosphere and ecoinvent-3.9-biosphere already contains a mapping from Arsenic to Arsenic, ion.

I haven't checked for all of the unlinked bioflows in my system, but only for a subset, for which the same pattern as above occurs. Overall I have the following unlinked biosphere exchanges, but I could imagine that although the database I am trying to import is quite large, there might be other flows with a similar problem that are not in my system.

{'Aluminium, in ground',
'Arsenic, ion',
'Bromine, 0.23% in water',
'Cadmium, 0.30% in sulfide, Cd 0.18%, Pb, Zn, Ag, In, in ground',
'Calcium, ion',
'Chromium, 25.5% in chromite, 11.6% in crude ore, in ground',
'Cobalt, in ground',
'Copper, ion',
'Dioxins, measured as 2,3,7,8-tetrachlorodibenzo-p-dioxin',
'Fluorine, 4.5% in apatite, 1% in crude ore, in ground',
'Iodine, 0.03% in water',
'Iron, 46% in ore, 25% in crude ore, in ground',
'Lead, 5.0% in sulfide, Pb 3.0%, Zn, Ag, Cd, In, in ground',
'Magnesium, 0.13% in water',
'Manganese, 35.7% in sedimentary deposit, 14.2% in crude ore, in ground',
'Mercury',
'Molybdenum, 0.11% in sulfide, Mo 4.1E-2% and Cu 0.36% in crude ore, in ground',
'NMVOC, non-methane volatile organic compounds',
'Nickel, ion',
'PAH, polycyclic aromatic hydrocarbons',
'Particulates',
'Pesticides, unspecified',
'Phosphorus, 18% in apatite, 12% in crude ore, in ground',
'Potassium, ion',
'Propiconazole',
'Selenium',
'Sodium, ion',
'Tebuconazole',
'Tin, 79% in cassiterite, 0.1% in crude ore, in ground',
'Titanium, ion',
'Uranium, in ground',
'Vanadium, ion',
'Waste to recycling',
'Water, cooling, unspecified natural origin, Europe without Switzerland',
'Water, cooling, unspecified natural origin, RER',
'Water, unspecified natural origin',
'Water, unspecified natural origin, FR',
'Water, well, RER',
'Zinc, 9.0% in sulfide, Zn 5.3%, Pb, Ag, Cd, In, in ground',
'_Exported electricity',
'_Exported heat'}

[muelleram]

Addition: while I could of course continue the migration to ecoinvent-3.9 or higher (I tried and it links most of the unlinked biosphere flows above when going to ecoinvent-3.10 and for the remaining unlinked flows, the issue is about the units), it is of interest for my case to have the project in ecoinvent3.8.

And I guess, it would be cleanest to have migration steps that work directly on the versions themselves and not only when combined with a later version-migration step.

[tngTUDOR]

@muelleram this is a very well documented issue, thanks for filing it

[tngTUDOR]

I suppose this could be linked to issue #4 , but I'm not sure.
I'm guessing the said spreadsheet referenced in #4 is probably a better source for the actual migration data.