Re: [SIESTA-L] TBtrans output

2022-03-15 Por tôpico Neculai PLUGARU
     518294 Mar 14 14:22 scat.TBT_UP.CEIG_Left
       518294 Mar 14 14:22 scat.TBT_UP.CEIG_Right
       158282 Mar 14 14:22 scat.TBT_UP.CORR_Left
       158282 Mar 14 14:22 scat.TBT_UP.CORR_Right
 186434408059 Mar 14 14:22 scat.TBT_UP.nc <http://scat.TBT_UP.nc>
       518279 Mar 14 14:22 scat.TBT_UP.TEIG_Left-Right
       518279 Mar 14 14:22 scat.TBT_UP.TEIG_Right-Left
       158267 Mar 14 14:22 scat.TBT_UP.TRANS_Left-Left
       158267 Mar 14 14:22 scat.TBT_UP.TRANS_Left-Right
       158267 Mar 14 14:22 scat.TBT_UP.TRANS_Right-Left
       158267 Mar 14 14:22 scat.TBT_UP.TRANS_Right-Right
---



On 3/11/22 15:08, Nick Papior wrote:

Hi,

And could you attach the input and output again... The last output 
clearly showed that you had not put those flags in. So I am guessing 
you are doing the same thing again


Please, always attach input and output!

And you write something about tbt.t.eig true which does not make 
sense... As I suggested previously, please check the output to see if 
it will write the things requested, when you attach the output, could 
you comment on the output and your interpretation of what it says 
about transmission eigenvalues etc.



On Fri, 11 Mar 2022, 09:39 Neculai PLUGARU,  
wrote:


Hi, All

I have the following flags in the input: section for TBT :

 ...
TBT.DOS.A.All true
TS.SolutionMethod btd
TS.BTD.Pivot atom+rev-CM+Left

%block TBT.k
diag 3 3 1
%endblock

%block TBT.Contours
line
%endblock TBT.Contours
%block TBT.Contour.line
part line
from -15. eV to 10. eV
delta 0.02 eV
method mid-rule
%endblock TBT.Contour.line
TBT.T.Bulk true
TBT.DOS.Elecs true
TBT.T.Eig 5
TBT.T.All true
TBT.T.Out true
TBT.Symmetry.TimeReversal false
TBT.Current.Orb  true

However, the code does not yield "the equivalent eigenvalue files"
for  TBT.T.Eig   true
Nor the *.nc files for spin_UP/DN
Here I list the TBT output files I get:

 195116 Feb 12 18:54 scat.TBT.CC <http://scat.TBT.CC>
 350488 Feb 12 19:19 scat.TBT_DN.ADOS_Left
 350488 Feb 12 19:19 scat.TBT_DN.ADOS_Right
  70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Left
  70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Right
  70074 Feb 12 19:19 scat.TBT_DN.AVTRANS_Left-Right
 350459 Feb 12 19:19 scat.TBT_DN.TRANS_Left-Right
    297 Feb 12 18:54 scat.TBT.KP <http://scat.TBT.KP>
 350488 Feb 12 19:06 scat.TBT_UP.ADOS_Left
 350488 Feb 12 19:06 scat.TBT_UP.ADOS_Right
  70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Left
  70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Right
  70074 Feb 12 19:06 scat.TBT_UP.AVTRANS_Left-Right
 350459 Feb 12 19:06 scat.TBT_UP.TRANS_Left-Right

What is wrong/missing in my TBT input ?

Thank you for your comments,
Neculai



On 3/11/22 07:36, Nick Papior wrote:

Please see my response 2 days ago, it seems that you are missing
flags in the input file.

/Nick

On Thu, 10 Mar 2022, 22:02 Neculai PLUGARU,
 wrote:


Hi, Nick

Thank you, very much, for the checks and your time.

