Refactor duplicated code in m_kern_exx_ subroutines

[tkoskela]

Based on our meeting with @lionelalexandre on April 12, we need to investigate how much we can reduce code duplication in the subroutines

CONQUEST-release/src/exx_kernel_default.f90

Line 921 in c00a071

subroutine m_kern_exx_cri(k_off, kpart, ib_nd_acc, ibaddr, nbnab, &

CONQUEST-release/src/exx_kernel_default.f90

Line 1268 in c00a071

subroutine m_kern_exx_eri(k_off, kpart, ib_nd_acc, ibaddr, nbnab, &

CONQUEST-release/src/exx_kernel_default.f90

Line 1649 in c00a071

subroutine m_kern_exx_eri_gto(k_off, kpart, ib_nd_acc, ibaddr, nbnab, &

CONQUEST-release/src/exx_kernel_default.f90

Line 2019 in c00a071

subroutine m_kern_exx_dummy(k_off, kpart, ib_nd_acc, ibaddr, nbnab, &

and do some refactoring before carrying on with the parallelisation work

[connoraird]

After comparing m_kern_exx_cri and m_kern_exx_eri, it does not look simple to reduce their duplication through refactoring. Many similar things are happening in both but the loop structures are different. For example in m_kern_exx_cri there is the loop do l = 1, nbnab(k_in_part) and inside this loop K_val and Phy_k are set before the loop is closed. However, in m_kern_exx_eri this same loop contains the setting of K_val as well as the rest of the kernel.

Further down the loop nest, the loop structure differs again. In m_kern_exx_cri there are two nested loops over kg%nsup and jb%nsup but in m_kern_exx_eri the loop is not nested and is only over jb%nsup.

[connoraird]

After comparing m_kern_exx_eri and m_kern_exx_eri_gto, the only differences seem to be that arrays are allocated in m_kern_exx_eri but not m_kern_exx_eri_gto and that m_kern_exx_eri_gto calls compute_eri_hoh at it's deepest point whereas m_kern_exx_eri calls exx_ewald_charge and exx_v_on_grid and performs calculations in a triple nested loop.

Therefore, it should be possible to reduce code duplication between these two kernels by first moving array allocations in m_kern_exx_eri outside of the duplicated region.

yes, this is correct ; I should have done this before...

[connoraird]

m_kern_exx_eri and m_kern_exx_dummy are also very similar with the main difference being that arrays are allocated at the beginning of m_kern_exx_dummy. Therefore, this can also likely be refactored to deduplicate code.

[lionelalexandre]

m_kern_exx_eri and m_kern_exx_dummy are also very similar with the main difference being that arrays are allocated at the beginning of m_kern_exx_dummy. Therefore, this can also likely be refactored to deduplicate code.

I am not sure but you will need to had a if statement in the nested loops. Can it be a problem ?

[lionelalexandre]

After comparing m_kern_exx_eri and m_kern_exx_eri_gto, the only differences seem to be that arrays are allocated in m_kern_exx_eri but not m_kern_exx_eri_gto and that m_kern_exx_eri_gto calls compute_eri_hoh at it's deepest point whereas m_kern_exx_eri calls exx_ewald_charge and exx_v_on_grid and performs calculations in a triple nested loop.

Therefore, it should be possible to reduce code duplication between these two kernels by first moving array allocations in m_kern_exx_eri outside of the duplicated region.

yes, this is correct ; I should have done this before...

[lionelalexandre]

After comparing m_kern_exx_cri and m_kern_exx_eri, it does not look simple to reduce their duplication through refactoring. Many similar things are happening in both but the loop structures are different. For example in m_kern_exx_cri there is the loop do l = 1, nbnab(k_in_part) and inside this loop K_val and Phy_k are set before the loop is closed. However, in m_kern_exx_eri this same loop contains the setting of K_val as well as the rest of the kernel.

Further down the loop nest, the loop structure differs again. In m_kern_exx_cri there are two nested loops over kg%nsup and jb%nsup but in m_kern_exx_eri the loop is not nested and is only over jb%nsup.

[connoraird]

I believe the code inside the do nsf2 = 1, jb%nsup loop is the same for m_kern_exx_cri and m_kern_exx_eri. Therefore, this should be able to be pulled out into a single subroutine.