EMAX_SPLINE too small

[salah]

Dear Laino,
thanks for you, your response time is astonishing.
I'm still working on the problem, but the solution is almost at my
grasp.

Cheers
salah


On 2 oct, 14:19, Laino Teodoro <teodor... at gmail.com> wrote:
> Just a follow up:
> Those two "bugs" have been fixed now (correct version in the CVS)..
> You will get a warning if you define the CHARGE when you define
> for the same element also the core-shell.
> And the printed total charge now takes into account also the core-
> shell contribution.
> Thanks for pointing out these problems.
> Teo
>
> On 2 Oct 2008, at 13:24, Laino Teodoro wrote:
>
> > Salah,
>
> >> So I set the charges exactly as shown if the distribution test files,
>
> > This is the premise:
> > distribution tests are there to test some functionalities.. never
> > trust them for
> > whatever production run. If you want to use something within CP2K
> > get ready
> > to make your hands dirty with the code.. otherwise you'd better use
> > some more
> > well documented program (until there will be some clear
> > documentation of course)...
>
> > In detail:
> > What I said in the previous e-mail is partially wrong. Let me correct:
> > If your atom type has a core-shell specification the value of the
> > charge in FORCEFIELD%CHARGE is just ignored.
> > For your input file, this is not the case for Si, while it is for O.
> > So.. the information FORCEFIELD%CHARGE for the O is ignored but not
> > for Si.
> > For the calculation itself does not make any difference if you use
> > FORCEFIELD%CHARGE for O or not,
> > but for cleanness I would avoid to have it in the input file..
> > (will put a warning when that value is ignored).
>
> >> ------------> CHARGE_INFO| Total Charge of the Classical
> >> System:                     0.000000
> >> I've tried to set the charge of O to zero and kept the charge coming
> >> from the shell-core part but cp2k displays a positive total charge
> >> for
> >> the system.
> >> so, I do not see what do you mean by setting charge of O to zero and
> >> keep the charge flowing from the shell-core part !!!!!!
>
> > This is an I/O bug and I will fix ASAP. The charge value displayed
> > does not account for the
> > CORE-SHELL contribution and it's clearly a bug. This bug does not
> > affect the calculation.
>
> >> second point is the EMAX_SPLINE itself. I've tried to increase it but
> >> the simulation start running only with a value higher than 300
> >> hartree !!! does this really need to be that high ????
>
> > well.. this means that:
> > (1) cell and geometry do not match
> > (2) the way you inputed the potential is wrong (maybe units). Check
> > it!
> > (3) geometry is wrong.
>
> >> fourth point, a timestep of 0.2 fs should be enough to capture the
> >> movements of the shell-core couples especially with a high force
> >> constant (using DLPOLY for example, simulations with a shell model
> >> and
> >> with 0.2 fs is stable without drift of energy).
>
> > I already said that 0.2 is a good starting point. I just told you
> > to check carefully that your dynamics is
> > a conserved one. Exporting this expertise from other programs is
> > IMHO quite dangerous.. implementations
> > are different.. so as I said check if you want to be sure to do
> > something meaningful.
>
> >> last point, I changed everything as you advised but the system
> >> collapsed.
>
> > Putting the charge of O to zero cannot be the reason for the
> > collapsing, since that value
> > as I already said is IGNORED. If your system collapse and the
> > geometry+cell are ok, then
> > check the definition of your potential (which maybe the reason why
> > you need such a huge emax_spline
> > and nonetheless the system collapse).
>
> > Teo
>
> >> So, can you please do me a favor and check this again
> >> closely ??????????????????