[Fsatom] FSAtom pseudopotential workgroup kickoff

[Asbjorn Christensen]

Dear FSAtom members,

Now is the time to get the working group on pseudopotential formats
going.

A mailing list `fsatom-pp' for the pseudopotential work group has been
created, as the mailing features of the FSAtom wiki
(http://dirac.cnrs-orleans.fr/fsatom_wiki) appears broken, according
to Konrad Hinsen. Please point your browser at
http://nautilus.fis.uc.pt/mailman/listinfo/fsatom-pp if you want to
subscribe or get more information.

At present the list contains the following people, who have already
agreed to participate: 

 asbjorn@fysik.dtu.dk 
 kwj@fysik.dtu.dk 
 lhansen@fysik.dtu.dk 


All material relevant for the workgroup can be put on the fsatom wiki
(http://dirac.cnrs-orleans.fr/fsatom_wiki). We have uploaded several
different example files and also some general information about XML.
There are currently two in-use XML-like/XML formats (one US-PP (UPF), one PAW).  
We think that they should serve as inspiration for our discussion and we
encourage you to browse these formats. We could of course decide to
build on say, the format as recommendation, but this should
be after a detailed discussion about pro's and contras, taking
developments in the future into account.


Below we have put some initial considerations/suggestions about
principles for a new file standard for pseudopotentials. Please put
forward you opinion.

#############################################################
                               General principles 
#############################################################

XML compliance : the format must be strictly XML compliant - otherwise
                 we'll severely limit which XML processors (XML I/O
                 modules) users can apply between the format and their
                 codes.

Extensibility : our format must be able to cover anticipated/projected
                developments within a foreseeable future.  We should
                definitely compile a list of extensions to have in
                mind.

Simplicity: Should preferably be easy to understand so that it is easy
            for new people to understand it.  Logical structure of the format and
            dependence between data elements must be as simple as possible.

Well-definedness: the format must be water-proof and explained in detail, so that we don't 
                  end up with a lot of broken data sets compromising the format.
                  It must work in all meaningful limits (say, if the number of KB projectors are zero).

more general principles?

############################################################
                               Concrete principles 
############################################################

1) Names: One should try to use descriptive names to avoid misunderstandings
          
---------------------------------------------------------------------------------------
2) Data redundancy: one can pick different options here 

    2a) Minimal: only include data, which are *not* implied by other data elements This
                 will require some work for all on the code side (to generate the
                 implied data that you happen to write in your pspot format)
                        
     2b) The union set: we ask all participants about what data their codes need to read and take the
                        union set as defining the format - it will require some 
                        work for all the pspot generation codes (to generate the implied data that other codes need)
     2c) Principle of least work: we take a slightly redundant data set, so that we all on average need to do
                                  least work on our codes/pspot generators
---------------------------------------------------------------------------------------        
3) How much should the format cover?
         a) Only US-PP
         b) All KB representable pspot types (US-PP, NC, local, ..?)
         c) All pspot types *and* PAW
     
   Option c) is clearly the most demanding but everybody could in the long run benefit from a common format.
   PAW may be formally be considered an extension to to US-PP, so the format should be able to cover both.
   The direction in the field is clearly a migration from pseudopotentials toward PAW.
   A unified format will clearly ease the situation.
---------------------------------------------------------------------------------------
4) How modular/general should the format be? 

    Modularity/generality requires some extra coding work now, but gives a strategic advantage.
    Should different grids for different objects be allowed?
    Should we allow general grids (log grids, linear grids, wavelet representations, ...)
    Should we allow data to appear either in real/recip space or fix a space?
    
    We think we should make things simple and settle for atomic Hartree/Rydberg units for all data
---------------------------------------------------------------------------------------
5)  Call for data entities needed by other ab initio codes (have a look and compare your needs with UPF)


With best regards, Karsten, Asbjorn

-- 
Asbjorn Christensen, PhD
CAMP, Physics Department, Building 307
Technical University of Denmark, 
DK-2800 Lyngby, Denmark
   
E-mail:       asbjorn@fysik.dtu.dk
Telephone: (+45) 45 25 32 27
Telefax:      (+45) 45 93 23 99
office:         room 257