[Pw_forum] Charge Density

[Paul M. Grant]

I've been assuming the units of charge density as stored in *.save and used
in plotrho and accessed by xcrysden are scaled as (number of
electrons/angstroms^3), but just thought I'd better check. Looking at the
codes, examples and tutorials available for PWscf, I couldn't find any
explicit confirmation (I'm sure there is somewhere) that this is indeed the
case. I could try performing a volumetric integration on some simple
example, but thought I'd ask the community first. It seems this is the case
just by looking at the contours and surfaces produced by xcrysden, but I'm
not too sure what the cryptic notation "delta n(r)" defines. I take it's
the differential between isolevels in the units I've been using.

Also, some time ago (about three months!), I switched from espresso-3.2.3 to
o-sesame, and noticed that the charge density files in *.save are in a *.dat
binary format rather than *.xml. What's going to be the future standard?

Finally, and I think I asked about this before, is there a developers guide
to the bowels of pw.x? The makefile links an enormous number of object
files and I suppose one could figure this all out. Surely, there have been
courses given at SISSA on its internal structure, if only in the shape of a
flow chart. If these lectures are in Italian, no problem, and I would make
a translation available to all.

Ciao, -Paul

Paul M. Grant, PhD
Principal, W2AGZ Technologies
Visiting Scholar, Applied Physics, Stanford University
EPRI Science Fellow (Retired)
IBM Research Staff Member Emeritus
w2agz at pacbell.net
http://www.w2agz.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.democritos.it/pipermail/pw_forum/attachments/20080510/10956c64/attachment.htm

[Lorenzo Paulatto]

Post by Paul M. Grant
in plotrho and accessed by xcrysden are scaled as (number of
electrons/angstroms^3), but just thought I'd better check.

Dear Paul,
internally the charge density is normalized to the number of electrons
(the code tells it at the beginning: starting charge X, renormalised to
Y).

There could be some problem because internal units are bohr, while xcd
uses angs, in any case the sum of the charge density on a grid of equally
spaced points must yield the number of electrons.

Post by Paul M. Grant
What's going to be the future standard?

I'm not sure, but I think only the suffix changed.

Post by Paul M. Grant
Finally, and I think I asked about this before, is there a developers
guide to the bowels of pw.x?

I fear there is no such guide, the core of the code is in electrons.f90,
which is called from pwscf.f90. Most of the files are extremely technical
and doesn't have to be understood. Anyway, I think such a guide could be
very useful, but I can't think of anybody to write it.

regards
--
Lorenzo Paulatto
SISSA & DEMOCRITOS (Trieste)
[phone]
http://people.sissa.it/~paulatto/


----------------------------------------------------------------
SISSA Webmail https://webmail.sissa.it/
Powered by SquirrelMail http://www.squirrelmail.org/

[Paolo Giannozzi]

I?ve been assuming the units of charge density as stored in *.save
and used in plotrho and accessed by xcrysden are scaled as (number
of electrons/angstroms^3)

number of electrons/(a.u.)^3 is a better assumption (no warranty).
PWscf uses atomic
(Rydberg) units everywhere, unless explicitly specified. In order to
preserve genetic
diversity, guess what? CP uses Hartree atomic units.

Also, some time ago (about three months!), I switched from
espresso-3.2.3 to o-sesame

you mean: the development version in the cvs repository, that for
historical reasons has 'o-sesame' as root directory?

and noticed that the charge density files in *.save are in a *.dat
binary format rather than *.xml. What?s going to be the future
standard?

it was done to fix some inconsistencies in the naming convention:
http://www.democritos.it:8888/O-sesame/chngview?cn=5687
See also the following for recent changes of the file format:
http://www.democritos.it:8888/O-sesame/chngview?cn=5744
http://www.democritos.it:8888/O-sesame/chngview?cn=5795
It is unfortunate that the file format had to be changed (once again)
at this stage, but these should hopefully be the last major changes
that can affect other people's software reading those files, if any
exists (Q-E will keep reading old files).

Finally, and I think I asked about this before, is there a
developers guide to the bowels of pw.x? The makefile links an
enormous number of object files and I suppose one could figure this
all out.

the closest thing to a developer's guide is, well, the "developer
manual"
linked in the main page of the wiki:
http://www.quantum-espresso.org/wiki/index.php/Developer_Manual
It used to be available as a latex file in previous versions. I wrote
it as
a template some time ago and from time to time I add to it some piece
of information that I deem suitable. One can find there a few important
things like the specifications of the file format, but what is
missing vastly
exceeds what is present.

Documentation of what a single *.f90 does is not supposed to be
written in the guide, though, but in each file. Sometimes there is
something useful (although in an unstructured way), sometimes
there is nothing useful, depending on the mood of the developer.

There are no flow charts of anything. If anybody knows any simple
automated way (e.g. by transforming code into linkable html) to
locate calls, variables in modules, etc, it would be very useful.

Paolo
---
Paolo Giannozzi, Dept of Physics, University of Udine
via delle Scienze 208, 33100 Udine, Italy
Phone [phone], fax [phone]

[Axel Kohlmeyer]

On Sun, 11 May 2008, Paolo Giannozzi wrote:

hi paolo,

[...]

PG> Documentation of what a single *.f90 does is not supposed to be
PG> written in the guide, though, but in each file. Sometimes there is
PG> something useful (although in an unstructured way), sometimes
PG> there is nothing useful, depending on the mood of the developer.

...which largely reflects the way software development works
these days in academic environments. there are no credits to be had
for writing something in a way that it can serve as a foundation for
future projects or so that it fits well into the existing code.
you only get credit for getting it done (through the publications).
there is nobody around to teach how to program well, altogether and
for a large package program in particular. one has to be happy if
people know a programming language well enough to get the job done.
just take a survey of how many people these days ask "is there a
feature XXX, and if not can somebody please implement it?" instead
of "where should i start to implement XXX?".

the fact that a correlated and concerted effort to improve the overall
code interoperability and consistency will help _much_ more in the long
run is frequently ignored. this is what is so great about the Q-E
effort, that there _is_ backing for going those extra steps and that
there _are_ people willing to do this, and the improvements in the code
over time are proof for it. one cannot regard this high enough, because
for the reasons from above, this ususally comes at the expense of
limiting ones own carreer.

PG> There are no flow charts of anything. If anybody knows any simple
PG> automated way (e.g. by transforming code into linkable html) to
PG> locate calls, variables in modules, etc, it would be very useful.

the latest version of doxygen has fortran 90/95 support (cp2k uses it),
that would also allow to place coded comments into the code to associate
functions and modules with (short) descriptions which can be seen from
the overview pages (and lots of html stuff...). it looks a bit odd,
since doxygen was written for C++.

there also is a python script the thierry deutsch wrote looooong ago
for CPMD. it does a pretty good job, but would need some adjustments.
i'm certain that thierry would give his blessing if somebody adapts
it to work with QE.

are there any python hackers around that need a challenge? :-)

