# Need help to run HOMO-LUMO calcualtion in psi4

Hi,
I am new to using PSI4 for the QM calculations. I started doing optimization and energy calculations and successfully able to run that. I am currently looking to calculate HOMO-LUMO calculations for small molecules. I got script from this forum and used it to run. Then I got an error which I pasted below:

Traceback (most recent call last):
File “C:\Users\Velan.conda\envs\psi4-env\Scripts\psi4-script.py”, line 337, in
exec(content)
File “”, line 40, in
File “C:\Users\Velan.conda\envs\psi4-env\lib\site-packages\psi4\driver\p4util\numpy_helper.py”, line 489, in _irrep_access
raise ValidationError(“Attempted to access by index/iteration a Psi4 data object that supports multiple”

psi4.driver.p4util.exceptions.ValidationError: Attempted to access by index/iteration a Psi4 data object that supports multiple irreps. Please use .np or .nph explicitly.

Printing out the relevant lines from the Psithon → Python processed input file:
“”“)
core.IO.set_default_namespace(”“)
core.set_global_option(“BASIS”, “6-31+g(d,p)”)
scf_e, scf_wfn = energy(“B3LYP/6-31+g(d,p)”, return_wfn=True)
→ HOMO = scf_wfn.epsilon_a_subset(“AO”, “ALL”)[scf_wfn.nalpha()]
LUMO = scf_wfn.epsilon_a_subset(“AO”, “ALL”)[scf_wfn.nalpha() + 1]
print(”\nThe HOMO - LUMO gap is %16.8f hartree" % (LUMO - HOMO))

!----------------------------------------------------------------------------------!
! !
! Attempted to access by index/iteration a Psi4 data object that supports !
! multiple irreps. Please use .np or .nph explicitly. !
! !
!----------------------------------------------------------------------------------

The input file I have used is below:
molecule {
0 1
C -3.36149391 -0.76945670 0.24637954
C -1.97984581 -0.94928857 0.09594355
C -1.15952779 0.14590121 -0.20664469
C -1.72085725 1.42092368 -0.35879230
C -3.10250484 1.60075623 -0.20835245
C -3.92282332 0.50556583 0.09423230
H -3.98782521 -1.60565879 0.47741023
H -1.55125815 -1.92279631 0.21211281
H -1.09452641 2.25712515 -0.58982646
H -3.53109232 2.57426422 -0.32452034
H -4.97774215 0.64287166 0.20909471
C 0.35876629 -0.05171694 -0.37196303
O 1.19582585 1.06582412 -0.68072392
H 1.95225965 0.76769049 -1.19113968
O 0.86281705 -1.19663533 -0.23534214

}
set basis 6-31+g(d,p)

scf_e, scf_wfn = energy(“B3LYP/6-31+g(d,p)”, return_wfn=True)

HOMO = scf_wfn.epsilon_a_subset(“AO”, “ALL”)[scf_wfn.nalpha()]
LUMO = scf_wfn.epsilon_a_subset(“AO”, “ALL”)[scf_wfn.nalpha() + 1]

print(“\nThe HOMO - LUMO gap is %16.8f hartree” % (LUMO - HOMO))

Can anyone help me in rectifying this?

Hi, I’m the developer who wrote the forum post you’re referring to. You forgot to include the .np part, which is the cause of the error.

In future, please link to the forum post you’re following, and enclose code snippets in triple backticks.

I also don’t understand why you’re running a gradient calculation and then an energy calculation.

Thank you for the response. After including the .np part, the calculation gets completed and I got the HOMO-LUMO gap. Thank you so much again.

When I run the HOMO - LUMO energy calculation with the above mentioned scripts without the gradient part of my input, it showed me an error like
“RuntimeError: Psi4 inputfile ba.in should have gradient() command.”
So, I have added this and run the calculation. With this, the calculation started running at least.

I have two more queries regarding this HOMO-LUMO energy calculation values. It would be a big help if you can address that.

1. In my above input, the last line
print(“\nThe HOMO - LUMO gap is %16.8f hartree” % (LUMO - HOMO))
What is the significance of %16.8f? What about the accuracy of the HOMO-LUMO gap value?

2. The output file of a geometry optimization includes the orbital energies of doubly occupied and virtual orbitals. Can we calculate HOMO-LUMO energy gap from this values or is it wrong?

What version of Psi4 are you using? (It should say this in the header of your output file, right before all the names.) There is nothing in the newest Psi4 that should raise that error. Is there another program calling Psi4 that may be raising that error?

This is a Python string format specifier. It says that the HOMO-LUMO gap is being printed to 8 decimal places. I would expect the HOMO-LUMO gaps to be correct to 8 decimal places in comparison to the exact values with the given functional, molecule, density-fitting approximation, DFT integration grid, and basis set. HOMO-LUMO is not a physical observable, so I cannot say it is accurate in comparison to experiment.

Yes. That’s exactly what the script is doing.

jmisiewicz,
Thank you for the response.

What version of Psi4 are you using? (It should say this in the header of your output file, right before all the names.) There is nothing in the newest Psi4 that should raise that error. Is there another program calling Psi4 that may be raising that error?
I am using Psi4 version 1. 7a1. dev3.

Yes. That’s exactly what the script is doing.
May I know the unit of the orbital energies given in the output files of the optimization calculation?
I have taken the unit as hartree and calculated HOMO-LUMO gap with that energies. And I have calculated the same using the script mentioned above for a HOMO-LUMO gap. It gives me a different value for the same molecule.

That won’t cause the “must have a gradient” error message. I need you to answer the other question: how are you running this script and calling psi4?

Hartrees, but…

…units have nothing to do with the problem. There was an indexing error in the old post. The HOMO needs scf_wfn.nalpha() - 1 and the LUMO needs scf_wfn.nalpha(). The original code correctly computed the gap between LUMO+1 and LUMO.

[quote=“jmisiewicz, post:6, topic:2555, full:true”]

That won’t cause the “must have a gradient” error message. I need you to answer the other question: how are you running this script and calling psi4?

I have the input file as .in file. I am using Psi4 through geometric in the following manner.
geometri-optimize --nt 8 --psi4 *.in

Then the error message is coming through geometric. That a geometry optimization program will check that you compute a gradient is not surprising.

A post was split to a new topic: How to run multiple computations