1) your scat.fdf does not ask for transmission eigenvalues.
I.e. I can't find TBT.T.Eig in scat.fdf, this is also
reflected in tbt.out which lists 0 transmission eigenvalues
should be calculated. So nothing wrong there.

Absolutely correct. The meaning of this piece of information
was to show that without specifications for additional data,
particularly TBT.T.EIG, the code works alright.
2) your scat-dn and scat-up. The output of the tbtrans runs
tbt-dn.out and tbt-up.out have these lines:


===
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES 

Correct. This happens when one follows the discussion since
2017, trying to perform two calculations (but using TBT
4.1.5) for spin_UP/DN. The code produces the (empty)
scat.TBT_UP/DN.CEIG_Left   files and huge scat.TBT_UP/DN.nc
files. It has been just a test of that approach, it failed
and this is understandable because it is a different version.
Now, just to complete the information, this is what one gets
with TBT 4.1.5  when using the attached scat.fdf input asking
for specific output data (I also attach the tbt.out)


  195116 Feb 12 18:54 scat.TBT.CC <http://scat.TBT.CC>
  350488 Feb 12 19:19 scat.TBT_DN.ADOS_Left
  350488 Feb 12 19:19 scat.TBT_DN.ADOS_Right
   70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Left
   70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Right
   70074 Feb 12 19:19 scat.TBT_DN.AVTRANS_Left-Right
  350459 Feb 12 19:19 scat.TBT_DN.TRANS_Left-Right
 297 Feb 12 18:54 scat.TBT.KP <http://scat.TBT.KP>
  350488 Feb 12 19:06 scat.TBT_UP.ADOS_Left
  350488 F

Re: [SIESTA-L] [***RedIris: Posible SPAM***] [***RedIris: Posible SPAM***] Re: TBtrans output

2022-03-11 Por tôpico Neculai PLUGARU

Hi, All

I have the following flags in the input: section for TBT :

 ...
TBT.DOS.A.All true
TS.SolutionMethod btd
TS.BTD.Pivot atom+rev-CM+Left

%block TBT.k
diag 3 3 1
%endblock

%block TBT.Contours
line
%endblock TBT.Contours
%block TBT.Contour.line
part line
from -15. eV to 10. eV
delta 0.02 eV
method mid-rule
%endblock TBT.Contour.line
TBT.T.Bulk true
TBT.DOS.Elecs true
TBT.T.Eig 5
TBT.T.All true
TBT.T.Out true
TBT.Symmetry.TimeReversal false
TBT.Current.Orb  true

However, the code does not yield "the equivalent eigenvalue files" for  
TBT.T.Eig   true

Nor the *.nc files for spin_UP/DN
Here I list the TBT output files I get:

 195116 Feb 12 18:54 scat.TBT.CC <http://scat.TBT.CC>
 350488 Feb 12 19:19 scat.TBT_DN.ADOS_Left
 350488 Feb 12 19:19 scat.TBT_DN.ADOS_Right
  70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Left
  70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Right
  70074 Feb 12 19:19 scat.TBT_DN.AVTRANS_Left-Right
 350459 Feb 12 19:19 scat.TBT_DN.TRANS_Left-Right
    297 Feb 12 18:54 scat.TBT.KP <http://scat.TBT.KP>
 350488 Feb 12 19:06 scat.TBT_UP.ADOS_Left
 350488 Feb 12 19:06 scat.TBT_UP.ADOS_Right
  70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Left
  70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Right
  70074 Feb 12 19:06 scat.TBT_UP.AVTRANS_Left-Right
 350459 Feb 12 19:06 scat.TBT_UP.TRANS_Left-Right

What is wrong/missing in my TBT input ?

Thank you for your comments,
Neculai



On 3/11/22 07:36, Nick Papior wrote:
Please see my response 2 days ago, it seems that you are missing flags 
in the input file.


/Nick

On Thu, 10 Mar 2022, 22:02 Neculai PLUGARU,  
wrote:



Hi, Nick

Thank you, very much, for the checks and your time.

