Michael F. Herbst
Michael F. Herbst
I would appreciate that, too. We have used it in DFTK as well for some time now.
Cool idea. Would be nice to have something like this. I wonder if it would make more sense to avoid the dependency of Brillouin on Spglib and rather move the...
First off, I am very sorry for having taken eternities to react. I had a very heavy past few weeks, but I am glad to see how this discussion has...
Atom-level properties already work (see `Atom` struct). Basically just overload `getproperty` and `hasproperty`. IMHO there is nothing additional needed for that. Same thing could be done with an identical mechanism...
In light of what I just said, let's brainstorm a little on what people would need / are already using (feel free to amend this post): ## System - ......
I think we should first collect the things someone has an actual use case for to not avoid clutter
Personally I don't care how we represent element types. I agree a separate struct would be nice for dispatch and as long it is light weight and flexible it really...
Yes sure, I understand that. But then you could just make your atom type that just stores the number and only implements the functions that return `atomic_symbol` by looking up...
Internally (i.e. in your implementation of the interface) you can still do this, so I don't see a restriction in the current interface. However, one might argue it might sense...
Just that I understand correctly: You would still return Unitful quantities when a user calls `position`, right ? Because at least in the current state of AtomsBase specifying the output...