Number of electrons in e2y

Various technical topics such as parallelism and efficiency, netCDF problems, the Yambo code structure itself, are posted here.

Moderators: Daniele Varsano, andrea.ferretti, andrea marini, Conor Hogan, myrta gruning

Number of electrons in e2y

Postby xavierandrade » Sun Mar 20, 2011 1:40 am

Hi,
I am trying to get data from Octopus into Yambo by using the etsf file format. For the moment I succeded in creating a Yambo db with e2y from an Octopus generated file.

The first problem I am having is that the number of electrons reported is -1. This is the output of yambo -D

Code: Select all
[RD./SAVE//ns.db1]------------------------------------------
 Bands                           : 16
 K-points                        :  4
 G-vectors             [RL space]: 1
 Components       [wavefunctions]: 1
 Symmetries       [spatial+T-rev]:  48
 Spinor components               : 1
 Spin polarizations              : 1
 Temperature                 [ev]: 0.000000
 Electrons                       :-1.000000
 WF G-vectors                    : 1
 Max atoms/species               :  8
 No. of atom species             : 1
- S/N 008615 ---------------------------- v.03.02.03 r.696 -
[RD./SAVE//ns.wf]-------------------------------------------
 Bands in each block             : 16
 Blocks                          : 1
- S/N 008615 ---------------------------- v.03.02.03 r.696 -


This causes Yambo initialization to fail with:

Code: Select all
 <---> [01] Files & I/O Directories
 <---> [02] CORE Variables Setup
 <---> [02.01] Unit cells
 <---> [02.02] Symmetries
 <---> [02.03] RL shells
 <---> [02.04] K-grid lattice
 <---> [02.05] Energies [ev] & Occupations

[ERROR] STOP signal received while in :[02.05] Energies [ev] & Occupations
[ERROR]Impossible to converge the Fermi Level


In interfaces/e2y/e2y_db1.F:272 the number of electrons is explicitly set to -1,

Code: Select all
    default_nel = -1  ! Until fixed in ETSF file. Is calculated later.


But it is not being calculated later, because it depends on some abinit non-standard data (line 36). If I comment that line the number is properly read.

About the lines

G-vectors [RL space]: 1
Components [wavefunctions]: 1

does it mean that e2y didn't read the wave-functions properly? Octopus writes the functions in real-space in the ETSF file.

Thanks
Xavier Andrade
Department of Chemistry and Chemical Biology, Harvard University (United States)
xavierandrade
 
Posts: 2
Joined: Fri Mar 18, 2011 3:03 pm

Re: Number of electrons in e2y

Postby andrea marini » Mon Mar 21, 2011 10:08 am

xavierandrade wrote:Hi,
I am trying to get data from Octopus into Yambo by using the etsf file format.


Dear Xavier,

nice to see you on board.

Conor is the local expert of the e2y interface. He wrote it and he will help you. I am sure the problem on the number of electrons is quite easy to fix. You could also attach the "ns.db1" or the contents of it obtained by using the ncdump command. In this way Conor will be able to see the value of the variables.

Instead, I am more concerned about these lines

xavierandrade wrote:About the lines

G-vectors [RL space]: 1
Components [wavefunctions]: 1

does it mean that e2y didn't read the wave-functions properly? Octopus writes the functions in real-space in the ETSF file.


Unfortunately Yambo can read wave-functions only in reciprocal space. These are, then, Fourier transformed when needed. Altough some of the sections of the code could be written in order to not Fourier transform this is not possible for most of the code features. Therefore the easiest solution would be to pseudize somehow the wave-functions by removing the oscillations due to the core region and pass the Fourier coefficients to Yambo introducing a dummy unit cell.

Andrea
Andrea MARINI
Istituto di Struttura della Materia, CNR, (Italy)
User avatar
andrea marini
 
Posts: 447
Joined: Mon Mar 16, 2009 4:27 pm

Re: Number of electrons in e2y

Postby xavierandrade » Mon Mar 21, 2011 3:28 pm

andrea marini wrote:Conor is the local expert of the e2y interface. He wrote it and he will help you. I am sure the problem on the number of electrons is quite easy to fix. You could also attach the "ns.db1" or the contents of it obtained by using the ncdump command. In this way Conor will be able to see the value of the variables.


Yes, this is simple to fix. In fact by removing the line I mentioned the number is read properly. We could also make Octopus add the additional variable that Yambo uses, but this is not very elegant and goes against the ETSF file format standard and its purpose.

andrea marini wrote:Instead, I am more concerned about these lines

xavierandrade wrote:About the lines

G-vectors [RL space]: 1
Components [wavefunctions]: 1

does it mean that e2y didn't read the wave-functions properly? Octopus writes the functions in real-space in the ETSF file.


Unfortunately Yambo can read wave-functions only in reciprocal space. These are, then, Fourier transformed when needed. Altough some of the sections of the code could be written in order to not Fourier transform this is not possible for most of the code features. Therefore the easiest solution would be to pseudize somehow the wave-functions by removing the oscillations due to the core region and pass the Fourier coefficients to Yambo introducing a dummy unit cell.


Since Octopus normally uses a uniform real space grid and pseudo-potentials I think it is just a matter of Fourier transforming the wave-functions. So from the numerical point of view there no problems (at least for the moment).

We have the machinery to do the Fourier transform in Octopus, but we get a cubic grid of G vectors. I could put the list of G vectors and the wave-functions in an ETSF file, but will Yambo be able to work with this and convert it to a spherical grid? Are there any special needs with respect to the G vectors? Do they need to form a sphere? Is a specific ordering of the G vectors required? The ETSF format does not say anything about this.
Xavier Andrade
Department of Chemistry and Chemical Biology, Harvard University (United States)
xavierandrade
 
Posts: 2
Joined: Fri Mar 18, 2011 3:03 pm

Re: Number of electrons in e2y

Postby Conor Hogan » Tue Mar 22, 2011 4:42 pm

Hi Xavier,
Welcome aboard. Sorry for not responding sooner, have been having some problems logging in! Thank you, spambots.

xavierandrade wrote:Yes, this is simple to fix. In fact by removing the line I mentioned the number is read properly. We could also make Octopus add the additional variable that Yambo uses, but this is not very elegant and goes against the ETSF file format standard and its purpose.

Right - as you have understood, the problem was related to Abinit, and since the only ETSF file I had available was from Abinit, I left that line in for checking. Later it gets rewritten correctly anyway if a KSS generated Abinit file is used. Now that a few people are moving towards using e2y, it might be appropriate to add some runtime flags for the appropriate codes (e.g. to reorder G-vectors, see below). In any case I'll take out the offending line from the source.

xavierandrade wrote:We have the machinery to do the Fourier transform in Octopus, but we get a cubic grid of G vectors. I could put the list of G vectors and the wave-functions in an ETSF file, but will Yambo be able to work with this and convert it to a spherical grid? Are there any special needs with respect to the G vectors? Do they need to form a sphere? Is a specific ordering of the G vectors required? The ETSF format does not say anything about this.


Clearly I never had in mind the intention of reading stuff in a real space grid...

This certainly won't work immediately since the two codes we have used up to now (pw,abinit) spit out ordered master lists of G vectors created on a sphere defined by the cutoff, and so yambo assumes the first G to be G=0. The main routine to handle the creation of the G-vector shells is src/setup/G_shells_finder.F. Just looking at the routine now, I think that condition might be all that is necessary. The maximum complete shell should truncate your cubic grid, but I wouldnt bet on it working everywhere. Also efficiency might be a problem later if you left the default ordering. So I would suggest to set up a sphere of G's centred on the origin, ordered by modulus and try that...

Conor
Dr. Conor Hogan
CNR-ISM, via Fosso del Cavaliere, 00133 Roma, Italy;
Department of Physics and European Theoretical Spectroscopy Facility (ETSF),
University of Rome "Tor Vergata".
User avatar
Conor Hogan
 
Posts: 143
Joined: Tue Mar 17, 2009 12:17 pm


Return to Technical Issues

Who is online

Users browsing this forum: No registered users and 1 guest