RAS cutoff keyword ignored

[elena.mol]

Dear all,
I am using Yambo (version 3.4.2) for RAS calculations.
What are the correct input keywords for calculating RAS spectra with the use of a spatial cutoff?

Following the Yambo "Surface spectroscopy" tutorial, I uncommented the "Cutoff" keyword in the yambo.in file (obtained by issuing: yambo_surf -s r ), and I set the CutZero and CutStep variables to the desired values for my system... but the result of running yambo_surf with this input remains identical to the one obtained with "Cutoff" commented, both for the "o...." files containing the spectra and for the "r....." file: in particular the latter explicitly states "No cut off function in matrix elements" (in the [04.01] section: Surface geometry and spectral analysis), and the cutoff-related variable values reported at the bottom of o.... and r... files are

# | #Cutoff # [RAS] Cutoff mode (Uncomment to use)
# | CutZero= 0.000000 # [RAS] Zero position of cutoff fn (Frac)
# | CutStep= 1.000000 # [RAS] Width of cutoff function (Frac)

irrespective of the values I gave in yambo.in, i.e. they are left at their default values.
Also, the variable "Layers", and the following line, specifying the number of atomic layers in cell/slab/bulk, which I commented in the input, appear uncommented in the final report (o.... and r.... files).

I obtain the same results also if I set
Cutoff="on"
in the input file, instead of simply uncommenting the Cutoff variable.

Apart from this problem, my yambo_surf executable works regularly, and gives reasonable results.

Is this a known issue, or am I forgetting any relevant input keywords?

Thanks in advance
Best regards
Elena Molteni
Department of Physics
Universita' degli Studi di Milano
via Celoria, 16
I-20133, Milan, Italy
and European Theoretical Spectroscopy Facility (ETSF)
http://www.etsf.eu

[Conor Hogan]

Hi Elena,
Thanks for pointing out the issue, I'll have a look at it.
It's very possible that something wasn't updated between versions since there is not much interest in this module.
Which version of yambo are you using precisely? (tarball or svn?)
Conor

[elena.mol]

Hi Conor, thanks for the fast reply!
I have compiled yambo starting from an svn version: the directory is named
"/2016.01.11_yambo_rev_94", but in the ouput files I obtain with these executables, the header states "GPL Version 3.4.2 Revision 93". I hope I have not mis-named the Yambo directory for some reason....
(It is one out of several different versions I tried to compile months ago...) Anyway the output header should be reliable, I guess....
Thanks again
best
Elena

Hi Elena,
Thanks for pointing out the issue, I'll have a look at it.
It's very possible that something wasn't updated between versions since there is not much interest in this module.
Which version of yambo are you using precisely? (tarball or svn?)
Conor

[Conor Hogan]

Hi Elena,
I downloaded the latest tarball (3.4.2) and svn version (3.4.2 v93) and they both run the tutorial correctly, with proper use of the cutoff, so I don't know what is going wrong... Can you post your report files and log files for the run: "yambo_surf -F INPUTS/04_RAS_front" , and list the contents of the SAVE directory? Thanks!
Conor

[elena.mol]

Hi Conor,
also in my case the GaAs001-c4x4 tutorial runs correctly with the yambo version I am using, and it reads the cutoff keywords. However, when I use the same yambo_surf executable on the system I am trying to run at the moment, i.e. clean Si(001), the code reads all my input keywords correctly *except for the keywords related to the use of a cutoff*, which are apparently always read as:

| #Cutoff # [RAS] Cutoff mode (Uncomment to use)
| CutZero= 0.000000 # [RAS] Zero position of cutoff fn (Frac)
| CutStep= 1.000000 # [RAS] Width of cutoff function (Frac)

(as reported in the r.... and o..... files) whatever values I give in input, i.e. "Cutoff" commented/uncommented, ...even if I put: Cutoff="on" (probably wrong syntax).....

Some further details about my system: clean Si(001) 4x2, modeled by a 8-layer-slab, with 8 Si atoms per layer + 16 H atoms to saturate the bottom layer (asymmetric slab). Of course the system I am "really" studying also has adsorbed molecules on the surface, and it gives reasonable results *without using a cutoff*, but at the moment I would like to check the effect of a spatial cutoff on the "simpler" clean Si(001) surface. I am performing the SCF and non-SCF runs with Abinit, then using a2y on the KSS file in order to create the /SAVE dir. (For the GaAs tutorial I performed the SCF and non-SCF runs with PWSCF... but I hope the problem does not depend on the initial code used...).


