Automation of DFT and QMC

General discussion of the Cambridge quantum Monte Carlo code CASINO; how to install and setup; how to use it; what it does; applications.

Automation of DFT and QMC

Postby Mariapia_Marchi » Thu May 29, 2014 12:44 pm

Dear all,
I don't know whether this is the most appropriate panel to post my question, or if I would have better chosen a more general one. Anyway, I will go on here!

Since one of the possible topics for this year QMC conference in the Apuan Alps is the following:
"it is intended to look into the better integration of DFT and QMC codes. In industrial applications, where users typically require ease-of-use and a graphical user interface, how can we move towards a situation where the user may do e.g. pre-screening of candidate structures with the faster DFT, then press a `Make the Answer Better button' which feeds the relevant wave function files into a QMC programme and spits out reliably accurate energetics for the selected problems",
I would like to present some examples of integration of QMC and DFT codes by exploting modeFRONTIER (one of the software products that we develop here at ESTECO, http://www.esteco.com) integration capabilities. Any suggestions about possible integrations of CASINO (for instance) and some DFT codes or wave function generation codes (if this makes sense) is welcome. My question is for non-commercial purposes, but just for the sake of the conference presentation and scientific purposes.

I will be able to perform runs on a linux virtual machine with 8 cores. Thus, I am afraid the system under examination should be "small"...

Looking forward to any feedback,
Mariapia
Mariapia_Marchi
 
Posts: 1
Joined: Fri May 09, 2014 10:59 am

Re: Automation of DFT and QMC

Postby Mike Towler » Wed Jun 04, 2014 8:43 am

Hi Mariapia,

Sorry for not responding to your post for a few days, but (a) I've been so busy you won't believe, and (b) I'm trying - in vain, obviously - to encourage other people to answer questions instead of me.. :)

As for integration of DFT and QMC codes, I think the main thing to do from the CASINO perspective is to make the QMC code easier to use. Now of course such a project is aimed at the sort of person who is unable to perform an action on a computer unless there is a little picture representing the action that he can click on. Such comments used to be a means of making fun of Windows users but these days it's actually fair enough, as it's what I do on my phone and my Android tablet. So this means - amongst other things:

(1) Not having a CASINO input file. All the usual input keywords and so on need to have sensible defaults that are either deducible from the DFT input or from being sensible/clever. I've been doing a bit of this recently, with stuff like `block_time' but there's clearly a lot of work still to do. Many keywords which are mainly for developers changing how the algorithm works should clearly be converted into internal parameters in a special module rather than continuing to be keywords, but in many other cases it's not obvious what the defaults should be.

(2) Things other than running a QMC calculation that are normally done by accompanying utilities, such as reblocking and plane-wave --> blip transformations need to be done automatically. I've just finished generalizing all the on-the-fly reblocking stuff (so that the reblock utility supplied with CASINO is now essentially redundant for normal VMC/DMC calculations) and at least one plane-wave code (PWSCF) can bypass all the hideous blip transformation stuff by generating a blip wave function file (formatted or binary) directly so that an intermediate plane-wave file never even exists.

(3) There needs to be a way of deciding when the calculation has finished other than 'specifying the number of moves then seeing if the error
bar is small enough and restarting if it isn't'. My private version of CASINO now has a new keyword 'stop_method' which can have
the value 'nstep' (which flags the previous behaviour), 'target_errorbar', or 'small_errorbar'. The latter two allow you to either 'keep running until a target error bar is attained and warn you if doing so will take longer than a reasonable amount of time' and 'keep going to make the error bar as small as possible in a reasonable amount of time'. There is another keyword to specify what you mean by 'reasonable amount of time'. This sounds like introducing lots of new keywords, but in fact these can be be given very sensible defaults and allow the calculation to proceed and complete automatically like the SCF part of a DFT calculation.

So some of this will be in the forthcoming CASINO 2.14 (and I know I've been promising this since March; it really should appear in the next few weeks) but some of it won't and there's clearly quite a bit of work to do to get sensible defaults for all keywords. I don't see why it can be done for CASINO 2.16 in early 2015 though..

One might also wonder about making CASINO into some sort of module that can be incorporated directly into other codes, or even incorporating a pet DFT code into CASINO. Lots of work/politics involved there.

Anyway, look forward to seeing you in Vallico again where we can discuss this (Saska is currently bouncing on my head and says 'Hi Mariapia!').

Cheers,
Mike
Mike Towler
 
Posts: 233
Joined: Thu May 30, 2013 11:03 pm
Location: Florence

Re: Automation of DFT and QMC

Postby Vladimir_Konjkov » Sun Jul 09, 2017 5:22 am

Hello, Mike.
I have found that CASINOHELP utility now knows about stop_method and target_error. But when I set stop_method to target_error and target_error to sufficiently large value for the statistics accumulation to take a small number of steps. I've got disappointment and statistics accumulation stops after 'nstep' as usual.

my input
Code: Select all
#-------------------#
# CASINO input file #
#-------------------#

# acetaldehyde molecule (ground state)

# SYSTEM
neu               : 12             #*! Number of up electrons (Integer)
ned               : 12             #*! Number of down electrons (Integer)
periodic          : F              #*! Periodic boundary conditions (Boolean)
atom_basis_type   : gaussian       #*! Basis set type (text)

# RUN
runtype           : vmc_dmc        #*! Type of calculation (Text)
newrun            : T              #*! New run or continue old (Boolean)
testrun           : F              #*! Test run flag (Boolean)

# VMC
vmc_equil_nstep   : 5000           #*! Number of equilibration steps (Integer)
vmc_nstep         : 1024           #*! Number of steps (Integer)
vmc_nblock        : 10             #*! Number of checkpoints (Integer)
vmc_nconfig_write : 1024           #*! Number of configs to write (Integer)
vmc_decorr_period : 0              #*! VMC decorrelation period (0 - auto)

# DMC
dmc_equil_nstep   : 1000           #*! Number of steps (Integer)
dmc_equil_nblock  : 1              #*! Number of checkpoints (Integer)
dmc_stats_nstep   : 50000          #*! Number of steps (Integer)
dmc_stats_nblock  : 50             #*! Number of checkpoints (Integer)
stop_method       : target_error   #*! How to terminate VMC/DMC run (String)
target_error      : 0.01           #*! Target error bar on the energy (Real)
dmc_target_weight : 1024.0         #*! Total target weight in DMC (Real)
dtdmc             : 0.00260        #*! DMC time step (Real)
use_tmove         : F              #*! Casula nl pp for DMC (Boolean)


# GENERAL PARAMETERS
use_gjastrow      : T              #*! Use a Jastrow function (Boolean)

# BLOCK INPUT


Vladimir.
In Soviet Russia Casino play you.
Vladimir_Konjkov
 
Posts: 116
Joined: Wed Apr 15, 2015 3:14 pm

Re: Automation of DFT and QMC

Postby Mike Towler » Sun Jul 09, 2017 1:07 pm

Hi Vladimir

Yes - I'm afraid the target_error stuff (or 95% of what I planned to implement) remains only in my private version.. The problem is that I lost my job just after implementing it and I've been able to do very little CASINO development work since then. You've probably noticed things have quietened down a lot recently..

It was quite a complex thing and it would take me quite a while to get back into it so I doubt it's going to get done any time soon. Sorry about that..!

I thought I'd put an error trap in to explain this but it seems not.. I'll do it..

Mike
Mike Towler
 
Posts: 233
Joined: Thu May 30, 2013 11:03 pm
Location: Florence

Re: Automation of DFT and QMC

Postby Vladimir_Konjkov » Mon Jul 10, 2017 4:43 pm

Hello Mike.

I believe that DMC strerr is not so difficult to predict and thus to estimate number of statistic accumulation steps required.

roughly stderr^2 = C * (HF energy - VMC energy) / (configurations * statistic accumulation time); where C ~ 1/4 for commonly used JASTROW.

Best, Vladimir.
In Soviet Russia Casino play you.
Vladimir_Konjkov
 
Posts: 116
Joined: Wed Apr 15, 2015 3:14 pm

Re: Automation of DFT and QMC

Postby Mike Towler » Mon Jul 10, 2017 9:19 pm

If only it were that simple..
Mike Towler
 
Posts: 233
Joined: Thu May 30, 2013 11:03 pm
Location: Florence

Re: Automation of DFT and QMC

Postby Vladimir_Konjkov » Fri Jul 14, 2017 4:10 am

It seems to me that if you perceive CASINO as an ordinary quantum chemical program, like GAUSSIAN or QCHEM, then the user would like to have a trial WFN on input and energy or another properties like forces with the desired accuracy on output after single run, using the calculation method that requires the shortest time. CASINO does not meet these criteria for now.
If you want to calculate a data set of more than hundreds of different molecules, this problem is most acute.
In Soviet Russia Casino play you.
Vladimir_Konjkov
 
Posts: 116
Joined: Wed Apr 15, 2015 3:14 pm

Re: Automation of DFT and QMC

Postby Roberto_Peverati » Sat Jun 16, 2018 12:23 pm

Hello Mike,
Sorry to reopen a quite old(-ish) post. Any info on the implementation of the target_error finish criterion?
Any chance we could have access even to a 95% completed code, to finish it up?

Thanks for the info...
Roberto_Peverati
 
Posts: 1
Joined: Sat Nov 19, 2016 5:46 pm


Return to The CASINO program

Who is online

Users browsing this forum: No registered users and 1 guest

cron