Molcas Forum

JakobS

Member

Registered: 2022-02-10

Posts: 5

Gradients along point charges

Dear all,

I'm attempting to compute gradients along point charges. Since Alaska does not permit to compute gradients along charges defined using the XFIELD keyword, I included point charges as normal atoms in the coordinates and assigned a basis set with zero basis functions and custom (non-integer) nuclear charge.

An example of such a basis set definition would be (Carbon with partial charge 0.5):

/C.ENV.chrg001.0s.0s.
Dummy basis set for atomic charges in environment
no ref 
 0.5 0
0 0
0

Doing so seems to work fine for a small number of charges (~100), but obviously required tweaking of the hard coded limits in "Molcas.fh" (mxAtom as well as Mxdbsc and MxShll) for larger point charge environments (~7000).
Initially, I was using the basis set label leaving the contraction info empty (i.e. /C.ENV.chrg001...) which omits reading in any exponents/contraction coefficients all together as it seems to set the maximum angular momentum to -1. However this, leads to a segmentation fault in Alaska, which is resolved by including the contraction info in the basis set label.

As far as I can see, those issues are related to the fact that the way basis set info is read and stored is not meant to be used with basis set definitions which include zero basis functions.
This makes me wonder if it is a safe "hack" to achieve what I want or if there is another standard way of computing gradients along point charge centres in Molcas?

Thanks for any help!

Jakob

Ignacio

Administrator

From: Uppsala

Registered: 2015-11-03

Posts: 1,031

Re: Gradients along point charges

Would it be enough to compute only the "frozen-density" gradient, i.e. the electric field times the charge?

JakobS

Member

Registered: 2022-02-10

Posts: 5

Re: Gradients along point charges

Hi Ignacio, thanks for the interesting suggestion. We need to compute gradients and also NACs for ground and excited states. I assume for the "frozen-density" gradients we would simply calculate the electric field at the point charge positions for each root and multiply by the charges. A similar work-around is not available for NACs, is it?

However, the route via Seward has the advantage that it is very practical, as it keeps atom ordering intact and does not require any post-processing. Also, the gradients/NACs along centres with no basis functions seem to come at essentially no extra cost and don't involve any extra approximations.
Are there any other concerns about this route apart from the fact that basis sets with no basis functions might lead to the kind of unexpected behaviour which I have described above?

Cheers,
Jakob

Ignacio

Administrator

From: Uppsala

Registered: 2015-11-03

Posts: 1,031

Re: Gradients along point charges

With the frozen-density approximation, the NACs would be zero, since by definition the wavefunction(s) won't change by moving the charges.

I don't think there's any fundamental problem with including the charges as "nuclei" with no basis functions, except that the code is obviously not optimized for that (including what you've already found). Something that may affect some results is that those fake nuclei have a mass too. It doesn't change the gradients, but it can change the center of mass (which is, I believe, the default origin for AngMom, for instance), the way internal coordinates are defined (if you're doing optimizations and not just single-point gradients), the harmonic frequencies, etc. Perhaps you can use X as the atomic symbol, or specify the mass with "Isotopes", if that's a problem.

Also, a workaround for the limitations in number of atoms, would be computing the gradients in batches, by including only a few of the external charges as nuclei in each batch. That would mean doing about 70 gradient calculations in your case, which is probably sub-optimal.

JakobS

Member

Registered: 2022-02-10

Posts: 5

Re: Gradients along point charges

Yes, that makes sense! Thanks for the clarification.
We'll watch out for those potential problems and proceed with increased limits. Performance hasn't been an issue so far.

Thanks again for the suggestions!