backflow to the g-orbitals

[Vladimir_Konjkov]

Hello Mike.

It seems to me that all remaining analytic derivatives except first three are right. All first three are wrong similar way.

Because g(4,0) = 3/8 * x^4 + 3/4 * x^2y^2 - 3 * x^2z^2 + 3/8 * y^4 - 3 * y^2z^2 + z^4 is symmetric upon x,y permutation, so dg(4,0)/dx + dg(4,0)/dy also should be but doesn't.

Code: Select all

     
     t11=threealpha*x4py4
     t12=zz*(24.d0+eightalphaz2)
     t13=6.d0*yy*(1.d0+fouralphaz2)
     t14=6.d0*xx*(alphay2+fouralphaz2-1.d0)
     t15=-0.25d0*(t11+t12-t13+t14)
     pgra(1)=x*t15
     pgra(2)=y*t15

dg(4,0)/dx + dg(4,0)/dy = (x+y)*t15 = (x+y) * -0.25d0*(t11+t12-t13+t14)

t11 - symmetric
t12 - symmetric
-t13+t14= - 6.d0*yy*(1.d0+fouralphaz2) + 6.d0*xx*(alphay2+fouralphaz2-1.d0) = 6.0*(xx*(alphay2+fouralphaz2-1.d0)-yy*(1.d0+fouralphaz2)) - not symmetric

same for dg(4,0)/dz.

Best Vladimir

[Vladimir_Konjkov]

I think that unit tests for gaussian WFN gradients, second derivatives and laplacians are strongly required and it is desirable to follow the DRY principle.

[Vladimir_Konjkov]

Hello Mike

Additionally try to change the next line from dg(4,0)/dx, dg(4,0)/dy, dg(4,0)/dz code:

t14=6.d0*xx*(alphay2+fouralphaz2-1.d0) to t14=6.d0*xx*(alphay2-fouralphaz2-1.d0)

This helps the 'g-ane' example to pass the the numerical check of the analytic derivatives test.

Best, Vladimir.

[Mike Towler]

Hi Vladimir,

OK - I've fixed the error in the way you suggest in the main distribution - it now passes the numerical derivative test. Thanks for pointing this out.

..it is desirable to follow the DRY principle.

Some guy tried to do that once to the Gaussian evaluators (he was talking about 'elegance' a lot) and he ended up making it significantly slower. The code repetition is there to avoid too many decisions in the middle of very frequently traversed loops.

In the gm2_bf SUBROUTINE evaluates the elements of the prim array in CASE of g-orbitals, it seems to me that in this function such calculations are not required.

Yeah, but :

(1) that part of the code can never be traversed, surely, as it is error trapped out:

Cannot use backflow with Gaussian basis functions of higher angular
momentum than f, as the required mixed second derivatives are not
implemented.

(2) The bit of code that is there is basically copied and pasted from gm2 in gauss_mol.f90, where the prim vector is in fact evaluated and then used to evaluate the Laplacian which doesn't require the mixed second derivatives. The thing that is not required there is ao_m(:) and indeed prim is not used to define this.

There should probably be a comment added to the g function parts of gm2_bf and gm3_bf pointing out that the full psderiv vector needs to be defined to make g functions work with backflow. Or someone should just code it up. Do you want to do this, or shall I?

Best wishes,
Mike

[Vladimir_Konjkov]

Hello Mike.

In the gm2_bf SUBROUTINE evaluates the elements of the prim array in CASE of g-orbitals, it seems to me that in this function such calculations are not required.

I apologize, I just automatically made the code review.

Some guy tried to do that once to the Gaussian evaluators (he was talking about 'elegance' a lot) and he ended up making it significantly slower.

Yes, I also wanted to improve significantly your inelegant code, and compiled profiling version that gave me 'empty' gmon.out, this discourages me and I limited myself to a minimal modification.

To be honest, I'm now run full electron calculation with multideterminant WF, which were obtained from QCHEM OD (Optimized Orbital Coupled Cluster Doubles).
I have postponed the use of backflow, that's in my opinion can't give a systematic improvement of the WF as multideterminant approach does.

But it would be interesting to implement some functionality in the program that I oftenly use.
I even read a short guide How to become a developer.

I'm used to working with git repository, creating a feather-branches, making code review. I hope you also do all this.

If you give me an access to CASINO repo I would make a feature-branch, commit some code for g function's backflow and create a merge request.
You should do a code review, tell me where I was wrong or merge my branch if it is correct.

Best, Vladimir.

[Vladimir_Konjkov]

Yes, I also wanted to improve significantly your inelegant code, and compiled profiling version that gave me 'empty' gmon.out.

FFLAGS_prof = -pg -no-pie fix generation of the gmon.out
Also mpif90 is the deprecated OpenMPI wrapper in favor of mpifort.

[Vladimir_Konjkov]

Hello Mike

I kept thinking about the elegance and the following thought came to me:
If one can convert an orbital basis in the MOLDEN file from GTO back to STO and keep MO coefficients intact, could he benefit from this in VMC & DMC calculations and
especially in the application of backflow procedure?

Best Vladimir.

[Vladimir_Konjkov]

Hello all


I looked through the code and noticed that in the file gauss_mol.f90 and in procedures gm2_screened, gm3_screened there was an old version of the pgra(27) and t14 local variables, while in the other three places it is commented and replaced with the correct one.

Best Vladimir