-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cost of elements #124
Comments
Great suggestion! I haven't planned for this but if you want to take a stab I'm happy to support. Few things to figure out would be what columns we need, which table the should be and how to handle point in time data I.e. price would be valid for a particular period in time. Any suggestions? |
Maybe the cost of alloys could be modeled as a linear combination of the metals included, but the same can not be said of generic elements. Pure Si is much more expensive than sand (SiO2) for example. So I don't think it belongs as a property of elements. (plus that it is volatile so we can't pin a mendeleev version and expect up-to-date information) |
I'd be happy to contribute, and yeah you're right we should determine which information we will include and how to handle updating it. For now, we can include the cost (dollars/kg or pounds) and we can update at the beginning of each new year. I think that even this can be considered as really up to date information.
Yeah, I'm planning to model as linear combination of elements. The alloys are not standard compunds like SiO2, they will be multi-element alloys/oxides (like high entropy alloys). I thought maybe the values can be updated every year. Even this information can be quite useful for most people because right now I'm collecting the information by looking at the individual report of each element (going through this page), which is out of 40 elements in total. |
I'm happy to explore further but I have gaps in how the prices are determined. I think @kalvdans made a few good point so we would need to draft a simple data model to see if it holds up for a few use cases. In terms of data model, since this data will evolve, maybe we should consider a separate table with commercial information with a key/id pointing back at elements? I don't know enough about how prices are structured but I guess some elements you can buy raw, some not, some are prices per volume, some by weight, are there purity grades influencing price?, is there a default granularity we would like to capture the price at (e.g. yearly average)? and there's also a choice to be made on currency but I guess $ might be uncontroversial? Let me know if this make sense and it there a way to simplify the design further. |
Good points! For the data type, I had thought that the cost can be stored for each element line in the way that you suggested: key/id and this can be obtained by an attribute like other properties of the elements (radius, electronegativity or so) For instance, by a line of code like:
Yes, the cost for different elements are given by different purity/grade or per volume/weight. But the most raw form of the element can be taken. I mean if the element has a price for its metallic form, then it's okay. Otherwise, if it is produced or sold in the form of compounds or salts (ferroalloys of Nb and Ta, or Na sulfate), then the price of that form can be reported with a note (I'm not sure how /where to put a note). The price would be dollar/kg. The price of every element can be converted to this unit, even the precious metals (e.g. gold is reported with dollars per troy ounce.) The data can be taken from US Geological Survey Mineral Commodities. These are few examples of the points above: aluminum, chromium, gold. I have to mention that I believe there is no price information of every element in the periodic table. If there is another source, the data can be taken from there. This was the one that I was able to find for the elements that I am considering. |
This looks like a solid plan. As a first step maybe you could compile a table/dataframe/csv with the available data on prices. This could include multiple entries per element if necessary. Then we can model a db table using existing data and add the new interface methods. I'm happy to help with the db migrations using alembic and getting the data into the db if that's helpful. Consider drafting a PR so we could start looking at concrete code changes to make it work. |
@sedaoturak any interest in pushing this forward? |
Hi, so sorry about this too late reply. I lost these messages in the emails since there is no notification feature on github.. I'd like to add the cost of these, but first I need to collect the data for all elements, or at least the most of the periodic table. Also, I've heard about Herfindahl–Hirschman index (Here is study on HHI for critical materials). This might be mostly related to earth abundance. But what do you think? |
No worries 🙂 HHI looks pretty interesting and might be easier to get. If I understand correctly it is less volatile than price so might not need updating (I'm guessing). I haven't yet looked at the paper they are citing in the link you shared but maybe getting the values HHI_production and HHI_reserve for each element would be a good start? |
Just found wikipedia has a nice page with prices of elements. Should be possible to parse with sth like pandas.read_html. |
I am going to estimate the cost of a list of alloys and I was trying to find this information from different resources.
Now, I'm getting the data from US Geological Survey and I thought if this information can be added to mendeleev, or are you planning to do something like this? Similarly, amount of production can also be added.
The text was updated successfully, but these errors were encountered: