Multiwfn forum

skaler

Member

From: Kazan

Registered: Today

Posts: 1

Implementation of LIBRETA in PAEM calculations

First of all, I would like to express my sincere gratitude to Sobereva and all the contributors who have developed and maintained Multiwfn over the years. With its remarkable breadth of functions and analytical tools, it has been an open window into the world of quantum chemistry for me. Thank you very much for your efforts and dedication.

In our group, we often analyze the Potential Acting on an Electron in a Molecule (PAEM) and several related functions that rely on the Müller-approximated exchange potential. While performing such calculations in Multiwfn, I noticed that PAEM evaluation can be rather slow, with computational cost increasing significantly with the number of GTFs involved.

To better understand the performance aspects, I started exploring the source code and found that the current implementation of PAEM relies on the McMurchie–Davidson (MD) scheme. Later, while studying the Libreta library, I discovered that it implements a more optimized Obara–Saika (OS) recursive scheme and already includes many relevant integral routines—such as recurrence relations, screening, a block-type computation framework, and table-based Boys function evaluation—all of which seem highly relevant to PAEM-type calculations, particularly in evaluating the nuclear attraction integral matrix.

This led me to the idea of exploring whether Libreta could be extended and integrated into Multiwfn as a back-end for PAEM, and perhaps also for other exchange-potential-based functions recently developed by our group. In this regard I have a few questions:

1. Are there known limitations that would make a Libreta-based back-end for PAEM impractical within Multiwfn?

2. If so, are there coding/style or licensing requirements I should follow from the start?

3. I noticed ESP routines in function.f90 optimized for planes/grids. Should I develop grid-optimized versions of PAEM/exchange-based functions as well? What pitfalls should I expect (e.g., memory layout, cache behavior, screening thresholds, Boys table accuracy, or parallelization strategy)?

I’m currently at an early stage of studying Libreta’s structure and would greatly appreciate any guidance. I have been using Multiwfn for several years and would be glad to contribute if this direction seems meaningful.

For reference: recent paper by our group investigating the topology of the Muller-approximated exchange potential and force fields and its implications for understanding the chemical structure. DOI: 10.1039/d5cp00061k.

sobereva

Tian Lu (Multiwfn developer)

From: Beijing

Registered: 2017-09-11

Posts: 2,113

Website

Re: Implementation of LIBRETA in PAEM calculations

Hello,

Currently there are two forms of PAEM in Multiwfn, corresponding to user-defined functions 33 and 34. The source code is "real*8 function PAEM(x,y,z,itype)" in function.f90, user-defined functions 33 and 34 correspond to itype=1 and 2, respectively.

In the case of itype=1, the most expensive part is calling subroutine genGTFattmat to construct nuclear attraction potential integral matrix, which was written very early based on slow algorithm (similar to the oldest slow version of ESP code).

In the case of itype=2, ESP is directly evaluated, and can take advantage of libreta. (If you are using latest version of Multiwfn and evaluating PAEM in this way, from prompts on screen you will find libreta is automatically initialized before formal calculation)

It seems possible to significantly accelerate subroutine genGTFattmat by properly utilizing adapted code of libreta, but I haven't explored this.