Other recommended descriptors

[jvita]

Starting an issue here for tracking requested descriptors to be added in the future:

• SGOP/VGOP. This would be interesting because it generates a configuration-level descriptor, rather than atom-level descriptor (like SOAP) that has to be averaged over all atoms.
• Edge-node neighbor graphs (e.g., as is done in the nequip data constructor). This is a common input to many MPNN models.

[ipcamit]

How is edge-node neighbor graphs different from KLIFF generated graphs? They both are $2 \times N$ array, with uni-directional graph node pairs. Or do you think it should be part of descriptor library instead of KLIFF?

[jvita]

1. I do think it should be part of a descriptor library instead of KLIFF -- people should be able to use libdescriptor independently of KLIFF
2. I'm not familiar with KLIFF's implementation, but wouldn't the graph be something more like where the nodes are a length - $N$ vector of element types and the edges are an $N_{pairs} \times 3$ array where each row is the Cartesian displacement vector pointing from an atom to one of its neighbors?
3. You could even go further, where you allow the edges to be expanded using spherical harmonics and Bessel functions, as is done by NequIP and many other MPNNs. This would make it easier for newcomers to get started building an MPNN even if they aren't familiar with the details of spherical harmonics and Bessel functions.

[ipcamit]

Ah ok.

1. The reason why it is not the part of descriptor library is because

• Graphs did not fit the exact box of descriptors. Their exact form do change with permutation etc.
• They are not differentiated against, they are just indexes.
• Descriptors are self-contained description of environments, the model only usually needs them for computation. Graphs need additional information for computation (coordinates)
  Therefore graphs are topology of the system, which is strictly not descriptor. And once you have the neighbors, computing graph is just two loops (model driver computes its own graphs). The KLIFF graph code is self contained, so adding it to libdescriptor is trivial, if needed. That said I do like the idea of libdescriptor being able to generate graphs, as that will simplify interface with several use cases. But I need to think over its exact categorization.

2. So KLIFF uses same notation as pytorch geometric, where it saves the atom pairs. The reason it does not compute the cartesian vectors is because more often then not the model handles it, and rarely you will pass the cartesian vectors to the model as an input. And I think model is better place to handle it as it is simple enough to implement, and it will enforce higher barrier for converting any model to OpenKIM format.

3. Again, these things are best handled in the model, at least at present, because these things can be easily deployed inside a model, and it would be significant amount of work to come up with e3nn like coherent framework on C++ side. Though I do have long term plan of having such barebones structure in place for a unified Bispectrum, SOAP, and higher order spectrum framework "in future", I would not invest time on it yet. But if enough interest is there, we can distribute work and discuss it. (basically we would like to implement subset of e3nn in C++, use their API and fill in the functions).