Incorrect AnionCorrections obtained using MaterialsProject2020Compatibility for ComputedEntry with sulfur having positive oxidation state.

[dembart]

Python version

Python 3.11.13

Pymatgen version

2025.10.7

Operating system version

OSX

Current behavior

I get AnionCorrections for S6+ species (it is cation) when I create ComputedEntry from scratch and apply corrections using MaterialsProject2020Compatibility.

from pymatgen.core import Composition 
from pymatgen.entries.computed_entries import ComputedEntry
from pymatgen.entries.compatibility import MaterialsProject2020Compatibility

comp = Composition.from_dict({"Li1+": 4, "Cs1+": 4, "S6+":4, "O2-": 16})
energy = -160.3371 # uncorrected energy for mp-6597

entry = ComputedEntry(composition = comp, energy = energy)
entry.parameters = {"run_type": "GGA"}

compat = MaterialsProject2020Compatibility(check_potcar=False, correct_peroxide=True)
compat.process_entry(entry, on_error="raise")
print(entry)

None ComputedEntry - Cs4 Li4 S4 O16 (CsLiSO4)
Energy (Uncorrected)     = -160.3371 eV (-5.7263  eV/atom)
Correction               = -13.0040  eV (-0.4644  eV/atom)
Energy (Final)           = -173.3411 eV (-6.1908  eV/atom)
Energy Adjustments:
  MP2020 anion correction (S): -2.0120   eV (-0.0719  eV/atom)
  MP2020 anion correction (oxide): -10.9920  eV (-0.3926  eV/atom)
Parameters:
  run_type               = GGA
Data:
  oxidation_states       = {'Li': 1.0, 'Cs': 1.0, 'S': 6.0, 'O': -2.0}

However, when I retrieve this record using mp_api, everything appears correct.

with MPRester(api_key) as mp_rester:
    entry = mp_rester.get_entries(['mp-6597'], additional_criteria={'thermo_types': ['GGA_GGA+U']})
print(entry[0])

Retrieving ThermoDoc documents: 100%|██████████| 1/1 [00:00<00:00, 19328.59it/s]
mp-6597-GGA ComputedStructureEntry - Cs4 Li4 S4 O16 (CsLiSO4)
Energy (Uncorrected)     = -160.3371 eV (-5.7263  eV/atom)
Correction               = -10.9920  eV (-0.3926  eV/atom)
Energy (Final)           = -171.3291 eV (-6.1189  eV/atom)
Energy Adjustments:
  MP2020 anion correction (oxide): -10.9920  eV (-0.3926  eV/atom)
Parameters:
  potcar_spec            = [{'titel': 'PAW_PBE Cs_sv 08Apr2002', 'hash': '096b53a7d80cc0086976bcda50d536e5', 'summary_stats': None}, {'titel': 'PAW_PBE Li_sv 23Jan2001', 'hash': '4799bab014a83a07c654d7196c8ecfa9', 'summary_stats': None}, {'titel': 'PAW_PBE S 17Jan2003', 'hash': 'd368db6899d8839859bbee4811a42a88', 'summary_stats': None}, {'titel': 'PAW_PBE O 08Apr2002', 'hash': '7a25bc5b9a5393f46600a4939d357982', 'summary_stats': None}]
  run_type               = GGA
  is_hubbard             = False
  hubbards               = None
Data:
  oxide_type             = oxide
  aspherical             = True
  last_updated           = 2024-11-21 20:38:24.276956+00:00
  task_id                = mp-1393723
  material_id            = mp-6597
  oxidation_states       = {'Cs': 1.0, 'Li': 1.0, 'S': 6.0, 'O': -2.0}
  license                = BY-C
  run_type               = GGA

Expected Behavior

No anion corrections for sulfur having positive oxidation state.

Minimal example

from pymatgen.core import Composition 
from pymatgen.entries.computed_entries import ComputedEntry
from pymatgen.entries.compatibility import MaterialsProject2020Compatibility

