gjastrow and cutoffs

General discussion of the Cambridge quantum Monte Carlo code CASINO; how to install and setup; how to use it; what it does; applications.
Post Reply
Katharina Doblhoff
Posts: 84
Joined: Tue Jun 17, 2014 6:50 am

gjastrow and cutoffs

Post by Katharina Doblhoff »

In my dmc calculations, the presence of a Jastrow factor (gjastrow form) increases the computational time needed for one DMC step by about a factor 2.5. From this I conclude that the evaluation of the MOs plus the determinant update need a computational effort on the same order of magnitude as the computational effort needed for the evaluation of the Jastrow in my current setup. Within the time it takes to evaluate the Jastrow, it is the e-e-n terms that dominate. None of this I am particularly astonished about yet.

However, the time it takes to evaluate the e-e-n term does not seem to change when I change the e-n cutoff length in the e-e-n term. The same seems to hold true for the e-e term when changing the e-e cutoff. This sounds strange to me since I would have expected the computational effort to depend on the cutoff length of the basis. In the code, I can see that the jastrow is evaluated as (shown here for the e-e term)

Code: Select all

jas=jas+p*prod_cutoff_ee*prod_basis_ee
I think this explains why the evaluation time does not change with cutoff: It seems that prod_basis_ee and prod_cutoff_ee are always evaluated, even if prod_cutoff_ee is zero. Would it not be more efficient to check whether eevecs_scr(4,...), which seems to contain the distance between the two electrons, is larger than the cutoff before actually evaluating prod_basis_ee and prod_cutoff_ee? (Especially in very large supercells where the e-n cutoff might be much smaller than the supercell size?)

In general, I follow the principle: "The problem is always the user", i.e. me in this case. So as null hypothesis, I would assume that I am overlooking something and that this check is done somewhere, but the timing of my calculation does suggest that this is not the case.

Is there a good reason why this cannot be done? Am I overlooking something else or did I fully misunderstand something here?

Thanks and all the best,
Katharina
Pablo_Lopez_Rios
Posts: 53
Joined: Thu Jan 30, 2014 1:25 am

Re: gjastrow and cutoffs

Post by Pablo_Lopez_Rios »

Hi Katharina,

The value of the cutoff function is indeed checked before performing the product. A bit above the line you quote there is:

Code: Select all

if(ii==jj.or..not.nzeecut1(jj))cycle
where "nzeecut" means "non-zero electron-electron cutoff". The handling of the cutoff functions, including determining whether a cut-off is zero or not, occurs in the gbasis.f90 module.

Best,
Pablo
Hey there! I am using CASINO.
Katharina Doblhoff
Posts: 84
Joined: Tue Jun 17, 2014 6:50 am

Re: gjastrow and cutoffs

Post by Katharina Doblhoff »

Hi Pablo!

thank you for your reply! The cutoff is indeed checked here, but still

T(Jast only e-e term, large cutoff length) - Ts(no Jast) = T(Jast only e-e term, small cutoff length) - Ts(no Jast)

Since the number of electrons within the cutoff radius is proportional to rcut^3, I would expect a clear scaling with rcut.

Checking the cutoff only when computing the Jastrow is also not sufficient, I believe, since the function that computes the jastrow function uses the precomputed eebasis. If eebasis is constructed for all e-e pairs, independently of the cutoff value, then little is gained from the if statement when computing of the Jastrow itself.

If I am not mistaken, then eebasis is calculated in the function eval_gbasis_val, but this function does not check on the cutoffs (since they are actually only set once the cutoff function is called). So could it be that the fact that there is no speedup when rcut is reduced stems from the fact that eebasis is calculated for all e- pairs, even if it is then not used when constructing the Jastrow due to the if statement you pointed out?
Pablo_Lopez_Rios
Posts: 53
Joined: Thu Jan 30, 2014 1:25 am

Re: gjastrow and cutoffs

Post by Pablo_Lopez_Rios »

Hi Katharina,

One of the underlying ideas of the gjastrow implementation are that basis functions can be shared across terms, e.g., when the code evaluates an e-e, an e-n, and an e-e-n term, the required powers of rij and riI are evaluated only once. Therefore it is not straightforward to determine if a basis function is going to be used - it may be required for the e-e term but not for the e-e-n term.

Note that computing the basis functions scales as the square of system size (~ N^2 for e-e, N*N_nuc for e-n), while combining them scales quadratically at best (e.g., ~ N^2*N_nuc for e-e-n terms).

Best,
Pablo
Hey there! I am using CASINO.
Katharina Doblhoff
Posts: 84
Joined: Tue Jun 17, 2014 6:50 am

Re: gjastrow and cutoffs

Post by Katharina Doblhoff »

Hi Pablo!

Thank you for your explanation. So one could only get a speedup if both e-e term and e-e-n term had a small cutoff, right? And implementing that makes little sense since the e-e term should usually spread over the entire system and will usually also require the highest powers of r^n. Correct?
Pablo_Lopez_Rios
Posts: 53
Joined: Thu Jan 30, 2014 1:25 am

Re: gjastrow and cutoffs

Post by Pablo_Lopez_Rios »

Yup, and the leading order operation is the construction of the e-e-n term from e-e and e-n functions, so on paper the evaluation of the basis is not a significant contribution to the cost of evaluating the Jastrow factor (in practice things might be slightly different depending on the system, of course).

Pablo
Hey there! I am using CASINO.
Post Reply