Error: expected an XYZ geometry, not Zmat

[isolated-matrix]

Sorry, but I'm back again!

I don't know what might be the problem this time, because I have already run one test calculation without issues...

Basically, I'm using this input:

geometry = """
N
F 1 r2
F 1 r2 2 a3
F 1 r4 2 a4 3 d4

r2 = 1.39443
a3 = 101.23496
r4 = 2.11631
a4 = 98.49666
d4 = 259.51459
"""
optimize = false
charge = -1
step_size = 0.005
sleep_int = 2
job_limit = 30
chunk_size = 1
coord_type = "normal"
findiff = false
template = """memory,1,g
gthresh,energy=1.d-12,zero=1.d-22,oneint=1.d-22,twoint=1.d-22;
gthresh,optgrad=1.d-8,optstep=1.d-8;
nocompress;
ang
geometry={
{{.geom}}
basis={
default,cc-pVTZ-f12
}
set,charge={{.charge}}
set,spin=1
hf,accuracy=16,energy=1.0d-10
{CCSD(T)-F12,thrden=1.0d-12,thrvar=1.0d-10}
{optg,grms=1.d-8,srms=1.d-8}

pbqff=energy(2)
show[1,f20.12],pbqff"""
program = "molpro"
queue = "slurm"
check_int = 100

queue_template = """
xxxx

and, for some reason, following the (successful) completion of the reference calculation, pbqff crashes with the following error:

7.8 s reading ok, 0.0 s writing input, 0.0 s writing script, 0.3 s submitting, 1320.0 s sleeping, 0.0 s removing
total ref time: 1397.1 sec
thread 'main' panicked at /home/runner/work/pbqff/pbqff/src/coord_type/cart.rs:269:31:
expected an XYZ geometry, not Zmat
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

There's nothing obvious in my input that seems to indicate I want to use cartesian coordinates. My test job (water) ran to completion without issues. However, one thing that I did do in the water calculation was optimise the structure, which I have not done here. Could the error be because Molpro doesn't print out the geometry at the end of the single point energy calculation?

[zpalmer618]

This error occurs when you provide the .toml file with a z-matrix input while leaving optimize = false. So, the remedy here would be setting optimize = true, or optimizing the geometry separately and providing the .toml file with the Cartesian geometry. Hope this helps!

[isolated-matrix]

Ahhh, okay then. Does using cartesian coordinates increase the number of energies which need to be calculated, though?

[zpalmer618]

No, it just ensures that the first step of the pbqff computation is a reference energy calculation rather than a full blown geometry optimization. The only way that the total number of energies would change is if you changed your coord_type. This is what dictates how the molecules coordinates are defined, and, therefore, the number of points need to to calculate the QFF.

So, regardless of the geometry input, there is an initial computation that provides pbqff with the reference energy and the reference Cartesian coordinates of the molecule in question. Since you have coord_type = "normal", it will take the Cartesian coordinates from the initial computation and displace those coordinates following a normal coordinate scheme. If you changed it to coord_type = "cart", it would definitely change the number of overall energies needed to fill out the QFF, though. I hope that makes sense!

[ntBre]

Thanks @zpalmer618! The only thing I would add, which Zach so carefully avoided blaming me for, is that it's just an arbitrary limitation in pbqff that it can't take a Z-matrix for the geometry when optimize = false. I've been working on a Z-matrix to Cartesian conversion routine, but I haven't gotten it working yet. pbqff does all of its internal geometry manipulation in Cartesians, so it just wants a Cartesian geometry for the single-point energy phase. Most programs I've looked at make it pretty easy to get a Cartesian geometry from an optimization output but not always from a single-point, as you pointed out.

And yes, using Cartesian coordinates does increase the size of the hessian compared to using the Z-matrix internal coordinates directly, but using normal coordinates for the anharmonic portion of the QFF makes the difference pretty negligible in my experience, especially for larger molecules. But I actually hadn't considered trying to use the Z-matrix directly. pbqff does have support for fully-internal-coordinate QFFs, but it relies on symmetry-internal coordinates, which are a little different from the Z-matrix coordinates, typically, and much harder to write out. The normal coordinates allow you to compute only the semi-diagonal quartic force constants, so using Cartesians for the harmonic force field and deriving normal coordinates for the cubic and quartic force constants from that is usually the fastest way to go (as you're doing here with coord_type = normal).

I actually will still consider this a more immediate bug, though. It would be much nicer for a user for the calculation to abort immediately rather than having to wait until the reference calculation fails.

[isolated-matrix]

Ahhhh, I thought the coord_type was to tell pbqff which type of geometry you were giving it, and that it would follow that convention (i.e., if you wrote coord_type = normal and gave it cartesian coordinates, the calculation would fail).

I have looked into doing symmetry internal coordinates, but they sound pretty difficult to derive—I've not found any examples that have not involved matrix algebra, at least...

Don't worry too much about it though—it's not a bug, I just misunderstood! :)

[ntBre]

This was closed by my last PR. I'm still hoping to handle Z-matrices directly later, but that'll take long enough that I think bailing out before the reference energy calculation is all I can promise for now.