molecular dipoles of charged molecules

[Axel]

hi,

this is a bit of a badly conditioned problem, but i noticed
that the molecular dipole value computed for charged molecules
does not take out any net charge and thus makes the resulting
dipole strongly position dependent, and thus practically useless.

i've met the same problem while writing a visualization tool for
VMD and ultimately decided to remove the total charge at the
center of the molecule to retain position independent results
(and visualizations).

are there any opinions on this matter?
or even examples for where the current
implementation is useful.

thanks,
axel.

[Laino Teodoro]

hi axel,

you can specify the reference point for the calculation of the
electrical dipole moments.
Have a look at :

http://cp2k.berlios.de/manual/CP2K_INPUT/FORCE_EVAL/DFT/PRINT/
MOMENTS.html#list_REFERENCE

or do you refer to this keywords?
http://cp2k.berlios.de/manual/CP2K_INPUT/FORCE_EVAL/DFT/PRINT/
LOCALIZATION.html#list_TOTAL_DIPOLE
http://cp2k.berlios.de/manual/CP2K_INPUT/FORCE_EVAL/DFT/PRINT/
LOCALIZATION.html#desc_MOLECULAR_DIPOLES

in which case I do agree.. they were never properly updated..

Don't forget always to specify the keywords in your messages..
thanks,
Teo

[Laino Teodoro]

Ciao Axel,

I checked carefully the part of the code connected with the
calculation of the dipoles (both total and for each molecule)
when using the wannier centers, i.e.:

DFT%PRINT%LOCALIZATION%MOLECULAR_DIPOLES
DFT%PRINT%LOCALIZATION%TOTAL_DIPOLE

While for MOLECULAR_DIPOLES they are always computed w.r.t the
position of the first atom in the molecule,
the TOTAL_DIPOLE was (as you said) totally position dependent.
Moreover, as I mentioned, it was absolutely not
related to the other possible way of computing dipoles: DFT%PRINT%
MOMENTS

Therefore:
-) MOLECULAR_DIPOLES and TOTAL_DIPOLE are now print_key sections
inside localization.
-) both sections have the same possible parameters as MOMENTS, i.e.:
PERIODIC (if the dipole should be
computed with the berry phase or not), REFERENCE and
REFERENCE_POINT.
-) While these keywords are fully implemented for the TOTAL_DIPOLE
section, they are not for MOLECULAR_DIPOLES
since I think the convention used (i.e. to compute the dipole
w.r.t. the first atom in the molecule) is already quite good.
In case somebody will really need it, the implementation is quite
straightforward..

Hope this solves your issue.
Teo

On 19 Oct 2008, at 03:32, Axel wrote:

[Axel]

On Oct 19, 11:26 am, Laino Teodoro <teodoro.la...@gmail.com> wrote:
> Ciao Axel,

hi teo,

there is/was only one entry for "molecular dipoles".

> I checked carefully the part of the code connected with the
> calculation of the dipoles (both total and for each molecule)
> when using the wannier centers, i.e.:
>
> DFT%PRINT%LOCALIZATION%MOLECULAR_DIPOLES
> DFT%PRINT%LOCALIZATION%TOTAL_DIPOLE

hmmmm.... the organization of this part of the input is a bit
confusing.

i would have either expected that you move them to the
CP2K_INPUT / FORCE_EVAL / DFT / PRINT / LOCALIZATION / LOCALIZE /
PRINT
block where the other wannier center related output is found or
- which makes even more sense to me - move those subsections
directly into LOCALIZATION and merge LOCALIZATION%LOCALIZE
into LOCALIZATION.

> While for MOLECULAR_DIPOLES they are always computed w.r.t the
> position of the first atom in the molecule,
> the TOTAL_DIPOLE was (as you said) totally position dependent.

> Moreover, as I mentioned, it was absolutely not
> related to the other possible way of computing dipoles: DFT%PRINT%
> MOMENTS

the documentation there is very terse. i understand this section
as computing properties of the "total" system, right?

