Skip to content

Matel enhancements and extra parallelizations

Matel enhancements and extra parallelizations

  • Re-design of matel tables and initialization strategy

    Previously, the matel tables were initialized as each element was first needed. In particular, most of the matrix elements were computed first in the nlefsm routine, which unfortunately had a large degree of redundancy when running in parallel.

    The matrix elements are now pre-computed in parallel, followed by a globalization of the data among all the MPI processes. The matel tables are initialized as needed: first the main tables, and the rest, if necessary, at the point just before they are needed (currently calls to 'optical', 'born_charge', 'ksv', or 'wannier').

    The data structures have been redesigned. The MATEL_t type tries to be a replica of the data in the old module, but removing the dimension associated with the various operations ('S', 'T', 'U', ...). Each operation is now handled by as many instances ("tables" with prefix tab_) of the MATEL_t type as are necessary.

    A wrapper routine matel_m::matel holds the logic to dispatch the right evaluators, while maintaining the calling sequence of the former new_matel.

  • Consolidation of parameters in spher_harm.f. Removal of allocations

    Define MAXL=10 at the top level. Make Y(:) and dydr(:,:) static arrays dimensioned to the maximum.

  • Extra parallelization over atoms in some routines

    Some routines (kinefsm, dnafsm, etc) perform loops over atoms. These loops can be distributed among different MPI ranks, and a final "reduce" operation performed at the end. The reductions use new "in place" versions of mpi_all_reduce.

Further optional work:

  • Add code to show the contents of the ylmk and matel tables. A simple version of this can be activated now by defining the pre-processor symbol SIESTA__MATEL_INIT_DEBUG.

  • Make sure that possible Lua-driven cases are treated correctly in the initialization. That is, check the conditions to initialize the "optical", "polarization", and "wannier" tables if the analysis stage is ever requested by means other than the fdf file (e.g., a Lua script).

  • Maybe eliminate the vna special case in the evaluation routine in matel_registry (factor of Y_00=1/sqrt(4*pi)).

  • Maybe use "object-oriented" techniques in matel_registry to handle radfuncs and trial_orbitals.

  • Add FORD documentation for the new suite of modules.

  • Add specific "unit tests"

Authors: Rogeli Grima and Alberto Garcia

Edited by Alberto Garcia

Merge request reports

Loading