Flexible penalty-based excited state algorithm

[victor11235]

I see Netket does not have an implementation of penalty-based excited state algorithm. As I needed to approximate low-lying excited states with RBM in a recent project, some of the code I have written may be of interest to Netket users.

The demo code compatible with Netket 3.9.2 can be found here: https://github.com/victor11235/Netket_excited_state/tree/master

More details of the algorithm can be found here (https://arxiv.org/abs/2307.03310), where the appendix also provides a short derivation of the gradient.

[gcarleo]

thank you, it is nice to see this application! would you consider doing a pull request to add this functionality? I think it is of enough general interest to be included in the main distribution. We should just make sure the interface is aligned with the rest (and maybe that for the overlap functions we use the "correct" estimators with low variance, but that is optional somehow)

[gcarleo]

Great, the overlap estimators are described here https://arxiv.org/abs/2305.14294, they are also already implemented in some repository of @alleSini99

[PhilipVinc]

For the overlap look here https://arxiv.org/pdf/2305.14294 and https://github.com/netket/netket_fidelity .

To get your code merged, I think the cleanest thing to do would be to do something similar to what was done in that repository and create a "operator-like" object whose expectation value and gradient match what you want.

In practice, the operator would be your $ H_n$ from Eq. 11 of your paper. Am I right in that if we implement an 'operator' like that it's all that is needed to use your algorithm?
If yes, all that is needed is a bit of reshuffling (you can follow a bit the operators of netket fidelity). You need to define an operator class that keeps inside a few extra things, such as the original hamiltonian and the additional parameters...
Then you just need to define the expect and grad functions and it can be used with the standard VMC driver.

[victor11235]

Thank you for the quick response!

@PhilipVinc: My current implementation uses modified expect_grad and vmc driver without any new 'operator' defined, this way I only need to add two new files. But yeah I will look into it and see which way would be the best!

[PhilipVinc]

That's entirely fine!
But for inclusion within NetKet, defining it as an operator object allows it to work well with the rest of our present (and future) APIs, and guarantee some level of homogeneity.

Another more self-contained example is the Reny2 entropy estimator we merged yesterday https://github.com/netket/netket/blob/master/netket/experimental/observable/renyi2/S2_operator.py

If you want, I can start a skeleton of the operator in the next few days and let you handle moving the logic to get the gradient other.

[victor11235]

Sounds good! I will get a fairly clean first version out and then explore the option using the operator framework.