search

JoshuaSBrown / QC_Tools

This small repository provides functionality for calculating the charge transfer integrals between two molecules.
MIT License
29 stars 14 forks source link

Problem in matrix multiplication for large molecule with 37 atoms #8

Closed dwaipayanroni closed 6 years ago

dwaipayanroni commented 6 years ago

My system has 37 atoms per molecule and I have done the Gaussian calculations with the following root line:

# b3lyp/6-311+g(d,p) scf=tight nosymm punch=mo iop(3/33=1) int=nobasistransform

I have got the error:

ERROR Matrix_Multiply only allowed for nxm by lxn matrices second matrix must have same number of colums as first matrix has number of rows

I noticed that my calculations for monomer result in 567 molecular orbitals with 574 atomic orbital coefficients and dimer calculation results in 1132 molecular orbitals with 1148 atomic orbital coefficients.

Is it the difference in no of molecular orbital and atomic orbital coefficient, the reason for the error? If that then how can I fix that or is there any other reason as well?

JoshuaSBrown commented 6 years ago

Yes, that would be the reason for the error. There might be a keyword you can use in gaussian so that it prints all the MOs. I would have to check.  It is likely that the high energy LUMO levels are simply excluded as they are not usually relevant, however they are for calc_J because they are used during the orthonormalization of the basis functions.  Joshua Brown University of Colorado  4001 Discovery DrRASEI N371 Boulder, CO 80303 

On Friday, June 22, 2018, 2:42:01 PM MDT, dwaipayanroni <notifications@github.com> wrote:

My system has 37 atoms per molecule and I have done the Gaussian calculations with the following root line:

b3lyp/6-311+g(d,p) scf=tight nosymm punch=mo iop(3/33=1) int=nobasistransform

I have got the error:

ERROR Matrix_Multiply only allowed for nxm by lxn matrices second matrix must have same number of colums as first matrix has number of rows

I noticed that my calculations for monomer result in 567 molecular orbitals with 574 atomic orbital coefficients and dimer calculation results in 1132 molecular orbitals with 1148 atomic orbital coefficients.

Is it the difference in no of molecular orbital and atomic orbital coefficient, the reason for the error? If that then how can I fix that or is there any other reason as well?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

dwaipayanroni commented 6 years ago

What is the reason for the error, is it the difference in no of molecular orbitals (here 567 for monomers and 1132 for dimer) and the no of atomic orbital coefficients (574 for monomers and 1148 for dimer) or is it the difference in the sum of the no of molecular orbitals of two monomers (here 567+567 = 1134) and the no of molecular orbitals present in dimer calculation (1132) (so the difference is 1134-1132 = 2)?

Which values should be same?

I have tried using the keyword pop=AllOrbital but got the same output as earlier and the prob still persists. Can you help me out, please?

JoshuaSBrown commented 6 years ago

Did you by chance get this working? You might try running with the pop=full keyword, this might print out everything instead of a select number of orbitals.  Joshua Brown University of Colorado  4001 Discovery DrRASEI N371 Boulder, CO 80303 

On Friday, June 22, 2018, 2:42:01 PM MDT, dwaipayanroni <notifications@github.com> wrote:

My system has 37 atoms per molecule and I have done the Gaussian calculations with the following root line:

b3lyp/6-311+g(d,p) scf=tight nosymm punch=mo iop(3/33=1) int=nobasistransform

I have got the error:

ERROR Matrix_Multiply only allowed for nxm by lxn matrices second matrix must have same number of colums as first matrix has number of rows

I noticed that my calculations for monomer result in 567 molecular orbitals with 574 atomic orbital coefficients and dimer calculation results in 1132 molecular orbitals with 1148 atomic orbital coefficients.

Is it the difference in no of molecular orbital and atomic orbital coefficient, the reason for the error? If that then how can I fix that or is there any other reason as well?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

dwaipayanroni commented 6 years ago

Yes, this is working.

The actual problem was with the difference between NBasis and NBsUse in the Gaussian output and this problem arose due to the use of diffuse basis set. The no of MOs is always equal to the NBsUse, and in some cases, to avoid the linear dependency problem caused by the diffuse basis set, Gaussian automatically makes the NBsUse(for my dimer 1132) less than NBasis(for my dimer, 1148) by eliminating linearly dependent basis functions. So by using a non-diffuse basis set like 6-311g, the code works correctly for my case. However for some other system like the one of 'ivorever' (uploaded in the issue 6) the use of diffuse basis set like 6-31g(d,p) does not make any problem, I don't know why!

