non-orthorhomic variable cell optimization
Rad
rad.... at arl.army.mil
Thu Feb 26 13:56:09 UTC 2009
Thank you everybody for all the feedback.
I have tested DCACP on several periodic systems (about a dozen) using
CP2K and found out they really perform well. Performance is not a
problem at all. On Cray-XT5 it is a breeze with 256 processors. The
particular system I mentioned was also working for as high
cutoff as 2000 Ry (starting from 700 Ry) until the patch was applied.
I still have the old executable and it goes through fine execpt for
printing a different parameter at the 0th step. The patch also works
for all the non triclinic systems.
That is why I have uploaded the test input along with the potential to
see if you can reproduce the error. If you cannot reproduce the error
then I will try the patch on a different architecture (I doubt that
will change the result) and see what happens.
Thanks again for your prompt response.
Rad
On Feb 26, 2:58 am, Juerg Hutter <hut... at pci.uzh.ch> wrote:
> > 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]:
>
> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -
More information about the CP2K-user
mailing list