> Therefore:
> -) MOLECULAR_DIPOLES and TOTAL_DIPOLE are now print_key sections
> inside localization.
> -) both sections have the same possible parameters as MOMENTS, i.e.:
> PERIODIC (if the dipole should be
> computed with the berry phase or not), REFERENCE and
> REFERENCE_POINT.
> -) While these keywords are fully implemented for the TOTAL_DIPOLE
> section, they are not for MOLECULAR_DIPOLES
> since I think the convention used (i.e. to compute the dipole
> w.r.t. the first atom in the molecule) is already quite good.

well, that makes the resulting dipole depend on the shape of the
molecule.
it is not a big deal for most molecules, but it is for the kind of
molecule
that i am currently looking into, which is a small organic cation that
is
mostly flat and picks up a dipole moment from bending and being
polarized
from solvate molecules.

> In case somebody will really need it, the implementation is quite
> straightforward..

i'll look into it. i don't really need that kind of output, since i
have
an equivalent implementation with sufficient flexibility already
integrated
into VMD (Extensions->Visualization->Dipole Moment Watcher), but i was
a
bit surprised by the discrepancies and wanted to check with the folks
here
whether this was intentional or accidental.


cheers,
axel.

[Laino Teodoro]

> hmmmm.... the organization of this part of the input is a
> bitconfusing.
>
> i would have either expected that you move them to the
> CP2K_INPUT / FORCE_EVAL / DFT / PRINT / LOCALIZATION / LOCALIZE /
> PRINT
> block where the other wannier center related output is found or
> - which makes even more sense to me - move those subsections
> directly into LOCALIZATION and merge LOCALIZATION%LOCALIZE
> into LOCALIZATION.

Well.. it has a sense how it is organized at the moment.
In fact, wannier centers (which are controlled by the LOCALIZE
section and the printing of the WANNIER* is controlled by that section)
are used in the LOCALIZATION section to compute/print properties
(MOLECULAR_DIPOLES, TOTAL_DIPOLE and MOLECULAR STATES) that depend
on the WANNIER centers..
With the today re-organization, the real print keys are
MOLECULAR_DIPOLES, TOTALE_DIPOLE, MOLECULAR_STATES,
(hopefully the manual online should be soon updated).
LOCALIZATION is therefore just a container for properties computed
using wannier centers (controlled by LOCALIZE).

WANNIER centers are also used in other sections, like LINRES:
http://cp2k.berlios.de/manual/CP2K_INPUT/FORCE_EVAL/PROPERTIES/
LINRES.html

that's why everything connected with the printing of wannier
functions (centers, spread, cubes) must
be in the LOCALIZE%PRINT section, and there you don't want to put for
example dipoles or molecular_states.
to me, it makes sense how it is organized..

> the documentation there is very terse. i understand this section
> as computing properties of the "total" system, right?

Absolutely right.. MOMENTS is always referred to the total system..

> well, that makes the resulting dipole depend on the shape of the
> molecule.
> it is not a big deal for most molecules, but it is for the kind of
> molecule
> that i am currently looking into, which is a small organic cation
> that is
> mostly flat and picks up a dipole moment from bending and being
> polarized
> from solvate molecules.

well.. even with the center of charge or center of mass the dipole
will always depend
on the shape of the molecule.. it's unavoidable..
maybe the center of charge or of mass behaves better.. but anyway..
as you said in the
first message the problem is ill-defined..

> i'll look into it. i don't really need that kind of output, since i
> have
> an equivalent implementation with sufficient flexibility already
> integrated
> into VMD (Extensions->Visualization->Dipole Moment Watcher), but i was
> a bit surprised by the discrepancies and wanted to check with the
> folks
> here whether this was intentional or accidental.

I would say more laziness... ;-)
Teo

[Axel]

hi teo,

On Oct 19, 7:48 pm, Laino Teodoro <teodoro.la...@gmail.com> wrote:
> > hmmmm.... the organization of this part of the input is a
> > bitconfusing.
>
> > i would have either expected that you move them to the
> > CP2K_INPUT / FORCE_EVAL / DFT / PRINT / LOCALIZATION / LOCALIZE /
> > PRINT
> > block where the other wannier center related output is found or
> > - which makes even more sense to me - move those subsections
> > directly into LOCALIZATION and merge LOCALIZATION%LOCALIZE
> > into LOCALIZATION.
>
> Well.. it has a sense how it is organized at the moment.