1) your scat.fdf does not ask for transmission eigenvalues. I.e. I
can't find TBT.T.Eig in scat.fdf, this is also reflected in
tbt.out which lists 0 transmission eigenvalues should be
calculated. So nothing wrong there.

Absolutely correct. The meaning of this piece of information was
to show that without specifications for additional data, 
particularly TBT.T.EIG, the code works alright.
2) your scat-dn and scat-up. The output of the tbtrans runs
tbt-dn.out and tbt-up.out have these lines:


===
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES 

Correct. This happens when one follows the discussion since 2017,
trying to perform two calculations (but using TBT 4.1.5) for
spin_UP/DN. The code produces the (empty)
scat.TBT_UP/DN.CEIG_Left   files and huge scat.TBT_UP/DN.nc files.
It has been just a test of that approach, it failed and this is
understandable because it is a different version. Now, just to
complete the information, this is what one gets with TBT 4.1.5 
when using the attached scat.fdf input asking for specific output
data (I also attach the tbt.out)


  195116 Feb 12 18:54 scat.TBT.CC <http://scat.TBT.CC>
  350488 Feb 12 19:19 scat.TBT_DN.ADOS_Left
  350488 Feb 12 19:19 scat.TBT_DN.ADOS_Right
   70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Left
   70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Right
   70074 Feb 12 19:19 scat.TBT_DN.AVTRANS_Left-Right
  350459 Feb 12 19:19 scat.TBT_DN.TRANS_Left-Right
 297 Feb 12 18:54 scat.TBT.KP <http://scat.TBT.KP>
  350488 Feb 12 19:06 scat.TBT_UP.ADOS_Left
  350488 Feb 12 19:06 scat.TBT_UP.ADOS_Right
   70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Left
   70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Right
   70074 Feb 12 19:06 scat.TBT_UP.AVTRANS_Left-Right
  350459 Feb 12 19:06 scat.TBT_UP.TRANS_Left-Right

Still, no output for

SystemLabel.TEIG_<1>_<2>
SystemLabel.BDOS_<>
SystemLabel.BTRANS_<>
SystemLabel.CORR_<>
SystemLabel.TRANS_<1>_<1>
as well as for SystemLabel.TBT_UP/DN.nc files, although tbt.out
says that the job was executed without error.

I have just completed the ts_graphene test in the 4.1.5 release in
a spin-polarized configuration with transmission eigenvalues, and
everything seems correctly written.

Please, is there anything wrong in the here-attached *fdf file
comparing with your input for the spin polarized graphene input ?

Thank you, very much, for your comments and suggestion wrt the
compilation of TBT when using intel compilers; I have had
painstaking experiences in the past with that. I will ask the
system administrator to recompile the code paying more attention
to the optimization flags, indeed.

 Kind regards,

Neculai

On 3/9/22 14:15, Nick Papior wrote:

Hi,

This is what I can find:

1) your scat.fdf does not ask for transmission eigenvalues. I.e.
I can't find TBT.T.Eig in scat.fdf, this is also reflected in
tbt.out which lists 0 transmission eigenvalues should be
calculated. So nothing wrong there.

2) your scat-dn an

[SIESTA-L] [***RedIris: Posible SPAM***] [***RedIris: Posible SPAM***] Re: TBtrans output

2022-03-10 Por tôpico Neculai PLUGARU


Hi, Nick

Thank you, very much, for the checks and your time.

1) your scat.fdf does not ask for transmission eigenvalues. I.e. I can't 
find TBT.T.Eig in scat.fdf, this is also reflected in tbt.out which 
lists 0 transmission eigenvalues should be calculated. So nothing wrong 
there.


Absolutely correct. The meaning of this piece of information was to show 
that without specifications for additional data, particularly TBT.T.EIG, 
the code works alright.


2) your scat-dn and scat-up. The output of the tbtrans runs tbt-dn.out 
and tbt-up.out have these lines:


=== 
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES 


Correct. This happens when one follows the discussion since 2017, trying 
to perform two calculations (but using TBT 4.1.5) for spin_UP/DN. The 
code produces the (empty) scat.TBT_UP/DN.CEIG_Left   files and huge 
scat.TBT_UP/DN.nc files. It has been just a test of that approach, it 
failed and this is understandable because it is a different version.


Now, just to complete the information, this is what one gets with TBT 
4.1.5  when using the attached scat.fdf input asking for specific output 
data (I also attach the tbt.out)



  195116 Feb 12 18:54 scat.TBT.CC
  350488 Feb 12 19:19 scat.TBT_DN.ADOS_Left
  350488 Feb 12 19:19 scat.TBT_DN.ADOS_Right
   70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Left
   70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Right
   70074 Feb 12 19:19 scat.TBT_DN.AVTRANS_Left-Right
  350459 Feb 12 19:19 scat.TBT_DN.TRANS_Left-Right
 297 Feb 12 18:54 scat.TBT.KP
  350488 Feb 12 19:06 scat.TBT_UP.ADOS_Left
  350488 Feb 12 19:06 scat.TBT_UP.ADOS_Right
   70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Left
   70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Right
   70074 Feb 12 19:06 scat.TBT_UP.AVTRANS_Left-Right
  350459 Feb 12 19:06 scat.TBT_UP.TRANS_Left-Right

Still, no output for

SystemLabel.TEIG_<1>_<2>
SystemLabel.BDOS_<>
SystemLabel.BTRANS_<>
SystemLabel.CORR_<>
SystemLabel.TRANS_<1>_<1>

as well as for SystemLabel.TBT_UP/DN.nc files, although tbt.out says 
that the job was executed without error.


I have just completed the ts_graphene test in the 4.1.5 release in a 
spin-polarized configuration with transmission eigenvalues, and 
everything seems correctly written.


Please, is there anything wrong in the here-attached *fdf file comparing 
with your input for the spin polarized graphene input ?


Thank you, very much, for your comments and suggestion wrt the 
compilation of TBT when using intel compilers; I have had painstaking 
experiences in the past with that. I will ask the system administrator 
to recompile the code paying more attention to the optimization flags, 
indeed.


 Kind regards,

Neculai

On 3/9/22 14:15, Nick Papior wrote:

Hi,

This is what I can find:

1) your scat.fdf does not ask for transmission eigenvalues. I.e. I 
can't find TBT.T.Eig in scat.fdf, this is also reflected in tbt.out 
which lists 0 transmission eigenvalues should be calculated. So 
nothing wrong there.


2) your scat-dn and scat-up. The output of the tbtrans runs tbt-dn.out 
and tbt-up.out have these lines:

===
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   RANK 46 PID 17638 RUNNING AT imt01
=   KILLED BY SIGNAL: 9 (Killed)
===

indicating a prematurely ending job. Always check whether your jobs 
are done. That information could be of a number of reasons that I 
don't have any knowledge about.
Sometimes intel compilers are extremely aggressive in optimizations, 
and this could be what is causing problems. Try lowering the 
optimization level, or ask the admins on your cluster why the jobs 
ended prematurely.


I have just completed the ts_graphene test in the 4.1.5 release in a 
spin-polarized configuration with transmission eigenvalues, and 
everything seems correctly written.


/ Nick


Den man. 7. mar. 2022 kl. 17.32 skrev Neculai PLUGARU 
:



Hello, Nick

Thank you for your help. I have delayed my message because I have
made several tests to be more explicit about the problems I face
with TBT 4.1.5. So, here are the answers to your questions:

1) I attach my input files; now there are three of them, because I
found and followed this discussion since 2017-01-24, regarding TBT
4.1-b3,  and somehow the present situation with TBT 4.1.5 is
similar, but still different.

https://bugs.launchpad.net/siesta/+bug/1658896
 "spin polarized tbtrans calculation"

