The general design of the curated hdf5 files includes grouping together conformers into a single entry. For example, coordinates are stored as an [m, n, 3] array for each molecule (where m is number of conformers, n is number of atoms, 3 correspond to x,y,z).
For a quantity such as atomic_numbers, which will be fixed for all conformers, we do not need to make m copies of the same data. To differentiate between these two types of data, I added in an attribute call "series" where True would indicate we have a series of per-conformer entries, and False would indicate something like atomic_numbers, which apply to all the conformers.
@ArnNag found that I was not consistent with how this was defined for the qm9 (which did not have explicit conformers defined); I marked all values as series=False, which since we don't have conformers is valid, but it means that the underlying arrays will have different shapes than a dataset with conformers (which might make routines to handle this data less generalizable). This code needs to be updated such that any quantity that could be per-conformer, is properly marked (and underlying data arrays have the same shape as if there were multiple conformers).
discussion of the aforementioned issue has led to a more in-depth conversation in terms of providing a quick way to determine what the data represents. currently "series" will tell us if axis=0 represents different conformers. We still do not know if the the underlying data represents a per-atom quantity or a per-molecule quantity. If the value of a given entry for a conformer were a scalar value, that would certainly indicate a per-molecule quantity (e.g., energy), but not all per-molecule quantities need to be scalars (e.g., dipole moments). As such, we should encode a second piece of information regarding per-molecule or per-atom. We do not necessarily need a second attribute, but could change the series attribute to be something like format which a string that encodes the format:
{conformerinfo}{property_info}
conformer_info could be: series or single
proper_info could be: atom or mol
More generally, I think need to ensure that, e.g., when defining energy per molecule, we have an array of size [m,1] rather than [m], such that how we interrogate the array (i.e., look at .shape) is the same for a quantity that may have a spatial dependence (e.g., shape [m,3]).
The general design of the curated hdf5 files includes grouping together conformers into a single entry. For example, coordinates are stored as an [
m,n,3] array for each molecule (wheremis number of conformers,nis number of atoms,3correspond to x,y,z).For a quantity such as atomic_numbers, which will be fixed for all conformers, we do not need to make
mcopies of the same data. To differentiate between these two types of data, I added in an attribute call "series" where True would indicate we have a series of per-conformer entries, and False would indicate something like atomic_numbers, which apply to all the conformers.@ArnNag found that I was not consistent with how this was defined for the qm9 (which did not have explicit conformers defined); I marked all values as series=False, which since we don't have conformers is valid, but it means that the underlying arrays will have different shapes than a dataset with conformers (which might make routines to handle this data less generalizable). This code needs to be updated such that any quantity that could be per-conformer, is properly marked (and underlying data arrays have the same shape as if there were multiple conformers).
discussion of the aforementioned issue has led to a more in-depth conversation in terms of providing a quick way to determine what the data represents. currently "series" will tell us if axis=0 represents different conformers. We still do not know if the the underlying data represents a per-atom quantity or a per-molecule quantity. If the value of a given entry for a conformer were a scalar value, that would certainly indicate a per-molecule quantity (e.g., energy), but not all per-molecule quantities need to be scalars (e.g., dipole moments). As such, we should encode a second piece of information regarding per-molecule or per-atom. We do not necessarily need a second attribute, but could change the series attribute to be something like
formatwhich a string that encodes the format:{conformerinfo}{property_info}
conformer_info could be:
seriesorsingleproper_info could be:atomormolMore generally, I think need to ensure that, e.g., when defining energy per molecule, we have an array of size [m,1] rather than [m], such that how we interrogate the array (i.e., look at .shape) is the same for a quantity that may have a spatial dependence (e.g., shape [m,3]).