sorry, but i fail to see the sense in having a LOCALIZE section
inside a LOCALIZATION section and having a PRINT section inside
LOCALIZE when LOCALIZATION is itself in a PRINT section.

to me it would seem _much_ more reasonable to have the LOCALIZE
section (w/o its PRINT section) directly located under DFT.
the reason being that it "processes" the wavefunction in a similar
spirit than SCF, SIC and other sections there.

then _all_ print keys would be located directly in the DFT%PRINT
section and the wannier cubes output would be alongside the density
cubes, the wannier centers alongside the dipole moments, molecular
states etc. etc.

this is much more what "ordinary users(tm)" would expect where to
find the respective flags.

[...]

> well.. even with the center of charge or center of mass the dipole
> will always depend
> on the shape of the molecule.. it's unavoidable..
> maybe the center of charge or of mass behaves better.. but anyway..
> as you said in the
> first message the problem is ill-defined..

yep. i've been sleeping about it and using the center of mass is
actually the most reasonable choice. basically, one can view those
molecular dipoles (or multipoles) as a part of a multipole expansion
of a molecule and that molecule would rotate around its center of
mass.

i'll change my VMD code accordingly (i've been using the geometrical
center for simplicity, as not all file formats provide reliable
information
about masses in VMD).

[...]

> > a bit surprised by the discrepancies and wanted to check with the
> > folks
> > here whether this was intentional or accidental.
>
> I would say more laziness... ;-)

that would be ok to me, so if nobody objects i'll try to modify
the calculation of the molecular dipoles accordingly.

cheers,
axel.

> Teo

[Laino Teodoro]

> to me it would seem _much_ more reasonable to have the LOCALIZE
> section (w/o its PRINT section) directly located under DFT.
> the reason being that it "processes" the wavefunction in a similar
> spirit than SCF, SIC and other sections there.

I'm sorry this does not make any sense to me.. if I'm computing the
wannier centers I'm
expecting to find a print section in the wannier section (LOCALIZE).

> then _all_ print keys would be located directly in the DFT%PRINT
> section and the wannier cubes output would be alongside the density
> cubes, the wannier centers alongside the dipole moments, molecular
> states etc. etc.

Maybe.. this does not make too much sense if you think that you may
want to
use a certain settings for LOCALIZE for the TOTAL_DIPOLE.. etc.. and
another
set for LINEAR RESPONSE.. so the LOCALIZE section MUST be inside the
respective
sections.

So.. I still like it is now.. maybe the name of the sections do not
make too much sense..
but I'm opened in having more meaningful names..

> that would be ok to me, so if nobody objects i'll try to modify
> the calculation of the molecular dipoles accordingly.

of course you can.. it's everything setup now (in the sense that one
can use the keywords
already introduced but not implemented..) and we should make the
input fully working..
this would be ideal..

cheers
teo

[Axel]

On Oct 20, 11:05 am, Laino Teodoro <teodoro.la...@gmail.com> wrote:
> > to me it would seem _much_ more reasonable to have the LOCALIZE
> > section (w/o its PRINT section) directly located under DFT.
> > the reason being that it "processes" the wavefunction in a similar
> > spirit than SCF, SIC and other sections there.

> I'm sorry this does not make any sense to me.. if I'm computing the
> wannier centers I'm
> expecting to find a print section in the wannier section (LOCALIZE).

we're not getting ahead here. the wannier centers and wannier orbitals
are "localization derived" quanties, just as the molecular dipoles,
molecular states and so on. i still don't get why you want to treat
these differently.

> > then _all_ print keys would be located directly in the DFT%PRINT
> > section and the wannier cubes output would be alongside the density
> > cubes, the wannier centers alongside the dipole moments, molecular
> > states etc. etc.
>
> Maybe.. this does not make too much sense if you think that you may
> want to
> use a certain settings for LOCALIZE for the TOTAL_DIPOLE.. etc.. and
> another