comp = Composition.from_dict({"Li1+": 4, "Cs1+": 4, "S6+":4, "O2-": 16})
energy = -160.3371 # uncorrected energy for mp-6597

entry = ComputedEntry(composition = comp, energy = energy)
entry.parameters = {"run_type": "GGA"}

compat = MaterialsProject2020Compatibility(check_potcar=False, correct_peroxide=True)
compat.process_entry(entry, on_error="raise")
print(entry.energy)

Relevant files to reproduce this bug

No response

[shyuep]

@rkingsbury Do you mind taking a look? I recall you were the main developer of the new corrections.

[rkingsbury]

@rkingsbury Do you mind taking a look? I recall you were the main developer of the new corrections.

Sure, no problem. Also tagging @awvio who did most of the hard work.

@dembart - thank you for report, I can see how this behavior is unintuitive. The way the corrections are supposed to work for most anions is the following (see code block):

1. Examine the ComputedEntry.data
2. If entry.data["oxidation_states"] exists, use its contents to determine the oxi states of all species
3. If it doesn't exist, use oxi_state_guesses to guess the correct oxidation states
4. Apply appropriate corrections only if the element is in a negative (anionic) oxidation state

Normally, the entry.data["oxidation_states"] is populated during the MP Database build process, using more sophisticated algorithms than oxi_state_guesses. So when you use mp-api, you get a correctly assigned oxi state and the corrections work properly.

However, for sulfides specifically there is a slightly different handling (see code block):

1. Examine the ComputedEntry.data
2. If entry.data["sulfide_type"] exists, use its contents to determine the sulfur / sulfide / polysulfide type
3. If it doesn't exist but there is a Structure, use Structure.sf_type to get the sulfide type
4. If (and only if) the sulfide type is 'sulfide, apply the anion correction.

As with oxidation states, sulfide_type is normally populated (correctly) during the MP build process. The fundamental bug here is that sulfide_type defaults to sulfide (see line 1110). So, when you built your entries manually, you got sulfide (since there was no Structure or `.data["sulfide_type"] key) and hence got the erroneous correction.

Recommended solution

This should be changed so that sulfide_type either defaults to None, or that there is a basic oxidation state check similar to what we do for the other anions, and only if S is anionic do we assume sulfide.

I hope this helps @shyuep !

I typed out all the below in the course of troubleshooting. I will leave it here for recordkeeping / future developers benefit, but the below things I checked do not cause this bug.

At first I thought you were running into a previously-reported bug (see #3425 and subsequent fix in #3427) involving the behavior of Species (which is the class that's invoked when you specify element + oxi state as in S6+) vs. Element. However, I tested your example comp without the oxidation states and it generates the same guesses.

>>> comp = Composition.from_dict({"Li1+": 4, "Cs1+": 4, "S6+":4, "O2-": 16})
>>> comp.oxi_state_guesses()
({'Li': 1.0, 'Cs': 1.0, 'S': 6.0, 'O': -2.0},)
>>> comp = Composition.from_dict({"Li": 4, "Cs": 4, "S":4, "O": 16})
>>> comp.oxi_state_guesses()
({'Li': 1.0, 'Cs': 1.0, 'S': 6.0, 'O': -2.0},)

Since the bug here is not coming from oxi_state_guesses, I also checked that Composition is counting Element vs. Species correctly, which was the problem in the previous bug report. A quick check doesn't indicate that's a problem here though:

>>> comp = Composition.from_dict({"Li1+": 4, "Cs1+": 4, "S6+":4, "O2-": 16})
>>> comp["Cs"]
4
>>> comp["S"]
4
>>> comp["O"]
16
>>> comp["Li"]
4

Finally, I thought the issue might be coming from this line, where we test if Element(<X>) in comp: as a condition for applying corrections, but this works correctly even with Species

>>> comp = Composition.from_dict({"Li1+": 4, "Cs1+": 4, "S6+":4, "O2-": 16})
>>> Element('S') in comp
True