I tried with pop=full also, but the outputs are same, it makes no changes in terms of no of MOs.

Ref:https://www.researchgate.net/post/Is_NBasis_and_no_of_Molecular_orbitals_in_a_Gaussian_calculation_need_to_be_same

JoshuaSBrown commented 6 years ago

Wow @dwaipayanroni that is a very informative discussion thanks for providing the link.

dwaipayanroni commented 6 years ago

Thanks@JoshuaSBrown for reading the discussion. As you noticed that my system and most of the systems face the same problem when diffused basis sets are used. But without using diffused basis sets it is hard to get good results. So can you please upgrade your code resolving this issue? I.e, where the difference between NBsUse and NBasis will not be a problem to have the transfer integral. I am also trying to write this code in python but if you could write it and make it user friendly and compilation friendly like the current one then it will be great.

JoshuaSBrown commented 6 years ago

Yes, I think I know what to do. The reason the the basis functions and the MO have thus far needed to be the same is because I have used lowden's approach to symmetrically orthonormalize the basis functions (using the vocabulary of the link, make them linearly independent). This operation required a square matrix. However, there are other schemes that can be used such as Graham Schmidt if the MO's and NBasis are not equal. I will try to get this fixed some time this next week.

dwaipayanroni commented 6 years ago

Thank you very much..

On Sat 7 Jul, 2018, 12:07 PM Joshua S Brown, notifications@github.com wrote:

Yes, I think I know what to do. The reason the the basis functions and the MO have thus far needed to be the same is because I have used lowden's approach to symmetrically orthonormalize the basis functions (using the vocabulary of the link, make them linearly independent). This operation required a square matrix. However, there are other schemes that can be used such as Graham Schmidt if the MO's and NBasis are not equal. I will try to get this fixed some time this next week.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JoshuaSBrown/QC_Tools/issues/8#issuecomment-403193096, or mute the thread https://github.com/notifications/unsubscribe-auth/AmoHjHC9IWmeu1PVsSZpoz-Zd6-Av0o7ks5uEFcVgaJpZM4U0Zax .

JoshuaSBrown commented 6 years ago

@dwaipayanroni Can you send me a copy of your input file so I can debug the problem?

dwaipayanroni commented 6 years ago

Here are my input files for monomers and dimer.

monomer1.txt monomer2.txt dimer.txt

JoshuaSBrown commented 6 years ago

This issue is fixed here: https://github.com/JoshuaSBrown/QC_Tools/pull/17 @dwaipayanroni for you files I got a Jeff of 0.00124623 eV let me know if you get the same.

dwaipayanroni commented 6 years ago

Hi Joshua,

I am extremely sorry that I could not reply to you these days as I was not well.

Thanks a lot for fixing the problem of the non-square matrix. Yes, I got the same result as you. But one problem is, the code can't perform the calculation if #p is used in the root line, i.e, #p b3lyp/6-311+g(d,p) scf=tight nosymm punch=mo iop(3/33=1) pop=full The error message is like that **Running calc_J VERSION 1.4 log file for first monomer is: ../../../DIPRO/CN/test/monomer1_new.log log file for second monomer is: ../../../DIPRO/CN/test/monomer2_new.log log file for dimer is: ../../../DIPRO/CN/test/dimer_new.log pun file for the first monomer is: ../../../DIPRO/CN/test/monomer1_new.pun pun file for the second monomer is: ../../../DIPRO/CN/test/monomer2_new.pun pun file for the dimer is: ../../../DIPRO/CN/test/dimer_new.pun

Dimer Spin Alpha Monomer 1 Spin Alpha Orbital HOMO Monomer 2 Spin Alpha Orbital HOMO J_ab 0.00238996 eV e_a -5.46086 eV e_b -6.14597 eV S_ab -0.00019708 J_eff 0.00124623 eV**

If 'p' is absent then it works fine.

JoshuaSBrown commented 6 years ago

@dwaipayanroni no problem glad you are feeling better, so I thought I had fixed the #p problem. What exactly is the error that you are getting now?

dwaipayanroni commented 6 years ago

If I use #p in the root line i.e, #p b3lyp/6-311+g(d,p) scf=tight nosymm punch=mo iop(3/33=1) pop=full then I am getting the error as:

