Dear colleagues,
I am trying to calculate I-V characteristics for typical (Left electrode) - (Device) – (Right electrode) system. Besides the well-known problem of difficult electronic convergence in NEGF, I notice that final atomic forces along transport direction near the electrode-device region increase largely while increasing bias voltage. Please, see dashed ellipses which denote these “problematic atoms” and Trans.fdf file attached.
For instance,
voltage = 0 V: forces ~ 0.005 eV/Ang
voltage = 0.01 V: forces ~ 2.5 eV/Ang
voltage = 0.04 V: forces ~ 10 eV/Ang
voltage = 0.08 V: forces ~ 22 eV/Ang
Other atoms also possess larger forces while increasing bias voltage, but much less than these two “boarder” atomic layers near the device region. Intuitively I can guess that some of my input parameters lead to a wrong seam (inter-connection) of bulk-like electrode and device region.
Maybe some of the following flags (or related to them) are used wrongly:
TS.Elecs.Bulk true
TS.Elecs.DM.Update cross-terms
Or maybe I should modify some TS contours while changing voltage. Now contour definitions are kept constant for each bias.
To be noticed, for each new bias the previous TSDE file is used to accelerate electronic convergence (DM and H criteria) and for each bias it is succesfully converged. But, again, forces become bigger and bigger.
So, would you mind answering two main questions?
1) Do these large forces are really wrong or it’s some methodological artefact and I should simply ignore it?
2) If such force enlargement is a bad symptom, how to fix it?
Thank you in advance for any suggestion or comment.
Forces on atoms in the electrode region can safely be ignored when using "bulk" electrodes. So nothing to worry about here. The electrode regions are "left out" of the calculation anyways. :)
Thank you a lot for clarification, Nick Rübner Papior !
May I ask you a few more questions about two abovementioned flags?
Are there some examples of when we should use:
1) TS.Elecs.Bulk False (instead of True)
2) TS.Elecs.DM.Update all or none (instead of cross-terms). Honestly, I set "cross-terms" intuitively (I study MTJ magnetoresistance) and didn't figure out any positive or negative effect of that.
Perhaps you could tell me what you think it means after reading the documentation, then I can hopefully improve the documentation simultaneously!
Nick Rübner Papior
Nice suggestion! Guess it's general problem when even comprehensive manual, e.g. Siesta 4.1-b4, has a lack of any examples which may undercover physical meaning in one sentence instead of pure statement like "Eta - control the imaginary part of the surface Green function for this electrode". How much does is affect? Are there cases when I really need to pay attention to this flag? If not, short sentence like "In the most cases you should keep this and this and that flags constant, unless " will definitely calm down 99% of users.
For instance, I really enjoy 10.4 part of the Manual (Electrodes) since it's written by human language with full sentences: "The electrode must be large enough (in the semi-infinite direction) so that orbitals within the unit cell only interact with a single nearest neighbor cell in the semi-infinite direction..."
Of course, such comprehension comes from the extreme importance of the main rule: no overlapping with far neighbors otherwise you can't construct one-by-one semi-infinite "chain" of perfect bulk electrodes from .TSHS file.
So, my final thought is obvious: as more detailed and human-readable text with examples, as better for the final users :-)
Generally that the only reason why users of Siesta (and any other packages) are googling forums and dashboards starting from 2000's and read them one-by-one searching for particular examples and explanations :D Yes, there are a lot of slides and even several Transiesta school materials, however they mostly include the same list of flags and equations without "real" cases and examples.
How it could be?
"FlagXXX = A or B. Use A in the most cases unless . FlagYYY = C or D. Choose the flag upon your system and test carefully to achieve better convergence".
And I really wish that such examples have to be for any flag that developers consider as important one to be taken into account.
As for the abovementioned flags,
1) TS.Elecs.Bulk true (or false)
Our scattering region (whole POSITIONS.fdf file) always includes electrode parts (blue region in my picture above described in %block TS.Elec.Left and Right) and central part (red device region). When flag is True, it forcibly assigns electrode region (blue) to have hamiltonian from the previusly calculated .TSHS files (perfect bulk). If False, whole scattering region (blue + red) calculates its Hamiltonian "from the scratch" in Siesta loop and doesn't use existing .TSHS hamiltonian for these blue region of the scattering part.
If I'm right, then I can't imagine why someone may wish to set False and keep blue region not "bulk-like". Any example, please? At least, the Manual directly indicates to make scattering region as large as possible and separate two electrodes via device part as much as possible: only then electrode parts (blue) will be really "bulk-like".
2) TS.Elecs.DM.Update cross-terms (or none or all)
"If all, both the density matrix elements in the electrode and the coupling elements between the electrode and scattering region are updated."
In my opinion, sometimes in the Manual it's unclear does "electrode" mean electrode part of scattering region? (blue region in the question 1) or "electrode" means previously calculated semi-infinite bulk-like electrode (.TSHS file).
To date I always explained this flag using the first explanation (as in question 1). But now I'm not totally sure.
Anyway, if TS.Elec.bulk = False, then obviously electrode part should be fully calculated from the scratch, therefore, DM-update = all automatically. However, if TS.elec.bulk = True (as I always do), then you may choose all|cross-terms|none. And actually I don't undestand which of them we choose in which case. As I imagine that, we should have some seamless ("smooth") connection between electrode part (blue region) and device part (red one). So, smth should be definitely updated in the electrode part otherwise we will have bulk-like electrode region (blue one) and sharply different device region. My thoughts are so metaphorical because I simply don't understand what does "coupling elements" mean - that's my problem, of course. However, I'm 99% sure that three (3) simple examples of the system (for none|all|cross-terms) will help many users to understand how large is the effect and how to choose the proper flag.
That's how I see that right now :-)
Thanks for your insight. Sadly, specifying general and non-general is very difficult and tends to be counter-productive. Say in one area of research Eta is generally not that important, but other areas it is generally important. And by documenting examples, new users tend to disregard its importance... :(
When people request "general advice", they often think that there is a general trend. However, we often see that is not the case, and if there is a "general" trend, then it is very difficult to know when one is not in the "general" case... So, while it would be a good idea to have more text, it just proves extremely difficult to not side-track users from believing their system is "general", or "not general".
As for 10.4, and even if this is a "human-readable" text, the majority of questions are still related to this section. :)
By far the most questions can be answered if users read and understood this section. So even something you may find easy to understand can be quite difficult to explain to other users... :(
I really think it would be more dangerous to add too many "generally do not touch this parameter" to the documentation as it may have side-effects to what users do. But we could be much (much) better at describing more details on individual flags! We would welcome any merge request regarding documentation! :)
1) Sometimes using bulk false can be beneficial when the electrostatics are behaving nicely towards the *end of the electrodes*. In this case using "false" will extend the scattering region size with the electrode region since those regions will be allowed to be updated in the SCF as well.
One case could be electrodes that are excessively long, but there are other cases as well (real-space self-energies) and possibly others as well.
2) Ok, so a better description of coupling elements should be added. The default value is probably what you want :) (cross-terms). :)
Do you have a gitlab account, then I'll try and ping you there for an update related to the documentation.
I totally agree with your arguments: no general case for all flags and all levels of users’ knowledge. That’s perpetual headache for any code developer I suppose :-) Nevertheless, I glad to hear that extension of the manual text is possible. My point is that you would get much more similar questions if haven’t placed this relatively thorough 10.4 part or, for instance, haven’t written “If in doubt, use 100 k-points along the semi-infinite direction.” At least, for me it really helped to rapidly understand the importance of transport direction k-spacing and approximate range of reliable values. So, continuation of thorough description of flags (and connection between them as Siesta actually does) is always a good idea.
Just few more issues I have right now as an example of possible improvements of the Manual.
1) While applying bias voltage you advised to keep a fixed ratio of voltage/(contour points), see the link below. In Siesta 3.X it’s related to TS.biasContour.NumPoints. However, I haven’t surely recognized its analogue in Siesta 4.1-b4. More general question: what should we (users) pay attention to or modify in Trans.fdf when applying voltage besides obvious TS.Voltage flag? https://answers.launchpad.net/siesta/+question/631955
Right now, my general perception is that default contours parameters shouldn’t be changed unless you know what are you doing (as always).
2) TBT.DOS.A vs TBT.DOS.Gf are laconically described as “DOS from spectral function” vs “DOS from Green function. From sisl --help one may see that “--dos Store DOS. If no electrode is specified, it is Green function, else it is the spectral function”. Particularly my calculations give me almost the same DOS for both options, so I couldn’t shed the light upon the difference between these two options. Probably some extended text description should be provided in the Manual besides the reference to the equations.
3) Yes, explanation of cross-terms coupling elements might help. Thank you!
Finally, am I right that Siesta doesn’t have some official help page nowadays as follows from the site? If it’s planned in the future, I would really be happy to see some kind of gradually extending “main issues page”. Among them one can highlight “convergence problems” (related to weight, history, useSaveDM flag and “baby-sitting” in the case of large Transiesta structures, etc). Saying short, such FAQ could collect main problems from all old forums and gitlab comments. Yes, such aggregation of main problems/answers seems to be really painstaking but some group of enthusiasts could help it step-by-step I guess.
As for the gitlab account I’ve made that one: konstantin.larionov
And again, I express my deep respect to your longstanding support of Siesta-related issues. No matter which question I am “googling” – most commonly I meet your thorough and amiable answers :-)
Yes, it is very hard as a developer to satisfy all needs. :)
1) In 4.1 (please do not use the b* releases, 4.1.5 is out) the non-equilibrium spacing is defined in this block:
%block TS.Contour.nEq.neq
part line
from -|V|/2 - 5 kT to |V|/2 + 5 kT
delta 0.01 eV # < here!
method mid-rule
%endblock TS.Contour.nEq.neq
the delta value says that the non-equilibrium contour is sampled with 10 meV precision, regardless of applied bias. So yes, nothing should be done here. And yes, the general contours should be sufficient for most.
2) They should not be exactly the same (rather a factor 2 or something). DOS is from the Green function, whereas DOS.A is from Gamma.G.Gamma^dagger. I'll add the equations and some small text at the DOS.A and DOS.Gf flags.
3) I have added something.
We are trying to convince users to contribute questions for siesta here: https://mattermodeling.stackexchange.com/ under the [siesta] tag.
Dear Nick Rübner Papior , may I, please, disturb you one more time regarding Transiesta results interpetation and correct SISL usage?
I am a bit struggling while comparing PDOS from pristine Siesta method and Transiesta EGF:
(a) Simple PDOS from the dashed layer (same as in the electrode) near the interface - it's not half-metallic in contrast to the electrode part due to some interaction with a spacer. No questions.
(b) PDOS for the same dashed atomic layer given by SISL after atoms selection. In this case, dashed layer is half-metallic (just as electrode part) which is principally different to Siesta results.
So my question is whether comparison of Siesta and Transiesta DOS are relevant? For now, it seems that Transiesta DOS (Gf and spectral) do not take into account interfacial interactions and produced somehow by properties of electrodes solely.
Or probably I use SISL in a wrong way while extracting PDOS of the dashed atoms...
Thank you a lot for any remark or reference to the guide for self-explanation!
I am not sure what you exactly mean. A siesta calculation is principally very different from a transiesta calculation. Comparing dos of different methods can provide insights, but one should know what the different methods introduce to fully understand differences in interpretation. I think you should ask this question on matter modelling (researchgate is not a good platform for this).
Lastly I think if you are drawing conclusions solely based on these two plots, your conclusions might be wrong.
For instance, we have a graphene monolayer as a spacer in device region. I didn't check but I'm sure that both Siesta and Transiesta must show typical Dirac cone for this graphene layer, isn't it? Nevetheless, based on your last answer, I can conclude that it's not a general rule: Transiesta DOS doesn't have to (more or less) reproduce Siesta DOS. And, in contrast to the simplest graphehe example, some other systems may easily give absolutely different DOS for the Siesta and Transiesta cases, right? I will read about this more carefully. Thank you again.
Why should they? There could be charge transfer between the surface and graphene.
I will close this discussion here, if you have other questions, please open them here:
https://mattermodeling.stackexchange.com/
- Badges
- Science topic
- Similar topics
- Correction