There are many issues in relaxing a geometry with TranSiesta, besides the
system you have chosen which has a band-gap.

1) For gapped electrodes one cannot be sure the electrostatics in your
electrode calculation and in the device calculation coincide *perfectly*
and hence you will have a mismatch between the two. If you include the
K-point for MoS2 this effect should be minimized, but in reality you can't
be really sure. Thus one introduces a junction between the electrode/device
calculation.
2) Forces for atoms in transiesta are *only* accurate far from the
electrodes due to electrostatic effects at the electrode-device boundary
which isn't handled too accurately (again, this discrepancy may be enhanced
even more with a gapped electrode). And one cannot trust forces *on*
electrodes, AT ALL.
3) The first step in siesta/transiesta always seems to have some effects to
it. I have tried several times to pinpoint whether there is an issue or
not, but I can't find anything... :(
4) Stresses I wouldn't trust with transiesta. :) Again this comes from
discrepancies in electrostatics and possibly some other things.

5) While the previous transiesta versions forced you to use the 3rd lattice
vector as the transport direction, this is not the case anymore. If you
want you can put the electrode/device in the XY-plane :) (just a hint)

Den tor. 28. mar. 2019 kl. 22.20 skrev Xavier Cartoixa Soler <
xavier.carto...@uab.es>:

>    Dear developers,
>
>    We are facing some behavior we can't make sense of when restarting a
> transiesta relaxation with v4.1-b4.
>    File  elec.fdf  contains a MoS2 electrode, for transport along the z
> axis. It runs OK. The cell is not fully relaxed because it is designed
> to match a different substrate. Nevertheless, residual strains are quite
> low.
>    File  0V.fdf  is the electrode system repeated 1x1x3, so we can have
> an upper bound for the conductance in the MoS2 system. We will
> eventually apply a bias to it, but even at zero bias we are observing a
> strange behavior:
>
>    1) 0V : If we run the fdf as it is, it performs several CG steps
> until forces in the scattering region are converged to less than 0.01
> eV/Ang.
>    However, there is a huge difference between the stress reported in
> the initial TS calculation
>     Stress-tensor-Voigt (kbar):        0.64       -1.14        0.69
> and the stresses in all the remaining steps, typically
>     Stress-tensor-Voigt (kbar):      150.08      180.11      156.63
>    We don't understand why there is such an increase in the strain and,
> moreover, forces in the electrodes become huge (eg 12.35 eV/Ang for
> something that was close to zero with siesta).
>    Also, why, given a structure relaxed with siesta, the initial forces
> in transiesta (step 0) are 10x bigger than a regular run with
> SolutionMethod diagon?
>
>    2) 0V-relaxed : If we take the final (force converged) coordinates of
> the 0V calculation, and paste them into a new  0V-relaxed.fdf  file,
> without XV, DM nor TSDE, we would expect the transiesta forces to be
> very low already in the zero-first step.
>   However, forces are already "high" in the 0th step (with low stress),
> and in CG step 1 both forces and stresses are high (significantly high
> for stresses).  Note that this input file has
>    MD.MaxDispl         0.000000001  Ang
> so that there aren't important atom displacements between step 0 and 1.
>
>   3) 0V-restart : Here we take the same fdf as in the 0V-relaxed case,
> but we provide the final/converged TSDE from the 0V calculation.
> Constrained forces are low and consistent with the final 0V forces, as
> they should be, but strains are high, as well as forces in the electrodes.
>
>   We don't know if all this is to be expected and we are missing
> something, or it is indicative of a bug in the code: while a little
> discrepancy between the forces in siesta/transiesta might be acceptable,
> it seems that there is a very substantial inconsistency between the way
> forces are computed in siesta/transiesta step 0, and the rest of the
> transiesta CG steps.
>
>   Thanks,
>
>   Xavier
>


-- 
Kind regards Nick

Responder a