cheers,
axel.

PG>
PG> Paolo
PG> ---
PG> Paolo Giannozzi, Dept of Physics, University of Udine
PG> via delle Scienze 208, 33100 Udine, Italy
PG> Phone [phone], fax [phone]
PG>
PG>
PG>
PG> _______________________________________________
PG> Pw_forum mailing list
PG> Pw_forum at pwscf.org
PG> http://www.democritos.it/mailman/listinfo/pw_forum
PG>

[Axel Kohlmeyer]

On Sun, 11 May 2008, Paolo Giannozzi wrote:

hi paolo,

[...]

PG> Documentation of what a single *.f90 does is not supposed to be
PG> written in the guide, though, but in each file. Sometimes there is
PG> something useful (although in an unstructured way), sometimes
PG> there is nothing useful, depending on the mood of the developer.

...which largely reflects the way software development works
these days in academic environments. there are no credits to be had
for writing something in a way that it can serve as a foundation for
future projects or so that it fits well into the existing code.
you only get credit for getting it done (through the publications).
there is nobody around to teach how to program well, altogether and
for a large package program in particular. one has to be happy if
people know a programming language well enough to get the job done.
just take a survey of how many people these days ask "is there a
feature XXX, and if not can somebody please implement it?" instead
of "where should i start to implement XXX?".

the fact that a correlated and concerted effort to improve the overall
code interoperability and consistency will help _much_ more in the long
run is frequently ignored. this is what is so great about the Q-E
effort, that there _is_ backing for going those extra steps and that
there _are_ people willing to do this, and the improvements in the code
over time are proof for it. one cannot regard this high enough, because
for the reasons from above, this ususally comes at the expense of
limiting ones own carreer.

PG> There are no flow charts of anything. If anybody knows any simple
PG> automated way (e.g. by transforming code into linkable html) to
PG> locate calls, variables in modules, etc, it would be very useful.

the latest version of doxygen has fortran 90/95 support (cp2k uses it),
that would also allow to place coded comments into the code to associate
functions and modules with (short) descriptions which can be seen from
the overview pages (and lots of html stuff...). it looks a bit odd,
since doxygen was written for C++.

there also is a python script the thierry deutsch wrote looooong ago
for CPMD. it does a pretty good job, but would need some adjustments.
i'm certain that thierry would give his blessing if somebody adapts
it to work with QE.

are there any python hackers around that need a challenge? :-)

cheers,
axel.

PG>
PG> Paolo
PG> ---
PG> Paolo Giannozzi, Dept of Physics, University of Udine
PG> via delle Scienze 208, 33100 Udine, Italy
PG> Phone [phone], fax [phone]
PG>
PG>
PG>
PG> _______________________________________________
PG> Pw_forum mailing list
PG> Pw_forum at pwscf.org
PG> http://www.democritos.it/mailman/listinfo/pw_forum
PG>

[Paul M. Grant]