by that reasoning, each of the sections like TOTAL_DIPOLE,
MOLECULAR_DIPOLE,
MOLECULAR_STATES should life directly under DFT%PRINT (or DFT
%PROPERTIES) and
have their _own_ LOCALIZE section.

> set for LINEAR RESPONSE.. so the LOCALIZE section MUST be inside the
> respective
> sections.

well, that is the debatable point. does anyone _need_ that? with the
same
argument i could ask for multiple LOCALIZATION sections, because i
would
like to use different flags in the LOCALIZE section at the same time,
or
multiple MOLECULAR_DIPOLES sections, because i would like to partition
my system differently.

> So.. I still like it is now.. maybe the name of the sections do not
> make too much sense..
> but I'm opened in having more meaningful names..

well, it is not the names, but it is consistency. please note that
i am very much putting a blind eye to the structure of the code here,
but am viewing this from the user's perspective, so while it may be
obvious to have certain choices from the perspective of the
programmer,
it is very confusing for a user. as a user you expect similar "things"
at similar locations.
of course, there is some amount of arbitrariness involved (when
should
something be in DFT%PRINT? when in PROPERTIES?).

[...]

anyways, i think we should move this to a private discussion (skype?)
in the hope to converge to a result that satisfies both of us faster.

cheers,
axel.

[Laino Teodoro]

> we're not getting ahead here. the wannier centers and wannier orbitals
> are "localization derived" quanties, just as the molecular dipoles,
> molecular states and so on. i still don't get why you want to treat
> these differently.

wannier center and orbitals are the direct product of the localization.
I like to consider them a bit more than "derived quantities" (dipoles/
states which use the centers/orbitals)...

Having said that.. I'm not defending the structure how it is now. If
I should follow
my personal taste I would totally change it in a way more like you
said:
each properties based on localization should have its wannier section
for localization..
That would be the way I like it. Maybe when I will really use
localization I will do
that.. at the moment it would require 2/3 days, which I don't have..
volunteers?

>
> anyways, i think we should move this to a private discussion (skype?)
> in the hope to converge to a result that satisfies both of us faster.

sure.. as long as it is a fast (quick/dirty) solution.. ;-)
cheers,
teo

[cavallo]

Hi Axel,

dipole moments for charged species are indeed position dependent. If
you approximate the charge distribution as sum of various multipoles,
only the first non vanishing multipole is position independent. In
neutral molecules the net charge (zeroth-order multipole) is zero so
that the dipole (if not vanishing) is position independent. In
molecules with zero charge and dipole, such as benzene, the quadrupole
is the first non-zero multipole, and it is position independent.
Thus, in charged molecules the total charge is position independent,
but higher multipoles, including the dipole, do not.

As far as I remember, in charged molecules it is "standard" to
calculate the dipole with reference to the center of mass, while
calculating it at the "center of charges" should result in a
vanishing dipole.

More on this, including some refs, at
http://www.ccl.net/chemistry/resources/messages/1995/01/13.002-dir/index.html

Ciao,
Luigi

[Laino Teodoro]

Just a follow up to people interested in the localization.

After a nice oversea skype conversation with Axel we arrived to a final agreement.

The LOCALIZE keyword has been restructured in order to avoid too many

nested sections. That's how the final template looks like:

DFT%PRINT%LOCALIZATION%LOCALIZE has been moved into DFT%LOCALIZE

DFT%PRINT%LOCALIZATION%LOCALIZE%PRINT%WANNIER* moved into DFT%PRINT%LOCALIZATION

LOCALIZATION is therefore now just a container for print_key based on localization. 

the LOCALIZE%PRINT does not exist anymore.

For XAS and LINRES the corresponding LOCALIZE%PRINT%WANNIER* have been moved into XAS%PRINT and LINRES%PRINT.

This should be the best compromise in order to have some logic grouping of common keywords and

avoid, at the same time, too many nested section to print basic quantities.

All changes are already in the CVS.

Cheers

Teo