Many-body solver computation time for larger system

Hylta

Hello,

currently I'm using the many-body solver to solve a quantum dot system with 2 electrons (with n_deg=2, and solver precision set to 1e-9).
I am trying to find the right choice of n_states where the solution converges. n_states=4 does not converge properly so the right choice is somewhere >=5. For n_states=5 the solver is still running relatively quickly on my machine with 64 cores, however n_single=6 takes pretty long.
For n_single=6, the calculation of the Colomb integrals still is quick (a few minutes or so) and -looking at the processor usage- well parallelized. However, once the integrals are finished, only one logical processor is used and the rest of the process takes rather long to finish (₁ day).
I assume that this is mainly the diagonalization of the Hamiltonian. I was wondering whether there is a way to reduce the computational time? Can I somehow use a parallelized version of a diagonalization algorithm?

fbeaudoin

@Hylta thank you very much for reaching out on our forum. This is an excellent and timely question.

It is intriguing to see that there is such a dramatic difference in computation time between n_states=5 and n_states=6, and this is clearly something that we should investigate.

To be clear : are you able to move forward in your projects with n_states=5 or do you absolutely need n_states=6 or even more?

In any case, we would like to try to reproduce this behavior on our end. If you have any material (scripts, .geo files or layouts) that may help us to do so, please feel free to share it with us.

We should get some developer time next week or so to start looking into this. On a longer term, we are also thinking of strategies to address systems with multiple electrons. It is important for us to get a sense of how much this is needed by our users to prioritize development.

Hylta

fbeaudoin
Thanks for your reply. I am also surprised by the big difference between the two.
Between n_states=5 and 6 there is still a difference of roughly 200µeV in the ground state, so it is not ideal but for now I think I'm fine with n_states=5.

The layout I'm using is your example file "lead_dot_lead.msh2" with scalingFactor of 1e-9 and GaAs eveywhere. Then I simply define the potential. To reproduce this, eg. use harmonic oszillators in y and z direction:
V_y = 5e-7 y² and V_z = 5e-5 z²
In x-direction I use a quartic potential
V_x = V₀ * ((x/x₀)⁴ - 2*(x/x₀)²), where x₀ ~ 1e-7 and V₀ ~ 5e-22.
Then I simply call:
"params_schrod = SolverParams(problem="schrodinger")
params_schrod.num_states = n_single
params_schrod.tol = solver_prec
ssol = Solver(dev, solver_params=params_schrod)
ssol.solve()
msol = ManyBodySolver(dev, num_states=n_single, n_degen=n_deg, precision=solver_prec)
msol.solve()"
(with solver_prec=1e-9 and n_single=n_states)

fbeaudoin

To be perfectly clear, parallelized diagonalization is not doable out of the box right now but should be doable in future versions; we will investigate this very soon.

fbeaudoin

Thanks a lot for the additional information @Hylta. I am glad to learn that n_states = 5 is somewhat fine, at least for a start. Regarding the behavior for n_states = 6, we will try to reproduce on our side ASAP and get back to you once we understand what is going on.

fbeaudoin

@Hylta, we think that we have identified the reason why the many-body solver slows down significantly for large n_states, and indeed this seems to be due to a part of the code that is not parallelized.
The good news is that we have some ideas that may significantly speed up the code.
We will be working on implementing these improvements in the next few weeks, and will keep you posted with our progress.
Thanks again for reporting this performance issue to us, this is very important feedback.

Hylta

fbeaudoin
Great, thanks. Im looking forward to the update 😉

fbeaudoin

@Hylta thanks a lot for staying tuned.
We are planning a release of QTCAD 1.0 sometime in September. If everything goes as planned the optimization/parallelization of the many-body solver should be part of the release. We are expecting very significant speed-ups.

Hylta

fbeaudoin
I saw that you released a version 1.0.4. Is the many-body solver optimization included there?

fbeaudoin

fbeaudoin Hylta version 1.0.4 is a simple bugfix related to the use of materials with different number of valence bands.

fbeaudoin

Hylta thanks a lot for staying so up to date with our versions! FYI, on the client portal, there is a link to the release notes document which explains what is new in each QTCAD version. Here is a link:
https://portal.nanoacademic.com/products/products/releasenotes/qtcad

fbeaudoin

@Hylta not yet, it will be coming with the next release which is planned on September 30th. Do you need the optimization before this?

Hylta

fbeaudoin Well it might be useful, since my license expires on September 30th.

ffehse

Hello Hylta , I'm one of the developers working on QTCAD.

I can report, that after a major refactor of the many-body solver, we were able to not only parallelize it, but also improve the performance drastically.
We created a calculation similar to yours and ran some benchmarks on our computer, see the figure below. The lines with triangles indicate the improved version, whereas the round symbols indicate the original version that you were using. The vertical axis shows the wall-clock time in seconds.

The following observations are in line with yours:
The Coulomb integrals (red lines) are calculated already in a parallel and optimized fashion.
The many-body solver takes exponentially increasing time with the number of single-particle states. However, as you observed, at n_states = 6, the total time reaches impractical levels and dominates the total run time.

The newly improved algorithm is, although still exponential in nature due to the physics involved, vastly faster and does not dominate the calculation time, even for n_states = 7 on our machine.

We hope you will be able to increase the number of states in your calculation as well after downloading QTCAD v1.1, which is scheduled to be released on September 30th.

fbeaudoin

@Hylta OK, we'll figure something out. Could you please email me at fbeaudoin@nanoacademic.com ?