GEMS-T0012 Unintuitive charge calculation for some compounds

[DocMT]

The Problem

When using the ChemicalFun::FormulaProperties to obtain the properties of some compounds, the charge is incorrectly calculated. For example, if we use Calcium carbide (CaC₂) as input compound and run:

ChemicalFun::FormulaToken token("CaC2");
ChemicalFun::DBElements all_elements;
ChemicalFun::FormulaProperties properties = token.properties(all_elements.elements());

Then we receive the following output:
{"atomic_mass":64.09959983825681,"atoms_formula_unit":3.0,"charge":10.0,"elemental_entropy":53.06999969482422,"formula":"CaC2"}

Note the "charge":10.0, which should be 0. Technically one could also write Ca(C2) which could indicate that Carbon forms a triple bond in this case and the species generated would have to be Ca²⁺ and (C₂)^2-. However, the parser is simply a tokenizer, not a chemical interpreter.
The atomic mass is calculated correctly and the atoms_formula_unit as well, but the charge is derived from valances and it is assumed that (C)arbon has a valence of 4 and (Ca)lcium of 2, which is then simply calculated as 1 * 2 + 4 * 2 = 10 (see double FormulaToken::calculate_charge). The valences are static and stored in map_elements_valences. This is not the expected behaviour for a chemist like myself. Therefore, this issue should at least be pointed out somewhere as a limitation.

Further Examples

Obviously, because of the static valence calculation, the abovementioned problem is not restricted to corner cases. Other common examples would be:

• Na₂S (i.e. Sodium sulfide: {"atomic_mass":78.0466003417968,"atoms_formula_unit":3.0,"charge":8.0,"elemental_entropy":134.3979988098144,"formula":"Na2S"})
• Na₂SO₃ (i.e. Sodium sulfite: {"atomic_mass":126.04480075836182,"atoms_formula_unit":6.0,"charge":2.0,"elemental_entropy":442.1049995422374,"formula":"Na2SO3"})
• Mn₂O₃ (i.e. Manganese(III) oxide: {"atomic_mass":157.8741998672486,"atoms_formula_unit":5.0,"charge":-2.0,"elemental_entropy":371.7269973754894,"formula":"Mn2O3"})
• MnO₂ (i.e. Manganese(IV) oxide: {"atomic_mass":86.9368000030518,"atoms_formula_unit":3.0,"charge":-2.0,"elemental_entropy":237.1479988098152,"formula":"MnO2"})
• Mn₂O₇ (i.e. Manganese(VII) oxide: {"atomic_mass":221.8718004226686,"atoms_formula_unit":9.0,"charge":-10.0,"elemental_entropy":782.0029983520534,"formula":"Mn2O7"})

Proposition for a Solution

The only possible solution for this problem is to explicitly define the valence like so CaC|-1|2, which assigns the (C)arbon atom a valence of -1. This would need to be mentioned somewhere and is only a suboptimal solution.

Better Solution: The program should not derive the (molecular) charge from valence calculation at all, but from charge indicators. If no charge indicators are present, the given formula should be electroneutral and the program could forget the valences altogether. However, I fear (although I haven't checked) that the reaction algorithm uses the valence information to calculate charged ions in solution.

[gdmiron]

@DocMT Indeed this is how the formula parser behaves, it assumes default valence stored in the map_elements_valences if not provided as in CaC|-1|2. If one writes any formula without explicitly defining the valence then the default one is taken. So Fe3O4 should be given as FeFe2|3|O4. The code at present does not look for charge indicators but calculates the charge from the elements and their valences.

[gdmiron]

@sdmytrievs could we change the behavior of the charge calculation? Now the charge is calculated based on the elements and their default or specified valence, independent of the charge symbol given in the formula. What if the charge calculator would calculate the charge from valence and then compare with charge based on symbol in given formula? If they don't mach return "false". In GEM-Selektor we have a check if charge does not match. Or we can have a preference of charge from symbols or charge from valence.