[CP2K:1389] Re: EMAX_SPLINE too small

[Laino Teodoro]

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