Open FarnazH opened 8 months ago
I agree. It's important for (multipole) moments too. We can put the functionality from grid here.
Note that it is also a good fit for AtomDB
Makes sense. Because it is a relatively light computation, it can be implemented as a read-only property using atmasses
and atcoords
.
What would you do when no atomic masses are set? We have tried to avoid including extensive atomic data in periodic.py
. At the moment, it does not contain standard atomic masses to instantiate atmasses
when it is not set yet. It would not be an issue to include it.
I think we can include the atomic masses (isotopic average) and the masses of the most common isotope. The alternative is to add a dependency on AtomDB
or similar, but I think this is too little to be worth it.
Note that this touches (indirectly and directly) on several issue we've had with IOData
, notably that it doesn't support computing "electronic" properties when input files have only "molecular" properties. Right now we are encountering this with molecular multipole moments vs. their electronic piece (to test GBasis
) and Issue #287 (e.g., to more easily to support ML workflows) is also related.
It can be useful to have a method in
IOData
class for computing the center of mass. For example, this is useful when computing dipole moment with Grid. What do you think? @tovrstra, @PaulWAyers, and @marco-2023.