DLA implementation and speed

[zenandrea]

@ye-luo @prckent
I am testing the DLA implementation (from the develop version of Oct 1st, as v.3.8.0 does not implement it), and I am observing that DLA is around 20% slower than LA or TM.
This is quite unexpected, as DLA should perform a smaller number of operations than LA and TM, so it should be systematically faster.
Am I missing something?

By the way, I have seen that DLA works on the GPU implementation, so I could in principle use it in Summit.
However, I have noticed in
https://cdash.qmcpack.org/CDash/index.php?project=QMCPACK
that there are some failures in the tests of summit.olcf.ornl.gov/gcc6.4-Real-SoA-Release and on some other cluster (e.g. oxygen.ornl.gov) with CUDA-Release.
Thus, I wonder if it is save to use on summit the development version for DMC calculations with spline and DLA?

[prckent]

@ye-luo can comment on the speed vs LA or TM.

To use Summit with good efficiency will require the new batched drivers (e.g. #1947, done), various dependencies such as population control (e.g. #1819 ), plus updates for observables. We are targeting the new INCITE year for this and will check with you about exactly what you need first.

[ye-luo]

DLA should not significantly impact performance. However if it affects the random walking a lot and acceptance ratio is increased, the whole code can be slower.
The DLA doesn't work with the CUDA build. It should work with the new driver out of the box but the new driver code has not been fully optimized.

[prckent]

I think we can close this provided the results are correct and we are not doing any extra work (redundant wavefunction evaluations, ratios etc.).

OK to close @zenandrea ?

[zenandrea]

@prckent
I can crosscheck the outcomes of DLA with CASINO or QMCPACK. in order to see if results are correct.
Anyway, the DLA seems to run also with the CUDA build on summit.
If the results obtained are not to be trusted, maybe some check should stop the execution when DLA is used with CUDA.

[zenandrea]

@ye-luo @prckent
Would it be possible to have something written in output when DLA option is set?
(right now I do not see any difference if DLA is set to yes or no)

@jtkrogel
How can I tell nexus that I want to perform QMC calculations with DLA="yes"?

[jtkrogel]

@zenandrea
It was not supported in Nexus before, but I just made a PR adding it. See #2061.

[ye-luo]

@zenandrea We do print a line if DLA is enabled.

qmcpack/src/QMCHamiltonians/ECPotentialBuilder.cpp

Line 81 in 3e0b560

app_log() << " Using determinant localization approximation (DLA)" << std::endl;

What is your DLA input line?

[zenandrea]

@jtkrogel Fantastic, many thanks

@ye-luo Ah, now I see it. It is in the section of the ECP potential.
I am sorry, I was confused because in the dmc section the output writes Using Locality Approximation.

Just to know, does that mean that if I set DLA="yes" and T-moves (i.e., nonlocalmoves=v1 or v3) it does the tmove with the determinant only (which is what I called DLTM in the manuscript)?

[ye-luo]

@zenandrea In this case, "Using Locality Approximation" is a bit misleading. I need to think about how deliver more precise messages.

Just to know, does that mean that if I set DLA="yes" and T-moves (i.e., nonlocalmoves=v1 or v3) it does the tmove with the determinant only (which is what I called DLTM in the manuscript)?

Yes. DLA and T-move can work together. T-move uses T probability computed during NLPP calculation.