Optimization is encountered with problem!

1

Dear developers,
I tried to optimize Benzene at B3LYP/def2-TZVP level. The input files is as follows:

memory 20 gb

molecule {
0 1
 C                 -1.59285705    0.48571428    0.00000000
 C                 -0.19769705    0.48571428    0.00000000
 C                  0.49984095    1.69346528    0.00000000
 C                 -0.19781305    2.90197428   -0.00119900
 C                 -1.59263805    2.90189628   -0.00167800
 C                 -2.29023905    1.69369028   -0.00068200
 H                 -2.14261605   -0.46660272    0.00045000
 H                  0.35181095   -0.46679872    0.00131500
 H                  1.59952095    1.69354528    0.00063400
 H                  0.35238695    3.85411728   -0.00125800
 H                 -2.14276005    3.85417728   -0.00263100
 H                 -3.38984305    1.69387328   -0.00086200 

}

set {
    basis def2-TZVP
    df_basis_scf  def2-TZVP-jkfit
    scf_type DF
    guess sad
    
}

optimize('b3lyp')

When PSI4 is called (psi4 0.dat 0.out -n 8) and after some seconds, the following errors are displayed:

saeed@Ubuntu-Lts:~$ psi4 0.dat 0.out -n 8
Traceback (most recent call last):
  File "/home/saeed/miniconda/bin/psi4", line 287, in <module>
    exec(content)
  File "<string>", line 40, in <module>
  File "/home/saeed/miniconda/lib//python3.6/site-packages/psi4/driver/driver.py", line 1052, in optimize
    G, wfn = gradient(lowername, return_wfn=True, molecule=moleculeclone, **kwargs)
  File "/home/saeed/miniconda/lib//python3.6/site-packages/psi4/driver/driver.py", line 691, in gradient
    wfn = procedures['gradient'][lowername](lowername, molecule=molecule, **kwargs)
  File "/home/saeed/miniconda/lib//python3.6/site-packages/psi4/driver/procrouting/proc.py", line 2064, in run_scf_gradient
    ref_wfn = run_scf(name, **kwargs)
  File "/home/saeed/miniconda/lib//python3.6/site-packages/psi4/driver/procrouting/proc.py", line 2002, in run_scf
    scf_wfn = scf_helper(name, post_scf=False, **kwargs)
  File "/home/saeed/miniconda/lib//python3.6/site-packages/psi4/driver/procrouting/proc.py", line 1289, in scf_helper
    old_wfn = core.Wavefunction.from_file(read_filename)
  File "/home/saeed/miniconda/lib//python3.6/site-packages/psi4/driver/p4util/python_helpers.py", line 156, in _core_wavefunction_from_file
    wfn_data = np.load(wfn_data).item()
  File "/home/saeed/miniconda/lib//python3.6/site-packages/numpy/lib/npyio.py", line 447, in load
    pickle_kwargs=pickle_kwargs)
  File "/home/saeed/miniconda/lib//python3.6/site-packages/numpy/lib/format.py", line 692, in read_array
    raise ValueError("Object arrays cannot be loaded when "

ValueError: Object arrays cannot be loaded when allow_pickle=False

Printing out the relevant lines from the Psithon --> Python processed input file:
    core.IO.set_default_namespace("")
    core.set_global_option("BASIS", "def2-TZVP")
    core.set_global_option("DF_BASIS_SCF", "def2-TZVP-jkfit")
    core.set_global_option("SCF_TYPE", "DF")
    core.set_global_option("GUESS", "sad")
--> optimize('b3lyp')

saeed@Ubuntu-Lts:~$

Please kindly let me know how this problem should be resolved.
Sincerely,
Saeed

2

Update your version of Psi4, and the problem will be fixed.

1 Like
3

Dear Jon,
Too many thanks but my version is 1.3.1. It should be updated!?

4

I go by Jonathon.

And yes, it should be updated to 1.3.2. Psi4 uses NumPy, and NumPy made a change to their code that broke Psi4 1.3.1, forcing us to release 1.3.2. The only changes between 1.3.1 and 1.3.2 are allowing us to work with NumPy again and also some changes to the NBO interface.

5

Dear Jonathon,
First, Excuse me!
Too many thanks for your nice recommendation. Now, I am going to update…
In addition, please kindly let me ask another question. Indeed, within frequency calculation, PSI4 does perform many “replacement”, e.g. 1 2 3 4 5 … which takes so long making PSI4 quite unsuitable for frequency calculations!
Is there any solution to prevent such so time-consuming task?

Sincerely yours,
Saeed

6

No worries.

The word is “displacement,” and there’s no solutions on your side. There are only two ways to compute frequencies: analytically or numerically. The numerical solution will necessarily involve many displacements. The analytical solution doesn’t have displacements and will still be longer than a single gradient, but not as long as all of the displacements. That would require some Psi4 developers programming RKS hessians. I do not think this is in our immediate plans, though I would love to be told otherwise.

1 Like
7

Dear Jonathon,
Many many thanks for your kindly attention.
I really hope you let me beneficial of your knowledge in future through direct messaging, if possible.

Yours,
Saeed

8

Oh, I did forget one important part. If you have access to multiple computers, there’s a feature in development that should let you distribute the individual gradients across them. @dgasmith would know more about that.

If the question has a chance of helping others, I’d prefer a forum topic. That way, others with the same question can see the answer as well. If it’s too specific for that to be possible, direct messaging is fine.

9

Dear Jonathon,
Yes, I use 8 Core processors but could not get your mean properly. Could you please guide me how can I accelerate frequency task via 8 cores? I used (psi4 input.dat output.dat -n 8). Is not it normally all cores for frequency task?

Saeed

10

I’m not talking about different cores on one machine, but multiple machines.

11

Yes,
You are quite right. Excuse me!

Saeed

12

We are working on DFT Hessians now and it may be ready for the 1.4 release this fall. Massively parallel finite difference computations are likely on the same time horizon.

1 Like
13

Dear Daniel,
Thank you so much.
This is a very promising news! I think “Gaussian” should be replaced by much faster codes such as PSI4 provided it becomes comprehensively complete and bugs are also fixed so soon.

Sincerely,
Saeed