Nickel cell optimization

[Alex]

Hi everyone. I'm trying to optimize a periodic (6x6x6) lattice of nickel using either CELL_OPT or GEO_OPT (input attached). The simulation's been running for several days on 8 cores, no SCF updates, it just hangs at

 *******************************************************************************

 ***                     STARTING GEOMETRY OPTIMIZATION                      ***

 ***                           CONJUGATE GRADIENTS                           ***

 *******************************************************************************

 Spin 1

 Number of electrons:                                                          9

 Number of occupied orbitals:                                                  9

 Number of molecular orbitals:                                                26

 Spin 2

 Number of electrons:                                                          9

 Number of occupied orbitals:                                                  9

 Number of molecular orbitals:                                                26

 Number of orbital functions:                                                 26

 Number of independent orbital functions:                                     26

 Extrapolation method: initial_guess

 SCF WAVEFUNCTION OPTIMIZATION

  Step     Update method      Time    Convergence         Total energy    Change

  ------------------------------------------------------------------------------

 BFGS minimizer doesn't seem like an option with this system size, so I used CG... Am I doing something seriously wrong?

Thank you.

[Matt W]

Hi,

you aren't running bullk Ni, but a Ni atom in a large box. See the definition of multiple unit cell in the CELL section

MULTIPLE_UNIT_CELL {Integer} {Integer} {Integer}

Specifies the numbers of repetition in space (X, Y, Z) of the defined cell, assuming it as a unit cell. This keyword affects only the CELL specification. The same keyword in SUBSYS%TOPOLOGY%MULTIPLE_UNIT_CELL should be modified in order to affect the coordinates specification.  [Edit]

Why you aren't getting any output, I'm not sure. Maybe the memory cost is too high and your system is swapping?

Matt

[Alex]

Hi Matt,

Thanks for the reply. The way it is specified in CP2K is quite confusing to me, to be honest. I am used to unit cell + translation vectors + # repetitions combination. Incidentally, this setup was actually suggested by another CP2K user from here, and it yielded per-atom nickel cohesive energy quite close to the experimental value (-4.422 eV from my calculations). The same for aluminum yielded -2.9 eV, which isn't great, but also close.

Now I wonder how that's possible, if the setup is wildly incorrect...

[Alex]

So, I added MULTIPLE_UNIT_CELL 6 6 6 into SUBSYS>TOPOLOGY, and now SCF is updating. I guess I should redo pretty much everything I've done up to this point....

[Alex]

Okay, my apologies. The setup suggested to me previously (used to calculate the cohesive energies correctly) did include the SUBSYS>TOPOLOGY section. My fault entirely.

[Alex]

With the TOPOLOGY subsection fixed, the GEO_OPT run (as defined in input above) produces about 200 SCF updates and quits reporting "SCF not converged." The CELL_OPT run (it is my understanding that it optimizes all coordinates for each given cell size and cycles between the two optimizations) quits with

 ***************************************************************************

 *** 02:51:32 ERRORL2 in qs_moments:qs_moment_berry_phase UNIMPLEMENTED, ***

 *** Berry phase moments for non uniform MOs' occupation numbers not     ***

 *** implemented                                                         ***

 ***************************************************************************

Any thoughts? Thanks,

Alex

[Florian Schiffmann]

Hi Alex,

try playing with some options in the SCF section, e.g. mixing parameter, diis settings, outer_scf loop,... The system might be hard to converge in the first step and therefore needs some tweaking.
The second error, as written in the error message has nothing to do with the cell optimzation but the point that you have activated the calculation of dipole moments (DFT PRINT MOMENTS or HIGH print level). In combination with smearing (non uniform occupation) this is not implemented and therefore the calcualtion stops. If you remove the moment section the calculation will run through even without a perfectly converged wavefunction.

Cheers
Flo

[Alex]

Hi Florian,

I removed the print statements for moments and tried to play around with the outer SCF optimization (with BISECT as the optimization scheme). No luck whatsoever, although the screaming about Berry phase has stopped. I really think there's something up with the way my cell is set up... I thought this was one of the simplest possible calculations one could do on a crystal structure, and here we are.

