I tried upping the KMP_STACKSIZE to ~2Gb (export KMP_STACKSIZE=2000000000) in my .bashrc and my SysV memory should have been more than enough based on what's in the manual.

$ /sbin/sysctl -a|grep shmmax
[...]
kernel.shmmax = 18446744073692774399
[...]

However, the program kept segfaulting at the same point. Reading in of files only worked when I made the stacksize unlimited as per the manual (ulimit -s unlimited). For your information, I'm running Debian 8.7 (Jessie), ~24Gb RAM, i7-4770 CPU x 8 cores.

Thanks very much again for your help.

Hi Tian and perhaps others with some experience,

I have also tried using Orca output with MultiWfn and with regards some analyses I've tried, QTAIM for example, things seem to work okay. I am however having a couple of problems with the following:

- When converting from Orca .gbw to .wfn using orca_2aim, sometimes the .wfn makes the program crash, as stated at the time of crash. Does this happen often enough that there is no point using the Orca-generated .wfn? Is there any disadvantage to using the molden file generated by orca_2mkl, such as data not included which is in the .wfn or are they largely equivalent?...

Dear Corey Taylor,

I have tested your .molden file, the CDA module can run normally, I attached all outputs:
out.txt

Please make sure that you have set up your Linux environment according to Section 2.1.2 of the manual. The most common reason leading to segmentation fault is that under default setting, the stack memory that can be allocated for Multiwfn is too small.

Best wishes,

Tian

1 According my test, the latest version of Multiwfn is compatible with the .wfn file generated by ORCA 4.0. Please update both the programs to the latest version. If Multiwfn still crash, please upload the compressed .wfn file (or send it to me via E-mail if the file is large).

Anyway, I do not suggest using .wfn file generated by ORCA, there are many limitations. Using .molden file is always a better choices, since .molden file contains basis function information, much more functions of Multiwfn can be used if you use .molden file instead of .wfn file. (More information can be found in Section 2.5 of the manual)

2 If possible, could you please send me your .molden files along with ORCA input files (via my E-mail sobereva[at]sina.com)? I am not quite sure about the reason of the segmentation fault, I need to do test based on your input files.

Best regards,

Tian

I have also tried using Orca output with MultiWfn and with regards some analyses I've tried, QTAIM for example, things seem to work okay. I am however having a couple of problems with the following:

- When converting from Orca .gbw to .wfn using orca_2aim, sometimes the .wfn makes the program crash, as stated at the time of crash. Does this happen often enough that there is no point using the Orca-generated .wfn? Is there any disadvantage to using the molden file generated by orca_2mkl, such as data not included which is in the .wfn or are they largely equivalent?

- I tried invoking the CDA module with a pi-pi system as per the tutorial on 4.16 of the manual. I loaded the complex .molden file (again generated by orca_2mkl) and it was able to read it with seemingly no problem. It was also able to read the two 'fragments' and was seemingly processing them when the software segfaulted. Is this because there's a problem with the files themselves or data missing from an option in Orca I should have specified with the calculation or some other reason perhaps?

The output leading up to the crash looks like this:

16
 Citation of generalized CDA method used in Multiwfn and original CDA method
 GCDA: Meng Xiao, Tian Lu, Generalized Charge Decomposition Analysis (GCDA) Method, J. Adv. Phys. Chem., 4, 111-124 (2015), http://dx.doi.org/10.12677/JAPC.2015.44013
 CDA: Stefan Dapprich, Gernot Frenking, J. Phys. Chem., 99, 9352-9362 (1995)
 
 How many fragments do you want to define?  e.g. 2
2
 Loading... Please wait
 Alpha electrons:     87     Beta electrons:     87     Multiplicity:  1
 The number of atoms in complex:        47
 The number of basis functions in complex:       882

 Input Gaussian .fch file of fragment   1
/MD1_taylorc/Pim1/MD/3UMW/LiteratureLig/Snapshots/4MBL/03_26L/S4MBL_26L_opt_3.molden
 Alpha electrons:     39     Beta electrons:     39     Multiplicity:  1
 The number of basis functions in this fragment:       389
 The number of atoms in this fragment:        19

 Input Gaussian .fch file of fragment   2
/MD1_taylorc/Pim1/MD/3UMW/LiteratureLig/Snapshots/4MBL/02_Phe49/S4MBL_Phe49_opt.molden
 Alpha electrons:     48     Beta electrons:     48     Multiplicity:  1
 The number of basis functions in this fragment:       493
 The number of atoms in this fragment:        28

 Loading orbitals information for complex...
 Its orbital occupation numbers:
 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000
 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000
etc.
[...]

Loading orbitals information for fragment   1...
 Its orbital occupation numbers:
 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000
 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000
 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000
