Re: [Jmol-developers] Abinit workshop

[Fabian D. <Fab...@wa...>]

Hi,

your question (" What's the largest amount of information that might be
emitted by such a  calculation.?") may probably be better answered by
Xavier Gonze.

Concerning phonon dispersion curves and electronic bandstructure, the
amount of information should remain reasonnable. Now, if we consider
storing the electronic density or states, it may become more
problematic.

Fabian  
 

On Thu, 2003-05-15 at 12:14, Peter Murray-Rust wrote:

> At 13:49 08/11/2002 +0100, Fabian Dortu wrote:
> >On Fri, 2002-11-08 at 12:38, E.L. Willighagen wrote:
> > > On Friday 08 November 2002 11:01, Fabian Dortu wrote:
> > > > so I am back from the abinit workshop where I presented Jmol. It seems
> > > > that Jmol is already used by few abinit users/developpers and will touch
> > > > more and more users if I continue to include more abinit features.
> > >
> > >
> > > > Concerning abinit:
> > > >
> > > > There is a strong motivation from the abinit leader that Jmol become
> > > > some kind of complete abinit output reader. To achieve this, he wants to
> > > > provide an abinit output in CML. I have not examine the CML DTD yet, and
> > > > I would like to know, Egon, if there is some specification to store
> > > > energy bands or phonon dispersion curves in CML.
> > >
> > > Ah, interesting... CML can hold all kinds of information for which 
> > there is a
> > > set of general elements, like <float>, <string> etc... If you could 
> > give me
> > > an example on how energy bands and phonon dispersion curves are stored 
> > in the
> > > current ABINIT output, I can propose a way to store it in CML...
> 
> This is very exciting...
> 
> We have been working on developing CMLComp and are now able to manage a 
> considerable number of concepts in XML. For example we have XMLised MOPAC7 
> and the control, parameters, coordinates and output are all in XML. There 
> are many properties for which we do not create markup but use dictionary 
> entries. An example is:
> 
> <scalar dictRef="ccml:dipole" dataType="xsd:float" 
> units="units:debye">1.234</scalar>
> 
> (We recommend CML2 where float and string have been superseded by scalar, 
> array and matrix. See http://www.xml-cml.org).
> 
> Most scalars and simple arrays can be held in this way.
> 
> cmlComp has been tested with several programs and among the new elements are:
> - atomicBasicFunction and basisSet
> - eigen (holds array and matrix for the values/vector)
> - potential and potentialForm
> 
> We are conscious that solid state requires some additional concepts and 
> Brillouin zones/band structure are at the top of the list. We have had 
> Jimmy Stewart (MOPAC) with us for the last two weeks and I've shown your 
> output to him - we think it is an excellent starting basis.
> 
> >for each k-point the number of bands, the k-point coordinates and the
> >energies are given i.e.:
> >
> >kpt 1 : nband=4, kpt= 0.0 0.5 0.0, 0.45456 1.3455 3.5653 6.3454
> >kpt 2 : nband=4, kpt= 0.1 0.5 0.0, 0.47567 1.2456 3.4365 6.1434
> >...
> 
> My initial design is something like:
> 
> <bandList>
>    <band kpt="0 0.5, 0">
>      <array units="units:ev" dictRef="cmlsolid:bandenergy" size="4">0.45456 
> 1.3455 3.5653 6.3454</array>
>    </band>
>    <band kpt="0 1.5, 0">
>      <array units="units:ev" dictRef="cmlsolid:bandenergy">0.47567 1.2456 
> 3.4365 6.1434</array>
>    </band>
> </bandList>
> 
> 
> >*the k-point coordinates are given in reduced coordinates of the
> >reciprocal unit cell.
> >
> >*the energies are usually given in eV
> >
> >*the k-points are given in a specific order to constitute a line i.e.:
> >
> >kpt 1 : nband=4, kpt= 0.00 0.5 0.0,  ....
> >kpt 2 : nband=4, kpt= 0.05 0.5 0.0,  ....
> >kpt 3 : nband=4, kpt= 0.10 0.5 0.0,  ....
> >..
> >..
> >kpt 20 : nband=4, kpt= 0.95 0.5 0.0,  ....
> >kpt 21 : nband=4, kpt= 1.00 0.5 0.0,  ...
> >
> >
> >for the line 0.0 0.5 0.0 --> 1.0 0.5 0.0
> >I think it is important to know to which line a k point belongs because
> >plots are always made along lines. There is a difficulty: a given k
> >point can belong to several lines. This causes duplicate information
> >which is not good in general.
> 
> The design above should manage this.
> 
> >Here is a real part of an ouput file:
> >
> >Eigenvalues (   eV  ) for nkpt=  40  k points:
> >  kpt#   1, nband=  8, wtk=  1.00000, kpt=  0.5000  0.0000  0.0000
> >(reduced coord)
> >   -3.78987  -1.16032   4.69394   4.69394   7.38388   9.23579   9.23579
> >13.45362
> >  kpt#   2, nband=  8, wtk=  1.00000, kpt=  0.4500  0.0000  0.0000
> >(reduced coord)
> >   -3.92925  -0.95943   4.71018   4.71018   7.40285   9.25271   9.25271
> >13.48580
> 
> ...
> 
> >  kpt#  23, nband=  8, wtk=  1.00000, kpt=  0.0000  0.5000  0.5000
> >(reduced coord)
> >   -1.96598  -1.96598   3.00346   3.00346   6.50928   6.50928  15.94975
> >16.44100
> >...
> 
> This should behave in exactly the same manner.
> 
> > >
> > > > In my last CVS commit (sorry for the disturbance btw), I included an
> > > > EnergyBand object to store energy bands along (symmetry) lines. This
> > > > object is already used by ABINITOutputReader but there is no graphical
> > > > output yet.
> > > >
> 
> The benefit of using <array> is that the software already exists - I have 
> even done this in Fortran... The general rule is that for every element you 
> have to write software, so creating lots of elements can be problematic
> 
> What's the largest amount of information that might be emitted by such a 
> calculation.?
> 
> .
> 
> P.
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Jmol-developers mailing list
> Jmo...@li...
> https://lists.sourceforge.net/lists/listinfo/jmol-developers

-- 
Fabian Dortu <Fab...@wa...>