Thanks for your suggestions.

Alex

[Matt W]

Hi Alex,

here's a slightly tidied version of you original input. It worked for a 3x3x3 supercell. Not sure what problems you were having without seeing more details. I did remove the UKS tag, as with smearing it is not needed - this might make the optimization easier.

Matt

[Alex]

Hey Matt,

Thanks, I will try your version. My only problem at this point is that SCF does not converge. 

Now, I thought that UKS (along with MULTIPLICITY) was there to include spin polarization, which should be very important for something like nickel. Also, why is it not needed if Fermi-Dirac smearing of the wavefunction is enabled? I kinda fail to see how one excludes the other qualitatively. In other words, by omitting the magnetic part, am I really simulating nickel?

Just to add to the info, the 6x6x6 simulation converged during energy minimization (constant cell size) and in fact yielded reasonable cohesive energy (the input included smearing and UKS). The convergence issues started during cell optimization.

Your help is appreciated.

Thanks,

Alex

[Alex]

So, instead of just running your file as is, I went through it and carefully tracked and implemented all the clean-up you did -- all but the UKS stuff. Converges like a rampant rabbit now, both with BFGS and CG. Thanks. 

My question about UKS and smearing still stands though... 

On Thursday, October 9, 2014 4:01:38 PM UTC-6, Matt W wrote:

[Matt W]

My question about UKS and smearing still stands though... 

Without UKS and smearing you'll get a spin averaged structure, no spin polarization obviously. Normally the magnetic effects are actually rather small, so you'll get say energy/volumes that are quite reasonable. 

There will be lower energy solutions that are (anti)-ferromagnetic, spin waves etc depending on the material. In general, you won't find these unless you can construct a good initial guess - by setting a guess based on spin polarized atomic calculations for instance (BS keyword in KIND). The exception is the fully ferromagnetic, which you can just set the multiplicity appropriately.

As you kept the UKS, probably the main change was reducing the ALPHA value (~amount of new solution mixed into the new trial density) to 0.1.

HTH

Matt

[Alex]

That does make sense, thanks. I suppose my comment about smearing and spin polarization would be more relevant to a case of a few Kelvin in electronic temperature. 

By the way, it is my understanding that the only way to get lattice constant as a function of lattice temperature is to run thermostatted MD, as CP2K does not include things like Monte Carlo. Is this correct?

Thanks,

Alex

[Alex]

Also, is the AD_LANGEVIN thermostat type in MOTION/MD/THERMOSTAT something that got implemented very recently?

This thing screams that the keyword is invalid, but works with NOSE. Except that NOSE is a generally crappy choice for a small ensemble...

[Noam Bernstein]

> On Oct 10, 2014, at 7:06 PM, Alex <nedo...@gmail.com> wrote:
>
> Also, is the AD_LANGEVIN thermostat type in MOTION/MD/THERMOSTAT something that got implemented very recently?

Relatively, yes. A few months at this point, I think.

> This thing screams that the keyword is invalid, but works with NOSE. Except that NOSE is a generally crappy choice for a small ensemble...

What do you mean by "this thing"?

There's conventional langevin too, by the way, as a different ensemble.

[Alex]

Relatively, yes. A few months at this point, I think.

Ah. now that makes sense.  

What do you mean by "this thing"?

There's conventional langevin too, by the way, as a different ensemble.

 

"This thing" is my version of CP2K. Yes, the "LANGEVIN" ensemble version is there, there's just no documentation of what that does to barostatics. I need both thermostat and isotropic barostat. If I select LANGEVIN as the ensemble, is that effectively well-damped NVT?

[Noam Bernstein]

>
> "This thing" is my version of CP2K. Yes, the "LANGEVIN" ensemble version is there, there's just no documentation of what that does to barostatics. I need both thermostat and isotropic barostat. If I select LANGEVIN as the ensemble, is that effectively well-damped NVT?

