From: Gumbart, JC (gumbart_at_physics.gatech.edu)
Date: Sat Apr 09 2022 - 20:40:03 CDT

Thanks for sharing the files. Unfortunately, I’m not sure what’s going on but it’s definitely something to do with ORCA. In the case of mon1, there are 89 internal coordinates and the hessian ORCA outputs also has 89 rows. But for mon2, there are 131 internal coordinates but ORCA only outputs 81 rows for the hessian, which sounds like it’s in cartesian coordinates (27 atoms * 3) rather than internal coordinates. I also noticed the files 33-mon1/2-hess_job2_internal.hess look slightly different; for example, the second file has this entry near the end while the first doesn’t: $dipole_derivatives. I wonder why that is?

I would start by ensuring your input files look the same. To be even more certain, copy-paste the atoms lines from your second input file into your first one and run again. Try to figure out what caused ORCA to output the hessian in cartesian rather than internal coordinates for the second molecule.

Best,
JC

> On Apr 7, 2022, at 9:34 AM, Gumbart, JC <gumbart_at_physics.gatech.edu> wrote:
>
> Hi Rahul,
>
> Can you send me your files off list with instructions of what you did to generate that error? I will try to reproduce it in order to track down the cause.
>
> Best,
> JC
>
>> On Apr 5, 2022, at 7:46 PM, Rahul Nikhar <rnikhar_at_udel.edu> wrote:
>>
>> Dear developers/users,
>>
>> I have successfully used ffTK for fitting intramonomer parameters for a small molecule (called mon1 which has 16 atoms). I used Orca 5.0.1 for my QM calculations.
>> Now, I have been trying to perform such a calculation for a slightly larger molecule (called mon2 which has 27 atoms), larger only when compared to mon1.
>> Since fitting parameters for mon1 was straightforward, I was surprised that I am facing issues for mon2.
>> When I tried to optimize bonds/angles, I got an error given at the end of the email.
>> I found a thread from 2014 from a simple google search where the developer (Christopher) solved such an issue for one of the users of ffTK.
>> As suggested in that thread, I checked if my calculation of Hessians was successfully completed.
>> This was even easy for my case, as I compared the output files of mon1 (successful run) against mon2.
>> It doesn't look like there is an issue with the calculation.
>> I checked the tcl file (fftk_QMORCA.tcl), which reads the information from the output file and determines whether the calculation was successful, and it seems okay.
>> All of the information searched ("FINAL ENERGY EVALUATION AT THE STATIONARY POINT", "THE OPTIMIZATION HAS CONVERGED") by $inLine are found in the output file.
>>
>> I am not sure how to debug this problem.
>> Any insight will be very much appreciated.
>>
>>
>> ERROR from ffTK
>>
>> ===================================================
>> can't use empty string as operand of "*"
>> can't use empty string as operand of "*"
>> while executing
>> "expr {($kc)*$h1up*$h2up}"
>> (procedure "::ForceFieldToolKit::BondAngleOpt::computePESqm" line 206)
>> invoked from within
>> "::ForceFieldToolKit::BondAngleOpt::computePESqm $hessLogID"
>> (procedure "::ForceFieldToolKit::BondAngleOpt::optimize" line 91)
>> invoked from within
>> "::ForceFieldToolKit::BondAngleOpt::optimize"
>> (procedure "::ForceFieldToolKit::gui::baoptRunOpt" line 40)
>> invoked from within
>> "::ForceFieldToolKit::gui::baoptRunOpt"
>> invoked from within
>> ".fftk_gui.hlf.nb.bondangleopt.runOpt invoke "
>> invoked from within
>> ".fftk_gui.hlf.nb.bondangleopt.runOpt instate !disabled { .fftk_gui.hlf.nb.bondangleopt.runOpt invoke } "
>> invoked from within
>> ".fftk_gui.hlf.nb.bondangleopt.runOpt instate pressed { .fftk_gui.hlf.nb.bondangleopt.runOpt state !pressed; .fftk_gui.hlf.nb.bondangleopt.runOpt insta..."
>> (command bound to event)
>> ===================================================
>>
>> Best,
>> Rahul
>>
>>
>