Duplicate Species name error when parsing FactSage DAT into Database about pycalphad HOT 4 OPEN

I can reproduce this, thanks for the excellent report. For TDB files, it's always been safe to assume Species(string) == Species(string.upper()), and so stringified species names are canonicalized to uppercase strings in several places in the code. (TDB would represent carbon monoxide as C1O1.) Right now we're actually converting the whole file to uppercase before parsing, which is clearly not safe to do for DAT files in general, and so we'll need to think about the right place(s) to relax this assumption so the Database can distinguish between, e.g., cobalt and carbon monoxide.

In light of this example, it is not obvious to me what Species('CO') should do, without bringing in more context. Should every Database define its own Species class? I think not, since Species intrinsically couples Model and Database together, and so I see it as more of a pycalphad-level helper object that isn't tied to particular database formats or model types.

My thinking is that we have to make the calling code responsible for managing case. I'm working through the implications of this for the parsers now. The DAT parser will need to work around the assumption that Species('CO') is cobalt, and keep track of case-insensitivity issues where it needs to.

from pycalphad.

This may be a use case for semantic typing, i.e., say Species will only accept a string of type CaseInsensitiveString, and then require explicit conversions.

from pycalphad.

This is related to #419, with the core issue being that species names are basically cosmetic in DAT files

from pycalphad.

#426 should fix the present issue, though it leaves the core issue mentioned above unresolved. It should be enough to move forward with this database, at least.

from pycalphad.