non-orthorhomic variable cell optimization

Axel akoh... at gmail.com
Wed Feb 25 19:16:39 UTC 2009



On Feb 25, 1:21 pm, Teodoro Laino <teodor... at gmail.com> wrote:
> Dear Rad,
> There is no bug coming from my previous patch. The CELL_OPT is working
> properly and what you see is
> something system dependent.

didn't we have a discussion - quite a while ago - with the outcome
that DCACP potentials can work in cp2k properly only for isolated
systems and QM/MM?

axel.


> Teo
>
> Rad wrote:
> > Dear Teo,
>
> > Thank you for your response and the fix has partially worked in the
> > sense
> > that it prints the correct lattice parameters in the 0th step as the
> > input.
> > However, it looks like the fix has broken other parts of the code. One
> > of
> > the systems I tried had volume going from 400 A3 to 1000 A3 during the
> > second step
> > Of the optimization and then the calculation stalled. The same
> > calculation
> > used to run smoothly before the fix except for the problem I reported
> > earlier. I am attaching here with the input I tested along with the
> > associated POTENTIAL and BASIS_SET files. You can run the input using
> > an
> > executable before the fix as well as after the fix and compare the
> > behavior.
> > Please take a look at this issue or someone from the team to resolve
> > this at
> > your convenience. I really appreciate the prompt response we get from
> > the
> > cp2k team and please feel free to ask if you need more information
> > about the
> > input.
>
> > I have uploaded three files with the prefix "RAD_TEST" and please let
> > me know if you trouble accessing them.
>
> > Thanks
> > Rad
>
> > On Feb 17, 3:07 pm, Teodoro Laino <teodor... at gmail.com> wrote:
>
> >> Hi Rad,
> >> actually, there was a bug when handling triclinic cells (in the
> >> optimization module).
> >> The bug fix is in the CVS.
> >> Thanks,
> >> Teo
>
> >> Rad wrote:
>
> >>> Dear Monica,
>
> >>> Thank you for your response and I really appreciate it. I would like
> >>> to clarify further about my earlier posting as it relates to the
> >>> behavior of the variable cell optimization module.
>
> >>> We are getting reasonable results using the variable cell optimization
> >>> module when it comes to non-monoclinic cells. But We have observed
> >>> consistently in the case of triclinic cells is a change in the lattice
> >>> vectors from the given input even before taking an optimization step.
> >>>  It is as if the module is starting with a different initial
> >>> configuration.
>
> >>> Our intention is to understand the process the module follows so that
> >>> we can be comfortable with the final output it produces. For example,
> >>> in one of our studies we gave the following input:
>
> >>> In this case we are providing the experimental lattice configuration
> >>> as the input.
>
> >>>  CELL| Vector a [ANGSTROM]:       9.814     0.000     0.000    |
> >>> a|      =       9.814
> >>>  CELL| Vector b [ANGSTROM]:       0.424     9.038     0.000    |b|
> >>> =       9.048
> >>>  CELL| Vector c [ANGSTROM]:       1.575     0.001    20.279    |c|
> >>> =      20.340
> >>>  CELL| Angle (b,c)
> >>> [degree]:                                              89.790
> >>>  CELL| Angle (a,c)
> >>> [degree]:                                              85.559
> >>>  CELL| Angle (a,b)
> >>> [degree]:                                              87.314
>
> >>> Then after the initial set up the module prints the following
> >>> configuration at the 0th step: (This 0th step is before any prior
> >>> calculation has happened)
> >>> ANGSTROM**3]:                                            1795.645
> >>>  CELL| Vector a [ANGSTROM]:       9.807     0.000     0.000    |a|
> >>> =       9.807
> >>>  CELL| Vector b [ANGSTROM]:       0.424     9.031     0.000    |b|
> >>> =       9.041
> >>>  CELL| Vector c [ANGSTROM]:       1.575    -0.001    20.276    |c|
> >>> =      20.337
> >>>  CELL| Angle (b,c)
> >>> [degree]:                                              89.795
> >>>  CELL| Angle (a,c)
> >>> [degree]:                                              85.559
> >>>  CELL| Angle (a,b)
> >>> [degree]:                                              87.312
>
> >>> This strange switch in the initial geometry is happening only in the
> >>> case of triclinic cells. In addition, the final output volume is off
> >>> by more than 10% in some cases. This is what prompted us to go over
> >>> the output in detail and come up with a pattern.
> >>> It would help us understand and be comfortable with the results if we
> >>> know what is happening at the 0th step and what prompts the change in
> >>> the configuration only for monoclinic cells.
>
> >>> If the developers can take a look at the pattern and provide us with
> >>> any suggestions we would appreciate it.
>
> >>> Thanks
> >>> Rad
>
> >>> On Feb 13, 9:33 am, monica <monic... at phys.chem.ethz.ch> wrote:
>
> >>>> Dear Rad,
>
> >>>> I was running recently several triclinic cell optimization jobs
> >>>> (although the angles are very close to 90), with variable hydrostatic
> >>>> pressure (0-20 GPa), and it seemed to work: when comparing the volume
> >>>> with similar orthorhombic cell, optimized manually (energy volume
> >>>> curve). See output below for example. In my case, when the cell was
> >>>> already close to the minimum, only minor changes occurred.
>
> >>>> Monica
>
> >>>> output for example
> >>>>  CELL| Volume
> >>>> [ANGSTROM**3]:                                            1798.737
> >>>>  CELL| Vector a [ANGSTROM]:       9.814     0.000     0.000    |a|
> >>>> =       9.814
> >>>>  CELL| Vector b [ANGSTROM]:       0.424     9.038     0.000    |b|
> >>>> =       9.048
> >>>>  CELL| Vector c [ANGSTROM]:       1.575     0.001    20.279    |c|
> >>>> =      20.340
> >>>>  CELL| Angle (b,c)
> >>>> [degree]:                                              89.790
> >>>>  CELL| Angle (a,c)
> >>>> [degree]:                                              85.559
> >>>>  CELL| Angle (a,b)
> >>>> [degree]:                                              87.314
> >>>>  CELL| Grid size for subcell
> >>>> generation                                    2.000
> >>>>  CELL| Volume
> >>>> [ANGSTROM**3]:                                            1795.645
> >>>>  CELL| Vector a [ANGSTROM]:       9.807     0.000     0.000    |a|
> >>>> =       9.807
> >>>>  CELL| Vector b [ANGSTROM]:       0.424     9.031     0.000    |b|
> >>>> =       9.041
> >>>>  CELL| Vector c [ANGSTROM]:       1.575    -0.001    20.276    |c|
> >>>> =      20.337
> >>>>  CELL| Angle (b,c)
> >>>> [degree]:                                              89.795
> >>>>  CELL| Angle (a,c)
> >>>> [degree]:                                              85.559
> >>>>  CELL| Angle (a,b)
> >>>> [degree]:                                              87.312
> >>>>  CELL| Grid size for subcell
> >>>> generation                                    2.000
> >>>>  CELL| Volume
> >>>> [ANGSTROM**3]:                                            1785.878
> >>>>  CELL| Vector a [ANGSTROM]:       9.783     0.000     0.000    |a|
> >>>> =       9.783
> >>>>  CELL| Vector b [ANGSTROM]:       0.424     9.008     0.000    |b|
> >>>> =       9.018
> >>>>  CELL| Vector c [ANGSTROM]:       1.574    -0.006    20.266    |c|
> >>>> =      20.327
> >>>>  CELL| Angle (b,c)
> >>>> [degree]:                                              89.810
> >>>>  CELL| Angle (a,c)
> >>>> [degree]:                                              85.560
> >>>>  CELL| Angle (a,b)
> >>>> [degree]:                                              87.307
>
> >>>> On Feb 11, 10:47 pm, Rad <rad.... at arl.army.mil> wrote:
>
> >>>>> Hello everybody,
>
> >>>>> We seem to be having an issue with non-orthorhombic cell optimization
> >>>>> when the lattice has all the three angles other than 90 degrees. Here
> >>>>> is what appears to be happening: After the initial set up, the module
> >>>>> Changes the lattice vectors by keeping the lengths the same but the
> >>>>> angles are slightly different. This happens only when all the angles
> >>>>> are not 90-degrees. The regtest for non-orthorhombic includes only one
> >>>>> angle 120 and the rest are 90s. So the scenario I described might be
> >>>>> missed out. This issue we have observed in several executables we have
> >>>>> built over the last several months and on multiple architectures.
>
> >>>>> ===========================================================================­­=======
> >>>>> Here is the output just after the set up which is the same as the
> >>>>> input:
> >>>>> CELL| Volume
> >>>>> [ANGSTROM**3]:                                             442.524
> >>>>>  CELL| Vector a [ANGSTROM]:       9.010     0.000     0.000    |a|
> >>>>> =       9.010
> >>>>>  CELL| Vector b [ANGSTROM]:      -4.510     7.821     0.000    |b|
> >>>>> =       9.028
> >>>>>  CELL| Vector c [ANGSTROM]:      -0.216    -2.630     6.280    |c|
> >>>>> =       6.812
> >>>>>  CELL| Angle (b,c)
> >>>>> [degree]:                                             108.580
> >>>>>  CELL| Angle (a,c)
> >>>>> [degree]:                                              91.820
> >>>>>  CELL| Angle (a,b)
> >>>>> [degree]:                                             119.970
>
> >>>>> Here is when it got changed just before the first step of the
> >>>>> optimization:
>
> >>>>>  CELL| Volume
> >>>>> [ANGSTROM**3]:                                             449.960
> >>>>>  CELL| Vector a [ANGSTROM]:       9.010     0.000     0.000    |a|
> >>>>> =       9.010
> >>>>>  CELL| Vector b [ANGSTROM]:      -4.510     7.821     0.000    |b|
> >>>>> =       9.028
> >>>>>  CELL| Vector c [ANGSTROM]:      -0.216    -2.363     6.386    |c|
> >>>>> =       6.812
> >>>>>  CELL| Angle (b,c)
> >>>>> [degree]:                                             106.534
> >>>>>  CELL| Angle (a,c)
> >>>>> [degree]:                                              91.820
> >>>>>  CELL| Angle (a,b)
> >>>>> [degree]:                                             119.970
> >>>>>  CELL| Grid size for subcell
> >>>>> generation                                    2.000
>
> >>>>>  --------  Informations at step =     0 ------------
> >>>>>   Optimization Method        =
>
> ...
>
> read more »


More information about the CP2K-user mailing list