I am attaching my Abinit non-SCF input file, my yambo_surf input file for RAS calculation, and its report file.

Thanks for any suggestions
Best
Elena Molteni
Department of Physics
Universita' degli Studi di Milano
via Celoria, 16
I-20133, Milan, Italy
and European Theoretical Spectroscopy Facility (ETSF)
http://www.etsf.eu

[Conor Hogan]

Dear Elena,
Thanks for the files - apologies for not replying yet, I'm looking into it.
Conor

[Conor Hogan]

Dear Elena,
I think the problem is the lines:
#% Layers
# 20.00000 | 10.00000 | 0.00000 | # [RAS] Atomic layers in cell/slab/bulk
%
in your input file. With them, I see the same problem; no problem with the default:
% Layers
20.00000 | 10.00000 | 0.00000 | # [RAS] Atomic layers in cell/slab/bulk
%
or even with
#% Layers
# 20.00000 | 10.00000 | 0.00000 | # [RAS] Atomic layers in cell/slab/bulk
#% <- note the extra comment here to finish off the block
So clearly something weird happens with the parser if you don't close the block properly.

In any case a couple of comments:
- If you use the cutoff, or don't wish to subtract some bulk layers from the cell epsilon (bulk = 0.0000) [which is only needed for EELS anyway], then the Layers block will not affect the RAS at all.
- Remember to do
yambo_surf -s r -V RL
to switch on the option for FFTGvecs:
FFTGvecs= 5 Ry # [FFT] Plane-waves
otherwise you will use the full set of G-vectors. This will be very very slow with the cutoff, due to the double sum. You might want to do your cutoff tests with a low value of FFTGvecs before deciding on a necessary value.
- For some reason yambo did not find any q-points from your mesh made with Abinit, as it appears not to be uniform. If doesn't matter if you just want q->0 but keep an eye on that in general!
Let me know if you have more problems.
Regards,
Conor

[elena.mol]

Dear Conor
thanks a lot for your reply, and also for your additional suggestions.

Yes, your "recipe" works: it appears the error was due to the "partially commented" Layers block.
Now Yambo reads the cutoff keywords correctly, with the values I have set in the input file. (Unfortunately it then stops with a NetCDF error "Numeric conversion not representable", but at the moment I am in a hurry and I do not have the necessary time to look into it; quite probably the new error has nothing to do with the cutoff keywords; maybe I made a mess with my files (e.g. the /SAVE directory... due to re-running / moving / removing files during multiple tests, or maybe I am running yambo_surf from a different yambo version w.r.t. the one I used to create the /SAVE... or something like that).

Thanks again
regards
Elena

Dear Elena,
I think the problem is the lines:
#% Layers
# 20.00000 | 10.00000 | 0.00000 | # [RAS] Atomic layers in cell/slab/bulk
%
in your input file. With them, I see the same problem; no problem with the default:
% Layers
20.00000 | 10.00000 | 0.00000 | # [RAS] Atomic layers in cell/slab/bulk
%
or even with
#% Layers
# 20.00000 | 10.00000 | 0.00000 | # [RAS] Atomic layers in cell/slab/bulk
#% <- note the extra comment here to finish off the block
So clearly something weird happens with the parser if you don't close the block properly.

In any case a couple of comments:
- If you use the cutoff, or don't wish to subtract some bulk layers from the cell epsilon (bulk = 0.0000) [which is only needed for EELS anyway], then the Layers block will not affect the RAS at all.
- Remember to do
yambo_surf -s r -V RL
to switch on the option for FFTGvecs:
FFTGvecs= 5 Ry # [FFT] Plane-waves
otherwise you will use the full set of G-vectors. This will be very very slow with the cutoff, due to the double sum. You might want to do your cutoff tests with a low value of FFTGvecs before deciding on a necessary value.
- For some reason yambo did not find any q-points from your mesh made with Abinit, as it appears not to be uniform. If doesn't matter if you just want q->0 but keep an eye on that in general!
Let me know if you have more problems.
Regards,
Conor