I've been assuming the units of charge density as stored in *.save and used
in plotrho and accessed by xcrysden are scaled as (number of
electrons/angstroms^3), but just thought I'd better check. Looking at the
codes, examples and tutorials available for PWscf, I couldn't find any
explicit confirmation (I'm sure there is somewhere) that this is indeed the
case. I could try performing a volumetric integration on some simple
example, but thought I'd ask the community first. It seems this is the case
just by looking at the contours and surfaces produced by xcrysden, but I'm
not too sure what the cryptic notation "delta n(r)" defines. I take it's
the differential between isolevels in the units I've been using.

Also, some time ago (about three months!), I switched from espresso-3.2.3 to
o-sesame, and noticed that the charge density files in *.save are in a *.dat
binary format rather than *.xml. What's going to be the future standard?

Finally, and I think I asked about this before, is there a developers guide
to the bowels of pw.x? The makefile links an enormous number of object
files and I suppose one could figure this all out. Surely, there have been
courses given at SISSA on its internal structure, if only in the shape of a
flow chart. If these lectures are in Italian, no problem, and I would make
a translation available to all.

Ciao, -Paul

Paul M. Grant, PhD
Principal, W2AGZ Technologies
Visiting Scholar, Applied Physics, Stanford University
EPRI Science Fellow (Retired)
IBM Research Staff Member Emeritus
w2agz at pacbell.net
http://www.w2agz.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pwscf.org/pipermail/pw_forum/attachments/20080510/10956c64/attachment-0002.html

[Lorenzo Paulatto]

Post by Paul M. Grant
in plotrho and accessed by xcrysden are scaled as (number of
electrons/angstroms^3), but just thought I'd better check.

Dear Paul,
internally the charge density is normalized to the number of electrons
(the code tells it at the beginning: starting charge X, renormalised to
Y).

There could be some problem because internal units are bohr, while xcd
uses angs, in any case the sum of the charge density on a grid of equally
spaced points must yield the number of electrons.

Post by Paul M. Grant
What's going to be the future standard?

I'm not sure, but I think only the suffix changed.

Post by Paul M. Grant
Finally, and I think I asked about this before, is there a developers
guide to the bowels of pw.x?

I fear there is no such guide, the core of the code is in electrons.f90,
which is called from pwscf.f90. Most of the files are extremely technical
and doesn't have to be understood. Anyway, I think such a guide could be
very useful, but I can't think of anybody to write it.

regards
--
Lorenzo Paulatto
SISSA & DEMOCRITOS (Trieste)
[phone]
http://people.sissa.it/~paulatto/


----------------------------------------------------------------
SISSA Webmail https://webmail.sissa.it/
Powered by SquirrelMail http://www.squirrelmail.org/

[Paolo Giannozzi]

I?ve been assuming the units of charge density as stored in *.save
and used in plotrho and accessed by xcrysden are scaled as (number
of electrons/angstroms^3)

number of electrons/(a.u.)^3 is a better assumption (no warranty).
PWscf uses atomic
(Rydberg) units everywhere, unless explicitly specified. In order to
preserve genetic
diversity, guess what? CP uses Hartree atomic units.

Also, some time ago (about three months!), I switched from
espresso-3.2.3 to o-sesame

you mean: the development version in the cvs repository, that for
historical reasons has 'o-sesame' as root directory?

and noticed that the charge density files in *.save are in a *.dat
binary format rather than *.xml. What?s going to be the future
standard?

it was done to fix some inconsistencies in the naming convention:
http://www.democritos.it:8888/O-sesame/chngview?cn=5687
See also the following for recent changes of the file format:
http://www.democritos.it:8888/O-sesame/chngview?cn=5744
http://www.democritos.it:8888/O-sesame/chngview?cn=5795
It is unfortunate that the file format had to be changed (once again)
at this stage, but these should hopefully be the last major changes
that can affect other people's software reading those files, if any
exists (Q-E will keep reading old files).

Finally, and I think I asked about this before, is there a
developers guide to the bowels of pw.x? The makefile links an
enormous number of object files and I suppose one could figure this
all out.

the closest thing to a developer's guide is, well, the "developer
manual"
linked in the main page of the wiki:
http://www.quantum-espresso.org/wiki/index.php/Developer_Manual
It used to be available as a latex file in previous versions. I wrote
it as
a template some time ago and from time to time I add to it some piece
of information that I deem suitable. One can find there a few important
things like the specifications of the file format, but what is
missing vastly
exceeds what is present.

Documentation of what a single *.f90 does is not supposed to be
written in the guide, though, but in each file. Sometimes there is
something useful (although in an unstructured way), sometimes
there is nothing useful, depending on the mood of the developer.

There are no flow charts of anything. If anybody knows any simple
automated way (e.g. by transforming code into linkable html) to
locate calls, variables in modules, etc, it would be very useful.

Paolo
---
Paolo Giannozzi, Dept of Physics, University of Udine
via delle Scienze 208, 33100 Udine, Italy
Phone [phone], fax [phone]