Multiwfn forum

Dear Tian Lu,

Thank you so much!

Unfortunately, using 100.19, that is not possible to construct promolecular density of different dimers without changing .wfn files.

I used that script for generating dimers with promolecular densities for comparing their densities with SCF-optimized densities (they are at H2p_*.wfn files).

for wfn in H2p_*.wfn;
do
  rm H0.5.wfn_001_0300_0434
  coord=`grep "(CENTRE  1)" $wfn | sed "s/ \+/ /g" | cut -d" " -f8`
  coord2=`echo "${coord} * 2" | bc -l`
  ADD=`echo "1000 10 48 6 31 0,0,-${coord} 1 32 0,0,${coord2} 1 1 -1 100 -5 1 ${wfn} 0" | tr " " "\n" | ./gMultiwfn H0.5.wfn 2>/dev/null | grep "Final result:" | sed "s/ \+/ /g" | cut -d" " -f4`
  echo "${wfn};${ADD}"
done

Probably, in the general case, I need a reader of XYZ-files and atomwfn directory for constructing promolecular densities for given XYZ's.

Best regards,
Igor

Dear Tian Lu,

I understand how to fix that part of the MultiWFN code for being it to work correctly (at least as I want).

I found a mistake with variable usage: center_tmp is not declared but used. The correct variable is ncenter_tmp.
There is a needed patch (works both for ifort and gfortran):
0001-center_tmp-is-not-declared.patch.txt

Best regards,
Igor

Dear Tian Lu,

Thank you so much! Now, it is working!

Best regards,
Igor

Dear Tian Lu,

While we tested a new code, we found that some basis sets lead to unreliable results while local Hartree-Fock energy is integrated over the whole space.

Here, the example .wfn where the problem is:
Al_large.wfn

At the same time, that .wfn have reliable energy:
Al_small.wfn

With binaries, provided in www.umsyar.com, we got the following energies:

$ echo "1000 2 999 100 4 100" | tr " " "\n" | ./Multiwfn Al_large.wfn 2>/dev/null | grep "Final result"
 Final result:                 NaN
$ echo "1000 2 999 100 4 100" | tr " " "\n" | ./Multiwfn Al_small.wfn 2>/dev/null | grep "Final result"
 Final result:      -18.0695836639

Best regards,
Igor

Dear Tian Lu,

Thank you so much!

Now, that is working!

Best regards,
Igor

Dear Tian Lu,

Thank you so much!

Unfortunately, I got SIGSEGV: Segmentation fault - invalid memory reference.

I will look what is the problem with my input file or with the implementation or with the compiler.

Best regards,
Igor

Dear Tian Lu,

Thank you!

I have one more patch for fixing build errors with gfortran:
0001-Fix-compilation-errors-with-gfortan.patch.txt

It should work both with ifort and gfortran. That should be the end.

One more patch adds gfortran-build-related files:
0002-Add-compilation-with-gfortran.patch.txt
Note:
1) It does not apply any optimization level
2) Only several features are tested*
3) openblas is used (can be changed manually to another BLAS/LAPACK implementation)
4) at noGUI_gfortran some additional sed-hacks are:

sed "s/directory=/file=/" *.f90 -i
sed "/kmp_[sg]et_stacksize_s/Id" Multiwfn.f90 -i
sed "/mkl_set_num_threads/Id" Multiwfn.f90 -i

*Tested features:
- Integration of rho, grad, lapl, G(r), some user-defined functions (not presented in the current build)
- Output of cube files
- Computation of functions along the line
- Reduced Density Functions

Do you have any non-manual tests of Multiwfn?

Best regards,
Igor

Dear Tian Lu,

Array initialization is described in 4.7 on page 67 in Fortran 2003 standard.

Mostly, MultiWFN uses R465 statement.

array-constructor is (/ ac-spec /)

where `ac-spec` is

ac-spec is  type-spec ::
        or [type-spec ::] ac-value-list

So, for MultiWFN, most popular declaration is (/ ac-value-list /)

Then, the standard says: If `type-spec` is omitted, each `ac-value` expression in the array constructor shall have the same length type parameters.

That is the reason why gfortran says a lot of errors in array initializations where parameters do not have the same lengths.

Another possible fix of gfortran compilation is provide `type-spec` in each array declaration, where errors are. For example (see also note 4.72):

clrtransname(0:18)*50=(/ character(len=50) :: "Rainbow & white/black for out-of-limit data","Rainbow","Reversed rainbow","Rainbow starting from white","Spectrum","Reversed Spectrum","Grey","Reversed Grey","Blue-White-Red",&
"Red-White-Blue","Blue-Green-Red","Red-Green-Blue","White-Dark red","Black-Orange-Yellow","White-Dark green","Black-Green","White-Dark blue","Black-Blue-Cyan","Viridis" /)

> Using .eqv. and .neqv. heavily contradicts my habit and it is evidently not as convenient as simply using == and !=

By the way,

if(alive==.true.)

can be rewritten as

if(alive)

That is acceptable by the standard. I hope, you will find it useful.

Best regards,
Igor

Dear Tian Lu,

I see that problem both in Ubuntu in WSL and in Fedora 34 with the source code package of MultiWFN 3.8(dev) from 31 January 2022.
I found that these files have specific charset:

$ file -i * | grep text/plain | grep iso
basin.f90:              text/plain; charset=iso-8859-1
excittrans.f90:         text/plain; charset=iso-8859-1
fuzzy.f90:              text/plain; charset=iso-8859-1
hyper_polar.f90:        text/plain; charset=iso-8859-1
otherfunc3.f90:         text/plain; charset=iso-8859-1
population.f90:         text/plain; charset=iso-8859-1
sub.f90:                text/plain; charset=iso-8859-1
topology.f90:           text/plain; charset=iso-8859-1
util.f90:               text/plain; charset=iso-8859-1

But this charset is wrong: the source code has other specific encodings. For example, util.f90 has GBK encoding.

I have attached a patch that changes encodings in problem files to universal UTF-8 charset.

0001-Use-UTF-8-charset.patch.txt

You could apply that using `patch < 0001-Use-UTF-8-charset.patch.txt` in the root directory of MultiWFN.

Best regards,
Igor