Repository navigation
feat: support returning of ions and bare elements in get_chemical_symbols #196
Description
Activity
Let's think about this a bit. I suggest we have an attribute that is something like
atom_symbols_rawthat is just whatever is pulled from the cif file. This could be a list or a dict to keep things compact. Then we can have a parser that tries to interpret it and returns two attributes, something likeatom_symbols_shortandatom_symbols_longor something like that. Short just strips the ion info, but long keeps the ion symbol, but validates it, so if it is an illegitimate ion it does something....raises an exception or fallls back to short or whatever we decide. The former is probably the behavior we had before (program crashed when it couldn't find the chemical species in the lookup table), the latter is the behavior we maybe have now, or were thinking of having....software ignores the ion info but doesn't crash. If we later add a lookup table that has ion information, the behavior of the software won't change but it will silently start pulling the ion information. Something like that.What I like about this approach is that we start keeping all the information....the raw string that was loaded, our best effort at turning it into an ion, and the bare element. These can then be obtained separately by the user as an attribute in the future as needed. What do you think?
Simon copy pasting this from the original discussion in PR #187
@sbillinge Yes makes sense. all atoms get passed through the
atom_bare_symbolfunction which strips all the symbols and only returns species. The challenge with supporting ions is sometimes the atom passed through is a bare symbol, ion, or something else. For example, the12-Cinput for this test,@pytest.mark.parametrize( "symbol, expected", [ ("Cl-", "Cl"), ("Ca2+", "Ca"), ("12-C", "C"), ], ) def test_atom_bare_symbol(symbol, expected): actual = atom_bare_symbol(symbol) assert actual == expectedI think its better to put this on a separate PR/issue. I'll make that issue
and ....
I agree. I commented on that issue btw. I think I see a better way in general of handling this and I laid it out there. I will merge this PR and this conversation can go there.
When we go to that work, it would be great if we could find examples of all the legitimate but odd ways that people put these things into cif files. I never saw that
12-Csyntax before, but I do see that it is some kind of possible standard that someone came up with. I guess it is for inputing isotopes? For example, I could imagine that13-Ccould be hte mass 13 C isotope? In any case, one test for each odd but legit case, but later in that issue
Problem
Currently,
Structure.get_chemical_symbols()only returns bare chemical species and does not offer support for returning ions.Proposed solution
Add an optional input to
atom_bare_symbolto return ions. Default is to return bare symbol. We might want to update the function name to better represent this behavior. Its been deprecated so this would just involve changing theatom_bare_symbolto something likeparse_atom_symbols.