Running calc_J VERSION 1.4 log file for first monomer is: ../../../DIPRO/CN/test/monomer1.log log file for second monomer is: ../../../DIPRO/CN/test/monomer2.log log file for dimer is: ../../../DIPRO/CN/test/dimer.log pun file for the first monomer is: ../../../DIPRO/CN/test/monomer1.pun pun file for the second monomer is: ../../../DIPRO/CN/test/monomer2.pun pun file for the dimer is: ../../../DIPRO/CN/test/dimer.pun

Dimer Spin Alpha Monomer 1 Spin Alpha Orbital HOMO Monomer 2 Spin Alpha Orbital HOMO WARNING unable to automatically line up basis functions of monomers with dimers, you better make sure they correctly line up or run the calculations again with the correct flag pop=full ERROR get_elem(int r, int c): row value larger than the scope of the Matrix

On Sat, Aug 4, 2018 at 9:50 AM, Joshua S Brown notifications@github.com wrote:

@dwaipayanroni https://github.com/dwaipayanroni so I thought I had fixed the #p problem. What exactly is the error that you are getting now?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JoshuaSBrown/QC_Tools/issues/8#issuecomment-410422236, or mute the thread https://github.com/notifications/unsubscribe-auth/AmoHjMp5Po5W9eruSxkckGKkTgBfJ1gRks5uNSEegaJpZM4U0Zax .

JoshuaSBrown commented 6 years ago

@dwaipayanroni so I'm having a little difficulty reproducing the error because I'm unable to get the dimer calculation to converge. Did you also have problems with this?

dwaipayanroni commented 6 years ago

No for this dimer I didn't face the convergence problem but for some other dimers, I faced that. So for them, I started with 6,311g basis set and saved the checkpoint file, and did a second calculation with 6-311+g(d,p) basis set reading the guess wavefunction from the saved checkpoint file using the 'guess=read' keyword.

On Wed, Aug 15, 2018 at 1:11 PM, Joshua S Brown notifications@github.com wrote:

@dwaipayanroni https://github.com/dwaipayanroni so I'm having a little difficulty reproducing the error because I'm unable to get the dimer calculation to converge. Did you also have problems with this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JoshuaSBrown/QC_Tools/issues/8#issuecomment-413119643, or mute the thread https://github.com/notifications/unsubscribe-auth/AmoHjM3OP0ayPbrXVddGnxBfTczkNdKNks5uQ9DEgaJpZM4U0Zax .

JoshuaSBrown commented 6 years ago

@dwaipayanroni do you by chance have any smaller systems that fail, and don't have convergence issues? :)

dwaipayanroni commented 6 years ago

@JoshuaSBrown No, I haven't any other smaller system right now, here I have attached the log file of the dimer system dimer_pun.txt dimer_log.txt.tar.gz

JoshuaSBrown commented 6 years ago

@dwaipayanroni I could be wrong but it does not look like your scf calculation converged. I think your calculation might have just run out of cycles? This might be the reason the calc_J is failing. The .log file is incomplete.

dwaipayanroni commented 6 years ago

@Joshua Sorry, I didn't check my log file. It was incomplete. You are right, with the log file having a normal termination, your code is working fine with #p in the root section. Thanks for your continuous reply :)

On Wed, Aug 22, 2018 at 9:19 AM, Joshua S Brown notifications@github.com wrote:

@dwaipayanroni https://github.com/dwaipayanroni I could be wrong but it does not look like your scf calculation converged. I think your calculation might have just run out of cycles? This might be the reason the calc_J is failing. The .log file is incomplete.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JoshuaSBrown/QC_Tools/issues/8#issuecomment-414901084, or mute the thread https://github.com/notifications/unsubscribe-auth/AmoHjPLRMWcGtY-vUm7fr_Bqh-Gy2Whbks5uTNTagaJpZM4U0Zax .

JoshuaSBrown commented 6 years ago

Great!

weiyu1234567 commented 1 year ago

I have done the Gaussian calculations with the following root line:

p b3lyp/6-311g(d) nosymm pop=full int=nobasistransform iop(3/33=1) punch=mo

I have got the error by version 1.9:

ERROR Matrix_Multiply only allowed for nxm by lxn matrices second matrix must have same number of colums as first matrix has number of rows Could you please help me to fix it?