In my calculations of the eigen channels, the first one (denoted
here below scat-up) stops after producing the files for the spin
UP. Then, in an independent TBT calculation, scat-dn, with the line

TBT.Spin 2

included in *fdf, one obtains all the files for the spin-DOWN chan

[SIESTA-L] TBtrans output

2022-03-04 Por tôpico Neculai PLUGARU

Dear SIESTA Community

I use SIESTA 4.1.5 and the associated TS and TBT. TBtrans was compiled 
following the instructions in the TBtrans manual, using NETCDF-4 and MKL 
libs.


I want to calculate the eigen channels for the transmission matrix for a 
spin-polarized system. For that purpose we have set the following flags 
in the TBT input:


TBT.Verbosity 8
TBT.T.Bulk true
TBT.T.All true
TBT.T.Eig  true
TBT.T.Eig 5
TBT.T.Out true
TBT.Symmetry.TimeReversal F
TBT.Current.Orb  true

But the TBT calculation does not provide the files

SystemLabel.TEIG_<1>_<2>
SystemLabel.BDOS_<>
SystemLabel.BTRANS_<>
SystemLabel.CORR_<>
SystemLabel.TRANS_<1>_<1>

Is the information in these files listed only in the  netcdf format 
(*.nc files) ?


Thank you for your help,
Neculai
***********
Dr. Neculai Plugaru
National Institute for R in Microtechnologies (IMT-Bucharest)
Simulation, Modelling and Computer-Aided Design - Laboratory L5
126A, Erou Iancu Nicolae Street, 077190, Ilfov
Bucharest, ROMANIA

E-mail: neculai.plug...@imt.ro
Tel:  +4021 269 0777
https://www.imt.ro
***