etc.
[...]

Loading orbitals information for fragment   2...
 Its orbital occupation numbers:
 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000
 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000
 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000 2.0000
etc.
[...]

Reloading S4MBL_complex_opt_4.molden
 
 Calculating, please wait...
Segmentation fault

Appreciate any insight you can offer, cheers all and cheers for creating a super useful program. Especially nice to implement aNCI!

Dear colleagues,
thank you for your replies. I'll try to use the latest versions of the above mentioned programs.
To Sobereva, I wrote "*.molden file cannot be properly recognized by Multiwfn" in the sense that the Multiwfn program opens such a file, but some type of analysis I performed yielded zero values. Alternatively, the Gaussian *.wfn file was treated properly (as it was in the manual).

Thank you again.

If wavefunction is loaded from the file, you will find brief summary of present wavefunction, such as the number of basis functions and orbitals. If these information are not shown, that means the file is treated as a plain text file, and thus no information is loaded, then it is very normal that many analyses give zero result.

Thank you again.

Dear Sobereva.

As it was stated in the manual  "the .wfn file generated by ORCA are usually non-standard and cannot be  properly recognized by Multiwfn. Therefore, using .molden file as input file of Multiwfn instead is highly recommended, see below", however, the *.molden file cannot be properly recognized by Multiwfn. Upon analyzing, it yields no information from this file. Alternatively, using Gaussian-made *.wfn, Multiwfn gives proper analysis.
So, could you resolve the problem with Orca-made *.wfn?

Hi,

Please first ensure that you are using the latest version of both ORCA and Multiwfn. At least, Multiwfn 3.5(dev) is completely compatible with the .molden file produced by ORCA 4.0.1.2.

I am not sure why "*.molden file cannot be properly recognized by Multiwfn". It is better to upload the compressed input file so that I can better figure out the reason. (If the file is larger than 5MB after compression, please send the file to my E-mail sobereva[at]sina.com).

For the latest version of Multiwfn, if the suffix of the molden input file is .molden or .molden.input, then the file will be recognized as molden input file and the wavefunction information will be loaded from it, and you can find brief description about present wavefunction on screen after loading finished. If the suffix is not recognized by Multiwfn, then no information will be loaded from the file and thus no analysis result will be finally yielded.

Also note that current version of Multiwfn is also compatible with the .wfn file generated by ORCA 4.0.x.

Best wishes,

Tian

Another way is that, when you want to get the wfn files by molden files, if the g-type functions haven't been obtained in the basis set you applied, the molden files are normalized. Then you can transform the molden files to wfn files by Multiwfn. Please read the 3.100.2 of Multiwfn manual. Other situations that, when the g-type functions have been obtained in the basis set you applied, the first thing you have to do is that using the Molden2AIM program to make the molden files be normalized. Then transform the molden files to wfn files by Multiwfn as you have just known.

best wishes
wawa

Please note that the latest version of Multiwfn has already been compatible with the .molden file containing g basis functions produced by ORCA

Dear Sobereva.

As it was stated in the manual  "the .wfn file generated by ORCA are usually non-standard and cannot be  properly recognized by Multiwfn. Therefore, using .molden file as input file of Multiwfn instead is highly recommended, see below", however, the *.molden file cannot be properly recognized by Multiwfn. Upon analyzing, it yields no information from this file. Alternatively, using Gaussian-made *.wfn, Multiwfn gives proper analysis.
So, could you resolve the problem with Orca-made *.wfn?

Dear foxterrier2005

The wfn files generated by ORCA are usually weird. So, if you query the accuracy of wfn files generated by ORCA, you may read the Appendix 5 of Multiwfn manual to check. If you find the answer is wrong, please try to use the Molden2AIM program (https://github.com/zorkzou/Molden2AIM) to make the wfn files generated by ORCA be standardized.

Another way is that, when you want to get the wfn files by molden files, if the g-type functions haven't been obtained in the basis set you applied, the molden files are normalized. Then you can transform the molden files to wfn files by Multiwfn. Please read the 3.100.2 of Multiwfn manual. Other situations that, when the g-type functions have been obtained in the basis set you applied, the first thing you have to do is that using the Molden2AIM program to make the molden files be normalized. Then transform the molden files to wfn files by Multiwfn as you have just known.

best wishes
wawa

As it was stated in the manual  "the .wfn file generated by ORCA are usually non-standard and cannot be  properly recognized by Multiwfn. Therefore, using .molden file as input file of Multiwfn instead is highly recommended, see below", however, the *.molden file cannot be properly recognized by Multiwfn. Upon analyzing, it yields no information from this file. Alternatively, using Gaussian-made *.wfn, Multiwfn gives proper analysis.
So, could you resolve the problem with Orca-made *.wfn?