[CP2K:1803] Re: non-orthorhomic variable cell optimization

Juerg Hutter hut... at pci.uzh.ch
Thu Feb 26 07:58:46 UTC 2009


>
> 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?

There were two problems (maybe more) with the DCACP's in CP2K.
One was that they were incredably slow, especially in periodic systems.
So slow that people stopped the runs because they thought the job was
hanging. The other problem is related to the non-local properties
of the potentials. In CP2K we assume a local potential and screen
the KS matrix accordingly. For normal non-local PP this is a very
mild approximation but for DCACP's this could be more of a problem.

With the recent commit the performance problem should be solved.
The screening problem can be delt with by using a small eps_pgf.

Juerg


>
> 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