-- 
SIESTA is supported by the Spanish Research Agency (AEI) and by the European 
H2020 MaX Centre of Excellence (http://www.max-centre.eu/)


Re: [SIESTA-L] transiesta yields negative total energy and TBTrans starts with positive total energy

2021-11-16 Por tôpico neculai . plugaru

Hello Nick

Thank you, very much, for your insightful comments.

Indeed, we have started with a 0 V calculation in all our tests, and the 
reported issue appears for V= 0 V. It also manifested when, after 
performing a successful 0 V calculation on the same heterostructure 
prior being relaxed in the slab geometry ( so only preoptimized cells in 
the electrodes and barrier, we call it "ideal") and increased the bias 
to 0.001 V or 0.5 V, independent calculations.


Also, the points:

- " you started a biased calculation (V) from a previous TranSiesta 
calculation (V'), ..."

- "- your mixing weight is too high"
-"- your convergence parameters too loose during the Siesta SCF

can be discarded.

We shall check the remaining of your comments and further report to the 
forum.


Kind regards from Bucharest,
Neculai

***********
Neculai Plugaru
National Institute for R in Microtechnologies (IMT-Bucharest)
Simulation, Modelling and Computer-Aided Design - Laboratory L5
126A, Erou Iancu Nicolae Street, 077190, Ilfov
Bucharest, ROMANIA

E-mail: neculai.plug...@imt.ro
Tel:  +4021 269 0777
https://www.imt.ro
***

On 2021-11-15 11:37, Nick Papior wrote:


Please use 4.1.5, it has checks for these kinds of things.

Probably what you are seeing is that the charge is leaking out of the 
device region during your SCF. This is an indication of one or a 
combination of the following:
- your initial Hamiltonian is far from the open-boundary one. I.e. your 
electrode regions are too close to the scattering in the device

- your mixing weight is too high
- your convergence parameters too loose during the Siesta SCF
- your integration variables in TranSiesta could be better (more 
points)
- you started a biased calculation (V) from a previous TranSiesta 
calculation (V'), and the difference V - V' is too large for the system 
to converge properly, try a smaller dV


There may be other things as well. Also, I hope you are doing a 0 V 
calculation to start with.


Den fre. 12. nov. 2021 kl. 22.08 skrev Neculai PLUGARU 
:



Dear SIESTA community

I attempt to perform conductance calculations on a heterostructure 
with

two interfaces, (slab geometry) which was previously relaxed and then
the SCF calculation produced correct results.

I use SIESTA v4.1-b4, Compiler version: ifort (IFORT) 18.0.5 20180823,
PARALLEL version.

However, although the SIESTA cycle in the transport calculation
converges and the Harris, KS and Free energies are negative, TS starts
from (huge) positive energy values, then the calculation converges
according to the DM tolerance criterion, the energies are still
positive, the forces on atoms are huge and the populations on orbitals
are wrong. The leads are cut from the electrodes, so that the 
scattering

region comprises the interfaces and the leads still are about one
nanometer long each.

I would greatly appreciate your comments to solve this issue.

Thank you,

Neculai

***
N. Plugaru
National Institute for R in Microtechnologies (IMT-Bucharest)
Simulation, Modelling and Computer-Aided Design - Laboratory L5
126A, Erou Iancu Nicolae Street, 077190, Ilfov
Bucharest, ROMANIA

E-mail: neculai.plug...@imt.ro
Tel:  +4021 269 0777
https://www.imt.ro
***

--
SIESTA is supported by the Spanish Research Agency (AEI) and by the 
European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)


--

Kind regards Nick
-- 
SIESTA is supported by the Spanish Research Agency (AEI) and by the European 
H2020 MaX Centre of Excellence (http://www.max-centre.eu/)


[SIESTA-L] correction to subject: transiesta yields negative total energy and TBTrans starts with positive total energy

2021-11-12 Por tôpico Neculai PLUGARU

Hi,

Sorry for the error in the subject of the previous message: it should be

"SIESTA yields negative total energy and TranSIESTA starts with positive 
total energy"


Neculai

***
N. Plugaru
National Institute for R in Microtechnologies (IMT-Bucharest)
Simulation, Modelling and Computer-Aided Design - Laboratory L5
126A, Erou Iancu Nicolae Street, 077190, Ilfov
Bucharest, ROMANIA

E-mail: neculai.plug...@imt.ro
Tel:  +4021 269 0777
https://www.imt.ro
***


-- 
SIESTA is supported by the Spanish Research Agency (AEI) and by the European 
H2020 MaX Centre of Excellence (http://www.max-centre.eu/)


[SIESTA-L] transiesta yields negative total energy and TBTrans starts with positive total energy

2021-11-12 Por tôpico Neculai PLUGARU

Dear SIESTA community

I attempt to perform conductance calculations on a heterostructure with 
two interfaces, (slab geometry) which was previously relaxed and then 
the SCF calculation produced correct results.


I use SIESTA v4.1-b4, Compiler version: ifort (IFORT) 18.0.5 20180823, 
PARALLEL version.


However, although the SIESTA cycle in the transport calculation 
converges and the Harris, KS and Free energies are negative, TS starts 
from (huge) positive energy values, then the calculation converges 
according to the DM tolerance criterion, the energies are still 
positive, the forces on atoms are huge and the populations on orbitals 
are wrong. The leads are cut from the electrodes, so that the scattering 
region comprises the interfaces and the leads still are about one 
nanometer long each.


I would greatly appreciate your comments to solve this issue.

Thank you,

Neculai

***
N. Plugaru
National Institute for R in Microtechnologies (IMT-Bucharest)
Simulation, Modelling and Computer-Aided Design - Laboratory L5
126A, Erou Iancu Nicolae Street, 077190, Ilfov
Bucharest, ROMANIA

E-mail: neculai.plug...@imt.ro
Tel:  +4021 269 0777
https://www.imt.ro
***


-- 
SIESTA is supported by the Spanish Research Agency (AEI) and by the European 
H2020 MaX Centre of Excellence (http://www.max-centre.eu/)