Yambo Community Forum

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
This causes Yambo initialization to fail with:
In interfaces/e2y/e2y_db1.F:272 the number of electrons is explicitly set to -1,
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

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 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.

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