Closed cortner closed 2 years ago
this should also fix #29
A simpler approach might be to
It feels like 3 can be done independently of the rest; so I will try to take care of #29 first.
this is done. next step sparsity the 1p basis.
still speaking to myself here ...
So the problem with removing the upper bound in the 1p basis is that then there is no simple way to generate and then sort the 1p basis functions. A workaround could be to just have the user specify maximum indices, maybe we just need to live with this?
Here is a specific case I'm currently struggling with : say we have an Rnl
basis, then what it its degree? It is not n + l
but rather just n
. Now when we generate the basis spec we need to generate all possible (n, l)
tuples. But there is no upper bound on l
just from the notion of degree. ouch.
So the current implementation will still keep an upper bound on the 1p basis components which must be user-specified. Then the basis is generated using that upper bound: 1p components -> product 1p -> pibasis -> symm. This is already a sparse basis, but it gets further sparsified by going backwards : clean pibasis -> clean product 1p basis -> clean 1p components. This is more than enough for now and we can keep it and start experimenting with sparsification.
This is closed by #110 as soon as we add some tests.
for growing the basis, we will open a new issue.
closed by #110
At the moment, the 1p basis components all have upper bounds on the degree. This restricts the product 1p basis and further then the many-body basis. In particular it makes it impossible to grow the basis in a systematic way.
So the goal is to remove this and other restrictions to allow the following reverse procedure:
All this requires a more flexible framework to set or adjust the basis spec. What makes it difficult is how the basis spec propagates the other way. This needs to be thought through carefully.