Page 2 of 2

Re: Changing decorr length in vmc for varmin_linjas and emin

Posted: Thu Sep 07, 2017 3:10 pm
by Ryan_Hunt
Katharina,

I don't think it should affect the calculations, however, that would assume no bugs. In my tests, if I manually set vmc_decorr_period to 3 (i.e. to the same as corper_default_vmc), and I repeat the tests from scratch, I find that correlation times agree (within uncertainties)....

Regards,
Ryan.

[next post deleted, Katharina was already keeping configs, postfit comments I made don't apply.]

Re: Changing decorr length in vmc for varmin_linjas and emin

Posted: Fri Sep 08, 2017 1:07 pm
by Katharina Doblhoff
To be honest: I would call a behaviour of a code that disregards my input a bug. It clearly does affect the calculations, since numbers and runtimes change!

Unfortunately, so far, I could not hunt the bug down.
Clearly, the difference between the two runs is solely the fact that the optimizable parameters are not set in the first run. Varmin linjas hence performs a first run where it disregards the Jastrow. (Naively, one might think that this is the same as using the parameters.0.casl, in which all optimizable parameters are set to 0. However, this is not true of course, because the Jastrow has fixed parameters due to the cusp conditions.)
However, I cannot find a statement that changes corper in dependence of use_jastrow or not_empty_jastrow.

What I do find, is the statement Ryan had pointed out: The resetting of corper if there are more vmc_nstep than vmc_configs_write. Here, I believe that there is indeed a bug:
In line 3151-3152 of vmc.f90, we have

Code: Select all

     corper=corper/nwrsteps
     if(mod(corper_default_opt,nwrsteps)>0)corper=corper+1
I think it should be

Code: Select all

     corper=corper/nwrsteps
     if(mod(corper,nwrsteps)>0)corper=corper+1
where I guess that the second line is there in order to round up instead of down in case of a non-integer result of the division. The statement as is, would only work if the old input style is used (which apparently existed at some time), since in monte_carlo.f90 we have on L661-662

Code: Select all

  corper=esdf_integer('corper',corper_default_opt)  !  (VMC for opt. or DMC)
  corper_default_opt=corper
For the new input, corper is set later, but corper_default_opt is not reset (see L1172):

Code: Select all

  corper=vmc_decorr_period
I do not see a good reason, why corper_default_opt is reset and I tend to change the code according to my suggestion. Any objections to this? Otherwise, I will keep it in mind and submit it as a pull request sooner or later.

As regarding the changing decorrelation, any hints are still welcome :-)

Re: Changing decorr length in vmc for varmin_linjas and emin

Posted: Fri Sep 08, 2017 1:12 pm
by Ryan_Hunt
Katharina,

I think you are correct. I'll make these changes and run my tests. I had spotted the oddity in line 661 of monte_carlo.f90 last night, intending to investigate further today. Unfortunately I haven't had time, but happily you seem to have done this detective work already.

Regards,
Ryan.

Re: Changing decorr length in vmc for varmin_linjas and emin

Posted: Fri Sep 08, 2017 1:39 pm
by Katharina Doblhoff
Hi Ryan!
Thanks! Good to know that we have the same opinion here.
Somebody must at some point have had a good reason for resetting the default value in L661. The corper_default _vmc is a parameter and is thus fixed. For sure there was a purpose behind freeing corper_default_opt. However, except for the strange line in vmc.f90 with the modulo, I cannot find a good reason for that. And the modulo clearly does not justify changing a default value...

However, this is clearly not the problem causing the strange behaviour observed earlier, since with vmc_nstep=250000, vmc_configs+write=100000 and vmc_decorrelation_period=24, we have nwrsteps=25 and corper=24. Thus corper_default_vmc is supposed to go to corper_default_vmc, which is 3.

Maybe CASINO tries to reoptimize corper somewhere?!
Best,
Katharina

Re: Changing decorr length in vmc for varmin_linjas and emin

Posted: Fri Sep 08, 2017 1:58 pm
by Ryan_Hunt
Katharina,

I have looked a little bit for those kind of statements, however, I think the problem is one specifically affecting the first vmc run when the runtype is 'vmc_opt'. Grepping about for "if" statements involving opt_cycle didn't lead me to anything that seems relevant, though...

If there are changes made to corper that lead to this issue, I think they will be found in conditional statements meeting the above suggestions (cycle one of vmc opt runs).

I will continue to look for possible problem sources which (I think) should manifest when both runtype='vmc_opt' and opt_cycle='1'.

Regards,
Ryan.

Edit: it's also possible the cases with opt_cycle>1 are the bugged ones. I'll do a plain vmc run shortly to check this.

Re: Changing decorr length in vmc for varmin_linjas and emin

Posted: Fri Sep 08, 2017 2:13 pm
by Katharina Doblhoff
Hi Ryan,
I believe that what you say is not necessarily true, since there are other flags that are only true in the first cycle and only true if the parameters in the jastrow are not present (the not_empty_jastrow and the use_jastrow).
opt_cycle=1, on the other hand, would be there in any run, independently of whether a jastrow is read. So I would be astonished to find the problem in an if with opt_cycle=1...
Best,
Katharina

Re: Changing decorr length in vmc for varmin_linjas and emin

Posted: Fri Sep 08, 2017 3:29 pm
by Katharina Doblhoff
Found the problem! And this is actually an issue!

OK, so, I had vmc_nstep=250000, vmc_configs_write=100000 and vmc_decorrelation_period=24.
Thus nwrsteps=2 and corper=24 (sorry, I had a mistake here in an earlier post)
Thus corper (or vmc_decorr_period) is reset to 24/2=12 in the first iteration. (actually to 13, due to the nonsense integer round up)
However, in the second iteration, CASINO pretends that I had wanted corper=13 and thus resets corper to 13/2+1=7
And so on.
Hence, samples used in the vmc optimization at high iterations may actually be correlated! (if corper gets too small!)
Best,
Katharina

Re: Changing decorr length in vmc for varmin_linjas and emin

Posted: Fri Sep 08, 2017 3:59 pm
by Ryan_Hunt
Katharina,

Ahhhhh! That (a) makes sense and is (b) obviously bad! Removing that pair of if statements should be safe for now. Perhaps in the long-term that block of code should be protected from re-executing, maybe by wrapping it in a conditional which is satisfied only for the first opt. cycle?

Perhaps it would also be worth writing something to an out file letting people know that their end results have been arrived at by a different means than they specified (currently the correlation period from the input file is printed in the out file, but obviously this is not the correlation period which has been used in the calculation).

Actually, maybe it is just worth removing this bit of code altogether..? Would people object to that?

Regards,
Ryan.

Re: Changing decorr length in vmc for varmin_linjas and emin

Posted: Fri Sep 08, 2017 5:36 pm
by Katharina Doblhoff
Hi Ryan!
To keep backward compatibility, I would not take the if statement out. Instead, I would make sure the code does what it is supposed to do. It is stated explicitly in the manual that the decorr period is adapted, such that write statements are separated by the decorr period if vmc_nconfigs_write is not zero.
It should be relatively easy to restore to the original corper after every iteration. I will look into it on Monday.
Have a nice weekend,
All the best,
Katharina

Re: Changing decorr length in vmc for varmin_linjas and emin

Posted: Fri Sep 29, 2017 12:50 pm
by Katharina Doblhoff
Fixed in v2.13.641 .
:-)