Structure for term-wise quantities

[mfherbst]

In #766 it came up that it might be useful to have a structure for term-wise quantities similar to what we have for the energies.

Let's start by what we want. From my point of view:

• It would be useful to collect energy, force, stress, hamitonian, potential ... contributions from different terms in a systematic and uniform way and expose them as individual contributions to the user to let them decide what to do with it.
• The basic structure is almost alike for all aforementioned contributions
• Most commonly one is interested in the total quantities so it should be easy to get those.
• Nice pretty-printing would be great.

In fact I never was a huge fan on how we handle the Energies right now. It seems like a lot of boiler plate for not giving much functionality. I see the following options:

• Just use an OrderedDict for the contributions and return this by all functions. The user is responsible for adding stuff up. We have convenience functions for printing and getting the sum.
  • Advantage: Little boilerplate code
  • Disadvantage: Pretty printing is not automatic, which is something I personally like about the Energies struct. Our users also like this.
• Have one structure for term-wise quantities, which is used for all of the afforementioned quantities.
  • Advantage: Nice pretty printing, common syntax across the quantities
  • Disadvantage: Likely more code and one struct that basically is a custom dictionary.

@azadoks @antoine-levitt I still lean to the second, but let's collect ideas.

[GVigne]

It's going to be hard to have a unified GPU/CPU code with this sort of thing. Dictionaries behave quite badly on the GPU, as they break kernels by adding local effects. Plus, we probably will have memory problems as those dictionaries would have to be stored on the GPU. It's an issue that we are going to have in #766 with the form factors. They way I see it:

• either we don't do this, which keeps a uniform code base for CPU/GPU.
• either we go for performance and we will need to split the code base to at least have a default fallback to the current implementation: we will be recomputing the form factors each time on the GPU but it will be much easier to handle.

[mfherbst]

Ok splitting the code base for something as simple such as storing such contributions sounds like an overkill. The advantage of a structure for term-wise quantities is that we can avoid using dicts by actually having two vectors (keys and values).

Let's keep the form factor discussion separate from this one as it's not user facing (and thus justifies other solutions).

[antoine-levitt]

How about not having the decomposition at all? Ie energy_hamiltonian returns the aggregate (the sum). Then we add energy_per_term(scfres) that recomputes the energies (should be pretty cheap) and does the pretty printing. Then, if we really feel the need, we add a stresses_per_term, or an option to stresses that gives the terms or something (I personally don't see the need, it's easy enough to hack in). There's not a lot of code to be factored there, so simplest is best...

[mfherbst]

Hmm. Ok for energy_hamiltonian, but for user facing functions (scf result, forces, stresses) we should have an intuitive way to get these terms in my opinion. Calling an extra separate function for this does not sound like a convenient solution to me given how often users from the application side are interested in this type of stuff.

What's the issue with just having a struct containing two vectors and a few support functions. We can probably settle down on something even simpler than Energies.

[antoine-levitt]

Feels like overengineering we're going to regret. What's wrong with having an extra function? I kind of like the way we have it now - we do an SCF, that computes an scfres that has the bare minimum, then whatever else you want to do you call an extra function.

[mfherbst]

Yes that I like, too. I fear though this leads to a combinatorial zoo of methods (energy terms, forces total, forces terms, stresses total, stresses terms, ...), which makes it in particular tricky for novice users to find what they want (unlike just navigating through what is stored in the scfres). In particular application users expect to quickly get an overview of the solution they found.

But of course one way out could be to have an endorsed "summary" function people should call on the scfres (which would become the default print function once the scfres is a struct on its own).