You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are only a few cases where units and periodic tables are needed (IO/glue-code and gbasis/grid respectively), so it is not worth breaking modularity for it.
We need to replace those situations with simple dictionaries of data (atomic-nubmer:covalent-radii for grid, symbol:atomic-number for gbasis). There is a little bit of duplication of data, but it's a small amount that will never get changed. The convenience of having a periodic table class should be reserved for glue-code level or maybe even user code.
The text was updated successfully, but these errors were encountered:
I would not remove them entirely. Units can be part of iodata. A periodic table package would still make sense as an independent project because it comes in handy when scripting and glueing, e.g. when some sort of radii is needed.
There are only a few cases where units and periodic tables are needed (IO/glue-code and gbasis/grid respectively), so it is not worth breaking modularity for it.
We need to replace those situations with simple dictionaries of data (atomic-nubmer:covalent-radii for grid, symbol:atomic-number for gbasis). There is a little bit of duplication of data, but it's a small amount that will never get changed. The convenience of having a periodic table class should be reserved for glue-code level or maybe even user code.
The text was updated successfully, but these errors were encountered: