Multiwfn official website: //www.umsyar.com/multiwfn. Multiwfn forum in Chinese: http://bbs.keinsci.com/wfn
You are not logged in.
Pages: 1
Thanks!
The file procgriddata.f90 has a current non-standard comparison between logicals that causes the following error with GFortran.
"Error: Logicals at (1) must be compared with .eqv. instead of =="
This currently prevents the build of https://github.com/digital-chemistry-la … -mac-build. It can be updated like this:
- write(10,*) count(cub_do==.true.)
+ write(10,*) count(cub_do .eqv. .true.)^M
I ran into some compilation issues with my CMake build script for the Mac build, due to the discrepancy between the module name of dislin in dislin_d.f90 ("dislin") and the imports in other files ("use dislin_d"). In your makefile, I believe this is currently obscured by the rule to create the mod-file dislin_d.mod from the source file dislin_d.f90:
dislin_d.mod : dislin_d.f90
$(FC) $(OPT) -c dislin_d.f90
For consistency and portability I would suggest to either:
1. Change the module name to "dislin_d"
2. Change the imports and the Makefile rule to use "dislin"
I have some trouble compiling the newest version of multiwfn with GFortran. I think "ifPBC" should be "PBCdir"
/Users/kjelljorner/Documents/GitHub/multiwfn-mac-build/cp2kmate.f90:353:16:
353 | if (ifPBC=="XYZ") then
| 1
Error: Operands of comparison operator '==' at (1) are INTEGER(4)/CHARACTER(3)
Many thanks for the fast reply. I have tried the recipe with "iuserfunc" and "uservar" and it seems to work perfectly.
I'm trying to calculate Hirshfeld weights for a user-specified point list. That corresponds to the options
5 -> 112 -> 1-num atoms -> 2 -> 100 -> name of input file -> name of output file
The computed weights for all points in the output file are zero. In the end I want to get the weights for individual atoms, but the sum of all atoms should be 1 for all points in space so it is a good diagnostic whether the algorithm works or not.
The same problem appears for the Becke weights.
I updated the build recipe to include the GUI: https://github.com/kjelljorner/multiwfn-mac-build
Many thanks to you - I was very happy to find Multiwfn when I started my PhD. I almost could not believe that so many things were implemented.
There also can be some interest to package Multiwfn with other package managers. I know conda-forge best, where it could be built for all operating systems. On Twitter I got a suggestion for that: https://twitter.com/ghutchis/status/1538140686029135872.
Currently I think the versioning would be the main problem to get it into the standard repository of any package. Multiwfn has an unclear version number, as 3.8dev changes often, while package manager maintainers want it to be more clear. I would suggest to have some type of date-based numbering: https://calver.org. There are some software that use this, for example RDKit: https://github.com/rdkit/rdkit/tags. Also, the licensing situation would need to be clarified a bit, as there is some LGPL code in Multiwfn.
Thanks for patching the source so quickly. I now removed the patch from GitHub as it is no longer needed. I set up an automated GitHub Actions that downloads your source code once per day and publishes it to a special branch of my repo: https://github.com/kjelljorner/multiwfn … ource_dist. The license file and settings.ini are taken from the binary distribution and is also included. This way, the user can always be assured that they have the latest code (+- one day) if they run "git pull". I also make a Homebrew "tap" so that the user can install Multiwfn with the homebrew package manager with minimal knowledge of how to compile a program: https://github.com/kjelljorner/homebrew-multiwfn. Here, the user can also update their version with "brew upgrade multiwfn". I hope this setup is OK for you
Thank you, your patch will be applied to next update of Multiwfn source code package.
Please note that in your patch "if (usern1/=-1) n2=usern2" should be "if (usern2/=-1) n2=usern2"
Are you sure about that? The current source code that I downloaded yesterday has the two lines (1913 and 1914). Is this a bug that will also be corrected in your source?
if (present(usern1).and.usern1/=-1) n1=usern1
if (present(usern2).and.usern1/=-1) n2=usern2
I created a minimal build recipe for Multiwfn on Mac using CMake and posted it on GitHub: https://github.com/kjelljorner/multiwfn-mac-build. Feedback or improvements appreciated. It seems to work reasonably well for me.
Additionally, I found that there is a line of non-compliant code on line 2090 of the file util.f90:
if ((.not.present(irewind)).or.(present(irewind).and.irewind==1)) rewind(fileid)
This apparently works with ifort, but does not work with GFortran. The reason is given here, http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html, and in short the compiler is free to evaluate the expressions in any order. GFortran then seems to evaluate irewind==1 and as it is not given, the program crashes. I refactored into:
if (.not. present(irewind)) then
rewind(fileid)
else
if (irewind==1) rewind(fileid)
end if
Edit: There's also a couple of other cases. I created a patch file here: https://github.com/kjelljorner/multiwfn … util.patch
Pages: 1