Page 2 of 2

Re: backflow to the g-orbitals

Posted: Tue Dec 05, 2017 6:21 pm
by 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

Re: backflow to the g-orbitals

Posted: Mon Dec 11, 2017 4:10 am
by 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.

Re: backflow to the g-orbitals

Posted: Tue Jan 02, 2018 3:19 pm
by 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.

Re: backflow to the g-orbitals

Posted: Wed Jan 03, 2018 5:51 pm
by 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

Re: backflow to the g-orbitals

Posted: Thu Jan 04, 2018 9:21 am
by 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.

Re: backflow to the g-orbitals

Posted: Sat Jan 06, 2018 1:37 am
by Vladimir_Konjkov
Vladimir_Konjkov wrote: 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.

Re: backflow to the g-orbitals

Posted: Mon Mar 12, 2018 6:06 am
by 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.

Re: backflow to the g-orbitals

Posted: Sat Sep 22, 2018 5:22 am
by 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