Dear All,
I'm playing around with CASINO to learn more about the method. One system I would like to try for a mini-project is a transition metal oxide like LiVO2.
This system is strongly correlated and there is significant interaction between d-orbitals on different sites to give orbital ordering. Vanilla DFT+U needless to say does not handle this well and even the crystal field splitting is not accounted for properly (equal occupancies for all t2g and eg levels). Controlling the occupancies with quantum espresso to give even an approximately correct wave function doesn't work.
So my question is will CASINO be able to use a trial wave function that is so far from the minimum to find the orbitally ordered ground state? I'm just trying to get a feel for how local minima are dealt with.
Best Wishes,
Chris Eames
UoBath, UK.
Low lying states in a transition metal oxide
-
Christopher_Eames
- Posts: 8
- Joined: Sun Dec 22, 2013 1:36 pm
-
Mike Towler
- Posts: 239
- Joined: Thu May 30, 2013 11:03 pm
- Location: Florence
- Contact:
Re: Low lying states in a transition metal oxide
Hi Chris,
OK, so you know that to do a diffusion Monte Carlo calculation you need to have a trial wave function produced by a preliminary HF/DFT run. For the DMC to give the right answer the nodal surface of the trial many-body wave function needs to be approximately correct (so that the 'fixed-node error' is small); in practice this means that you would like the HF/DFT calculation to give approximately the right charge density, and the DMC propagation in imaginary time can then be thought of as 'improving' the many-body wave function by effectively correcting the pair-correlation function so that (at least) the total energy comes out right.
So in your case if the DFT calculation is not giving the correct orbitally-ordered state, then the density is not right and your trial wave function probably won't be good enough. You therefore need to find a way to convince the DFT code to do this. If I was doing this -- and I'm aware that my answer will be unpopular with physicists because it uses the hated Gaussian basis sets -- I would use the CRYSTAL code (http://www.crystal.unito.it). This is a commercial code but as a UK academic you can have it for free. It has excellent links with CASINO for all versions from 1995 to 2009 (though they just released a new 2014 version a week or so ago; I'm working with the developers to add CASINO support for this - should be finished within a week to ten days).
CRYSTAL has excellent tools for encouraging the SCF to converge into different local minima (which work precisely because Gaussian basis sets have appropriate angular momentum dependence) and is very good for getting orbitally-ordered states. If you look at my paper "Oxygen stripes in La0.5Ca0.5MnO3 from ab initio calculations" Phys. Rev. Lett. 91, 227202 (2003) you'll see I was able to drive manganites into states with different orbital-ordering, spin-ordering, and charge-ordering (i.e. different charge states arranged into 'stripes'), which at the time I thought was very cool indeed. There's also my paper "Magnetic interactions and the co-operative Jahn-Teller effect in KCuF3" M. D. Towler, R. Dovesi and V.R. Saunders Phys. Rev. B 52, 10150 (1995) where - even though it's approximately cubic, the orbital ordering on the copper ions means the thing is a one-dimensional antiferromagnet. It also shows how to understand 'superexchange' in terms of the spin-polarization of the intervening F ions. I thought that was cool as well.
As for the 'strong correlation' problem, this is an issue caused by approximate XC functionals such as LDA/GGA not giving the correct orbital-dependent potential (one of the cases where the fact that the DFT eigenvalues strictly speaking have no meaning becomes important - influencing the SCF to give the wrong density). Perversely, because of course it does not account for 'correlation', the unrestricted Hartree-Fock method - which CRYSTAL can do - is ideal for this. In that case the exact exchange cancels out the self-interaction exactly and introduces the correct orbital dependence i.e. it distinguishes between 'different orbital exchange' ('J') and 'same orbital exchange = same-orbital Coulomb interaction' (approximately 'U') so there's no need to introduce U artificially as in the LDA+U method. See my paper "Ab initio study of NiO and MnO" M.D. Towler, N.L. Allan, N.M. Harrison, V.R. Saunders, W.C. Mackrodt and E. Aprà Phys. Rev. B 50, 5041 (1994). You may also have some success with exact-exchange or hybrid DFT methods, though I have less experience with this.
To be fair, I have no experience with making plane-wave DFT codes produce orbitally-ordered states. Clearly it's possible in some cases but you'll have to ask an expert.
It's interesting to note that a considerable number of many-body theorists have convinced themselves that first principles electronic structure methods can't do strongly-correlated materials like NiO because we use 'naive band theory' (this was the official position of the Cambridge University solid-state physics course at one point; it probably still is). They often imagine the U term in the Hubbard model or whatever is some magic thing that we cannot include except artificially - even though U is just an on-site Coulomb interaction and therefore part of the basic Hartree electron-electron term (strong correlation isn't 'correlation' in the sense of what is left out of HF theory or as in the phrase 'exchange-correlation functional' in DFT).. Almost all such statements turn out - incredibly - to be based on the assumption that we can't do spin-polarized band theory i.e. Mott's argument about a linear chain of H atoms always being a metal no matter what the lattice constant is only true if you force up and down spin orbitals to have the same energy, which of course no-one sane would actually do. If you do an unrestricted HF calculation of a linear hydrogen chain you can very easily see the metal-insulator transition at a lattice constant a little over 2 Angstrom and everything comes out perfectly (you can even calculate U almost exactly - with Hartree-Fock!).
Note finally that almost no-one has done DMC calculations of such things, and that you're likely to need a big computer to do so (QMC has a poor scaling with atomic number and calculations for heavier atoms are difficult; you will of course need to use pseudopotentials). That said, Lucas Wagner showed some very interesting QMC calculations of superconducting cuprates this summer at the annual QMC conference at my place in Tuscany (you can find his talk online on our website talk archive: http://vallico.net/casinoqmc/talk-archive/ )
Hope this helps, and sorry for the slight delay in responding (busy week).
Cheers,
Mike
OK, so you know that to do a diffusion Monte Carlo calculation you need to have a trial wave function produced by a preliminary HF/DFT run. For the DMC to give the right answer the nodal surface of the trial many-body wave function needs to be approximately correct (so that the 'fixed-node error' is small); in practice this means that you would like the HF/DFT calculation to give approximately the right charge density, and the DMC propagation in imaginary time can then be thought of as 'improving' the many-body wave function by effectively correcting the pair-correlation function so that (at least) the total energy comes out right.
So in your case if the DFT calculation is not giving the correct orbitally-ordered state, then the density is not right and your trial wave function probably won't be good enough. You therefore need to find a way to convince the DFT code to do this. If I was doing this -- and I'm aware that my answer will be unpopular with physicists because it uses the hated Gaussian basis sets -- I would use the CRYSTAL code (http://www.crystal.unito.it). This is a commercial code but as a UK academic you can have it for free. It has excellent links with CASINO for all versions from 1995 to 2009 (though they just released a new 2014 version a week or so ago; I'm working with the developers to add CASINO support for this - should be finished within a week to ten days).
CRYSTAL has excellent tools for encouraging the SCF to converge into different local minima (which work precisely because Gaussian basis sets have appropriate angular momentum dependence) and is very good for getting orbitally-ordered states. If you look at my paper "Oxygen stripes in La0.5Ca0.5MnO3 from ab initio calculations" Phys. Rev. Lett. 91, 227202 (2003) you'll see I was able to drive manganites into states with different orbital-ordering, spin-ordering, and charge-ordering (i.e. different charge states arranged into 'stripes'), which at the time I thought was very cool indeed. There's also my paper "Magnetic interactions and the co-operative Jahn-Teller effect in KCuF3" M. D. Towler, R. Dovesi and V.R. Saunders Phys. Rev. B 52, 10150 (1995) where - even though it's approximately cubic, the orbital ordering on the copper ions means the thing is a one-dimensional antiferromagnet. It also shows how to understand 'superexchange' in terms of the spin-polarization of the intervening F ions. I thought that was cool as well.
As for the 'strong correlation' problem, this is an issue caused by approximate XC functionals such as LDA/GGA not giving the correct orbital-dependent potential (one of the cases where the fact that the DFT eigenvalues strictly speaking have no meaning becomes important - influencing the SCF to give the wrong density). Perversely, because of course it does not account for 'correlation', the unrestricted Hartree-Fock method - which CRYSTAL can do - is ideal for this. In that case the exact exchange cancels out the self-interaction exactly and introduces the correct orbital dependence i.e. it distinguishes between 'different orbital exchange' ('J') and 'same orbital exchange = same-orbital Coulomb interaction' (approximately 'U') so there's no need to introduce U artificially as in the LDA+U method. See my paper "Ab initio study of NiO and MnO" M.D. Towler, N.L. Allan, N.M. Harrison, V.R. Saunders, W.C. Mackrodt and E. Aprà Phys. Rev. B 50, 5041 (1994). You may also have some success with exact-exchange or hybrid DFT methods, though I have less experience with this.
To be fair, I have no experience with making plane-wave DFT codes produce orbitally-ordered states. Clearly it's possible in some cases but you'll have to ask an expert.
It's interesting to note that a considerable number of many-body theorists have convinced themselves that first principles electronic structure methods can't do strongly-correlated materials like NiO because we use 'naive band theory' (this was the official position of the Cambridge University solid-state physics course at one point; it probably still is). They often imagine the U term in the Hubbard model or whatever is some magic thing that we cannot include except artificially - even though U is just an on-site Coulomb interaction and therefore part of the basic Hartree electron-electron term (strong correlation isn't 'correlation' in the sense of what is left out of HF theory or as in the phrase 'exchange-correlation functional' in DFT).. Almost all such statements turn out - incredibly - to be based on the assumption that we can't do spin-polarized band theory i.e. Mott's argument about a linear chain of H atoms always being a metal no matter what the lattice constant is only true if you force up and down spin orbitals to have the same energy, which of course no-one sane would actually do. If you do an unrestricted HF calculation of a linear hydrogen chain you can very easily see the metal-insulator transition at a lattice constant a little over 2 Angstrom and everything comes out perfectly (you can even calculate U almost exactly - with Hartree-Fock!).
Note finally that almost no-one has done DMC calculations of such things, and that you're likely to need a big computer to do so (QMC has a poor scaling with atomic number and calculations for heavier atoms are difficult; you will of course need to use pseudopotentials). That said, Lucas Wagner showed some very interesting QMC calculations of superconducting cuprates this summer at the annual QMC conference at my place in Tuscany (you can find his talk online on our website talk archive: http://vallico.net/casinoqmc/talk-archive/ )
Hope this helps, and sorry for the slight delay in responding (busy week).
Cheers,
Mike
-
Christopher_Eames
- Posts: 8
- Joined: Sun Dec 22, 2013 1:36 pm
Re: Low lying states in a transition metal oxide
Hi Mike
Thanks for taking the time to write such a great answer to my question.
I have tried CRYSTAL before for the control it offers as you mentioned but I always seemed to hit problems associated with the diffuse basis set 'exploding'.
We don't have any CRYSTAL experts here in Bath and developing a more robust basis set myself without any guidance put me off a bit.
Best Wishes
Chris.
Thanks for taking the time to write such a great answer to my question.
I have tried CRYSTAL before for the control it offers as you mentioned but I always seemed to hit problems associated with the diffuse basis set 'exploding'.
We don't have any CRYSTAL experts here in Bath and developing a more robust basis set myself without any guidance put me off a bit.
Best Wishes
Chris.
-
Mike Towler
- Posts: 239
- Joined: Thu May 30, 2013 11:03 pm
- Location: Florence
- Contact:
Re: Low lying states in a transition metal oxide
Hi Chris,
Yes, clearly you don't use molecular basis sets with diffuse functions in periodic systems, or CRYSTAL will go crazy (or at least take a very long time as the number of bielectronic integrals to do will go through the roof).
So, what you need is a really useful person who has optimized loads of Gaussian basis sets for use specifically in the solid-state. Well, ahem, er.. I have! See here:
http://www.tcm.phy.cam.ac.uk/~mdt26/crystal.html
The Li, V, and O basis sets there will do fine (I played with VO years ago). I don't maintain that page any more but it still has lots of useful stuff on it.
The CASINO distribution includes a couple of CRYSTAL optimizer scripts which will improve the basis sets for you - my ancient 'billy' script, and Pablo's more modern (and in principle better) 'opt_crystal'. Basically put a * symbol next to any number in the basis set that you want to optimize, and the scripts will run CRYSTAL multiple times to do this for you (Pablo's using fancy maths which sometimes doesn't work, and billy using boring but safe line minimization). If you send me your CRYSTAL input file for LiVO2 (and buy me a beer if we ever meet in person) then I'm happy to do this (it does take a bit of experience to know what to do).
Useful, aren't we..
M.
Yes, clearly you don't use molecular basis sets with diffuse functions in periodic systems, or CRYSTAL will go crazy (or at least take a very long time as the number of bielectronic integrals to do will go through the roof).
So, what you need is a really useful person who has optimized loads of Gaussian basis sets for use specifically in the solid-state. Well, ahem, er.. I have! See here:
http://www.tcm.phy.cam.ac.uk/~mdt26/crystal.html
The Li, V, and O basis sets there will do fine (I played with VO years ago). I don't maintain that page any more but it still has lots of useful stuff on it.
The CASINO distribution includes a couple of CRYSTAL optimizer scripts which will improve the basis sets for you - my ancient 'billy' script, and Pablo's more modern (and in principle better) 'opt_crystal'. Basically put a * symbol next to any number in the basis set that you want to optimize, and the scripts will run CRYSTAL multiple times to do this for you (Pablo's using fancy maths which sometimes doesn't work, and billy using boring but safe line minimization). If you send me your CRYSTAL input file for LiVO2 (and buy me a beer if we ever meet in person) then I'm happy to do this (it does take a bit of experience to know what to do).
Useful, aren't we..
M.
-
Christopher_Eames
- Posts: 8
- Joined: Sun Dec 22, 2013 1:36 pm
Re: Low lying states in a transition metal oxide
Hi Mike
This is very generous, above and beyond the call of duty etc. I will remember that pint if I come to the summer school (even though I am a Yorkshireman and tight with money).
The LiVO2 crystal input is below (with the dodgy basis set in it).
I was just reading about billy in the postscript document on your website - seems like a useful script to learn.
Many thanks and best wishes,
Chris.
This is very generous, above and beyond the call of duty etc. I will remember that pint if I come to the summer school (even though I am a Yorkshireman and tight with money).
The LiVO2 crystal input is below (with the dodgy basis set in it).
I was just reading about billy in the postscript document on your website - seems like a useful script to learn.
Many thanks and best wishes,
Chris.
Code: Select all
LiVO2
CRYSTAL
0 0 0
166
2.8373 14.7734
3
3 0. 0. 0.
23 0. 0. 0.5
8 0. 0. 0.2418
OPTGEOM
FULLOPTG
END
END
23 7
0 0 8 2. 1.
246297.0 0.000228
35328.3 0.001929
7524.86 0.0111
1969.96 0.0500
594.016 0.1699
205.385 0.3687
80.1571 0.4038
33.218 0.1440
0 1 6 8. 1.
611.206 -0.0058 0.0086
146.715 -0.0675 0.0607
48.724 -0.1278 0.2123
19.2296 0.2508 0.3966
8.1086 0.6301 0.4076
2.8353 0.2781 0.217
0 1 4 8. 1.
31.5966 0.0175 -0.0274
12.7943 -0.2515 -0.0928
5.1332 -0.9153 0.2146
2.2534 0.9818 1.5909
0 1 1 0. 1.
0.9655 1.0 1.0
0 1 1 0. 1.
0.4096 1.0 1.0
0 3 3 2. 1.
16.79 0.05975
4.372 0.26822
1.326 0.51315
0 3 1 0. 1.
0.3838 0.45636
8 5
0 0 8 2.0 1.0
8020.0 0.00108
1338.0 0.00804
255.4 0.05324
69.22 0.1681
23.90 0.3581
9.264 0.3855
3.851 0.1468
1.212 0.0728
0 1 4 6.0 1.0
49.43 -0.00883 0.00958
10.47 -0.0915 0.0696
3.235 -0.0402 0.2065
1.217 0.379 0.347
0 1 1 2.0 1.0
0.4520495 1.0 1.0
0 1 1 0.0 1.0
0.1678880 1.0 1.0
0 3 1 0.0 1.0
0.4509895 1.0
3 4
0 0 5 2. 1.
840.0 0.00264
217.5 0.00850
72.3 0.0335
19.66 0.1824
5.044 0.6379
0 1 1 0. 1.
1.478 1.0 1.0
0 1 1 0. 1.
0.479 1.0 1.0
0 3 1 0. 1.
0.600 1.
99 0
PRINT
END
DFT
SPIN
EXCHANGE
BECKE
CORRELAT
LYP
NONLOCAL
0.9 0.81
HYBRID
20
XLGRID
END
TOLINTEG
7 7 7 7 14
SCFDIR
SHRINK
8 8
FMIXING
60
LEVSHIFT
4 0
ATOMSPIN
1
2 1
SPINLOCK
2 10
TOLDEE
7
MAXCYCLE
400
PPAN
END-
Mike Towler
- Posts: 239
- Joined: Thu May 30, 2013 11:03 pm
- Location: Florence
- Contact:
Re: Low lying states in a transition metal oxide
Hi Chris,
OK - I'm just packing up our things in Vallico Sotto in Italy in readiness for a flight back to England tomorrow. I should be in a position to play with your input at the weekend - give me a few days.
M.
OK - I'm just packing up our things in Vallico Sotto in Italy in readiness for a flight back to England tomorrow. I should be in a position to play with your input at the weekend - give me a few days.
M.
-
Mike Towler
- Posts: 239
- Joined: Thu May 30, 2013 11:03 pm
- Location: Florence
- Contact:
Re: Low lying states in a transition metal oxide
Hi Chris,
OK - I've done the basis set optimization for LiVO2 now - sorry for the slight delay.
If I delete the OPTGEOM stuff at the top (I assume the geometry is approximately correct without being optimized) the file you posted gives a DFT energy of -1102.140897180 Ha with CRYSTAL09. My optimized file below gives -1102.146710855 Ha, a lowering of 0.006 Ha (and takes about 5 minutes to run - a few minutes slower than yours). So your original basis set wasn't disastrous, and nor were the functions particularly diffuse. What problems were you having with it, specifically? Did the geometry optimization actually work, and does it work now? (I haven't tried)
If you have any problems with it, let me know and I'll try to do a better job. I note that there's a strong tendency for it to become metallic (and for the SCF to fail completely) if you let the lithium basis in particular become too diffuse.
Also, I haven't looked into the details of LiVO2 at all, and I have no idea if it's entering the correct orbitally-ordered state or not - probably not (you may have to lower the symmetry and fiddle with EIGSHIFTing etc..) but the above should be a good starting point.
Best wishes,
Mike
OK - I've done the basis set optimization for LiVO2 now - sorry for the slight delay.
If I delete the OPTGEOM stuff at the top (I assume the geometry is approximately correct without being optimized) the file you posted gives a DFT energy of -1102.140897180 Ha with CRYSTAL09. My optimized file below gives -1102.146710855 Ha, a lowering of 0.006 Ha (and takes about 5 minutes to run - a few minutes slower than yours). So your original basis set wasn't disastrous, and nor were the functions particularly diffuse. What problems were you having with it, specifically? Did the geometry optimization actually work, and does it work now? (I haven't tried)
If you have any problems with it, let me know and I'll try to do a better job. I note that there's a strong tendency for it to become metallic (and for the SCF to fail completely) if you let the lithium basis in particular become too diffuse.
Also, I haven't looked into the details of LiVO2 at all, and I have no idea if it's entering the correct orbitally-ordered state or not - probably not (you may have to lower the symmetry and fiddle with EIGSHIFTing etc..) but the above should be a good starting point.
Best wishes,
Mike
Code: Select all
LiVO2
CRYSTAL
0 0 0
166
2.8373 14.7734
3
3 0.0 0.0 0.0
23 0.0 0.0 0.5
8 0.0 0.0 0.2418
END
23 9
0 0 8 2.0 1.0
246297.0 0.000228
35328.3 0.001929
7524.86 0.0111
1969.96 0.0500
594.016 0.1699
205.385 0.3687
80.1571 0.4038
33.218 0.1440
0 1 6 8.0 1.0
611.206 -0.0058 0.0086
146.715 -0.0675 0.0607
48.724 -0.1278 0.2123
19.2296 0.2508 0.3966
8.1086 0.6301 0.4076
2.8659 0.2781 0.217
0 1 4 8.0 1.0
31.5966 0.0175 -0.0274
12.7943 -0.2515 -0.0928
5.1332 -0.9153 0.2146
2.2801 0.9818 1.5909
0 1 1 0.0 1.0
0.9714 1.0 1.0
0 1 1 0. 1.
0.4023 1.0 1.0
0 3 1 2.0 1.0
16.87 1.0
0 3 1 0.0 1.0
4.4378 1.0
0 3 1 0.0 1.0
1.3745 1.0
0 3 1 0. 1.
0.4275 1.0
8 5
0 0 8 2.0 1.0
8020.0 0.00108
1338.0 0.00804
255.4 0.05324
69.22 0.1681
23.90 0.3581
9.264 0.3855
3.851 0.1468
1.2304 0.0728
0 1 4 6.0 1.0
49.43 -0.00883 0.00958
10.47 -0.0915 0.0696
3.235 -0.0402 0.2065
1.217 0.379 0.347
0 1 1 2.0 1.0
0.4787 1.0 1.0
0 1 1 0.0 1.0
0.2234 1.0 1.0
0 3 1 0.0 1.0
0.2613 1.0
3 5
0 0 5 2.0 1.0
840.0 0.00264
217.5 0.00850
72.3 0.0335
19.66 0.1824
5.044 0.6379
0 1 1 0.0 1.0
1.4707 1.0 1.0
0 1 1 0.0 1.0
0.4307 1.0 1.0
0 1 1 0.0 1.0
0.172 1.0 1.0
0 3 1 0.0 1.0
0.32 1.0
99 0
PRINT
END
DFT
SPIN
EXCHANGE
BECKE
CORRELAT
LYP
NONLOCAL
0.9 0.81
HYBRID
20
XLGRID
END
TOLINTEG
7 6 7 7 14
SCFDIR
SHRINK
8 16
FMIXING
35
LEVSHIFT
6 0
ATOMSPIN
1
2 1
SPINLOCK
2 10
TOLDEE
7
MAXCYCLE
100
END-
Mike Towler
- Posts: 239
- Joined: Thu May 30, 2013 11:03 pm
- Location: Florence
- Contact:
Re: Low lying states in a transition metal oxide
Hi Chris,
By the way, I spent a little time earlier in the week trying to get the newly released CRYSTAL14 to communicate with CASINO. The results were not encouraging; they have a defined interface (API) for external codes - and the idea of this is that it should remain consistent as CRYSTAL evolves - but sadly they seem to change/break it with every new release.
So the last three excerpts from the CASINO DIARY file are below; the practical upshot of this is that the tools provided with the current beta CASINO distribution all now work according to the last published specifications, but that CRYSTAL14 doesn't seem to - and the CRYSTAL-->CASINO converter therefore doesn't work. I can't check what the problem is because the routine documenting the interface - which the manual claims is provided on the website - isn't. I sent the CRYSTAL support people an email last weekend. Hopefully they'll reply to it soon.
In the meantime, if you want to generate a gwfn.data file for use with CASINO, use the -09 command line flag with all CASINO-provided CRYSTAL tools to run the previous CRYSTAL09 version if you have it.
it's quite funny that the CRYSTAL people insist on only using MP2 perturbation theory if they go beyond the Hartree-Fock level (this is what their CRYSCOR code - a sort of extension to CRYSTAL - does) and they remain completely determined never to use QMC. Even though it is - of course - far superior to MP2!
Of the CRYSTAL authors Mauro Causa of Napoli University - who has posted on these forums - is an honourable exception and I know he likes playing with CASINO. Perhaps he can help me with fixing the interface..?
M.
By the way, I spent a little time earlier in the week trying to get the newly released CRYSTAL14 to communicate with CASINO. The results were not encouraging; they have a defined interface (API) for external codes - and the idea of this is that it should remain consistent as CRYSTAL evolves - but sadly they seem to change/break it with every new release.
So the last three excerpts from the CASINO DIARY file are below; the practical upshot of this is that the tools provided with the current beta CASINO distribution all now work according to the last published specifications, but that CRYSTAL14 doesn't seem to - and the CRYSTAL-->CASINO converter therefore doesn't work. I can't check what the problem is because the routine documenting the interface - which the manual claims is provided on the website - isn't. I sent the CRYSTAL support people an email last weekend. Hopefully they'll reply to it soon.
In the meantime, if you want to generate a gwfn.data file for use with CASINO, use the -09 command line flag with all CASINO-provided CRYSTAL tools to run the previous CRYSTAL09 version if you have it.
it's quite funny that the CRYSTAL people insist on only using MP2 perturbation theory if they go beyond the Hartree-Fock level (this is what their CRYSCOR code - a sort of extension to CRYSTAL - does) and they remain completely determined never to use QMC. Even though it is - of course - far superior to MP2!
Of the CRYSTAL authors Mauro Causa of Napoli University - who has posted on these forums - is an honourable exception and I know he likes playing with CASINO. Perhaps he can help me with fixing the interface..?M.
Code: Select all
---[v2.13.248]---
* Updated the opt_crystal script to handle CRYSTAL14.
-- Mike Towler, 2014-01-13
---[v2.13.247]---
* Updated the billy basis set optimizer to handle CRYSTAL14.
-- Mike Towler, 2014-01-13
---[v2.13.246]---
* Modified the CRYSTAL run script 'runcrystal' to support the newly released
CRYSTAL14 (it continues to be able to run all previous versions). Also added
a CRYSTAL-->CASINO converter 'crysgen14' based on the standard documented
API. However, note that this *does not work* - thus either there is an error
in CRYSTAL14 or the API has changed without anyone being told. The manual
claims that there is a cryapi_inp.f routine available on the website which
documents the current API; however this is not the case (at least as far as I
can see). I have emailed the CRYSTAL support people about this but have yet
to receive a response. I include this stuff in the CASINO distribution anyway
so developers can play with it. If you wish to use CRYSTAL for production
purposes using the current CASINO tools, then you should use the previous
CRYSTAL09 version, which you can do by including '-09' as a command line
argument to the runcrystal script.
-- Mike Towler, 2014-01-13
-
Christopher_Eames
- Posts: 8
- Joined: Sun Dec 22, 2013 1:36 pm
Re: Low lying states in a transition metal oxide
Dear Mike
Thankyou very much for taking a look at my basis set - it's reassuring that it wasn't too far off. Now I have more confidence in the basis set I will try again to optimise the structure and drive it into the orbitally ordered state.
If I can generate a good starting basis from CRYSTAL I will have a go with CASINO. I'm pretty sure that I can get some time on ARCHER for this purpose via the Materials Chemistry Consortium - they are very keen on calculations that exploit the parallelism. My only concern is whether I can get the statistics of the DMC calculation completed in the 24hour slot. An alternative is our in-house 48 core machine which I could block book for 6 months if necessary - again I have no idea how satisfactory this would be.
As you know there are many examples where DFT utterly fails. There are three computational chemistry groups here in Bath who would be very interested in using the method for certain systems if I can just get a good example that shows the merits.
All the best
Chris.
Thankyou very much for taking a look at my basis set - it's reassuring that it wasn't too far off. Now I have more confidence in the basis set I will try again to optimise the structure and drive it into the orbitally ordered state.
If I can generate a good starting basis from CRYSTAL I will have a go with CASINO. I'm pretty sure that I can get some time on ARCHER for this purpose via the Materials Chemistry Consortium - they are very keen on calculations that exploit the parallelism. My only concern is whether I can get the statistics of the DMC calculation completed in the 24hour slot. An alternative is our in-house 48 core machine which I could block book for 6 months if necessary - again I have no idea how satisfactory this would be.
As you know there are many examples where DFT utterly fails. There are three computational chemistry groups here in Bath who would be very interested in using the method for certain systems if I can just get a good example that shows the merits.
All the best
Chris.
-
Mike Towler
- Posts: 239
- Joined: Thu May 30, 2013 11:03 pm
- Location: Florence
- Contact:
Re: Low lying states in a transition metal oxide
Glad to be of service. Your basis wasn't too far off (presumably you got them off the Torino site?) but it did give rise to calculations which were pretty unstable; I would definitely use my improved one from now on.Thankyou very much for taking a look at my basis set - it's reassuring that it wasn't too far off.
CASINO is set up to work out of the box on Archer. The automatic detection should come up with the following CASINO_ARCHs:I'm pretty sure that I can get some time on ARCHER for this purpose
linuxpc-cray-pbs-parallel.archer
linuxpc-intel-pbs-parallel.archer
linuxpc-gnu-pbs-parallel.archer
for the three different compilers that are set up on the machine. I checked that the Gnu one produces the fastest CASINO executables. Note that I did some tweaking of the Archer setup last weekend, so you want to have at least version 2.13.252 of the CASINO current beta to run on that machine.
Well, CASINO scales essentially linearly with the number of processor cores - tested up to more than half a million cores - they've got to be keen on that. Most methods get slower if they use more than a couple of thousand.They are very keen on calculations that exploit the parallelism.
That's actually not a concern. CASINO can save it's state in the 'config.out' file after (say) 23.5 hours then you can start a new instance of the calculation which will carry on where it left off. Repeat ad nauseam. This can even be done automatically with the --auto-continue option to the runqmc script. Note that this requires you to set max_cpu_time in input to be 0.9 * the queue walltime limit, so that CASINO emergency stops before it gets killed.My only concern is whether I can get the statistics of the DMC calculation completed in the 24hour slot.
Remember QMC calculations don't have a definite end point. You can continue them as long as you like and all that will happen is that the statistical error bar on the answer will get smaller. You have to decide when smaller is small enough..
Well, good luck! Make sure you write something on the CASINOQMC site to let us all know how it went afterwards..As you know there are many examples where DFT utterly fails. There are three computational chemistry groups here in Bath who would be very interested in using the method for certain systems if I can just get a good example that shows the merits.
Mike