As I recall nvt vs npt is selected at the ensemble level, and is that's indeed the case the langevin ensemble might only be constant V.

I implemented AD_LANGEVIN, but I don't actually know much about how the rest of the dynamics in CP2K is implemented. I certainly never tested it together with a barostat. When I implemented barostats and thermostats in my own code, I was careful to come up with a consistent time propagation algorithm that included both. Assuming that the rest of the constant P dynamics (in CP2K) was implemented in a way that's reasonably thermostat agnostic, and since I based AD_LANGEVIN on the existing Nose and Langevin codes, it has a decent chance of working.

There are also other stochastic thermostats like CSVR, which have been in the code longer and are presumably well tested, and might be decent for a small system.

What's keeping you from updating to a newer version, anyway?

Noam

[Alex]

I'll try and see how much unphysical oscillation I get with Nose and maybe then switch to either CSVR or yours.

What's keeping you from updating to a newer version, anyway?

Lack of admin rights on the cluster. Will have to wait until Tuesday to ask our sysadmin to install the new version. 

[Alex]

Our sysadmin installed v. 2.5.1, after about 20 steps of seemingly normal simulation (NPT_I MD, AD_LANGEVIN thermostat, force calculations as suggested by Matt above) the job crashes and I get:

 ****************************************************************************

 *** 22:05:49 ERRORL2 in input_enumeration_types:enum_i2c processor 0  :: ***

 *** err=-300 invalid value for enumeration:   104                        ***

 ****************************************************************************

Any thoughts? Thanks.

Alex

[Alex]

Will anyone be able to test-run an input file for me for maybe 50-100 MD steps? 

I'm trying to figure out if our cluster setup/CP2K build is causing trouble... Attached crashed after 24 iterations during a parallel run on eight cores (segmentation fault in one of the processes). I will really appreciate any help.

Thanks,

Alex

[Matthias Krack]

Hi,

your input does run for 100 MD steps (32 cores) even if the setup will not produce useful results.

Matthias

[Alex]

Hi Matthias,

Thanks for your help, it's very good to know that it runs. Could you please state your CP2K version and OS, and also whether the software was built locally, or from a binaries package (e.g. from Debian repository)?

Thank you,

Alex

[Matthias Krack]

Hi,

the cp2k.popt executable was compiled using the latest development version and the arch file Linux-x86-64-gfortran.popt.
uname -r -> 2.6.32-431.23.3.el6.x86_64

CP2K| version string:                    CP2K version 2.6 (Development Version)
CP2K| source code revision number:                                    svn:14486
CP2K| is freely available from                             http://www.cp2k.org/
CP2K| Program compiled at                          Tue Oct 28 09:13:23 CET 2014
CP2K| Program compiled on                                             merlinl02
CP2K| Program compiled for                                Linux-x86-64-gfortran
CP2K| Input file name                                                    Ni.inp

Concerning your (metallic) system: I assume you know that CP2K has not yet k points implemented.

Matthias

[Alex]

Thanks for the info, this is very useful.

 

                                            

Concerning your (metallic) system: I assume you know that CP2K has not yet k points implemented.

 

 I do realize that the electronic energy is sampled at the gamma point, so no transport properties as such. With this input, I want to see if I am able to at least get the thermal expansion coefficient and heat capacity with some degree of accuracy. Do you think it's a realistic goal?

[Matthias Krack]

I am afraid you might need prohibitively large model systems to get reasonable results for such systems without k points. Note, Fermi smearing requires diagonalisation which becomes computationally expensive for larger systems quite quickly.

Matthias

On Wednesday, 29 October 2014 09:10:34 UTC+1, Alex wrote:

Thanks for the info, this is very useful.

 

Concerning your (metallic) system: I assume you know that CP2K has not yet k points implemented.

[Alex]

Oh sure, I do realize that. Even without smearing, the size issue makes me doubt the value of DFT-MD idea (without sampling the k-space) for a metallic system. Or for a non-metallic crystal, for that matter. Hence, the testing. There's clearly need for k points, I wonder when this gets implemented.