Re: [SIESTA-L] Parallel siesta crashing during SCF

[Nick Papior]

Hi,

Without more information we can't help,

1) compiler and library versions
2) your arch.make
3) your input files



Den tir. 17. nov. 2020 kl. 22.01 skrev D. Bennett :

> Dear siesta users,
>
> I'm running some calculations using a parallel version of siesta-psml,
> and I'm finding that some of them are crashing during the SCF loop.
> Things seem to go fine, and then I get a message like
>
> ---
> Primary job  terminated normally, but 1 process returned
> a non-zero exit code.. Per user-direction, the job has been aborted.
> ---
> --
> mpirun detected that one or more processes exited with non-zero status,
> thus causing
> the job to be terminated. The first process to do so was:
>
>Process name: [[48394,1],3]
>Exit code:174
> --
>
> but it isn't apparent from the output file why the crash occured.
> Usually I just re-run the jobs and eventually they finish without
> crashing, but I'm working on a large set of calculations and I'd rather
> not have to babysit them all. Has anyone else had a similar experience,
> or does anyone have any suggestions on how I could find what is causing
> the problem? I suspect it could be to do with memory, mainly because
> there aren't any other signs of anything else going wrong.
>
> Thanks in advance,
>
> Danny Bennett
>
> --
> 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/)

Re: [SIESTA-L] Performance issue in Pd slab calculation

[Nick Papior]

Hi,

This is not totally unsurprising.

When you hit 128 cores you are effectively only having 30 orbitals per
core. This means when the diagonalization takes place it's blocks will be
~30x30 matrices.
You are reaching the bottleneck of the diagonalization routines which takes
up a considerable amount of time in this case. So there isn't much to do :)
Your system is simply too small to scale to larger core-counts.

Also:

1. The METIS decomposition has no influence on the diagonalization routines.
2. The vacuum region has very little overhead, so that shouldn't affect the
calculation time a lot, same goes for the dipole-correction.

The fact that 2. isn't influencing your speed-up is a further indication
that it is the diagonalization routines.

Den ons. 21. okt. 2020 kl. 22.03 skrev Karen Fidanyan <
fidan...@fhi-berlin.mpg.de>:

> Dear colleagues,
>
> I started working with Siesta (v4.0.2-17, Intel compiler) recently, and
> cannot understand its performance. I do a 6x6x7 Pd slab with a water
> molecule and have a long time per SCF step:
> #Cores  seconds_per_scf_step
> 2  753.0
> 4  376.8
> 8  235.3
> 16181.4
> 32114.5
> 64  86.3
> 12871.9
>
> I'm puzzled with the fact that performance is saturated at 64 cores,
> although SCF is still pretty slow. I tried: METIS domain decomposition,
> reducing vacuum layer almost to zero and disabling dipole correction,
> but the numbers are similar in all those cases.
> I enclose the archive with my inputs and selected outputs. If someone
> could point out what is wrong, I would be very grateful.
>
> Best regards,
> Karen Fidanyan
>
>
> --
> 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/)

Re: [SIESTA-L] How to find find variation of potential with distance in siesta

[Nick Papior]

I don't know if you did it correctly. A plot does not show this! But from
what you describe it sounds correct to me.

However, it seems that you have a dipole in the system, i.e. you should add
the dipole correction for this calculation.

Den lør. 3. okt. 2020 kl. 11.19 skrev Harkishan Dua :

> Dear sir,
> I have generated the data set  (VH_z.dat file) for my structure using SISL
> and generated its plot using gnuplot. And from that plot, I have taken
> points 1 and 2 (given in the 1.5.png file) for calculating the
> potential difference for my structure. But the potential difference that i
> am getting is very small. So, could you please tell me if I am going in the
> right direction?
>
> On Mon, Sep 21, 2020 at 6:56 PM Nick Papior  wrote:
>
>> How did you do it? How were your unit conversions etc.?
>>
>> Remember that sisl automatically converts to eV and Ang when reading
>> siesta files.
>>
>> Den man. 21. sep. 2020 kl. 15.22 skrev Harkishan Dua > >:
>>
>>> We are working on a system similar to the paper attached. In the paper
>>> it can be seen in Figure 1.(b) (page 15328) the potential plot where the
>>> potential difference is visible. and with that they have made the Table 1
>>> (page 15331) where they have taken the potential difference in volts.
>>> In our work, we are creating the potential plots using SISL,
>>> But in our work, even though we are getting potential difference which
>>> is very small to be seen directly from the graph, yet when we convert it
>>> into volts, we get a very large number. please help me with my doubt
>>>
>>> Regards
>>> Harkishan Dua
>>> PhD student
>>> Department of Physics
>>> Assam University Silchar.
>>>
>>> On Mon, Sep 7, 2020 at 12:24 PM Nick Papior 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Den søn. 6. sep. 2020 kl. 16.36 skrev Harkishan Dua <
>>>> hdua.p...@gmail.com>:
>>>>
>>>>> Dear sir,
>>>>> I am trying to generate the potential plot for monolayer CdS and
>>>>> Bilayer CdS systems using sisl. and with that I am getting the plots of 
>>>>> the
>>>>> ones I have attached with this mail.There are some queries that I wished 
>>>>> to
>>>>> clarify:
>>>>> 1. As both structures are planar Z coordinates are fixed for all the
>>>>> atoms. So how I am getting potential for variation of Z near the proximity
>>>>> of the regions where the atoms reside. As these are regions of empty 
>>>>> space.
>>>>>
>>>> The plot you show is just the potential with respect to Z coordinate.
>>>> So your atoms Z-coordinate can be directly transferred to this plot.
>>>>
>>>>> 2. When measuring distance between the two dips we are getting
>>>>> slightly different values than that of the  interlayer distance of the
>>>>> structure. As per my knowledge these two values should be the same.
>>>>> I will be glad if you help me in this regard.
>>>>>
>>>> What does "slightly different" mean? The real-space grid is not
>>>> infinitely precise, and so each voxel (3D box) occupies a finite space
>>>> resulting in a finite discretization of the potential/density. I think
>>>> you'll find that the voxel spacing (along Z) should correspond nicely with
>>>> your mismatch.
>>>>
>>>>>
>>>>> Attached with this email are the plots for CdS monolayer and Bilayer
>>>>> systems.
>>>>>
>>>>> On Wed, Sep 2, 2020 at 2:11 PM Boubacar Traore 
>>>>> wrote:
>>>>>
>>>>>> Thanks Nick for this update on sisl :-)
>>>>>>
>>>>>> On Tue, 1 Sep 2020 at 22:00, Nick Papior 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> In this it seems you don't need the filtering that macroave is
>>>>>>> capable of.
>>>>>>> In that case you can use sisl to create the data for you.
>>>>>>>
>>>>>>> The command would be something like this:
>>>>>>>
>>>>>>> sgrid siesta.VH --average 0 --average 1 --out VH_z.dat
>>>>>>>
>>>>>>> which will write a 2 column data file with z coordinates (in Ang) as
>>>>>>> the first and the plane-averaged potent

Re: [SIESTA-L] antiparallel calculation of the leads

[Nick Papior]

Please have a look at DM.InitSpin to initialize a spin configuration.
However, converging this in transiesta is probably difficult due to the
abrupt spin-boundary. But you could try this.

Den tor. 24. sep. 2020 kl. 22.02 skrev rayan moukhadder <
rayanroro321...@gmail.com>:

> I mean that I want to make a calculation for the leads two times..one time
> with spin up and the other time with all spins down how can I make such
> thing ? In other words what are the options that I should add to the input
> file of the leads ?
>
> On Wed, Sep 23, 2020 at 11:01 PM Nick Papior  wrote:
>
>> Please be more specific in your question, it isn't clear to us what
>> anti-parallel means?
>>
>> Den tir. 22. sep. 2020 kl. 22.05 skrev rayan moukhadder <
>> rayanroro321...@gmail.com>:
>>
>>> Dear siesta users,
>>> I want to perform a calculation in transiesta code with two graphene
>>> sheets sandwiching a cobalt atom. I want the two graphene leads to be
>>> antiparallel to each other so what are the options that I should add to the
>>> input file to make them antiparallel.
>>> thanks in advance.
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> 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 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/)

Re: [SIESTA-L] antiparallel calculation of the leads

[Nick Papior]

Please be more specific in your question, it isn't clear to us what
anti-parallel means?

Den tir. 22. sep. 2020 kl. 22.05 skrev rayan moukhadder <
rayanroro321...@gmail.com>:

> Dear siesta users,
> I want to perform a calculation in transiesta code with two graphene
> sheets sandwiching a cobalt atom. I want the two graphene leads to be
> antiparallel to each other so what are the options that I should add to the
> input file to make them antiparallel.
> thanks in advance.
>
>
> --
> 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/)

Re: [SIESTA-L] How to find find variation of potential with distance in siesta

[Nick Papior]

How did you do it? How were your unit conversions etc.?

Remember that sisl automatically converts to eV and Ang when reading siesta
files.

Den man. 21. sep. 2020 kl. 15.22 skrev Harkishan Dua :

> We are working on a system similar to the paper attached. In the paper it
> can be seen in Figure 1.(b) (page 15328) the potential plot where the
> potential difference is visible. and with that they have made the Table 1
> (page 15331) where they have taken the potential difference in volts.
> In our work, we are creating the potential plots using SISL,
> But in our work, even though we are getting potential difference which is
> very small to be seen directly from the graph, yet when we convert it into
> volts, we get a very large number. please help me with my doubt
>
> Regards
> Harkishan Dua
> PhD student
> Department of Physics
> Assam University Silchar.
>
> On Mon, Sep 7, 2020 at 12:24 PM Nick Papior  wrote:
>
>> Hi,
>>
>> Den søn. 6. sep. 2020 kl. 16.36 skrev Harkishan Dua > >:
>>
>>> Dear sir,
>>> I am trying to generate the potential plot for monolayer CdS and Bilayer
>>> CdS systems using sisl. and with that I am getting the plots of the ones I
>>> have attached with this mail.There are some queries that I wished to
>>> clarify:
>>> 1. As both structures are planar Z coordinates are fixed for all the
>>> atoms. So how I am getting potential for variation of Z near the proximity
>>> of the regions where the atoms reside. As these are regions of empty space.
>>>
>> The plot you show is just the potential with respect to Z coordinate. So
>> your atoms Z-coordinate can be directly transferred to this plot.
>>
>>> 2. When measuring distance between the two dips we are getting slightly
>>> different values than that of the  interlayer distance of the structure. As
>>> per my knowledge these two values should be the same.
>>> I will be glad if you help me in this regard.
>>>
>> What does "slightly different" mean? The real-space grid is not
>> infinitely precise, and so each voxel (3D box) occupies a finite space
>> resulting in a finite discretization of the potential/density. I think
>> you'll find that the voxel spacing (along Z) should correspond nicely with
>> your mismatch.
>>
>>>
>>> Attached with this email are the plots for CdS monolayer and Bilayer
>>> systems.
>>>
>>> On Wed, Sep 2, 2020 at 2:11 PM Boubacar Traore 
>>> wrote:
>>>
>>>> Thanks Nick for this update on sisl :-)
>>>>
>>>> On Tue, 1 Sep 2020 at 22:00, Nick Papior  wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> In this it seems you don't need the filtering that macroave is capable
>>>>> of.
>>>>> In that case you can use sisl to create the data for you.
>>>>>
>>>>> The command would be something like this:
>>>>>
>>>>> sgrid siesta.VH --average 0 --average 1 --out VH_z.dat
>>>>>
>>>>> which will write a 2 column data file with z coordinates (in Ang) as
>>>>> the first and the plane-averaged potential in the 2nd column (in eV). Note
>>>>> this is accessible in the latest sisl development, so you'll need to
>>>>> install the development version (
>>>>> http://zerothi.github.io/sisl/docs/latest/installation.html#development-version
>>>>> ).
>>>>>
>>>>> The macroave calculations have only recently been added (by an
>>>>> external contributor, see https://github.com/zerothi/sisl/pull/230),
>>>>> but we haven't made a tutorial for this yet. ;)
>>>>>
>>>>>
>>>>> Den man. 31. aug. 2020 kl. 22.00 skrev Boubacar Traore <
>>>>> bt.bouba...@gmail.com>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> I am trying to generate the potential plot using macroave and for
>>>>>>> that I have taken the .XV file and made it to run it with the
>>>>>>> macroave.in
>>>>>>> <https://protection.puc.rediris.es/fmlurlsvc/?fewReq=:B:JVw4MzE7OCR0PzMsMiRrZj8yMzgyMyRxa2VsY3Z3cGc/MWY1YTA6YDJjY2dnM2EwZ2MyNzEwZzY0Z2EzZ2YwZDRnNDMyMjRkNyR2PzM3Ozo6NDE6NzUkc2tmPzI1VDprZ0xvMjM1NjoxLzI1VDprZ0xtMjM1NjoxJHBhcnY/cWtncXZjL25Cd2NvLGdxJGE/OzI==http%3a%2f%2fmacroave.in>
>>>>>>> file. But there are some queries that I have not understood regarding 
>>>>>>> the
>>>>>>> mac

Re: [SIESTA-L] some questions about NEGF

[Nick Papior]

Den fre. 4. sep. 2020 kl. 22.00 skrev zhyphy :

> Dear All，
> I have some questions in the process of learning Green's function.I hope
> someone can help me.
> (1)  The surface Green function contains all the informations about
> interaction between  electrodes and scatter region, but for Transiesta, we
> must add some buffer layers, so the surface GF  in transiesta will be
> the interaction between electrodes and buffers? if so,  how can I get the
> real information about the coupling between the electrode and the central
> region?
>
Not exactly, the surface green function contains the self-energy of a truly
bulk electrode. Thus it contains the information about how it interacts
with another bulk part.
The spectral density of states arising from incoming states from a given
electrode will be a measure of the coupling between the electrode and the
central region.

> (2) The current obtained by Landauer formula is related to transimisson,
> so all the current is resonant transport current, it that right? Then, how
> to calculate the tunneling current?
>
The transiesta NEGF is ballistic transport.
To calculate the tunneling current you'll have to just add some vacuum,
however, be careful about the vacuum region due to Siesta's range limited
basis set. You'll have to add ghost-orbitals or extended orbitals, if you
want to use TranSiesta for this.

> (3) The GF formula have a small complex number (called eta ), why is this
> number introduced? For Transiesta code, how to deal with this formula?
> Is it represented by 0.001j ?
>
Because you can't invert a singular matrix. The Green function is
G(E) \propto \frac{1}{E - \eig}

If E == \eig it blows up to infinity. To remove this infinity we add a
small imaginary number i\eta which ensures finiteness. This then acts as a
broadening value. Please derive what the density of states looks for the
Green function (hint Lorentzian).

> Thanks,
> zhy
>
>
>
> --
> 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/)

Re: [SIESTA-L] How to find find variation of potential with distance in siesta

[Nick Papior]

Hi,

Den søn. 6. sep. 2020 kl. 16.36 skrev Harkishan Dua :

> Dear sir,
> I am trying to generate the potential plot for monolayer CdS and Bilayer
> CdS systems using sisl. and with that I am getting the plots of the ones I
> have attached with this mail.There are some queries that I wished to
> clarify:
> 1. As both structures are planar Z coordinates are fixed for all the
> atoms. So how I am getting potential for variation of Z near the proximity
> of the regions where the atoms reside. As these are regions of empty space.
>
The plot you show is just the potential with respect to Z coordinate. So
your atoms Z-coordinate can be directly transferred to this plot.

> 2. When measuring distance between the two dips we are getting slightly
> different values than that of the  interlayer distance of the structure. As
> per my knowledge these two values should be the same.
> I will be glad if you help me in this regard.
>
What does "slightly different" mean? The real-space grid is not infinitely
precise, and so each voxel (3D box) occupies a finite space resulting in a
finite discretization of the potential/density. I think you'll find that
the voxel spacing (along Z) should correspond nicely with your mismatch.

>
> Attached with this email are the plots for CdS monolayer and Bilayer
> systems.
>
> On Wed, Sep 2, 2020 at 2:11 PM Boubacar Traore 
> wrote:
>
>> Thanks Nick for this update on sisl :-)
>>
>> On Tue, 1 Sep 2020 at 22:00, Nick Papior  wrote:
>>
>>> Hi,
>>>
>>> In this it seems you don't need the filtering that macroave is capable
>>> of.
>>> In that case you can use sisl to create the data for you.
>>>
>>> The command would be something like this:
>>>
>>> sgrid siesta.VH --average 0 --average 1 --out VH_z.dat
>>>
>>> which will write a 2 column data file with z coordinates (in Ang) as the
>>> first and the plane-averaged potential in the 2nd column (in eV). Note this
>>> is accessible in the latest sisl development, so you'll need to install the
>>> development version (
>>> http://zerothi.github.io/sisl/docs/latest/installation.html#development-version
>>> ).
>>>
>>> The macroave calculations have only recently been added (by an external
>>> contributor, see https://github.com/zerothi/sisl/pull/230), but we
>>> haven't made a tutorial for this yet. ;)
>>>
>>>
>>> Den man. 31. aug. 2020 kl. 22.00 skrev Boubacar Traore <
>>> bt.bouba...@gmail.com>:
>>>
>>>> Hi,
>>>>
>>>>> I am trying to generate the potential plot using macroave and for that
>>>>> I have taken the .XV file and made it to run it with the macroave.in
>>>>> <https://protection.puc.rediris.es/fmlurlsvc/?fewReq=:B:JVw4MzE7OCR0PzMsMiRrZj8yMzgyMyRxa2VsY3Z3cGc/MWY1YTA6YDJjY2dnM2EwZ2MyNzEwZzY0Z2EzZ2YwZDRnNDMyMjRkNyR2PzM3Ozo6NDE6NzUkc2tmPzI1VDprZ0xvMjM1NjoxLzI1VDprZ0xtMjM1NjoxJHBhcnY/cWtncXZjL25Cd2NvLGdxJGE/OzI==http%3a%2f%2fmacroave.in>
>>>>> file. But there are some queries that I have not understood regarding the
>>>>> macroave.in
>>>>> <https://protection.puc.rediris.es/fmlurlsvc/?fewReq=:B:JVw4MzE7OCR0PzMsMiRrZj8yMzgyMyRxa2VsY3Z3cGc/MWY1YTA6YDJjY2dnM2EwZ2MyNzEwZzY0Z2EzZ2YwZDRnNDMyMjRkNyR2PzM3Ozo6NDE6NzUkc2tmPzI1VDprZ0xvMjM1NjoxLzI1VDprZ0xtMjM1NjoxJHBhcnY/cWtncXZjL25Cd2NvLGdxJGE/OzI==http%3a%2f%2fmacroave.in>
>>>>> file. And I would be very glad if any one could help me in this regard.
>>>>
>>>> It's the .VH file that is needed  in your case.
>>>>
>>>>
>>>>> 1. In the fourth line of macroave.in
>>>>> <https://protection.puc.rediris.es/fmlurlsvc/?fewReq=:B:JVw4MzE7OCR0PzMsMiRrZj8yMzgyMyRxa2VsY3Z3cGc/MWY1YTA6YDJjY2dnM2EwZ2MyNzEwZzY0Z2EzZ2YwZDRnNDMyMjRkNyR2PzM3Ozo6NDE6NzUkc2tmPzI1VDprZ0xvMjM1NjoxLzI1VDprZ0xtMjM1NjoxJHBhcnY/cWtncXZjL25Cd2NvLGdxJGE/OzI==http%3a%2f%2fmacroave.in>
>>>>> file we need to mention how many step functions we need to smooth. And I 
>>>>> am
>>>>> working on a bilayer system so I wish to know whether I should take 
>>>>> surface
>>>>> or interface calculation in this regard (appeded below is the fdf file of
>>>>> the calculation that I am running). What would be the case for trilayer
>>>>> system?
>>>>>
>>>> Your bi-layer system consists of layers of the same type. So, "surface"
>>>> should do the job. "Interface" is for heterstructures or hetero-layers with
>>>> different materials. Anyway, you

Re: [SIESTA-L] Question about continuing TranSIESTA job

[Nick Papior]

The same flag applies to transiesta. :)

On Tue, 1 Sep 2020, 22:01 El-abed Haidar, 
wrote:

> Good afternoon,
>
> In siesta you can use UseData to continue a siesta job, what command
> should I use to make sure that TranSIESTA continues from where it stops
> especially if the job was not completed?
>
> Thank you and looking forward to all thoughts.
>
> EL-abed
>
>
>
> El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group| School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

-- 
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] Command for scattering region calculation

[Nick Papior]

You simply do "siesta xxx.fdf"

TranSiesta is enabled through the fdf-option "SolutionMethod".

As for the I-V curve, yes, I would recommend you to compile siesta with
NetCDF4 support.

Den fre. 28. aug. 2020 kl. 22.00 skrev MANISH KR MOHANTA <
manish.ph16...@inst.ac.in>:

> Dear Experts,
>
> I am new to Siesta and installed the latest version from gitlab.
> I have performed electrode calculation using
> "siesta --electrode .fdf" command. And since transiesta is enabled in
> this version, what should be my command for scattering calculation ?
>
> e.g. "siesta .fdf" or "siesta --sr ,fdf" ?
>
> For the I-V curve, do I need to compile siesta with NETCDF4 ?
> Kindly help me out.
>
> --
> *Best Regards*
> *Manish Kumar Mohanta (**CSIR-SRF)*
> *Ph.D Student, Prof. Abir Research group*
> *Institute of Nano Science and Technology*
>
> *Mohali, Punjab, India*
> *M- +91-9643212837*
>
> --
> 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/)

Re: [SIESTA-L] How to find find variation of potential with distance in siesta

[Nick Papior]

Hi,

In this it seems you don't need the filtering that macroave is capable of.
In that case you can use sisl to create the data for you.

The command would be something like this:

sgrid siesta.VH --average 0 --average 1 --out VH_z.dat

which will write a 2 column data file with z coordinates (in Ang) as the
first and the plane-averaged potential in the 2nd column (in eV). Note this
is accessible in the latest sisl development, so you'll need to install the
development version (
http://zerothi.github.io/sisl/docs/latest/installation.html#development-version
).

The macroave calculations have only recently been added (by an external
contributor, see https://github.com/zerothi/sisl/pull/230), but we haven't
made a tutorial for this yet. ;)


Den man. 31. aug. 2020 kl. 22.00 skrev Boubacar Traore <
bt.bouba...@gmail.com>:

> Hi,
>
>> I am trying to generate the potential plot using macroave and for that I
>> have taken the .XV file and made it to run it with the macroave.in
>> 
>> file. But there are some queries that I have not understood regarding the
>> macroave.in
>> 
>> file. And I would be very glad if any one could help me in this regard.
>
> It's the .VH file that is needed  in your case.
>
>
>> 1. In the fourth line of macroave.in
>> 
>> file we need to mention how many step functions we need to smooth. And I am
>> working on a bilayer system so I wish to know whether I should take surface
>> or interface calculation in this regard (appeded below is the fdf file of
>> the calculation that I am running). What would be the case for trilayer
>> system?
>>
> Your bi-layer system consists of layers of the same type. So, "surface"
> should do the job. "Interface" is for heterstructures or hetero-layers with
> different materials. Anyway, you may try both and see the difference.
>
>
>> 2. In the Fifth and Sixth line of macroave.in
>> 
>> file we need to mention the width of the two functions like planar lattice
>> spacing. I am not able to understand what quantity it is asking. Should I
>> specify the the interlayer distance? what should be these values for my
>> input given below? What would be the case for multilayer system? and if the
>> system has buckling, then how should I chose these values?
>>
> What macroave does is nothing but averaging the potential/density in the
> plane and filtering it out  let's say along z-direction.  The two functions
> ( for interface) or one function (for surface) are for the filtering
> purpose. In the filtering step, macroave performs convolutions. The length
> is about the unit cell length or cell period along z. See this reference
> paper of Junquera et al. for more detail: 10.1088/0953-8984/19/21/213203
> 
>
>
>> 3.In the 7th line, of macroave.in
>> 
>> file we need to specify the number of electrons in the slab. Here I wanted
>> to know that suppose I am working on a carbon based bilayer system, do I
>> need to take the valence electrons or all the 6 electrons and multiply it
>> with the number of carbon atoms on each layer?
>>
> Yes, but in carbon you have 4 valence electrons. Remember that this is
> important only when you use macroave with charge densities (.RHO file); it
> is used for normalization. To get the total number of electrons, you can
> also do :
> grep "Total number of electrons" SystemLabel.out
>
> 4. And  in running the macroave calculation, I am getting two generated
>> files with the calculation with extensions MAV and PAV. what is the
>> difference between macroscopic average and the planar average files?
>>
> PAV : is the averaged 

Re: [SIESTA-L] tbtrans errors

[Nick Papior]

Could you try with a nonzero eta for the electrodes?
Same goes for transiesta calculations with bias.
Say a value of 1e-4 eV.

One cannot use eta==0 since the dos explodes if you hit an eigenstate.

On Sat, 25 Jul 2020, 07:12 赵鸿远,  wrote:

> Dear all,
> I am using siesta4.1-b4 version. I want to calculate I-V curve for my
> system. My scf and ts-scf calculations were done successfully with
> transiesta code. An error occurs  when I run tbtrans program to extract
> data.
> the screen shows following error:
>
> tbt: LHS Green function padding / memory: 715712 /   23.730 MB
> tbt: RHS Green function padding / memory: 129600 /   14.787 MB
> TT_eigen: Could not calculate eigenvalues.
>
> Intel MKL ERROR: Parameter 3 was incorrect on entry to ZGEBAL.
>
> Intel MKL ERROR: Parameter 4 was incorrect on entry to ZHSEQR.
>   -4
> TT_eigen: Could not calculate eigenvalues.
> Stopping Program from Node:   22
> Stopping Program from Node:   22
>
>
> Could someone help me solve the problem?
>
>
> Thanks,
>
> Zhao HY
>
>
>

-- 
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] K points in TranSIESTA vs TbTrans question

[Nick Papior]

Den fre. 10. jul. 2020 kl. 08.22 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> No, the TSHS is the output of TranSiesta. TSHS files are only read by
> TBtrans, not altered or changed. If you mean EigenChannels from the
> Inelastica suite, then the k-points in your tbtrans calculation has no
> influence on the Inelastica calculation, I am not sure exactly what you
> mean here...
>
>
>
> *THAT IS EXACTLY WHAT I WANTED TO KNOW ABOUT THAT*  
>
>
>
> I would advice to always disclose 3 k-point samplings in any publication,
> 1) the electrode k-point sampling, 2) the transiesta k-point sampling, 3)
> the tbtrans k-point sampling. If you are simulating chains, then you don't
> only need to mention the electrode, for obvious reasons
>
>
>
> *ALSO THAT IS EXACTLY WHAT I WANTED TO KNOW ABOUT THAT*  
>
>
>
>
>
> And if you want to really be sure, then once you have converged TBtrans,
> you do a SIESTA with increased k-points, then redo the tbtrans for the
> converged tbtrans k-point sampling. This will really show the robustness of
> the parameters. :)
>
> *Sorry I don’t understand. Could you kindly elaborate on that?*
>
>
>
> I did *TranSIESTA for example from electrode the scattering with
> increased k points 5 1 100 from 1 1 100 and had a look at he Tbtrans and
> got really similar results in T(E) and even Eigenchannels.* *Is that the
> robustness you are aiming for?*
>
Yeah, sounds correct.

>
>
> El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group| School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
>
>
> *From: *Nick Papior 
> *Sent: *Friday, 10 July 2020 4:10 PM
> *To: *El-abed Haidar 
> *Cc: *siesta-l@uam.es
> *Subject: *Re: [SIESTA-L] K points in TranSIESTA vs TbTrans question
>
>
>
> Hi,
>
>
>
> Den fre. 10. jul. 2020 kl. 05.00 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Thank you a lot for the outline Nick and thank you Berna for your insight.
>
>
>
> So coming back to my email that means it is feasible to start with lower K
> points (as long as they are converged) and then increase them only in
> Tbtrans.
>
> A couple of questions though:
>
>1. @Nick Papior  when you increase your k points
>in Tbtrans that wont change the kpoints in TSHS files because those are
>TranSIESTA. Is that correct? Because that affects the Eigenchannel
>calculations.
>
> No, the TSHS is the output of TranSiesta. TSHS files are only read by
> TBtrans, not altered or changed. If you mean EigenChannels from the
> Inelastica suite, then the k-points in your tbtrans calculation has no
> influence on the Inelastica calculation, I am not sure exactly what you
> mean here...
>
>
>1. I am asking this because when I read any paper based on TranSIESTA
>and they mention k points 1 1 100 i would assume that means in TbTrans they
>have done the same.
>
> If the paper you read were mentioning this for the electrode region then
> it suggests to me that the system is a "chain" and thus have no k-points
> transverse to the transport direction which means that you don't need to
> use k-points in TBtrans. So this is perfectly fine. I would advice to
> always disclose 3 k-point samplings in any publication, 1) the electrode
> k-point sampling, 2) the transiesta k-point sampling, 3) the tbtrans
> k-point sampling. If you are simulating chains, then you don't only need to
> mention the electrode, for obvious reasons :)
>
>
>1. So in summary we should do a SIESTA convergence test and then
>Tbtrans. Would you agree?
>
> Yes. And if you want to really be sure, then once you have converged
> TBtrans, you do a SIESTA with increased k-points, then redo the tbtrans for
> the converged tbtrans k-point sampling. This will really show the
> robustness of the parameters. :)
>
> Thank you all !
>
> EL-abed
>
> El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group| School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
>
>
> *From: *Nick Papior 
> *Sent: *Friday, 10 July 2020 6:04 AM
> *To: *siesta-l 
> *Subject: *Re: [SIESTA-L] K points in TranSIESTA vs TbTrans question
>
>
>
> The basic principle of transiesta is as with siesta.
>
>
>
> A rough outline would be this:
>
>
>
> 0) Create your system, decide upon the electrodes. Ensure your device
> screens off the defect towards the electrodes (meaning you'll need some
> additional electrode layers)
>
> 1) You converge your density in your electrodes. This is a standard
> procedure for *any* DFT calculations, check all p

Re: [SIESTA-L] K points in TranSIESTA vs TbTrans question

[Nick Papior]

Hi,

Den fre. 10. jul. 2020 kl. 05.00 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Thank you a lot for the outline Nick and thank you Berna for your insight.
>
>
>
> So coming back to my email that means it is feasible to start with lower K
> points (as long as they are converged) and then increase them only in
> Tbtrans.
>
> A couple of questions though:
>
>1. @Nick Papior  when you increase your k points
>in Tbtrans that wont change the kpoints in TSHS files because those are
>TranSIESTA. Is that correct? Because that affects the Eigenchannel
>calculations.
>
> No, the TSHS is the output of TranSiesta. TSHS files are only read by
TBtrans, not altered or changed. If you mean EigenChannels from the
Inelastica suite, then the k-points in your tbtrans calculation has no
influence on the Inelastica calculation, I am not sure exactly what you
mean here...

>
>1. I am asking this because when I read any paper based on TranSIESTA
>and they mention k points 1 1 100 i would assume that means in TbTrans they
>have done the same.
>
> If the paper you read were mentioning this for the electrode region then
it suggests to me that the system is a "chain" and thus have no k-points
transverse to the transport direction which means that you don't need to
use k-points in TBtrans. So this is perfectly fine. I would advice to
always disclose 3 k-point samplings in any publication, 1) the electrode
k-point sampling, 2) the transiesta k-point sampling, 3) the tbtrans
k-point sampling. If you are simulating chains, then you don't only need to
mention the electrode, for obvious reasons :)

>
>1. So in summary we should do a SIESTA convergence test and then
>Tbtrans. Would you agree?
>
> Yes. And if you want to really be sure, then once you have converged
TBtrans, you do a SIESTA with increased k-points, then redo the tbtrans for
the converged tbtrans k-point sampling. This will really show the
robustness of the parameters. :)

> Thank you all !
>
> EL-abed
>
> El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group| School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
>
>
> *From: *Nick Papior 
> *Sent: *Friday, 10 July 2020 6:04 AM
> *To: *siesta-l 
> *Subject: *Re: [SIESTA-L] K points in TranSIESTA vs TbTrans question
>
>
>
> The basic principle of transiesta is as with siesta.
>
>
>
> A rough outline would be this:
>
>
>
> 0) Create your system, decide upon the electrodes. Ensure your device
> screens off the defect towards the electrodes (meaning you'll need some
> additional electrode layers)
>
> 1) You converge your density in your electrodes. This is a standard
> procedure for *any* DFT calculations, check all parameters k-points,
> mesh-cutoff, pseudos etc.
>
> 2) Once you have defined your converged parameters, you try those on the
> full device system, here starting with a regular siesta calculation should
> suffice. Once done you should again ensure that you converge the system
> parameters, i.e. try increasing k-points etc and see if you get the same
> results.
>
> 3) Now you do your transiesta calculation with your converged parameters.
>
> 4) TBtrans calculates DOS and transmissions. These quantities are more
> sensitive to the k-point sampling compared to the charge density. So you,
> generally, should always use a denser k--grid for tbtrans.
>
> See slide 5 here:
> https://github.com/zerothi/ts-tbt-sisl-tutorial/releases/download/v2018.11/talk_2.pdf
> <https://protect-au.mimecast.com/s/O7gOCxngwOfMy80Kt826WB?domain=github.com>
>
> Needless to say, this is also important for correct DOS analysis for
> siesta calculations.
>
> So again you have to converge the number of k-points for your tbtrans
> calculations.
>
>
>
> Den ons. 8. jul. 2020 kl. 22.00 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Good afternoon,
>
> I was wondering about the following:
>
>1. I have done a TranSIESTA + TbTrans calculation using 1 1 100 and
>had a look at transmission curves and PDOS. I got certain results but I
>then increased k points to 5 1  100. And only ran a TbTrans. The NEW
>results saw some changes.
>2. I decided then to restart from scratch the same Transiesta +
>Tbtrans calculation with 5 1 100 instead of 1 1 100. I got almost the same
>results as the NEW in step 1. Is that expected? If so why ?
>3. If so also does that mean I could start with less k points and just
>increase them in the TbTrans run by using TBT.k [a b c]?
>
>
>
> I just want to make sure that my results are feasible and acceptable.
>
> Thank you and looking forward t

Re: [SIESTA-L] K points in TranSIESTA vs TbTrans question

[Nick Papior]

The basic principle of transiesta is as with siesta.

A rough outline would be this:

0) Create your system, decide upon the electrodes. Ensure your device
screens off the defect towards the electrodes (meaning you'll need some
additional electrode layers)
1) You converge your density in your electrodes. This is a standard
procedure for *any* DFT calculations, check all parameters k-points,
mesh-cutoff, pseudos etc.
2) Once you have defined your converged parameters, you try those on the
full device system, here starting with a regular siesta calculation should
suffice. Once done you should again ensure that you converge the system
parameters, i.e. try increasing k-points etc and see if you get the same
results.
3) Now you do your transiesta calculation with your converged parameters.
4) TBtrans calculates DOS and transmissions. These quantities are more
sensitive to the k-point sampling compared to the charge density. So you,
generally, should always use a denser k--grid for tbtrans.
See slide 5 here:
https://github.com/zerothi/ts-tbt-sisl-tutorial/releases/download/v2018.11/talk_2.pdf
Needless to say, this is also important for correct DOS analysis for siesta
calculations.
So again you have to converge the number of k-points for your tbtrans
calculations.

Den ons. 8. jul. 2020 kl. 22.00 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good afternoon,
>
> I was wondering about the following:
>
>1. I have done a TranSIESTA + TbTrans calculation using 1 1 100 and
>had a look at transmission curves and PDOS. I got certain results but I
>then increased k points to 5 1  100. And only ran a TbTrans. The NEW
>results saw some changes.
>2. I decided then to restart from scratch the same Transiesta +
>Tbtrans calculation with 5 1 100 instead of 1 1 100. I got almost the same
>results as the NEW in step 1. Is that expected? If so why ?
>3. If so also does that mean I could start with less k points and just
>increase them in the TbTrans run by using TBT.k [a b c]?
>
>
>
> I just want to make sure that my results are feasible and acceptable.
>
> Thank you and looking forward to your reply.
>
> EL-abed
>
> El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group| School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
>
>
> --
> 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/)

Re: [SIESTA-L] Fw: How to read WFSX file

[Nick Papior]

How do you want to read it?

In sisl there is a recent addition which allows you to iterate the values
in the file

 python
import sisl as si
wfsx = si.get_sile("file.WFSX")
for es in wfsx.yield_eigenstate():
print(es, es.shape)
###

This lets you use the values in the file, if needed :)
Then you can parse it as needed, for instance es.state gives you the
coefficients of the eigenstates.

Den lør. 4. jul. 2020 kl. 22.04 skrev Medondjio Linda <
lindamedond...@yahoo.fr>:

> Dear Siesta user,
>
> I would like to  generate a readable file from
> 'systemlabel.selected.WFSX' . I have changed the name into WFSX.
>
> I used the following command line to go back to the old format as stated
> in the siesta manual :
> siesta-4.1-b4/Util/WFS/wfsx2wfs  WFSX.
> I am running the following command:
>
> /SIESTA/siesta-4.1-b4/Util/WFS/readwfx WFS
>
> But nothing is happening(No file is being generated, no message is
> displayed on my terminal)
>
>
> Thank you in advance.
>
> Linda
>
> --
> 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/)

Re: [SIESTA-L] PDOS and EIG files in transiesta

[Nick Papior]

TranSiesta does not use the same file formats.

1) Eigenvalues cannot be calculated using the NEGF formalism, so you won't
get the eig file, ever.
2) If you use siesta-4.1 or later you will only get a projected DOS output
from TBtrans in the *.TBT.nc files. Subsequently you should use sisl,
https://github.com/zerothi/sisl, to extract the DOS for given orbitals
and/or atoms. Remark that if you haven't compiled with NetCDF 4 support
(see manual) then you will only get the full DOS for the device region,
i.e. no individual orbital PDOS.

Den ons. 24. jun. 2020 kl. 22.03 skrev rayan moukhadder <
rayanroro321...@gmail.com>:

> Hello everybody, I would like to ask why .PDOS and
> .EIG files are not obtained by me after a successful
> transiesta and tbtrans run knowing that i added the options
> TS.TBT.AtomPDOS true
> TBT.DOS.A.All true
> Thanks in advance.
>
>
> --
> 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/)

Re: [SIESTA-L] [SIESTA-user] Problem while installing psml compatible SIESTA

[Nick Papior]

In conjunction with making Siesta easier to install (and the future PSML
incorporation) I have made some scripts which should ease this.

I here attach the scripts which I have tested (only a few times), any
feedback is very welcome.

They should more or less be self-contained. :)

@Nicolas please read the manual, if you have specific questions, let us
know.

Den tir. 23. jun. 2020 kl. 22.01 skrev FOURCHES Nicolas <
nicolas.fourc...@cea.fr>:

> Hello,
>
>
>
> Has anyone have a users’ guide for the installation of siesta latest
> version for full parallel computing ? Where can I find this info ?
>
>
>
> Regards
>
>
>
> Nicolas Fourches
>
>
>
>
>
>
>
> *From:* siesta-l-requ...@uam.es  *On Behalf Of *Yuvam
> Bhateja
> *Sent:* vendredi 19 juin 2020 10:49
> *To:* siesta-l@uam.es
> *Subject:* [SIESTA-L] [SIESTA-user] Problem while installing psml
> compatible SIESTA
>
>
>
> Hey,
>
> I was installing siesta-psml but getting error and I am not understanding
> where I am doing wrong. I am using libraries from esl-bundle.
>
> I want an accelerated and accurate siesta program which I think psml will
> do, though I am not really sure.
>
> I am attaching the screenshot of the error and my arch.make file.
>
> Please let me know how can I fix it and can I accelerate my SIESTA
> calculations in any other way.
>
> Thanks in advance
>
>
>
> Regards
>
> Yuvam Bhateja
>
> --
> 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


install_psml.bash
Description: Binary data


install_gridxc.bash
Description: Binary data

-- 
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] << Materials Modeling Stack Exchange >>

[Nick Papior]

Thanks for bringing this to the attention of the community!

Den ons. 17. jun. 2020 kl. 22.06 skrev I. Camps :

> Dear SIESTers,
>
> I would like to invite you to visit the Materials Modeling Stack Exchange
> forum (in public beta).
>
> The site is dedicated for those interested in building a community
> dedicated to answering research level questions about molecular and
> materials modeling.
>
> https://materials.stackexchange.com/
>
>
>
> []'s,
>
> Camps
>
> --
> 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/)

Re: [SIESTA-L] Transiesta DM does not converge

[Nick Papior]

Hi,

Den tir. 16. jun. 2020 kl. 22.00 skrev Seyed Mohammad Tabatabaei <
smt...@gmail.com>:

> Thank you so much for your answer.
>
> Do I need to use more buffer layers?
>
Maybe, first change to metallic MoS2, then see.

>
> I am currently using semiconducting MoS2 nanoribbons (1D system) with a
> bandgap of about 0.5 eV. Would changing to metallic MoS2 nanoribbons
> improve convergence?
>
Yes, using metallic electrodes would definitely help.

>
> Do you mean I should increase the cutt-off energy?
>
I didn't realize it was a nanoribbon. So no need for k-point convergence.
But you should converge system parameters before doing NEGF calculations.
This includes basis set optimization + mesh-cutoff etc.

>
>
>
>
>
> On Tue, Jun 16, 2020 at 12:36 AM Nick Papior  wrote:
>
>> Hi,
>>
>> 1. Great that you are using buffer atoms to get the *correct* behaviour
>> of your electrodes
>> 2. However, you are using MoS2 as electrodes, which is semiconducting.
>> This is not a good idea since the NEGF formalism requires the electrodes
>> are *bulk-like* and this cannot be enforced if the screening distance is
>> very long. This is the case for semi-conducting electrodes.
>> 3. Your other convergence parameters are very low, you really should
>> first converge the basic MoS2 setup for k-points, mesh-cutoff etc. but in
>> general, if you have semi-conducting electrodes, you shouldn't use NEGF
>> unless you are being really careful. :)
>>
>> Den lør. 13. jun. 2020 kl. 22.00 skrev Seyed Mohammad Tabatabaei <
>> smt...@gmail.com>:
>>
>>> Dear all,
>>>
>>> I am doing a TranSIESTA calculation for the following system.
>>>
>>> [image: image.png]
>>>
>>> However, I cannot converge the density matrix no matter how small my
>>> mixing weight is.
>>>
>>> I would be grateful if you help me with it. My output file is also
>>> attached.
>>>
>>> Best regards,
>>>
>>>
>>>
>>> --
>>> 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 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/)

Re: [SIESTA-L] [***Posible SPAM***]Sin Asunto/Subject is blank

[Nick Papior]

A bulk system where you know the LDA+U results, then do the same bulk
system with NEGF + LDA+U.

Den tir. 16. jun. 2020 kl. 15.42 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> What should I be looking for? Because as far I have been aware of it has
> been highly recommended to utilize both simultaneously.
>
> My question in other words: What should I test exactly? U and J did you
> mean?
>
> Thank you and really appreciate your time!
>
> EL-abed
>
>
>
> El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group| School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
>
>
> *From: *Nick Papior 
> *Sent: *Tuesday, 16 June 2020 11:35 PM
> *To: *El-abed Haidar 
> *Cc: *siesta-l 
> *Subject: *Re: [SIESTA-L] [***Posible SPAM***]Sin Asunto/Subject is blank
>
>
>
> I have never tried, I don't know if there are any restrictions using both
> simultaneously. :(
>
>
>
> So a careful test of everything to see if it behaves as expected would be
> required, I think. ;)
>
>
>
> Den tir. 16. jun. 2020 kl. 15.32 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Thank you again Nick! Just a follow up question are we allowed to use
> LDA+U in TranSIESTA + TbTrans?
>
> Is that applicable? Has anyone published or tested such exchange
> correlation for current voltage calculations? Any further comments would be
> highly appreciated!
>
> Thank you and looking forward to your thoughts!
>
> EL-abed
>
>
>
> El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group| School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
>
>
> *From: *El-abed Haidar 
> *Sent: *Tuesday, 16 June 2020 10:43 PM
> *To: *Nick Papior ; siesta-l 
> *Subject: *RE: [SIESTA-L] [***Posible SPAM***]Sin Asunto/Subject is blank
>
>
>
> Thank you very much Nick!
>
> No wonder my calculations were taking that much long!
>
> El-abed
>
>
>
> El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group| School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
>
>
> *From: *Nick Papior 
> *Sent: *Tuesday, 16 June 2020 4:41 PM
> *To: *siesta-l ; El-abed Haidar
> 
> *Subject: *Re: [SIESTA-L] [***Posible SPAM***]Sin Asunto/Subject is blank
>
>
>
> Hi,
>
>
>
> 1. Original poster. Could you please try read the manual. Your problem are
> multiple, the electronic structure parameters are insufficient and you are
> not using the electrodes as they should. I.e. they are not bulk like.
>
>
>
> Your simulation requires the use of real-space self-energies, see
> https://journals.aps.org/prb/abstract/10.1103/PhysRevB.100.195417
> <https://protect-au.mimecast.com/s/6sxiCJyBrGf4jNBZCVeMd9?domain=journals.aps.org>
>  .
>
> However, if you are a first in doing transiesta/tbtrans calculations you
> should not start with something this complicated... :(
>
>
>
> 2. @El-abed Haidar , a comment on the input
> suggested.
>
>from -999.99893 eV - V/2 to -10. kT - V/2
>
> Don't do this! You should probably never go below -100 eV, the default -40
> eV should be sufficient for most systems, but -1000 eV is definitely too
> much.
>
> Also, "used-atoms 63" should only be supplied in case you have a subset
> electrode calculation. Otherwise remove this line.
>
>
>
> / Nick
>
>
>
> Den man. 15. jun. 2020 kl. 22.02 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Hi Rayan
>
> Quick question what is the transport direction?
>
> I feel there are some essential blocks missing. Those are generally
> required for a TranSIESTA and TbTrans calculation. Good luck!
>
>
>
> %block TS.ChemPots
>
>   Left
>
>   Right
>
> %endblock TS.ChemPots
>
> %block TS.ChemPot.Left
>
>   mu V/2
>
>   contour.eq
>
> begin
>
>   c-Left
>
>   t-Left
>
> end
>
> %endblock TS.ChemPot.Left
>
> %block TS.ChemPot.Right
>
>   mu -V/2
>
>   contour.eq
>
> begin
>
>   c-Right
>
>   t-Right
>
> end
>
> %endblock TS.ChemPot.Right
>
> TS.Elecs.Bulk true
>
> TS.Elecs.DM.Update cross-terms
>
> TS.Elecs.GF.ReUse true
>
> %block TS.Elecs
>
>   Left
>
>   Right
>
> %endblock TS.Elecs
>
> %block TS.Elec.Left
>
>   HS ./left.TSHS
>
>   chem-pot Left
>
>   semi-inf-dir -a2
>
>   elec-pos begin 1
>
>   used-atoms 63
>
> %endblock TS.Elec.Left
>
> %block TS.Elec.Right
>
>   HS ./right.TSHS
>
>   chem-pot Rig

Re: [SIESTA-L] [***Posible SPAM***]Sin Asunto/Subject is blank

[Nick Papior]

Hi,

1. Original poster. Could you please try read the manual. Your problem are
multiple, the electronic structure parameters are insufficient and you are
not using the electrodes as they should. I.e. they are not bulk like.

Your simulation requires the use of real-space self-energies, see
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.100.195417 .
However, if you are a first in doing transiesta/tbtrans calculations you
should not start with something this complicated... :(

2. @El-abed Haidar , a comment on the input
suggested.

   from -999.99893 eV - V/2 to -10. kT - V/2
Don't do this! You should probably never go below -100 eV, the default -40
eV should be sufficient for most systems, but -1000 eV is definitely too
much.
Also, "used-atoms 63" should only be supplied in case you have a subset
electrode calculation. Otherwise remove this line.

/ Nick

Den man. 15. jun. 2020 kl. 22.02 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Hi Rayan
>
> Quick question what is the transport direction?
>
> I feel there are some essential blocks missing. Those are generally
> required for a TranSIESTA and TbTrans calculation. Good luck!
>
>
>
> %block TS.ChemPots
>
>   Left
>
>   Right
>
> %endblock TS.ChemPots
>
> %block TS.ChemPot.Left
>
>   mu V/2
>
>   contour.eq
>
> begin
>
>   c-Left
>
>   t-Left
>
> end
>
> %endblock TS.ChemPot.Left
>
> %block TS.ChemPot.Right
>
>   mu -V/2
>
>   contour.eq
>
> begin
>
>   c-Right
>
>   t-Right
>
> end
>
> %endblock TS.ChemPot.Right
>
> TS.Elecs.Bulk true
>
> TS.Elecs.DM.Update cross-terms
>
> TS.Elecs.GF.ReUse true
>
> %block TS.Elecs
>
>   Left
>
>   Right
>
> %endblock TS.Elecs
>
> %block TS.Elec.Left
>
>   HS ./left.TSHS
>
>   chem-pot Left
>
>   semi-inf-dir -a2
>
>   elec-pos begin 1
>
>   used-atoms 63
>
> %endblock TS.Elec.Left
>
> %block TS.Elec.Right
>
>   HS ./right.TSHS
>
>   chem-pot Right
>
>   semi-inf-dir +a2
>
>   elec-pos end -1
>
>   used-atoms 63
>
> %endblock TS.Elec.Right
>
> TS.Contours.Eq.Pole2.5 eV
>
> %block TS.Contour.c-Left
>
>   part circle
>
>from -999.99893 eV + V/2 to -10. kT + V/2
>
> points 50
>
>  method g-legendre
>
> %endblock TS.Contour.c-Left
>
> %block TS.Contour.t-Left
>
>   part tail
>
>from prev to inf
>
> points 10
>
>  method g-fermi
>
> %endblock TS.Contour.t-Left
>
> %block TS.Contour.c-Right
>
>   part circle
>
>from -999.99893 eV - V/2 to -10. kT - V/2
>
> points 50
>
>  method g-legendre
>
> %endblock TS.Contour.c-Right
>
> %block TS.Contour.t-Right
>
>   part tail
>
>from prev to inf
>
> points 10
>
>  method g-fermi
>
> %endblock TS.Contour.t-Right
>
> TS.Elecs.Eta0.000100 eV
>
> %block TS.Contours.nEq
>
>   neq
>
> %endblock TS.Contours.nEq
>
> %block TS.Contour.nEq.neq
>
>   part line
>
>from -|V|/2 - 5 kT to |V|/2 + 5 kT
>
> delta 0.01 eV
>
>  method mid-rule
>
> %endblock TS.Contour.nEq.neq
>
> # TBtrans options
>
> TBT.T.Eig 5
>
> TBT.Elecs.Eta0.136058 eV
>
> %block TBT.Contours
>
>   neq
>
> %endblock TBT.Contours
>
> %block TBT.Contour.neq
>
>   part line
>
>from   -2.0 eV to2.0 eV
>
> delta0.00800 eV
>
>  method mid-rule
>
> %endblock TBT.Contour.neq
>
>
>
> TBT.DOS.A.All  true
>
> TBT.CDF.MPI true
>
> TS.Voltage 0.0 eV
>
>
>
>
>
> El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group| School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
>
>
> *From: *rayan moukhadder 
> *Sent: *Monday, 15 June 2020 6:04 AM
> *To: *siesta-l@uam.es
> *Subject: *[SIESTA-L] [***Posible SPAM***]Sin Asunto/Subject is blank
>
>
>
> Dear all,
>
>
>
> I am a phd student and I am new to siesta , I am doing a Transiesta
> calculation for a system that consist of two graphene sheets sandwiching
> three cobalt atoms, as the electrode calculation is successfully done, the
> SCF iterations in SR calculation are not converging where my input file is
>
>
>
> SystemName  SR.Co
> SystemLabel SR.Co
>
> NumberOfAtoms   131
> NumberOfSpecies2
>
> %block ChemicalSpeciesLabel
>   1   6  C
>   2   27 Co
> %endblock ChemicalSpeciesLabel
>
> PAO.BasisSize  SZP
> PAO.EnergyShift  0.05 Ry
> PAO.SplitNorm0.2
>
> ==
> ==
> # K-points
>
> %block kgrid_Monkhorst_Pack
>1   0   0  0.0
>0   1   0  0.0
>0   0   1  0.5
> %endblock Kgrid_Monkhorst_Pack
> ==
> ==
> # UNIT CELL AND ATOMIC POSITIONS
>
> # UNIT CELL
> LatticeConstant 1.00 Ang
>
> %block LatticeVectors
> 17.016 0.000 0.000
> 0.000 9.824 0.000
> 0.000 0. 14.000
> %endblock LatticeVectors
> AtomicCoordinatesFormat Ang
>
> %block AtomicCoordinatesAndAtomicSpecies
>
> 0.000 0.000 0.000 1
> 1.418 0.000 0.000 1
> 2.127 1.228 0.000 1
> 3.545 1.228 0.000 1
> 4.254 0.000 

Re: [SIESTA-L] [***Posible SPAM***]Sin Asunto/Subject is blank

[Nick Papior]

I have never tried, I don't know if there are any restrictions using both
simultaneously. :(

So a careful test of everything to see if it behaves as expected would be
required, I think. ;)

Den tir. 16. jun. 2020 kl. 15.32 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Thank you again Nick! Just a follow up question are we allowed to use
> LDA+U in TranSIESTA + TbTrans?
>
> Is that applicable? Has anyone published or tested such exchange
> correlation for current voltage calculations? Any further comments would be
> highly appreciated!
>
> Thank you and looking forward to your thoughts!
>
> EL-abed
>
>
>
> El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group| School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
>
>
> *From: *El-abed Haidar 
> *Sent: *Tuesday, 16 June 2020 10:43 PM
> *To: *Nick Papior ; siesta-l 
> *Subject: *RE: [SIESTA-L] [***Posible SPAM***]Sin Asunto/Subject is blank
>
>
>
> Thank you very much Nick!
>
> No wonder my calculations were taking that much long!
>
> El-abed
>
>
>
> El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group| School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
>
>
> *From: *Nick Papior 
> *Sent: *Tuesday, 16 June 2020 4:41 PM
> *To: *siesta-l ; El-abed Haidar
> 
> *Subject: *Re: [SIESTA-L] [***Posible SPAM***]Sin Asunto/Subject is blank
>
>
>
> Hi,
>
>
>
> 1. Original poster. Could you please try read the manual. Your problem are
> multiple, the electronic structure parameters are insufficient and you are
> not using the electrodes as they should. I.e. they are not bulk like.
>
>
>
> Your simulation requires the use of real-space self-energies, see
> https://journals.aps.org/prb/abstract/10.1103/PhysRevB.100.195417
> <https://protect-au.mimecast.com/s/Ty4RC91WPRTZl1JQcoJX1f?domain=journals.aps.org>
>  .
>
> However, if you are a first in doing transiesta/tbtrans calculations you
> should not start with something this complicated... :(
>
>
>
> 2. @El-abed Haidar , a comment on the input
> suggested.
>
>from -999.99893 eV - V/2 to -10. kT - V/2
>
> Don't do this! You should probably never go below -100 eV, the default -40
> eV should be sufficient for most systems, but -1000 eV is definitely too
> much.
>
> Also, "used-atoms 63" should only be supplied in case you have a subset
> electrode calculation. Otherwise remove this line.
>
>
>
> / Nick
>
>
>
> Den man. 15. jun. 2020 kl. 22.02 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Hi Rayan
>
> Quick question what is the transport direction?
>
> I feel there are some essential blocks missing. Those are generally
> required for a TranSIESTA and TbTrans calculation. Good luck!
>
>
>
> %block TS.ChemPots
>
>   Left
>
>   Right
>
> %endblock TS.ChemPots
>
> %block TS.ChemPot.Left
>
>   mu V/2
>
>   contour.eq
>
> begin
>
>   c-Left
>
>   t-Left
>
> end
>
> %endblock TS.ChemPot.Left
>
> %block TS.ChemPot.Right
>
>   mu -V/2
>
>   contour.eq
>
> begin
>
>   c-Right
>
>   t-Right
>
> end
>
> %endblock TS.ChemPot.Right
>
> TS.Elecs.Bulk true
>
> TS.Elecs.DM.Update cross-terms
>
> TS.Elecs.GF.ReUse true
>
> %block TS.Elecs
>
>   Left
>
>   Right
>
> %endblock TS.Elecs
>
> %block TS.Elec.Left
>
>   HS ./left.TSHS
>
>   chem-pot Left
>
>   semi-inf-dir -a2
>
>   elec-pos begin 1
>
>   used-atoms 63
>
> %endblock TS.Elec.Left
>
> %block TS.Elec.Right
>
>   HS ./right.TSHS
>
>   chem-pot Right
>
>   semi-inf-dir +a2
>
>   elec-pos end -1
>
>   used-atoms 63
>
> %endblock TS.Elec.Right
>
> TS.Contours.Eq.Pole2.5 eV
>
> %block TS.Contour.c-Left
>
>   part circle
>
>from -999.99893 eV + V/2 to -10. kT + V/2
>
> points 50
>
>  method g-legendre
>
> %endblock TS.Contour.c-Left
>
> %block TS.Contour.t-Left
>
>   part tail
>
>from prev to inf
>
> points 10
>
>  method g-fermi
>
> %endblock TS.Contour.t-Left
>
> %block TS.Contour.c-Right
>
>   part circle
>
>from -999.99893 eV - V/2 to -10. kT - V/2
>
> points 50
>
>  method g-legendre
>
> %endblock TS.Contour.c-Right
>
> %block TS.Contour.t-Right
>
>   part tail
>
>from prev to inf
>
> points 10
>
>  method g-fermi
>
> %endblock TS.Contour.t-Right
>
> TS.Elecs

Re: [SIESTA-L] Transiesta DM does not converge

[Nick Papior]

Hi,

1. Great that you are using buffer atoms to get the *correct* behaviour of
your electrodes
2. However, you are using MoS2 as electrodes, which is semiconducting. This
is not a good idea since the NEGF formalism requires the electrodes are
*bulk-like* and this cannot be enforced if the screening distance is very
long. This is the case for semi-conducting electrodes.
3. Your other convergence parameters are very low, you really should first
converge the basic MoS2 setup for k-points, mesh-cutoff etc. but in
general, if you have semi-conducting electrodes, you shouldn't use NEGF
unless you are being really careful. :)

Den lør. 13. jun. 2020 kl. 22.00 skrev Seyed Mohammad Tabatabaei <
smt...@gmail.com>:

> Dear all,
>
> I am doing a TranSIESTA calculation for the following system.
>
> [image: image.png]
>
> However, I cannot converge the density matrix no matter how small my
> mixing weight is.
>
> I would be grateful if you help me with it. My output file is also
> attached.
>
> Best regards,
>
>
>
> --
> 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/)

Re: [SIESTA-L] Transietsa/sisl problem

[Nick Papior]

Hi,

Den ons. 20. maj 2020 kl. 22.04 skrev shirin zandi <
shirinzandi1...@gmail.com>:

> Dear Nick,
> The sgeom works and it produces:
>  info:0: SislInfo: Scaling vector by: 2.7056029424251387
>
> What was wrong with the sdata command? and also how I can scaling all the
> bond current vectors by specific values (multiple by 3, 4, and ..)
>
It is an _internal_ thing.
Basically if you specify the xsf file as output you will _only_ get the
correct output options if runned by the sgeom command.
if you do sgeom siesta.TBT.nc --out test.xsf --help
you can see the options to manually specify the scaling factor.

>
>
> And one more question! is there any graphical package that I can use to
> visualize the bond current vectors inserted xcrysden?
>
I don't get what you mean? You can use xcrysden?

>
> Thanks.
> Sincerely,
> SH.
>
> On Wed, May 20, 2020 at 12:33 AM Nick Papior  wrote:
>
>> Could you try with:
>> sgeom instead of sdata?
>> That forces the interpreter to recognize geometry output settings.
>>
>> Den man. 18. maj 2020 kl. 22.02 skrev shirin zandi <
>> shirinzandi1...@gmail.com>:
>>
>>> Dear Nick,
>>>
>>> Many thanks.
>>>
>>> I did the data por.TBT.nc <http://por.tbt.nc/> --info  command  and
>>> this is what code produces:
>>>
>>> Device information:
>>>   - number of kpoints: 1 <- [ A = 1 , B = 1 , C = 1 ] (time-reversal
>>> unknown)
>>>   - energy range:
>>>  -4.99950 -- 4.99950 eV  [1.000 meV]
>>>   - imaginary part (eta): 0. meV
>>>   - atoms with DOS (fortran indices):
>>>  1-149, 155-160, 166-168, 179-181
>>>   - number of BTD blocks: 3
>>>   + DOS Green function: true
>>>   - Density matrix Green function: false[TBT.DM.Gf]
>>>   - COOP Green function: false  [TBT.COOP.Gf
>>> ]
>>>   - COHP Green function: false  [TBT.COHP.Gf
>>> ]
>>>
>>> Electrode: elec_1
>>>   - number of BTD blocks: 2
>>>   - Bloch: [1, 1, 1]
>>>   - chemical potential: 0. eV
>>>   - electron temperature: 300.00 K
>>>   - imaginary part (eta): 0.0100 meV
>>>   + DOS bulk: true
>>>   + DOS spectral: true
>>>   + orbital-current: true
>>>   - Density matrix spectral: false  [TBT.DM.A]
>>>   - COOP spectral: false[TBT.COOP.A]
>>>   - COHP spectral: false[TBT.COHP.A]
>>>   + transmission bulk: true
>>>   - transmission out: false [TBT.T.Out]
>>>   - transmission out correction: false  [TBT.T.Out]
>>>   - transmission out correction (eigen): false  [TBT.T.Out,
>>> TBT.T.Eig]
>>>   + transmission -> elec_2: true
>>>   - transmission (eigen) -> elec_2: false   [TBT.T.Eig]
>>>   + transmission -> elec_3: true
>>>   - transmission (eigen) -> elec_3: false   [TBT.T.Eig]
>>>   + transmission -> elec_4: true
>>>   - transmission (eigen) -> elec_4: false   [TBT.T.Eig]
>>>
>>> Electrode: elec_2
>>>   - number of BTD blocks: 2
>>>   - Bloch: [1, 1, 1]
>>>   - chemical potential: 0. eV
>>>   - electron temperature: 300.00 K
>>>   - imaginary part (eta): 0.0100 meV
>>>   + DOS bulk: true
>>>   + DOS spectral: true
>>>   + orbital-current: true
>>>   - Density matrix spectral: false  [TBT.DM.A]
>>>   - COOP spectral: false[TBT.COOP.A]
>>>   - COHP spectral: false[TBT.COHP.A]
>>>   + transmission bulk: true
>>>   - transmission out: false [TBT.T.Out]
>>>   - transmission out correction: false  [TBT.T.Out]
>>>   - transmission out correction (eigen): false  [TBT.T.Out,
>>> TBT.T.Eig]
>>>   - transmission -> elec_1: false
>>>   - transmission (eigen) -> elec_1: false   [TBT.T.Eig]
>>>   + transmission -> elec_3: true
>>>   - transmission (eigen) -> elec_3: false   [TBT.T.Eig]
>>>   + transmission -> elec_4: true
>>>   - transmission (eigen) -> elec_4: false   [TBT.T.Eig]
>>>
>>> Electrode: elec_3
>>>   - number of BTD blocks:

Re: [SIESTA-L] << Error compiling Util/COOP >>

[Nick Papior]

I can't recall if we *may* have fixed some things since then.

Could you try and download the latest commit on the 4.1 branch?
Here:
https://gitlab.com/siesta-project/siesta/-/archive/rel-4.1/siesta-rel-4.1.tar.bz2



Den ons. 20. maj 2020 kl. 22.08 skrev I. Camps :

> The output of "make dep" at the util folder was:
>
> *make: *** No rule to make target 'dep'.  Stop.*
>
> Inside the COOP folder was:
>
>
>
>
>
> *sfmakedepend --depend=obj --modext=o \
> /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.f
> /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.f90
> /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.F
> /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.F90 \ *.f
> *.f90 *.F *.F90/bin/sh: sfmakedepend: command not foundmake: ***
> [Makefile:53: dep] Error 127*
>
> I didn't have *sfmakedepend  *on my system. So, Googling, I download a
> version from here <https://marine.rutgers.edu/po/tools/perl/sfmakedepend>
> that looks to work after minor modifications. The output now is (attached):
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *sfmakedepend -o obj -m o \
> /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.f
> /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.f90
> /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.F
> /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.F90 \ *.f
> *.f90 *.F *.F90Can't find file: class_Data1D.T90Can't find file:
> class_Data1D.T90Can't find file: class_Data1D.T90Can't find file:
> class_Data1D.T90Can't find file: class_Data1D.T90Can't find file:
> class_Data1D.T90Can't find file: class_Data2D.T90Can't find file:
> class_Data2D.T90Can't find file: class_Data2D.T90Can't find file:
> class_Data2D.T90Can't find file: class_Data2D.T90Can't find file:
> class_Data2D.T90Can't find file: basic_type.incCan't find file:
> Fstack.T90Can't find file: Fstack.T90Can't find file: Fstack.T90Can't find
> file: Fstack.T90Can't find file: Fstack.T90Can't find file: Fstack.T90Can't
> find file: Fstack.T90Can't find file: basic_type.incCan't find file:
> basic_type.incCan't find file: Pair.T90Can't find file: Pair.T90Can't find
> file: Pair.T90Can't find file: Pair.T90Can't find file: Pair.T90Can't find
> file: basic_type.incCan't find file: class_SpData1D.T90Can't find file:
> class_SpData1D.T90Can't find file: class_SpData1D.T90Can't find file:
> class_SpData1D.T90Can't find file: class_SpData1D.T90Can't find file:
> class_SpData1D.T90Can't find file: class_SpData2D.T90Can't find file:
> class_SpData2D.T90Can't find file: class_SpData2D.T90Can't find file:
> class_SpData2D.T90Can't find file: class_SpData2D.T90Can't find file:
> class_SpData2D.T90Can't find file: class_TriMat.T90Can't find file:
> class_TriMat.T90Can't find file: class_TriMat.T90Can't find file:
> class_TriMat.T90Can't find file: class_TriMat.T90Can't find file:
> class_TriMat.T90Can't find file: f_interface.f90Can't find file:
> zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
> zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
> zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
> zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
> zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
> zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
> zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
> zmumps_struc.h*
> I didn't mention before, because I though this can be irrelevant, but my
> system CPU is not Intel, it is AMD (Six-Core AMD Opteron(tm) Processor
> 8431).
>
>
>
> []'s,
>
> Camps
>
>
> On Fri, May 15, 2020 at 5:04 PM Nick Papior  wrote:
>
>> Hmm, this looks weird.
>>
>> Could you do a "make dep" in the utility folder, and do
>> make clean
>> make
>> ?
>>
>> Den tor. 14. maj 2020 kl. 22.04 skrev I. Camps :
>>
>>> Thanks Nick.
>>>
>>> The output from make parallel.o was:
>>>
>>>
>>> *ifort  -c -O2 -ipo -xHost -ip -prec-div -prec-sqrt
>>> -opt-prefetch -mkl=parallel
>>>  
>>> -I/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/include
>>> -I/software/SIESTA_LIBS/netcdf/4.4.1/include -DMPI -UMPI
>>>  /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/parallel.Ffpp:
>>> warning: cannot remove MPI - not a predefined macro*
>>>
>&

Re: [SIESTA-L] Transietsa/sisl problem

[Nick Papior]

Den man. 18. maj 2020 kl. 22.00 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> A follow up question if I may:
>
> TO make sure we can use ssil should the fdf file contain TBT.DOS.A.All
> true and TBT.CDF.MPI true (for parallel job) ?
>
> Would those be enough? Any other blocks or command purely for PDOS we
> should be aware of?
>
It depends on what you want.
TBT.DOS.A
will give you the spectral DOS (originating from an electrode)
TBT.DOS.Gf
will give you the full DOS.
Generally you don't need TBT.DOS.A.All since there is a relation between
DOS(Gf) and SUM_elec(DOS(A_elec)) (see manual). You should definitely play
around with these options to get a feel for the performance implications of
doing 1, 2 or all 3 options.
Both Gf and A DOS can be divided into orbitals/atoms using sdata.

Also, you don't need TBT.CDF.MPI regardless of whether you are doing a
serial or parallel calculation. It only affects performance, so try it out
and see if it is faster for your HPC system, if so, prefer to use it. :)

Thank you and looking forward to your reply.
>
> EL-Abed
>
>
>
>
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>
> | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
> *From: *Nick Papior 
> *Sent: *Monday, 18 May 2020 6:01 AM
> *To: *siesta-l 
> *Subject: *Re: [SIESTA-L] Transietsa/sisl problem
>
>
>
> Hi,
>
>
>
> Simply do:
>
>
>
> sdata por.TBT.nc
> <https://protect-au.mimecast.com/s/f3bhCr81nytxYwkmc46V3_?domain=por.tbt.nc>
> --help
>
> and you'll see what commands are available.
>
>
>
> Please give back this command:
>
> sdata por.TBT.nc
> <https://protect-au.mimecast.com/s/f3bhCr81nytxYwkmc46V3_?domain=por.tbt.nc>
> --info
>
>
>
>
>
>
>
> Den lør. 16. maj 2020 kl. 22.02 skrev shirin zandi <
> shirinzandi1...@gmail.com>:
>
> Dear Nick,
>
>
>
> Thank you so much for your reply. After that I've got the following
> error :
>
>
>
> No data has been collected in the arguments, nothing will be written, have
> you forgotten arguments?
>
>
>
>
>
> The command I have run is this :   sdata por.TBT.nc
> <https://protect-au.mimecast.com/s/zEjpCp81lrt5WQVwCPjfEY?domain=por.tbt.nc/> 
> --vector
> vector_current elec_1 0.1 --out A1.xsf
>
>
>
> I know, the electrode name and energy range should be written in bond
> currents command line, is it need something else?  And generally from
> where I can find a complete list of commands and their requirements which
> can be done with sisl. I am really new in using sisl!!!
>
>
>
>
>
>
>
> Regards,
>
> SH.
>
>
>
> On Sat, May 16, 2020 at 12:30 AM Nick Papior  wrote:
>
> Hi,
>
>
>
> You probably haven't calculated bond currents. Please check your tbtrans
> input options.
>
>
>
> / Nick
>
>
>
> On Thu, 14 May 2020, 22:13 shirin zandi, 
> wrote:
>
> Dear Transiesta/sisl user
>
>
>
> I am trying to use sisl code to analyze the Transiesta obtained data, But
> when I use this code the below error has appeared:
>
>
>
>
>
> Traceback (most recent call last):
>   File "/share/apps/anaconda3/bin/sdata", line 11, in 
> load_entry_point('sisl==0.9.5', 'console_scripts', 'sdata')()
>   File
> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/utils/sdata.py",
> line 122, in sdata
> p.parse_args(argv, namespace=ns)
>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1749, in
> parse_args
> args, argv = self.parse_known_args(args, namespace)
>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1781, in
> parse_known_args
> namespace, args = self._parse_known_args(args, namespace)
>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1987, in
> _parse_known_args
> start_index = consume_optional(start_index)
>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1927, in
> consume_optional
> take_action(action, args, option_string)
>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1855, in
> take_action
> action(self, namespace, argument_values, option_string)
>   File "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/xsf.py",
> line 339, in __call__
> vector = input_sile.read_data(*values, **d)
>   File
> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/tbt.py",
> line 1930, in read_data
> val.append(self.vector_current(*args))
>   File
> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/

Re: [SIESTA-L] Transietsa/sisl problem

[Nick Papior]

.COOP.A]
>   - COHP spectral: false[TBT.COHP.A]
>   + transmission bulk: true
>   - transmission out: false [TBT.T.Out]
>   - transmission out correction: false  [TBT.T.Out]
>   - transmission out correction (eigen): false  [TBT.T.Out,
> TBT.T.Eig]
>   - transmission -> elec_1: false
>   - transmission (eigen) -> elec_1: false   [TBT.T.Eig]
>   - transmission -> elec_2: false
>   - transmission (eigen) -> elec_2: false   [TBT.T.Eig]
>   - transmission -> elec_3: false
>   - transmission (eigen) -> elec_3: false   [TBT.T.Eig]
>
>
>
>
> Wishes,
>
> SH.
>
>
> On Mon, May 18, 2020 at 12:31 AM Nick Papior  wrote:
>
>> Hi,
>>
>> Simply do:
>>
>> sdata por.TBT.nc --help
>> and you'll see what commands are available.
>>
>> Please give back this command:
>> sdata por.TBT.nc --info
>>
>>
>>
>> Den lør. 16. maj 2020 kl. 22.02 skrev shirin zandi <
>> shirinzandi1...@gmail.com>:
>>
>>> Dear Nick,
>>>
>>> Thank you so much for your reply. After that I've got the following
>>> error :
>>>
>>> No data has been collected in the arguments, nothing will be written,
>>> have you forgotten arguments?
>>>
>>>
>>> The command I have run is this :   sdata por.TBT.nc <http://por.tbt.nc/> 
>>> --vector
>>> vector_current elec_1 0.1 --out A1.xsf
>>>
>>> I know, the electrode name and energy range should be written in bond
>>> currents command line, is it need something else?  And generally from
>>> where I can find a complete list of commands and their requirements which
>>> can be done with sisl. I am really new in using sisl!!!
>>>
>>>
>>>
>>> Regards,
>>> SH.
>>>
>>> On Sat, May 16, 2020 at 12:30 AM Nick Papior 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> You probably haven't calculated bond currents. Please check your
>>>> tbtrans input options.
>>>>
>>>> / Nick
>>>>
>>>> On Thu, 14 May 2020, 22:13 shirin zandi, 
>>>> wrote:
>>>>
>>>>> Dear Transiesta/sisl user
>>>>>
>>>>> I am trying to use sisl code to analyze the Transiesta obtained data,
>>>>> But when I use this code the below error has appeared:
>>>>>
>>>>>
>>>>> Traceback (most recent call last):
>>>>>   File "/share/apps/anaconda3/bin/sdata", line 11, in 
>>>>> load_entry_point('sisl==0.9.5', 'console_scripts', 'sdata')()
>>>>>   File
>>>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/utils/sdata.py",
>>>>> line 122, in sdata
>>>>> p.parse_args(argv, namespace=ns)
>>>>>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1749,
>>>>> in parse_args
>>>>> args, argv = self.parse_known_args(args, namespace)
>>>>>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1781,
>>>>> in parse_known_args
>>>>> namespace, args = self._parse_known_args(args, namespace)
>>>>>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1987,
>>>>> in _parse_known_args
>>>>> start_index = consume_optional(start_index)
>>>>>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1927,
>>>>> in consume_optional
>>>>> take_action(action, args, option_string)
>>>>>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1855,
>>>>> in take_action
>>>>> action(self, namespace, argument_values, option_string)
>>>>>   File
>>>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/xsf.py", line
>>>>> 339, in __call__
>>>>> vector = input_sile.read_data(*values, **d)
>>>>>   File
>>>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/tbt.py",
>>>>> line 1930, in read_data
>>>>> val.append(self.vector_current(*args))
>>>>>   File
>>>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/tbt.py",
>>>>> line 1377, in vector_current
>>>>

Re: [SIESTA-L] Transietsa/sisl problem

[Nick Papior]

Hi,

Simply do:

sdata por.TBT.nc --help
and you'll see what commands are available.

Please give back this command:
sdata por.TBT.nc --info



Den lør. 16. maj 2020 kl. 22.02 skrev shirin zandi <
shirinzandi1...@gmail.com>:

> Dear Nick,
>
> Thank you so much for your reply. After that I've got the following
> error :
>
> No data has been collected in the arguments, nothing will be written, have
> you forgotten arguments?
>
>
> The command I have run is this :   sdata por.TBT.nc <http://por.tbt.nc/> 
> --vector
> vector_current elec_1 0.1 --out A1.xsf
>
> I know, the electrode name and energy range should be written in bond
> currents command line, is it need something else?  And generally from
> where I can find a complete list of commands and their requirements which
> can be done with sisl. I am really new in using sisl!!!
>
>
>
> Regards,
> SH.
>
> On Sat, May 16, 2020 at 12:30 AM Nick Papior  wrote:
>
>> Hi,
>>
>> You probably haven't calculated bond currents. Please check your tbtrans
>> input options.
>>
>> / Nick
>>
>> On Thu, 14 May 2020, 22:13 shirin zandi, 
>> wrote:
>>
>>> Dear Transiesta/sisl user
>>>
>>> I am trying to use sisl code to analyze the Transiesta obtained data,
>>> But when I use this code the below error has appeared:
>>>
>>>
>>> Traceback (most recent call last):
>>>   File "/share/apps/anaconda3/bin/sdata", line 11, in 
>>> load_entry_point('sisl==0.9.5', 'console_scripts', 'sdata')()
>>>   File
>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/utils/sdata.py",
>>> line 122, in sdata
>>> p.parse_args(argv, namespace=ns)
>>>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1749, in
>>> parse_args
>>> args, argv = self.parse_known_args(args, namespace)
>>>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1781, in
>>> parse_known_args
>>> namespace, args = self._parse_known_args(args, namespace)
>>>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1987, in
>>> _parse_known_args
>>> start_index = consume_optional(start_index)
>>>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1927, in
>>> consume_optional
>>> take_action(action, args, option_string)
>>>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1855, in
>>> take_action
>>> action(self, namespace, argument_values, option_string)
>>>   File
>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/xsf.py", line
>>> 339, in __call__
>>> vector = input_sile.read_data(*values, **d)
>>>   File
>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/tbt.py",
>>> line 1930, in read_data
>>> val.append(self.vector_current(*args))
>>>   File
>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/tbt.py",
>>> line 1377, in vector_current
>>> Jab = self.bond_current(elec, E, kavg, only=only)
>>>   File
>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/tbt.py",
>>> line 1187, in bond_current
>>> Jij = self.orbital_current(elec, E, kavg, isc, only=only)
>>>   File
>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/tbt.py",
>>> line 1063, in orbital_current
>>> J = self._sparse_data('J', elec, E, kavg, isc)
>>>   File
>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/tbt.py",
>>> line 865, in _sparse_data
>>> rptr = np.insert(_a.cumsumi(self._value('n_col')), 0, 0)
>>>   File
>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/sile.py", line
>>> 757, in _value
>>> return self._variable(name, tree)[:]
>>>   File
>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/sile.py", line
>>> 750, in _variable
>>> return self._variables(self, name, tree=tree)
>>>   File
>>> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/sile.py", line
>>> 763, in _variables
>>> return n.variables[name]
>>> KeyError: 'n_col'
>>>
>>> Could you please help me to solve this issue?
>>>
>>>
>>> Many thanks,
>>> SH.
>>>
>>>
>>>
>>> --
>>> SIESTA is supported by the Spanish Research Agency (AEI) and by the
>>> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>>>
>>
>> --
>> SIESTA is supported by the Spanish Research Agency (AEI) and by the
>> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>>
>
> --
> 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/)

Re: [SIESTA-L] << Error compiling Util/COOP >>

[Nick Papior]

Hmm, this looks weird.

Could you do a "make dep" in the utility folder, and do
make clean
make
?

Den tor. 14. maj 2020 kl. 22.04 skrev I. Camps :

> Thanks Nick.
>
> The output from make parallel.o was:
>
>
> *ifort  -c -O2 -ipo -xHost -ip -prec-div -prec-sqrt -opt-prefetch
> -mkl=parallel
>  -I/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/include
> -I/software/SIESTA_LIBS/netcdf/4.4.1/include -DMPI -UMPI
>  /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/parallel.Ffpp:
> warning: cannot remove MPI - not a predefined macro*
>
> and the output from make was:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *ifort  -c -O2 -ipo -xHost -ip -prec-div -prec-sqrt -opt-prefetch
> -mkl=parallel
>  -I/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/include
> -I/software/SIESTA_LIBS/netcdf/4.4.1/include -DMPI -UMPI
>  /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/precision.Ffpp:
> warning: cannot remove MPI - not a predefined macroifort  -c -O2
> -ipo -xHost -ip -prec-div -prec-sqrt -opt-prefetch -mkl=parallel
>  -I/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/include
> -I/software/SIESTA_LIBS/netcdf/4.4.1/include -DMPI -UMPI
>  /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90fpp:
> warning: cannot remove MPI - not a predefined
> macro/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(212):
> error #7002: Error in opening the compiled module file.  Check INCLUDE
> paths.   [SYS]  use sys,   only: die   ! Termination
> routine--^/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(213):
> error #7002: Error in opening the compiled module file.  Check INCLUDE
> paths.   [M_IO]  use m_io,  only: io_assign ! Get and reserve an
> available IO
> unit--^/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(212):
> error #6580: Name in only-list does not exist.   [DIE]  use sys,
> only: die   ! Termination
> routine---^/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(213):
> error #6580: Name in only-list does not exist.   [IO_ASSIGN]  use m_io,
>  only: io_assign ! Get and reserve an available IO
> unit---^/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(374):
> error #6406: Conflicting attributes or multiple declaration of name.
> [IO_ASSIGN]call
> io_assign(REPORT_UNIT)-^/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(381):
> error #6406: Conflicting attributes or multiple declaration of name.
> [IO_ASSIGN]call
> io_assign(REPORT_UNIT)-^/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(2343):
> error #6406: Conflicting attributes or multiple declaration of name.
> [DIE]  call die('alloc_err: allocate error')---^compilation aborted for
> /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90 (code
> 1)make: *** [../../Obj/arch.make:128: alloc.o] Error 1*
>
>
> []'s,
>
> Camps
>
>
> On Wed, May 13, 2020 at 5:02 PM Nick Papior  wrote:
>
>> Could you try and do (in Util/COOP):
>>
>> make clean
>> make parallel.o
>> make
>>
>> and give me the output if it fails?
>>
>> Den fre. 8. maj 2020 kl. 22.10 skrev I. Camps :
>>
>>> Hello SIESTers,
>>>
>>> I successfully compiled SIESTA with the attached arch.make (link
>>> <https://drive.google.com/open?id=128E5AgyuakybDlr2q31TBNICabxvvdO5>).
>>>
>>> Now, when trying to compile some utilities (COOP, for example), I am
>>> getting several errors. The output is attached (link
>>> <https://drive.google.com/open?id=1HvuaqcFPALHoNplu_k3wufrx9eNLhMJp>).
>>>
>>> I will appreciate any help you can provide.
>>>
>>> Thanks in advance.
>>>
>>> []'s,
>>>
>>> Camps
>>>
>>> --
>>> 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 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/)

Re: [SIESTA-L] Transietsa/sisl problem

[Nick Papior]

Hi,

You probably haven't calculated bond currents. Please check your tbtrans
input options.

/ Nick

On Thu, 14 May 2020, 22:13 shirin zandi,  wrote:

> Dear Transiesta/sisl user
>
> I am trying to use sisl code to analyze the Transiesta obtained data, But
> when I use this code the below error has appeared:
>
>
> Traceback (most recent call last):
>   File "/share/apps/anaconda3/bin/sdata", line 11, in 
> load_entry_point('sisl==0.9.5', 'console_scripts', 'sdata')()
>   File
> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/utils/sdata.py",
> line 122, in sdata
> p.parse_args(argv, namespace=ns)
>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1749, in
> parse_args
> args, argv = self.parse_known_args(args, namespace)
>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1781, in
> parse_known_args
> namespace, args = self._parse_known_args(args, namespace)
>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1987, in
> _parse_known_args
> start_index = consume_optional(start_index)
>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1927, in
> consume_optional
> take_action(action, args, option_string)
>   File "/share/apps/anaconda3/lib/python3.7/argparse.py", line 1855, in
> take_action
> action(self, namespace, argument_values, option_string)
>   File "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/xsf.py",
> line 339, in __call__
> vector = input_sile.read_data(*values, **d)
>   File
> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/tbt.py",
> line 1930, in read_data
> val.append(self.vector_current(*args))
>   File
> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/tbt.py",
> line 1377, in vector_current
> Jab = self.bond_current(elec, E, kavg, only=only)
>   File
> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/tbt.py",
> line 1187, in bond_current
> Jij = self.orbital_current(elec, E, kavg, isc, only=only)
>   File
> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/tbt.py",
> line 1063, in orbital_current
> J = self._sparse_data('J', elec, E, kavg, isc)
>   File
> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/tbtrans/tbt.py",
> line 865, in _sparse_data
> rptr = np.insert(_a.cumsumi(self._value('n_col')), 0, 0)
>   File
> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/sile.py", line
> 757, in _value
> return self._variable(name, tree)[:]
>   File
> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/sile.py", line
> 750, in _variable
> return self._variables(self, name, tree=tree)
>   File
> "/share/apps/anaconda3/lib/python3.7/site-packages/sisl/io/sile.py", line
> 763, in _variables
> return n.variables[name]
> KeyError: 'n_col'
>
> Could you please help me to solve this issue?
>
>
> Many thanks,
> SH.
>
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

-- 
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] regarding pDOS

[Nick Papior]

Hi, no, only 4.1 and later versions.

On Thu, 14 May 2020, 22:02 RUPESH TIWARI,  wrote:

> Thank you so much Nick.
> Currently, i'm using siesta 4.0.2
> version. I'll install siesta-4.1-b4 version and compile with NetCDF support
> and then i'll try. Can i do same with 4.0.2 version?
>
> On Thu, 14 May 2020 at 01:30, Nick Papior  wrote:
>
>> This can be done if you use siesta-4.1-b4 and if compiled with NetCDF
>> support.
>>
>> Then you will get a file named: *.TBT.nc
>> Then you can use sisl (https://github.com/zerothi/sisl) to extract
>> orbital resolved DOS by doing something like this:
>>
>> sdata siesta.TBT.nc --atom 10-12[3,4] --DOS --out dos_10-12_34.dat
>>
>> which will take the DOS of atoms 10, 11, 12 but only orbitals 3 and 4 and
>> save in file dos_10-12_34.dat.
>> If you do
>>
>> sdata siesta.TBT.nc --help
>> you get more information about what you can do.
>>
>> So you have to figure out which atoms you wish to extract from, then
>> figure out which orbital indices the d's are and then issue the above
>> command.
>>
>> Den lør. 9. maj 2020 kl. 22.01 skrev RUPESH TIWARI <
>> rupesh199...@gmail.com>:
>>
>>> Dear siesta users,
>>>   I am doing quantum transport calculation
>>> on a Fe(III) system placed between two gold electrodes. I plotted the
>>> projected density of state that i got in tbtrans output file. Now i want
>>> figure out that which density of states are metal d-orbitals. If anybody
>>> knows please help. Your contribution will be highly appreciated.
>>>
>>> --
>>> Rupesh Kumar Tiwari
>>> C/o: Prof. Gopalan Rajaraman
>>> Junior Research Fellow (CSIR)
>>> Department of Chemistry
>>> IIT Bombay
>>> Mumbai- 400076
>>>
>>> --
>>> 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/)
>>
>
>
> --
> Rupesh Kumar Tiwari
> C/o: Prof. Gopalan Rajaraman
> Junior Research Fellow (CSIR)
> Department of Chemistry
> IIT Bombay
> Mumbai- 400076
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

-- 
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] regarding pDOS

[Nick Papior]

This can be done if you use siesta-4.1-b4 and if compiled with NetCDF
support.

Then you will get a file named: *.TBT.nc
Then you can use sisl (https://github.com/zerothi/sisl) to extract orbital
resolved DOS by doing something like this:

sdata siesta.TBT.nc --atom 10-12[3,4] --DOS --out dos_10-12_34.dat

which will take the DOS of atoms 10, 11, 12 but only orbitals 3 and 4 and
save in file dos_10-12_34.dat.
If you do

sdata siesta.TBT.nc --help
you get more information about what you can do.

So you have to figure out which atoms you wish to extract from, then figure
out which orbital indices the d's are and then issue the above command.

Den lør. 9. maj 2020 kl. 22.01 skrev RUPESH TIWARI :

> Dear siesta users,
>   I am doing quantum transport calculation on
> a Fe(III) system placed between two gold electrodes. I plotted the
> projected density of state that i got in tbtrans output file. Now i want
> figure out that which density of states are metal d-orbitals. If anybody
> knows please help. Your contribution will be highly appreciated.
>
> --
> Rupesh Kumar Tiwari
> C/o: Prof. Gopalan Rajaraman
> Junior Research Fellow (CSIR)
> Department of Chemistry
> IIT Bombay
> Mumbai- 400076
>
> --
> 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/)

Re: [SIESTA-L] << Error compiling Util/COOP >>

[Nick Papior]

Could you try and do (in Util/COOP):

make clean
make parallel.o
make

and give me the output if it fails?

Den fre. 8. maj 2020 kl. 22.10 skrev I. Camps :

> Hello SIESTers,
>
> I successfully compiled SIESTA with the attached arch.make (link
> ).
>
> Now, when trying to compile some utilities (COOP, for example), I am
> getting several errors. The output is attached (link
> ).
>
> I will appreciate any help you can provide.
>
> Thanks in advance.
>
> []'s,
>
> Camps
>
> --
> 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/)

Re: [SIESTA-L] Still confused about K points in siesta, transiesta and tbtrans in siesta 4.1b4

[Nick Papior]

Den ons. 6. maj 2020 kl. 22.01 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Yes that is exactly what I am saying. I just needed the confirmation. The
> way I understood from gathering the previous siesta mails and after going
> through the literature the following:
>
>
>
> in solid state physics: we need only 1 kpoint along a NON-periodic
> direction.  That is why, for a molecule or scattering region connected
> between gold for example, only 1 kpoint is used.
>
> This is based on the fact that kpoints are a result of the Bloch  theorem
> which applies only to infinitely large crystals. With finite dimensions let
> us say graphene,  we have a crystal with periodicity in only 2 dimensions,
> so only kpoints in 2 dimensions, and so on z axis is NOT infinite, it is
> "semi" infinite, so we only use 1 kpoint still  and as you said previous
> studies Transiesta does a very different semi infinite DFT Hamiltonian
> calculation yet a Hamiltonian unlike TbTrans which we aim to find the
> current.
>
No, the z axis for graphene is not "semi" infinite. It is vacuum and hence
not periodic (I have intentionally left out the discussion about the cell
used in siesta).
A semi-infinite region means it is infinite, but only in the negative or
positive of 1 direction.

In transiesta+tbtrans the semi-infinite region is replaced by self-energies
that takes into account the infinite periodic part behind or in front of
the scattering region electrode (semi-inf-dir -a3 or semi-inf-dir +a3,
respectively).

Hope that is correct and thank you again for your time.
>
> EL-abed
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Nick Papior 
> *Sent: *Tuesday, 5 May 2020 6:14 AM
> *To: *siesta-l 
> *Subject: *Re: [SIESTA-L] Still confused about K points in siesta,
> transiesta and tbtrans in siesta 4.1b4
>
>
>
> Hi,
>
>
>
> Den søn. 3. maj 2020 kl. 22.03 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Thank you for the compliment Nick,
>
> I was seeking an answer from yourself on why does the k points change from
> 100 to 1 in tbtrans.
>
> The answer seems to be in the physics where the system is not being
> periodic (semi periodic to be precise) therefore the kpoints from tbtrans
> changes automatically to 1. But we use the 100 in the electrode calculation
> and transiesta to find the Hamiltonian of both electrodes and scattering
> region. Is that correct?
>
> In the electrode calculation you do use a high number of k-points along
> the semiinfinite direction.
>
> Not in the scattering region. Please try and understand my question in 2.
>
>
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
> *From:* siesta-l-requ...@uam.es  on behalf of
> Nick Papior 
> *Sent:* Saturday, 2 May 2020 7:07 PM
> *To:* siesta-l 
> *Subject:* Re: [SIESTA-L] Still confused about K points in siesta,
> transiesta and tbtrans in siesta 4.1b4
>
>
>
> Hi,
>
>
>
> Great you have tried to fully understand this issue.
>
>
>
> Den man. 20. apr. 2020 kl. 22.01 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Following up on that: In the manual it says that if we use* TBT kgrid
> Monkhorst Pack (block):*
>
> This means it would act as the same as * kgrid Monkhorst Pack*, however,
> this is used to have a separate k-sampling in the tbtrans utility. If it
> does not exist it will use kgrid Monkhorst Pack
>
> But as i look into the output it seems to make it back to the default of 1
> 1 1.
>
> Not sure why?
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
> *From:* El-abed Haidar
> *Sent:* Friday, 17 April 2020 2:44 AM
> *To:* siesta-l@uam.es 
> *Subject:* Still confused about K points in siesta, transiesta and
> tbtrans in siesta 4.1b4
>
>
>
> Good afternoon to whom it may concern,
>
> i really want to understand the in depth behind the kpoints in electron
> transport. I still feel after going through the siesta mail where I have
> asked about it before in
> https://www.mail-archive.com/siesta-l@uam.es/msg10916.html
> <https://protect-au.mimecast.com/s/Gn7tCWLVXkUZlO9Rf6KvAP?domain=mail-archive.com>
>  leading
> to  https://www.mail-archive.com/siesta-l@uam.es/msg09386.html
> <https://protect-au.mimecast.com/s/lgFTCXLW2mUjp25VuV3TvR?domain=mail-archive.com>
>  .
> However, the answers were not clear to be honest as i did not get the
> complete understand

Re: [SIESTA-L] wave function coefficientes in a calculation with SO

[Nick Papior]

Hi,

This is already fixed in a coming release. :)
You can't get out the wavefunction coefficients in the code (without adding
code).

If you want it you can use sisl https://github.com/zerothi/sisl
to extract the information and post-calculate the eigenvalues again.

Den søn. 3. maj 2020 kl. 22.01 skrev Pablo Aguado :

> Hi everyone,
> The writing of the WFSX file is not currently implemented in the case of a
> calculation including spin-orbit. Is there any other straightforward way to
> extract the wave function coefficients in a calculation including
> spin-orbit?
>
> Thanks,
> Pablo
>
> Pablo Aguado-Puente
> Queen's University Belfast
> Belfast, Northern Ireland, UK
>
>
> --
> 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/)

Re: [SIESTA-L] Still confused about K points in siesta, transiesta and tbtrans in siesta 4.1b4

[Nick Papior]

Hi,

Den søn. 3. maj 2020 kl. 22.03 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Thank you for the compliment Nick,
> I was seeking an answer from yourself on why does the k points change from
> 100 to 1 in tbtrans.
> The answer seems to be in the physics where the system is not being
> periodic (semi periodic to be precise) therefore the kpoints from tbtrans
> changes automatically to 1. But we use the 100 in the electrode calculation
> and transiesta to find the Hamiltonian of both electrodes and scattering
> region. Is that correct?
>
In the electrode calculation you do use a high number of k-points along the
semiinfinite direction.
Not in the scattering region. Please try and understand my question in 2.

>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
> ------
> *From:* siesta-l-requ...@uam.es  on behalf of
> Nick Papior 
> *Sent:* Saturday, 2 May 2020 7:07 PM
> *To:* siesta-l 
> *Subject:* Re: [SIESTA-L] Still confused about K points in siesta,
> transiesta and tbtrans in siesta 4.1b4
>
> Hi,
>
> Great you have tried to fully understand this issue.
>
> Den man. 20. apr. 2020 kl. 22.01 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Following up on that: In the manual it says that if we use* TBT kgrid
> Monkhorst Pack (block):*
> This means it would act as the same as * kgrid Monkhorst Pack*, however,
> this is used to have a separate k-sampling in the tbtrans utility. If it
> does not exist it will use kgrid Monkhorst Pack
> But as i look into the output it seems to make it back to the default of 1
> 1 1.
> Not sure why?
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
> --
> *From:* El-abed Haidar
> *Sent:* Friday, 17 April 2020 2:44 AM
> *To:* siesta-l@uam.es 
> *Subject:* Still confused about K points in siesta, transiesta and
> tbtrans in siesta 4.1b4
>
> Good afternoon to whom it may concern,
> i really want to understand the in depth behind the kpoints in electron
> transport. I still feel after going through the siesta mail where I have
> asked about it before in
> https://www.mail-archive.com/siesta-l@uam.es/msg10916.html
> <https://protect-au.mimecast.com/s/j_mvCP7LAXf9oqZ6UzLfZ4?domain=mail-archive.com>
>  leading
> to  https://www.mail-archive.com/siesta-l@uam.es/msg09386.html
> <https://protect-au.mimecast.com/s/IzB8CQnMBZfg3m9RCPzoD8?domain=mail-archive.com>
>  .
> However, the answers were not clear to be honest as i did not get the
> complete understanding out of this. I went back and read more about
> periodicity  as suggested back here in
> https://www.mail-archive.com/siesta-l@uam.es/msg08489.html
> <https://protect-au.mimecast.com/s/VqxvCROND2uoR8QOSPmrq4?domain=mail-archive.com>
> and as Cubot mentioned its not about periodicity that is usually defined in
> solid states.* Any resources on k points for transport we can rely on or
> tutorials? Because*
> I am  more confused on the k points when defined for electron transport
> study. So im trying really and really would appreciate if there is a
> tutorial in the future for the latest siesta version to how we use k points
> BECAUSE
>
> So far i understand that we will go through 3 steps
> 1-transiesta electrode.out to calculate Hamiltonian and
> overlap matrix of electrodes
> 2-transiesta scattering.out to calculate density matrix of
> scattering region ]
> 3-tbtran .tbtrans.out to calculate current and transmission
> When papers define the k points to be 1 1 100 along electron transport i
> would assume we use in all siesta versions  %block Monkhorst Pack and
> through out the 3 steps i assume i am using 1 1 100 in my entire
> calculation.  *I found out recently that once siesta run is done in step
> 2 and starts a transiesta run the k points change suddenly to 1 1 1.
> WHY It was
> mentioned https://answers.launchpad.net/siesta/+question/686603
> <https://protect-au.mimecast.com/s/-9yOCVARKgCm51XZiJdbmo?domain=answers.launchpad.net>
>  but
> not enough explanation on the reason why. *
>
> I am not sure why especially that i want my study to be infinite along x
> and y ( or lattice vector a and b) and finite in z ( or c vector).
> *Now if I am suppose to add a block in each step above mentioned, what
> should I do to make sure all 3 steps have 1 1 100? IF NOT AGAIN WHY?*
> *I fully understand that i should do convergence tests for k points but i
> need to know also if that is always the case. Because i read 

Re: [SIESTA-L] Still confused about K points in siesta, transiesta and tbtrans in siesta 4.1b4

[Nick Papior]

Hi,

Great you have tried to fully understand this issue.

Den man. 20. apr. 2020 kl. 22.01 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Following up on that: In the manual it says that if we use* TBT kgrid
> Monkhorst Pack (block):*
> This means it would act as the same as * kgrid Monkhorst Pack*, however,
> this is used to have a separate k-sampling in the tbtrans utility. If it
> does not exist it will use kgrid Monkhorst Pack
> But as i look into the output it seems to make it back to the default of 1
> 1 1.
> Not sure why?
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
> --
> *From:* El-abed Haidar
> *Sent:* Friday, 17 April 2020 2:44 AM
> *To:* siesta-l@uam.es 
> *Subject:* Still confused about K points in siesta, transiesta and
> tbtrans in siesta 4.1b4
>
> Good afternoon to whom it may concern,
> i really want to understand the in depth behind the kpoints in electron
> transport. I still feel after going through the siesta mail where I have
> asked about it before in
> https://www.mail-archive.com/siesta-l@uam.es/msg10916.html leading to
> https://www.mail-archive.com/siesta-l@uam.es/msg09386.html . However, the
> answers were not clear to be honest as i did not get the complete
> understanding out of this. I went back and read more about periodicity
> as suggested back here in
> https://www.mail-archive.com/siesta-l@uam.es/msg08489.html  and as Cubot
> mentioned its not about periodicity that is usually defined in solid states.* 
> Any
> resources on k points for transport we can rely on or tutorials? Because*
> I am  more confused on the k points when defined for electron transport
> study. So im trying really and really would appreciate if there is a
> tutorial in the future for the latest siesta version to how we use k points
> BECAUSE
>
> So far i understand that we will go through 3 steps
> 1-transiesta electrode.out to calculate Hamiltonian and
> overlap matrix of electrodes
> 2-transiesta scattering.out to calculate density matrix of
> scattering region ]
> 3-tbtran .tbtrans.out to calculate current and transmission
> When papers define the k points to be 1 1 100 along electron transport i
> would assume we use in all siesta versions  %block Monkhorst Pack and
> through out the 3 steps i assume i am using 1 1 100 in my entire
> calculation.  *I found out recently that once siesta run is done in step
> 2 and starts a transiesta run the k points change suddenly to 1 1 1.
> WHY It was
> mentioned https://answers.launchpad.net/siesta/+question/686603
>  but not enough
> explanation on the reason why. *
>
> I am not sure why especially that i want my study to be infinite along x
> and y ( or lattice vector a and b) and finite in z ( or c vector).
> *Now if I am suppose to add a block in each step above mentioned, what
> should I do to make sure all 3 steps have 1 1 100? IF NOT AGAIN WHY?*
> *I fully understand that i should do convergence tests for k points but i
> need to know also if that is always the case. Because i read that 1 1 100
> is more than enough (based on literature and reading around the siesta
> mail)*
>
> *Would anyone be able to give their in sight thoughts as detailed as
> possible. Thank you*
>

I would suggest you to first conceptually figure out what the NEGF code
does. As per your 3 steps above
1. transiesta elec.fdf
This calculates a _truly_ bulk electrode. Ask your selve this:
a) how do you approach the truly bulk charge density in a regular
calculation? Which parameter should be *tuned* to find the truly bulk
electrode?
b) You want the electrode to be added to a device region. In the device
calculation you have a particular direction of the electrodes that are
"semi-infinite". You want the two systems to be commensurate in terms of
calculation parameters. How does this relate to a)? What does this imply
for the semi-infinite direction, and for the transverse directions?
2. transiesta scat.fdf
Here you calculate the device region where you place your _truly_ bulk
electrodes. What does the NEGF implementation state about electrodes? What
does an electrode mean in a device region system? And more importantly, if
you have 2 electrodes both with the same semi-infinite direction. What does
this mean for the k-point sampling along that direction? Why shouldn't it
matter whether you use any number of k-points? (once you figure
out/understand this it means you understand the NEGF concept ;) )
3. tbtrans scat.fdf
This calculates the spectroscopic quantities, such as DOS.
There is no conceptual difference from TBtrans and from a regular PDOS
calculation using Siesta.
E.g. if you use a k-point sampling [nx=3 ny=3 nz=3] in siesta, would that
be enough to get a good PDOS estimate?
If not, why? And how do you resolve this?

>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  

Re: [SIESTA-L] Concerning K points in siesta, transiesta and tbtrans

[Nick Papior]

Please see this discussion:

https://www.mail-archive.com/siesta-l@uam.es/msg09386.html

Den tir. 10. mar. 2020 kl. 22.10 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good afternoon,
> I was doing transiesta and tbtrans calculation with siesta 4.1-b4  version
> I wanted to find the DOS and PDOS for the system and it looked weird and
> then i found out in both transiesta and tbtrans the k points were 1 1 1
> instead of my defined 1 1 100.
> IS there a  reason for that? will that affect the current value?
> if it is wrong then what should I do to fix it?
> Thank you and looking forward to your thoughts
> EL-abed
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
> --
> 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/)

Re: [SIESTA-L] mix:Pulay --inversion failed,

[Nick Papior]

Hi,

This has no influence, it is a message about the Pulay mixing algorithm
which tries to solve the problem using SVD since the inversion failed.
When an inversion fails in a Pulay mixing scheme it means that two
iterations are extremely close and thus the matrix becomes non-invertible.
When this happens one can change to the SVD routine which will more likely
work.

Den tir. 10. mar. 2020 kl. 22.03 skrev SIFUNA, james :

> Hello all,
>
> I get this error when approaching convergence, what could be the issue? I
> see some similar questions pointing in this direction.
>
> *mix: Pulay -- inversion failed, > SVD [rank/size] 3 / 5*
> James
>
> El destino baraja las cartas, pero nosotros las jugamos.
>
> --
> 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/)

Re: [SIESTA-L] Error on transfer matrix indices... Stopping Program from Node X (Siesta-4.1b3)

[Nick Papior]

This has been fixed in later revisions, please try 4.1-b4 :)

On Sat, 7 Mar 2020, 22:01 Rajesh Thakur, 
wrote:

> Dear All,
> I tried to run a Molecular Dynamics (MD) calculation for a one-dimensional
> system (Periodic in Z-direction only). In the non-periodic direction, the
> distance between the images is greater than 15 Angstrom. Code runs without
> any problem for 185 MD steps but then throws an error as following:
> outcell: Cell vector modules (Ang)   :   27.00   27.006.09
> outcell: Cell angles (23,13,12) (deg): 90. 90. 89.9996
> outcell: Cell volume (Ang**3):   4439.6100
>r,C334   1336 ia,ja 26 26
> is, tm, old_tm:   2 0   0   1 0   0  -2
> xij - ucell*tm, |V|: 0.00.00.0   11.50844
> xijo: 0.00.0   11.50844   ucell: 0.0
>  0.0   11.50844
> Error on transfer matrix indices...
> Stopping Program from Node:   22
>r,C770   2344 ia,ja 60 26
> is, tm, old_tm:   3 0   0   2 0   0  -1
> xij - ucell*tm, |V|:-0.00.00.0   23.01687
> xijo:-0.00.0   23.01687   ucell: 0.0
>  0.0   23.01687
> Error on transfer matrix indices...
> Stopping Program from Node:   51
>r,C328   1778 ia,ja 26 60
> is, tm, old_tm:   2 0   0  -2 0   0   1
> xij - ucell*tm, |V|: 0.0   -0.00.0   23.01687
> xijo: 0.0   -0.0  -23.01687   ucell: 0.0
>  0.0  -23.01687
> Error on transfer matrix indices...
> Stopping Program from Node:   21
> This also happened for another 1D structure after running successfully for
> a few steps. What could be the possible reason for this error?
> Thanks.
>
> Regards
> RAJESH THAKUR
> RESEARCH SCHOLAR
> DEPARTMENT OF PHYSICS
> HPU SHIMLA
> 171005
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

-- 
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] Fwd: errors with Siesta Version : v4.1-b4

[Nick Papior]

Sorry for the delay.

I have now runned your big system, and I am not able to reproduce the
problem.
I would suggest you try with other linear algebra packages.
The standard shipped BLAS+LAPACK packages are also *extremely* slow.

Den ons. 4. mar. 2020 kl. 22.12 skrev Giacomo Giorgi :

> Dear all,
> following a previous unanswered message I would like to ask you your
> opinion about this weird behavior of my calculations with siesta.
>
> I am working with TiO2 anatase.
> Bulk worked perfectly. Also the (101) surface unit cell worked perfectly.
>
> Now I need a (5x3) supercell. (attached the fdf).
> Running it as a replica of the initial unit cell I get the following error:
>
> 
> 
> cdiag: Error in Cholesky factorisation
> Stopping Program from Node:4
>  160
> cdiag: Error in Cholesky factorisation
> Stopping Program from Node:5
>  160
> cdiag: Error in Cholesky factorisation
> Stopping Program from Node:0
> --
> MPI_ABORT was invoked on rank 6 in communicator MPI COMMUNICATOR 3 CREATE
> FROM 0
> with errorcode 1.
>
> NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
> You may or may not see output from other processes, depending on
> exactly when Open MPI kills them.
> --
> [node03:300332] PMIX ERROR: UNREACHABLE in file server/pmix_server.c at
> line 2079
> [node03:300332] PMIX ERROR: UNREACHABLE in file server/pmix_server.c at
> line 2079
> [node03:300332] PMIX ERROR: UNREACHABLE in file server/pmix_server.c at
> line 2079
> [node03:300332] PMIX ERROR: UNREACHABLE in file server/pmix_server.c at
> line 2079
> [node03:300332] PMIX ERROR: UNREACHABLE in file server/pmix_server.c at
> line 2079
> [node03:300332] 23 more processes have sent help message help-mpi-api.txt
> / mpi-abort
> [node03:300332] Set MCA parameter "orte_base_help_aggregate" to 0 to see
> all help / error messages
>
>
> Maybe the structure is too large (strange...), thus I decided to run a
> calculation on a smaller (1x3) supercell (still fdf atteched along with psf
> used).
> Then this time I get this new error:
> ...
> ...
> Stopping Program from Node:   19
> Bad DM normalization: Qtot, Tr[D*S] =576.
>  638080922.01711190
> Stopping Program from Node:   21
> Bad DM normalization: Qtot, Tr[D*S] =576.
>  638080922.01711190
> Stopping Program from Node:   22
> --
> MPI_ABORT was invoked on rank 15 in communicator MPI COMMUNICATOR 3 CREATE
> FROM 0
> with errorcode 1.
>
> NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
> You may or may not see output from other processes, depending on
> exactly when Open MPI kills them.
> --
> [node03:306841] 23 more processes have sent help message help-mpi-api.txt
> / mpi-abort
> [node03:306841] Set MCA parameter "orte_base_help_aggregate" to 0 to see
> all help / error messages
>
> Since I do not find anyone able to fix this issue, which actually seems to
> be system-independent ( I have had similar behaviour with other slabs), I
> wonder if there is any of you able to help me.
>
> Thanks a lot-
> Regards,
> Giacomo
>
>
> Siesta Version  : v4.1-b4
> Architecture: unknown
> Compiler version: GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
> Compiler flags  : mpif90 -O2 -fPIC -ftree-vectorize
> PP flags: -DFC_HAVE_ABORT -DMPI -DSIESTA__DIAG_2STAGE
> Libraries   : libsiestaLAPACK.a libsiestaBLAS.a
> /opt/share/scalapack_gnu/libscalapack.a
> PARALLEL version
>
> * Running on 24 nodes in parallel
> >> Start of run:   3-MAR-2020  10:41:40
>
>
>
>
> --
> G
>
>
> "Oltre le illusioni di Timbuctù e le gambe lunghe di Babalù c'era questa
> strada...Questa strada zitta che vola via come una farfalla, una nostalgia,
> nostalgia al gusto di curaçao...Forse un giorno meglio mi spiegherò"
>
> (Paolo Conte, "Hemingway")
>
> --
> 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/)

Re: [SIESTA-L] How to calculate state-resolved transmission function

[Nick Papior]

In Siesta 4.1 you can do projected transmissions, please see the tbtrans
manual in section 4.6.2 (Projected transmissions).

Den fre. 21. feb. 2020 kl. 22.07 skrev Jingxian Yu <
jingxian...@adelaide.edu.au>:

> Dear colleagues,
>
> I have computed transmission coefficients for the junction device, however my 
> reviewer suggested to project the transmission function onto an eigenstate, 
> for example the HOMO state.
>
> I note that Drs Guangping Zhang and Carlo Motta posted similar questions here 
> more than 8 years ago. The only answer to these was contributed by Dr 
> Gabriele Penazzi, saying that there was no easy and quick way in Siesta.
>
> I believe such calculations are quite common and routine. Would you like to 
> share how you do this in Siesta, if you have figured out a way? Or if you 
> don’t do this in Siesta, would you please recommend the programs you use?
>
> Your suggestion will be sincerely appreciated. Best regards
>
> Jin
>
>
> --
> 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/)

Re: [SIESTA-L] Difference between TBT.DOS.Gf and TBT.DOS.A

[Nick Papior]

Please see the tbtrans manual, just after TBT.DOS.A.All, there is a small
discussion.

Basically DOS.Gf = \sum_electrodes DOS.A + DOS.bound-states

So if there are no bound states you have that the sum of spectral density
of states equals the Green function density of states.

Den fre. 21. feb. 2020 kl. 22.00 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good afternoon,
> I was wondering if anyone could give me more insight onto the physical
> difference between Density of states (orbital resolved) in both:
>  1- Green function DOS
> 2- Scattering DOS
> what is the meaning of each case? When are they identical (if that is the
> case)?
> In the manual it does not dive into it.
> If there are any references I am more than happy to read just need to find
> one.
> Thank you and looking forward to all responses!
> EL-Abed
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
> --
> 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/)

Re: [SIESTA-L] Error in Electrode Calculation in 4.1-b4

[Nick Papior]

An electrode calculation should not use the transiesta solution. :)

On Wed, 12 Feb 2020, 22:04 Dwaipayan Chakraborty,  wrote:

> Thank you very much for your reply.
>
> The input file is like that:
>
> SystemName 3X1X1_elec
> SystemLabel 3X1X1_elec
>
> NumberOfAtoms 18
> NumberOfSpecies 2
>
> %block Chemical_Species_label
> 1 X A
> 2 Y B
> %endblock Chemical_Species_label
>
> LatticeConstant 1.0 Ang
> %block LatticeVectors
> 11.968238830   0.00   0.00
> 0.00  26.670763   0.00
> 0.00   0.00   6.9099664688
> %endblock LatticeVector
>
>
> AtomicCoordinatesFormat Ang
> %block  AtomicCoordinatesAndAtomicSpecies
> 0.0   2.10750   0.0 1
> 3.989413062   2.10750   0.0 1
> 7.978826125   2.10750   0.0 1
> 1.994706531   2.10750   3.454983234 1
> 5.984119415   2.10750   3.454983234 1
> 9.973532121   2.10750   3.454983234 1
>  1.994646252  1.228218009   5.758178399 2
>  5.984059136  1.228218009   5.758178399 2
>  9.973472199  1.228218009   5.758178399 2
>  3.989352783  1.228218009   2.303195164 2
>  7.978765489  1.228218009   2.303195164 2
> 11.968178908  1.228218009   2.303195164 2
>  1.994646609  4.771869162   1.151788070 2
>  5.984059493  4.771869162   1.151788070 2
>  9.973472199  4.771869162   1.151788070 2
>  3.989353140  4.771869162   4.606771305 2
>  7.978766202  4.771869162   4.606771305 2
> 11.968178908  4.771869162   4.606771305 2
> %endblock  AtomicCoordinatesAndAtomicSpecies
>
> # K-points
>
> %block kgrid_Monkhorst_Pack
> 3   00   0.0
> 0   10   0.0
> 0   0  100   0.0
> %endblock kgrid_Monkhorst_Pack
>
> # General variables
>
> PAO.BasisSize  DZP
> PAO.SplitTailNorm  .true.
> PAO.EnergyShift0.05 Ry
> xc.functional  GGA   # Exchange-correlation functional
> xc.authors PBE
> ElectronicTemperature  100 K
> MeshCutoff 350. Ry
> SpinPolarized  .false.
> SolutionMethod transiesta
>
> # MD variables
>
> MD.FinalTimeStep   1
> MD.TypeOfRun   CG
> MD.NumCGsteps  000
> MD.UseSaveXV   .true.
>
> # SCF variables
>
> DM.MixSCF1 T
> MaxSCFIterations   1000  # Maximum number of SCF iter
> DM.MixingWeight0.03  # New DM amount for next SCF cycle
> DM.Tolerance   1.d-4 # Tolerance in maximum difference
> DM.UseSaveDM   true  # to use continuation files
> DM.NumberPulay 5
> Diag.DivideAndConquer  no
> Diag.ParallelOverK yes
>
> # Output variables
>
> WriteMullikenPop1
> WriteBands  .false.
> SaveRho .false.
> SaveDeltaRho.false.
> SaveHS  .false.
> SaveElectrostaticPotential  True
> SaveTotalPotential  no
> WriteCoorXmol   .true.
> WriteMDXmol .true.
> WriteMDhistory  .false.
> WriteEigenvaluesyes
>
>
>
> On Tue, Feb 11, 2020 at 2:35 AM MB MB  wrote:
>
>> Hi Dwaipayan,
>>
>> It would be easier to answer your question if you could you share your
>> input!?
>>
>> Best,
>> Mohammad
>>
>>
>> On Sun, Feb 9, 2020 at 10:02 PM Dwaipayan Chakraborty 
>> wrote:
>>
>>> Dear All,
>>>
>>> I have done calculations for electrode and scattering region in version
>>> 4.0 but when I am trying to do the electrode calculation in version 4.1-b4
>>> with "solution method = transiesta" and the executable "siesta --electrode"
>>> the following errors are coming
>>> "transiesta: *** No electrode names were found, default Left/Right are
>>> expected
>>> "
>>> Can anyone please help me what is going wrong here. Is it some
>>> installation problem or library issue?
>>>
>>> Thanks in advance.
>>> --
>>> *Dwaipayan Chakraborty*
>>> *Ph.D. Scholar *
>>> *Department of Physics*
>>> *School of Natural Science*
>>> *Shiv Nadar University (snu.edu.in )*
>>> *Gautam Buddha Nagar, UP, India*
>>> *Ph. No.: +91-8130593163*
>>>
>>> --
>>> SIESTA is supported by the Spanish Research Agency (AEI) and by the
>>> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>>>
>>
>> --
>> SIESTA is supported by the Spanish Research Agency (AEI) and by the
>> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>>
>
>
> --
> *Dwaipayan Chakraborty*
> *Ph.D. Scholar *
> *Department of Physics*
> *School of Natural Science*
> *Shiv Nadar University (snu.edu.in )*
> *Gautam Buddha Nagar, UP, India*
> *Ph. No.: +91-8130593163*
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

-- 
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] Erroneous electrode setup, check out-put

[Nick Papior]

Like I mentioned, your lattice vectors are not parallel, see device
lattice vectors and electrode lattice vectors. They need to be parallel in
case you want to use k-points.

Den man. 3. feb. 2020 kl. 22.10 skrev Ziba Torkashvand <
zi.torkashv...@gmail.com>:

> These are my input files for the device and electrodes.
>
> On Mon, Feb 3, 2020 at 9:32 AM Ziba Torkashvand 
> wrote:
>
>> Thanks for your response Nick,
>> Previously, I have used the following lattice vectors for the device
>> %block LatticeVectors
>>   24.8355890   0.0312245  -0.2325957
>>0.0300392  22.4960510  -0.2979615
>>   -0.2501458  -0.3417446  26.7881732
>> %endblock LatticeVectors
>> and
>> %block LatticeVectors
>> 15.5329 0   0
>> 0   5.98023 0
>> 0   0   6.24937
>> %endblock LatticeVectors
>> for the left electrode and
>> %block LatticeVectors
>> 15.5329  0   0
>> 05.98023 0
>> 00   6.26654
>> %endblock LatticeVectors
>> for the right electrode after fully relaxation.
>> But as I see in the example ts_term4
>> %block LatticeVectors
>> 31.750.  0.
>>  0. 12.  0.
>>  0.  0. 31.75
>> %endblock LatticeVectors
>> was used for the device and
>> %block LatticeVectors
>> 5.08  0.  0.
>> 0.   12.  0.
>> 0.0. 12.
>> %endblock LatticeVectors
>> and
>> %block LatticeVectors
>> 0.0.  5.08
>> 0.   12.  0.
>>12.0.  0.
>> %endblock LatticeVectors
>> for the elec-x and elec-z, respectively.
>> So, based on this example should I change the order of lattice vectors
>> for the electrodes (y-direction) which are perpendicular to the device
>> region (z-direction)?
>> Or, what is your suggestion for my case?
>>
>> Thanks in advance,
>> Ziba Torkashvand
>>
>>
>> On Fri, Jan 24, 2020 at 6:08 AM Nick Papior  wrote:
>>
>>> Hi,
>>>
>>> Sorry, I don't understand your response. I referred to the lattice
>>> vectors in the two calculations not being parallel.
>>> It is not due to your k-point samplings.
>>>
>>>
>>> Den ons. 22. jan. 2020 kl. 22.01 skrev Ziba Torkashvand <
>>> zi.torkashv...@gmail.com>:
>>>
>>>> Actually, I just have two electrodes (in the y-direction) and both of
>>>> them are perpendicular to the device region (in the z-direction). As I see
>>>> in the example of Au 111 it has the largest kpoint along the semi-infinite
>>>> direction of electrodes for the electrode run (2 2 10) which in my work is
>>>> in the y-direction and (2 2 2) for the device region. Also, I have tried (2
>>>> 20 2) for the electrode run and (2 2 2) for the scattering region but again
>>>> I have received an error.
>>>>
>>>> Thanks
>>>>
>>>> [image: Mailtrack]
>>>> <https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
>>>>  Sender
>>>> notified by
>>>> Mailtrack
>>>> <https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
>>>>  01/22/20,
>>>> 11:15:34 AM
>>>>
>>>> On Wed, Jan 22, 2020 at 6:01 AM Nick Papior 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Your 3rd electrode and device lattice vector are not parallel. Please
>>>>> make sure they are parallel. :)
>>>>>
>>>>> Den man. 20. jan. 2020 kl. 22.04 skrev Ziba Torkashvand <
>>>>> zi.torkashv...@gmail.com>:
>>>>>
>>>>>> Hello everybody
>>>>>> I want to do a transiesta calculation with Siesta 4.1-b4.
>>>>>> In my device, two bulk electrodes are on the top of a monolayer
>>>>>> hexagonal system. The transport direction is in z direction so the
>>>>>> electrode direction is y.
>>>>>> I have used kpoint sampling
>>>>>> 1 0 0
>>>>>> 0 20 0
>>>>>> 0 0 40
>>>>>> for the electrodes and
>>>>>> 1 0 0
>>>>>> 0 1 0
>>>>>> 0 0 40
>>>>>> for the scattering region
>>>>>> but I receive the error
>>>>>>
>>>>

Re: [SIESTA-L] Asking for alternative to extract PDOS from tbtrans

[Nick Papior]

In Siesta 4.1 you don't need to specify TS.TBT.PDOSFrom/To. They are not
used.

If you have the *.TBT.nc files you can simply use the sdata command to
extract PDOS for individual atoms.
Please go through TB_04 example in the TranSiesta tutorial here:
https://github.com/zerothi/ts-tbt-sisl-tutorial

Then you should be able to extend that to your case.

Den tor. 6. feb. 2020 kl. 22.04 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> I also need to point out that i want an alternative especially if the
> transport unit cell has multiple elements which means
> fixing TS.TBT.PDOSFrom and TO many times.
> Not to forget that i have many different systems I am aiming to use. SO I
> really hope there is an alternative?
> THank you and sorry for the multiple emails.
> EL_abed
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
> --
> *From:* El-abed Haidar
> *Sent:* Thursday, 6 February 2020 10:36 PM
> *To:* siesta-l@uam.es 
> *Subject:* Asking for alternative to extract PDOS from tbtrans
>
> Good evening,
> I was wondering if there is another way for extracting PDOS from tbtrans
> especially when we have many different elements and for a large unit cell.
> I read about sisl but could find a clear manual to how to extract PDOS
> from nc files?
> Could anyone give me a proper explanation or way to do this?
> Thank you and looking forward to your reply!
> EL-Abed
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
> --
> 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/)

Re: [SIESTA-L] Erroneous electrode setup, check out-put

[Nick Papior]

Hi,

Sorry, I don't understand your response. I referred to the lattice vectors
in the two calculations not being parallel.
It is not due to your k-point samplings.


Den ons. 22. jan. 2020 kl. 22.01 skrev Ziba Torkashvand <
zi.torkashv...@gmail.com>:

> Actually, I just have two electrodes (in the y-direction) and both of them
> are perpendicular to the device region (in the z-direction). As I see in
> the example of Au 111 it has the largest kpoint along the semi-infinite
> direction of electrodes for the electrode run (2 2 10) which in my work is
> in the y-direction and (2 2 2) for the device region. Also, I have tried (2
> 20 2) for the electrode run and (2 2 2) for the scattering region but again
> I have received an error.
>
> Thanks
>
> [image: Mailtrack]
> <https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
>  Sender
> notified by
> Mailtrack
> <https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
>  01/22/20,
> 11:15:34 AM
>
> On Wed, Jan 22, 2020 at 6:01 AM Nick Papior  wrote:
>
>> Hi,
>>
>> Your 3rd electrode and device lattice vector are not parallel. Please
>> make sure they are parallel. :)
>>
>> Den man. 20. jan. 2020 kl. 22.04 skrev Ziba Torkashvand <
>> zi.torkashv...@gmail.com>:
>>
>>> Hello everybody
>>> I want to do a transiesta calculation with Siesta 4.1-b4.
>>> In my device, two bulk electrodes are on the top of a monolayer
>>> hexagonal system. The transport direction is in z direction so the
>>> electrode direction is y.
>>> I have used kpoint sampling
>>> 1 0 0
>>> 0 20 0
>>> 0 0 40
>>> for the electrodes and
>>> 1 0 0
>>> 0 1 0
>>> 0 0 40
>>> for the scattering region
>>> but I receive the error
>>>
>>>
>>> transiesta: k-grid: Number of Green function k-points =20
>>> transiesta: k-grid: Supercell and displacements
>>> transiesta: k-grid:1   0   0  0.000
>>> transiesta: k-grid:0   1   0  0.000
>>> transiesta: k-grid:0   0  40  0.500
>>> Erroneous electrode setup, check out-put
>>> Stopping Program from Node:0
>>> ERROR: Electrode: elecl
>>> Electrode direction = 3
>>> Projected direction = 3
>>> |elec_cell(:, 3) . cell(:,3)| - 1 = -.1249E-03
>>> Erroneous electrode setup, check out-put
>>> Stopping Program from Node:0
>>> application called MPI_Abort(comm=0x8400, 1) - process 0
>>> [unset]: write_line error; fd=-1 buf=:cmd=abort exitcode=1
>>> :
>>> system msg for write_line failure : Bad file descriptor
>>>
>>> and here is some part of my input
>>>
>>> block TS.Elec.elecl
>>> TSHS ./elecl.TSHS
>>> chem-pot Left
>>> semi-inf-dir +a2
>>> elec-pos begin 1
>>> used-atoms 54
>>> %endblock TS.Elec.elecl
>>>
>>> %block TS.Elec.elecr
>>> TSHS ./elecr.TSHS
>>> chem-pot Right
>>> semi-inf-dir +a2
>>> elec-pos end -1
>>> used-atoms 54
>>> %endblock TS.Elec.elecr
>>>
>>> any suggestions for my problem would be kindly appreciated.
>>>
>>> Thanks in advance
>>> Ziba Torkashvand
>>>
>>>
>>> [image: Mailtrack]
>>> <https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
>>>  Sender
>>> notified by
>>> Mailtrack
>>> <https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
>>>  01/20/20,
>>> 12:52:58 PM
>>>
>>> --
>>> 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 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/)

Re: [SIESTA-L] Erroneous electrode setup, check out-put

[Nick Papior]

Hi,

Your 3rd electrode and device lattice vector are not parallel. Please make
sure they are parallel. :)

Den man. 20. jan. 2020 kl. 22.04 skrev Ziba Torkashvand <
zi.torkashv...@gmail.com>:

> Hello everybody
> I want to do a transiesta calculation with Siesta 4.1-b4.
> In my device, two bulk electrodes are on the top of a monolayer hexagonal
> system. The transport direction is in z direction so the electrode
> direction is y.
> I have used kpoint sampling
> 1 0 0
> 0 20 0
> 0 0 40
> for the electrodes and
> 1 0 0
> 0 1 0
> 0 0 40
> for the scattering region
> but I receive the error
>
>
> transiesta: k-grid: Number of Green function k-points =20
> transiesta: k-grid: Supercell and displacements
> transiesta: k-grid:1   0   0  0.000
> transiesta: k-grid:0   1   0  0.000
> transiesta: k-grid:0   0  40  0.500
> Erroneous electrode setup, check out-put
> Stopping Program from Node:0
> ERROR: Electrode: elecl
> Electrode direction = 3
> Projected direction = 3
> |elec_cell(:, 3) . cell(:,3)| - 1 = -.1249E-03
> Erroneous electrode setup, check out-put
> Stopping Program from Node:0
> application called MPI_Abort(comm=0x8400, 1) - process 0
> [unset]: write_line error; fd=-1 buf=:cmd=abort exitcode=1
> :
> system msg for write_line failure : Bad file descriptor
>
> and here is some part of my input
>
> block TS.Elec.elecl
> TSHS ./elecl.TSHS
> chem-pot Left
> semi-inf-dir +a2
> elec-pos begin 1
> used-atoms 54
> %endblock TS.Elec.elecl
>
> %block TS.Elec.elecr
> TSHS ./elecr.TSHS
> chem-pot Right
> semi-inf-dir +a2
> elec-pos end -1
> used-atoms 54
> %endblock TS.Elec.elecr
>
> any suggestions for my problem would be kindly appreciated.
>
> Thanks in advance
> Ziba Torkashvand
>
>
> [image: Mailtrack]
> 
>  Sender
> notified by
> Mailtrack
> 
>  01/20/20,
> 12:52:58 PM
>
> --
> 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/)

Re: [SIESTA-L] Specify geometry in .fdf only from .XV file

[Nick Papior]

Hi,

Yes, it first reads the atomic species and atomic information from the fdf
file. Then it proceeds to read the XV file and reads the coordinates and
lattice vectors.


Den tor. 16. jan. 2020 kl. 22.02 skrev D. Bennett :

> Dear siesta users,
>
> I have a very quick technical question: is it possible to use a .fdf
> file and specify the lattice and atomic coordinates only from a .XV
> file? When I run with MD.UseSaveXV true and without LatticeVectors and
> AtomicCoordinatesAndAtomicSpecies blocks, siesta complains that I
> haven't specified atomic coordinates. I guess it reads them from the
> .fdf file first and then overwrites from the .XV file?
>
> Thanks,
>
> Danny Bennett
>
> --
> 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/)

Re: [SIESTA-L] TRANSIESTA QUESTIONs Concerning unit cell with skew lattice vectors

[Nick Papior]

Den tor. 12. dec. 2019 kl. 22.06 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Thank you again for the reply
> For question 2 isn’t it defined as Ky and Kz so I’m not sure I get your
> point that it is fine
>
I don't understand what you mean. :)
A k-point is a k-point in Siesta AND in TranSiesta. However, there is no
need for k-points along semi-infinite directions since the electrodes take
care of the periodicity.

> For question 3 if our electrodes like our system are skewed ( direction of
> transport interested are a2 and a3) are we allowed to say a2 a3 ? If not
> what does a3 only mean for a skewed system? In other words how would
> transport take place in a skew system while specifying only one direction
> especially one would be mostly interested to cover
>
You can't define transport to be aligned with 2 lattice vectors. You can
ONLY define transport along a single lattice vector. But this lattice
vector may have components along each of the 3 Cartesian directions.

> Thank you for your time really appreciate it
> El abed
>
> Sent from my iPhone
>
> On 12 Dec 2019, at 8:16 am, Nick Papior  wrote:
>
>
>
> Den tir. 10. dec. 2019 kl. 22.04 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
>> Good evening
>> I was just wondering if we have a unit cell with skew vectors ( c vector
>> for example having y and z components) I have the following TRANSIESTA
>> questions:
>>
> This is only possible in 4.1 and beyond.
>
>> 1- Based on siesta mail usually I usually define the k points as 1 1 100
>> Should I change it for skewed systems? I tried to look for the answer in
>> the manual but it does not seem to give in depth on that.
>>
> No, a lattice vector is still a lattice vector. So this should be fine.
>
>> 2- May I know the difference between k points in a siesta run vs a
>> transiesta run? I really want to know the in-depth understanding behind
>> both.
>>
> They both mean the same thing. However, in a transiesta run k-points along
> the semi-infinite direction has no meaning (the self-energies are
> semi-infinite by definition).
>
>> 3- Which block in the siesta input file identifies the direction of the
>> bias voltage ? Is there much more in depth to that?
>>
> In 4.0 it is always the third lattice vector. In 4.1 it is determined from
> the semi-infinite directions of the electrodes. If they are parallel there
> exists a unique transport direction.
>
>> Thank you and looking forward to all replies
>> El abed
>>
>> Sent from my iPhone
>> --
>> 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 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/)

Re: [SIESTA-L] TRANSIESTA QUESTIONs Concerning unit cell with skew lattice vectors

[Nick Papior]

Den tir. 10. dec. 2019 kl. 22.04 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good evening
> I was just wondering if we have a unit cell with skew vectors ( c vector
> for example having y and z components) I have the following TRANSIESTA
> questions:
>
This is only possible in 4.1 and beyond.

> 1- Based on siesta mail usually I usually define the k points as 1 1 100
> Should I change it for skewed systems? I tried to look for the answer in
> the manual but it does not seem to give in depth on that.
>
No, a lattice vector is still a lattice vector. So this should be fine.

> 2- May I know the difference between k points in a siesta run vs a
> transiesta run? I really want to know the in-depth understanding behind
> both.
>
They both mean the same thing. However, in a transiesta run k-points along
the semi-infinite direction has no meaning (the self-energies are
semi-infinite by definition).

> 3- Which block in the siesta input file identifies the direction of the
> bias voltage ? Is there much more in depth to that?
>
In 4.0 it is always the third lattice vector. In 4.1 it is determined from
the semi-infinite directions of the electrodes. If they are parallel there
exists a unique transport direction.

> Thank you and looking forward to all replies
> El abed
>
> Sent from my iPhone
> --
> 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/)

Re: [SIESTA-L] Error: parse module integers not enough integers in line

[Nick Papior]

Your monkhorst pack grid input block should contain 3 lines of:
integer integer integer float

This is probably why you see the error.


Den tir. 10. dec. 2019 kl. 22.12 skrev RAHUL SURESH :

> Hi
>
> SystemName  GRAPHENE
> SystemLabel GH
>
> Systemtype = molecule
>
> NumberOfAtoms   127
> NumberOfSpecies 1
>
> %block ChemicalSpeciesLabel
>  1   6  C
> %endblock ChemicalSpeciesLabel
>
> %block PAO.Basis #Define basis set
> C 2 # species label, number of l-shells
> n=2 0 1 #n,l, Nzeta
> 4.088
> 1.000
> n=2 2 1  #n, l, Nzeta, POlarization, NzetaPol
> 4.870
> 1.000
> %endblock PAO.Basis
>
> LatticeConstant 1.433600 Ang
> %block LatticeVectors
>  20.0319194794  0.000.00
>   0.00 17.3481511557   0.00
>   0.00  0.00   15.00
> %endblock LatticeVectors
>
> PAO.BasisSize   DZP
> PAO.EnergyShift 50 meV
>
> XC.functional GGA
> XC.authorsPBE
>
> MD.TypeOfRun cg
> MD.NumCGsteps50
> MD.MaxCGDispl 0.1  Ang
> MD.MaxForceTol0.04 eV/Ang
>
> AtomicCoordinatesFormat  ScaledCartesian
> %block AtomicCoordinatesAndAtomicSpecies
>  1.091377139 0.482418239 7.2617001531
> -0.161108613 2.650156260 7.2617001531
> -1.413567424 4.819488049 7.2617001531
> -2.664646864 6.988037586 7.2617001531
>  3.595748425 0.481264472 7.2617001531
>  2.340801954 2.651713371 7.2617001531
>  1.091264725 4.819432735 7.2617001531
> -0.161268234 6.985428810 7.2617001531
>  6.098221302 0.481264472 7.2617001531
>  4.846980095 2.650747776 7.2617001531
>  3.592674017 4.834912777 7.2617001531
>  2.355370045 6.977977753 7.2617001531
>  8.602592468 0.482418239 7.2617001531
>  7.353157997 2.651713371 7.2617001531
>  6.101296425 4.834912777 7.2617001531
> -0.160712123 1.204446077 7.2617001531
> -1.414793491 3.372574806 7.2617001531
> -2.665408850 5.542710304 7.2617001531
> -3.917418003 7.711501122 7.2617001531
>  2.343657732 1.204304218 7.2617001531
>  1.088551879 3.370188236 7.2617001531
> -0.165192604 5.541729450 7.2617001531
> -1.413341761 7.711630344 7.2617001531
>  4.846969604 1.200943112 7.2617001531
>  3.597290516 3.367228508 7.2617001531
>  2.328475475 5.533756256 7.2617001531
>  1.086618900 7.715842247 7.2617001531
>  7.350282192 1.204304218 7.2617001531
>  6.096659184 3.367228508 7.2617001531
>  4.846970081 5.448971272 7.2617001531
>  3.514302254 7.757229328 7.2617001531
> -3.917549849 9.156570435 7.2617001531
> -5.16898012211.325343132 7.2617001531
> -6.42053413413.493108749 7.2617001531
> -7.67303848315.661262512 7.2617001531
> -1.413455725 9.157464981 7.2617001531
> -2.66520381011.324963570 7.2617001531
> -3.91741561913.493108749 7.2617001531
> -5.16897964515.661633492 7.2617001531
>  1.090989590 9.156326294 7.2617001531
> -0.16222429311.324670792 7.2617001531
> -1.41349172613.493728638 7.2617001531
> -2.66492176115.661262512 7.2617001531
>  3.609686852 9.150509834 7.2617001531
>  2.34490966811.326258659 7.2617001531
>  1.09096622513.492943764 7.2617001531
> -0.16162490815.661520004 7.2617001531
> -5.168990135 9.879426003 7.2617001531
> -6.42030763612.048069000 7.2617001531
> -7.67275905614.216072083 7.2617001531
> -8.92444706016.383924484 7.2617001531
> -2.665730715 9.879986763 7.2617001531
> -3.91766238212.048069000 7.2617001531
> -5.16898965814.215423584 7.2617001531
> -6.42063713116.383678436 7.2617001531
> -0.164601326 9.881243706 7.2617001531
> -1.41407251412.047904015 7.2617001531
> -2.66522169114.216072083 7.2617001531
> -3.91733169616.383678436 7.2617001531
>  2.336297989 9.880359650 7.2617001531
> 

Re: [SIESTA-L] Electrode connectivity is not perfect, refer to the manual for achieving a perfect electrode PROBLEM!

[Nick Papior]

In your electrode calculation, look for:
superc: Internal auxiliary supercell: 3 x 5 x 3  =  45

This should have a 3 along the semi-infinite direction.
Your electrode in your attached output does seem too short.

Den tir. 10. dec. 2019 kl. 22.03 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good afternoon
> I really was hoping for someone to explain to me what the error means:
>
> *Left principal cell is extending out with 480 elements: *
> *Atom 19 connects with atom 91*
>
>  I started off with only 3 sheets of gold but that did not work. I added
> one sheet for each electrode and still did not work.
> I added another 2 sheets to expand each electrodes further but still not
> working out.
> Please note that the unit cell lattice vectors will only change towards
> the c direction which i recalculated.
> Could the mistake because I have x and negative coordinates? Could it be
> the unit cell vectors are not true. I just was hoping for more explanation
> than :
> *Electrode connectivity is not perfect, refer to the manual for achieving
> a perfect electrode.*
> Any thoughts would be highly appreciated.
> Thank you!
> EL-abed
>
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
> --
> 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/)

Re: [SIESTA-L] TRANS file not printing out in siesta 4.1b4

[Nick Papior]

I guess you are doing a gamma point calculation. In that case avtrans and
trans files are exactly the same, hence it only writes avtrans.

On Tue, 3 Dec 2019, 22:02 El-abed Haidar, 
wrote:

> Good evening,
> I am not sure why TRANS file is not printing out as one of the final
> output files.
> I got everything even AVTRANS but NOT TRANS. I was wondering if in the
> latest siesta 4.1b4 if there is a command for that.
> Thank you and looking forward to your reply.
> EL_abed
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

-- 
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 question about unit cell vectors

[Nick Papior]

Hi,

This is a limitation in 4.0 and prior versions.
In 4.1 this restriction has been lifted and you can do calculations on
skewed cells.

Den tor. 21. nov. 2019 kl. 22.00 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good afternoon,
> I have a question concerning the unit cell for a transiesta study. IN THIS
> LINK:
> https://www.mail-archive.com/siesta-l@uam.es/msg07905.html
>
> Apparently the geometry of the unit cell is not compatible if the c axis
> is not simultaneously perpendicular to a and b. Is that really the case?
> The manual does not state that in an obvious manner.
> Could you elaborate on the reasoning behind of this?
> Any other conditions for the unit vectors to be transiesta friendly?
> Thank you and eager to read the reply.
> EL-abed
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
> --
> 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/)

Re: [SIESTA-L] TSDE File

[Nick Papior]

If you are using 4.0 and older versions then please check the output for
details. It should clearly state why it stopped without writing the TSDE.

If you are using 4.1 and newer versions, then it is because you are using
the wrong flags. Please carefully read the manual which explains all new
flags, and a short-cut from old keywords.

Den tor. 31. okt. 2019 kl. 22.03 skrev RUPESH TIWARI :

> Hi Everyone,
>  I am a new siesta user. I am doing a transiesta
> calculation of a junction device. but it's not generating the TSDE file.
> Can anyone please suggest me the possible solution for this? I am attaching
> the input file of the device here
>
> Rupesh Kumar Tiwari
> C/o: Prof. Gopalan Rajaraman
> Junior Research Fellow (CSIR)
> Department of Chemistry
> IIT Bombay
> Mumbai- 400076
>
> --
> 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/)

Re: [SIESTA-L] Regarding Installation of SIESTA 4.1

[Nick Papior]

We don't officially have any distribution packages for Siesta.

So you'll have to install Siesta manually. :)

/ Nick

Den tir. 24. sep. 2019 kl. 22.00 skrev Jyotirmoy Deb <
deb.jyotirmo...@gmail.com>:

> Dear Sir/Madam,
> Whether it is possible to install mpi version of SIESTA using yum install
> in CentOS. Library files have to be installed separately or it comes within
> yum install of SIESTA.
> Thank you in advance.
>
> With regards
> Jyotirmoy
>
> --
> 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/)

Re: [SIESTA-L] Device Relaxation

[Nick Papior]

Essentially you need to add so many electrode layers that the relaxation
does not induce changes in the layers closest to the electrode. You can
test the effect by adding more electrode layers and changing what you
constrain. You want the physical properties to be converged as a function
of electrode length.

Den ons. 18. sep. 2019 kl. 22.01 skrev Ziba Torkashvand <
zi.torkashv...@gmail.com>:

> In fact, my device is a monolayer hexagonal system which I want to put two
> three-layer bulk electrodes on it. In the previous questions and answers, I
> saw that relaxation of the electrodes is not necessary but there is some
> difference between those systems and mine. In those cases, electrodes are
> connected to the channel from two ends but in my system electrodes are on
> the channel and the bond length must be relaxed. I want to ask which layers
> must be constrained and the remainder must be relaxed.
>
>
> Thanks,
> Ziba Torkashvand
> [image: Mailtrack]
> 
>  Sender
> notified by
> Mailtrack
> 
>  09/18/19,
> 05:50:06 PM
>
> On Sun, Sep 15, 2019 at 1:02 PM Ziba Torkashvand 
> wrote:
>
>> Dear Siesta users, my question is about device relaxation like in  paper
>> https://nanoscalereslett.springeropen.com/articles/10.1186/s11671-016-1673-5
>>
>> I want to ask about the steps and geometry constraints.
>> Furthermore, I want to know how can I constraints lattice vectors in what
>> the device will change in size just in the z-direction and the vacuums in x
>> and y are constant.
>>
>> Thank a lot,
>> Ziba Torkashvand
>>
>>
>> [image: Mailtrack]
>> 
>>  Sender
>> notified by
>> Mailtrack
>> 
>>  09/15/19,
>> 12:39:35 PM
>>
>

-- 
Kind regards Nick

[SIESTA-L] [***Posible SPAM***]Re: Nanoribbon Band Structure

[Nick Papior]

When you duplicate a system you fold the bandstructure. However, they refer
to the same system in a new reference supercell.
If you *only* duplicate your system you should be able to *visually*
decipher which bands belongs to the original band-structure by following
the folding.

Den søn. 8. sep. 2019 kl. 22.10 skrev Ziba Torkashvand <
zi.torkashv...@gmail.com>:

> Dear Siesta users, I want to do a calculation for armchair boron nitride.
> First, I calculated the band structure for a H-terminated 16-atom
> supercell and everything goes well but after repeating it in the
> Z-direction the band structure is completely different. Below is my input
> data.
> Any help will be kindly appreciated.
>
> SystemName  BN96
> SystemLabel BN96
>
> NumberOfAtoms  120
> NumberOfSpecies3
>
> %block ChemicalSpeciesLabel
>   1   5  B
>   2   7  N
>   3   1  H
> %endblock ChemicalSpeciesLabel
>
> %block PAO.BasisSizes
> B  DZP
> N  DZP
> H  DZP
> %endblock PAO.BasisSizes
> XC.functional GGA
> XC.authorsPBE
>
> LatticeConstant 1.00 Ang
> %block LatticeVectors
> 15.0184160.000   
> 28.110748   
> 0   26.254219
> %endblock LatticeVectors
>
> AtomicCoordinatesFormat Ang
> %block AtomicCoordinatesAndAtomicSpecies
> 4.99806814   10.130305692.89878885   1   1  B
> 4.99801199   11.373707333.63699571   2   2  N
> 4.99813743   10.164713141.48289328   2   3  N
> 4.99812179   11.384041660.71785760   1   4  B
> 4.99804236   12.633718302.90545729   1   5  B
> 4.99806374   13.890267583.63634513   2   6  N
> 4.99806280   12.638727501.44914602   2   7  N
> 4.99813944   13.894167510.71724054   1   8  B
> 4.99808119   15.144938502.90508953   1   9  B
> 4.99803141   16.400463363.63686499   2  10  N
> 4.99813910   15.148881461.44842366   2  11  N
> 4.99812876   16.405596150.71755851   1  12  B
> 4.99798906   17.655337962.90555046   1  13  B
> 4.99788191   18.874674913.67055732   2  14  N
> 4.99805568   17.665741481.44897236   2  15  N
> 4.99801717   18.909319740.71071300   1  16  B
> 4.998065039.036779713.45950287   3  17  H
> 4.998160339.283326440.96932716   3  18  H
> 4.99786641   19.756247713.15723011   3  19  H
> 4.99796237   20.002838491.27139448   3  20  H
> 4.99790820   10.130268257.27450101   1  21  B
> 4.99785143   11.373665938.01269652   2  22  N
> 4.99797713   10.164653175.85858366   2  23  N
> 4.99796310   11.384015545.09356218   1  24  B
> 4.99788147   12.633680777.28115248   1  25  B
> 4.99790238   13.890227018.01205439   2  26  N
> 4.99790265   12.638677345.82484688   2  27  N
> 4.99797974   13.894131905.09294272   1  28  B
> 4.99792079   15.144893967.28078063   1  29  B
> 4.99787292   16.400430228.01257295   2  30  N
> 4.99797938   15.148843905.82412986   2  31  N
> 4.99796881   16.405551425.09325906   1  32  B
> 4.99782955   17.655303327.28124601   1  33  B
> 4.99772085   18.874612468.04627489   2  34  N
> 4.99789629   17.665708825.82467266   2  35  N
> 4.99785742   18.909277735.08641847   1  36  B
> 4.997905129.036738627.83520640   3  37  H
> 4.998000359.283297295.34504337   3  38  H
> 4.99770663   19.756228767.53291210   3  39  H
> 4.99780259   20.002804865.64709520   3  40  H
> 4.99774776   10.13022465   11.65017932   1  41  B
> 4.99769162   11.37362315   12.38839710   2  42  N
> 4.99781561   10.16464145   10.23430424   2  43  N
> 4.99780189   11.383968029.46925765   1  44  B
> 4.99772147   12.63364075   11.65685073   1  45  B
> 4.99774209   13.89018391   12.38775530   2  46  N
> 4.99774334   12.63863840   10.20055561   2  47  N
> 4.99781899   13.894093229.46863329   1  48  B
> 4.99776070   15.14485300   11.65647996   1  49  B
> 4.99771319   16.40038834   12.38827319   2  50  N
> 4.99781908   15.14880766   10.19983398   2  51  N
> 4.99780894   16.405511359.46895174   1  52  B
> 4.99766994   17.65526407   11.65694927   1  53  B
> 4.99756106   18.87456680   12.42197812   2  54  N
> 4.99773633   17.66566869   10.20037198   2  55  N
> 4.99769738   18.909243529.46210019   1  56  B
> 4.997745419.03669567   12.21089917   3  57  H
> 4.997840239.283234599.72071812   3  58  H
> 4.99754692   19.75618834   11.90861606   3  59  H
> 4.99764272   20.00276817   10.02279069   3  60  H
> 4.99758812   10.13017685   16.02589674   1  61  B
> 

Re: [SIESTA-L] Input generation regarding

[Nick Papior]

You could use sisl (https://github.com/zerothi/sisl) which can convert
several file formats to other file formats.

It your case you could run:
 sgeom input.xyz output.fdf

Which does what you need.

On Sat, 7 Sep 2019, 22:01 RAHUL SURESH,  wrote:

> Hi Herbert
>
> I need the input in fdf format.
>
> I have my input coordinates as PDB and xyz. In case of siesta, as the
> coordinates must be terminated with  atomic species number and my system is
> having 700 atoms ( C N H ) it is too difficult to terminate them manually.
> Any way I have to do it if there is no option left. So I wanna know if it
> is possible to determine siesta accessible coordinates format.
>
> Thank you
>
> On Sat, 7 Sep, 2019, 1:38 AM Herbert Fruchtl, <
> herbert.fruc...@st-andrews.ac.uk> wrote:
>
>> Hi Rahul,
>>
>> In what format do you have the coordinates? I have a program that
>> translates
>> between various periodic formats (fdf, VASP, CASTEP, Quantum Espresso)
>> that I
>> could send you. Some viewers (I use gdis) can save structures as fdf. And
>> then
>> there's ASE, which can read and write in a plethora of formats (but you
>> need to
>> now a bit of Python).
>>
>> Cheers,
>>
>>Herbert
>>
>> On 05/09/2019 07:54, RAHUL SURESH wrote:
>> > Hi
>> >
>> > On a basic question- I am computing large-scale density functional
>> theory (DFT)
>> > calculations. The system has 700 atoms approx. Is there any particular
>> software
>> > to generate coordinates for siesta input to be included in %block
>> > atomiccoordinatesandatomicspecies?
>> >
>> > Or in case if I am reading the input from a file, say
>> "coordinate.data", should
>> > the coordinates be terminated with atomic species number?
>> >
>> > Thank you
>> > --
>> > /Regards,/
>> > /Rahul**/
>>
>> --
>> Herbert Fruchtl
>> Senior Scientific Computing Officer
>> School of Chemistry, School of Mathematics and Statistics
>> University of St Andrews
>> --
>> The University of St Andrews is a charity registered in Scotland:
>> No SC013532
>>
>

Re: [SIESTA-L] << two different values for charge same output >>

[Nick Papior]

Ok, I see the mistake now.

It is because you calculate the LDOS. The first value is the correct value,
the second value corresponds to the V/H charges for the LDOS charge, so not
really useful here. :)

I have submitted a patch for this!

Thanks!

Den tir. 3. sep. 2019 kl. 22.01 skrev I. Camps :

> Thank you for your reply.
>
> @Nick: I attached both files: input and output.
> @Berna: They are different schemes but the output is shown twice with
> different values.
>
>
> []'s,
>
> Camps
>
>
> On Mon, Sep 2, 2019 at 5:09 PM Nick Papior  wrote:
>
>> Could you share your input fdf? And also which version of siesta you are
>> using?
>>
>> Den søn. 1. sep. 2019 kl. 22.01 skrev I. Camps :
>>
>>> Hello SIESTers,
>>>
>>> I am trying to analyze the charge transfer when a metal is absorbed on a
>>> surface. In order to do that, I calculated the charges using different
>>> schemes implemented in SIESTA  (Mulliken, Hirshfeld, Voronoi and Bader).
>>>
>>> At the end of the output (bellow), I got two values for the Hirshfeld
>>> and Voronoi.
>>>
>>> My question is: why did I got two values instead of one?
>>>
>>> # Output for Pb
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Hirshfeld Net Atomic Populations:Atom #Qatom  Species 1
>>> -0.000  PbVoronoi Net Atomic Populations:Atom #Qatom  Species 1
>>> -0.000  PbBader Analysis core-charge setup. Radii (standard, H):  1.000
>>> 0.600dhscf: Vacuum level (max, mean) =0.0033770.003376 eVHirshfeld
>>> Net Atomic Populations:Atom #Qatom  Species 16.000  PbVoronoi
>>> Net Atomic Populations:Atom #Qatom  Species 16.000  Pb*
>>> # Output for Pb
>>>
>>> []'s,
>>>
>>> Camps
>>>
>>
>>
>> --
>> Kind regards Nick
>>
>

-- 
Kind regards Nick

Re: [SIESTA-L] << two different values for charge same output >>

[Nick Papior]

Could you share your input fdf? And also which version of siesta you are
using?

Den søn. 1. sep. 2019 kl. 22.01 skrev I. Camps :

> Hello SIESTers,
>
> I am trying to analyze the charge transfer when a metal is absorbed on a
> surface. In order to do that, I calculated the charges using different
> schemes implemented in SIESTA  (Mulliken, Hirshfeld, Voronoi and Bader).
>
> At the end of the output (bellow), I got two values for the Hirshfeld and
> Voronoi.
>
> My question is: why did I got two values instead of one?
>
> # Output for Pb
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Hirshfeld Net Atomic Populations:Atom #Qatom  Species 1   -0.000
>  PbVoronoi Net Atomic Populations:Atom #Qatom  Species 1   -0.000
>  PbBader Analysis core-charge setup. Radii (standard, H):  1.000
> 0.600dhscf: Vacuum level (max, mean) =0.0033770.003376 eVHirshfeld
> Net Atomic Populations:Atom #Qatom  Species 16.000  PbVoronoi
> Net Atomic Populations:Atom #Qatom  Species 16.000  Pb*
> # Output for Pb
>
> []'s,
>
> Camps
>


-- 
Kind regards Nick

Re: [SIESTA-L] << Spin polarization output >>

[Nick Papior]

Well, you could read in the DM and overlap matrix in sisl and manually
calculate the spin-polarization.

Otherwise you have to recalculate with this option XML.Write.

But why don't just use: *spin moment: S , {S} =2.0   0.0
0.0   2.0*
?

Den fre. 9. aug. 2019 kl. 22.01 skrev I. Camps :

> Thanks Nick.
>
> Unfortunately, the only xml output that I have is related to the ion files
> :(.
>
> Should I have to re-calculate?
>
> []'s,
>
> Camps
>
>
> On Thu, Aug 8, 2019 at 5:00 PM Nick Papior  wrote:
>
>> If you also store the xml output you can get the spin polarization
>> information there, key=siesta:stot and key=siesta:svec (only for
>> non-colinear).
>>
>> Den tir. 6. aug. 2019 kl. 22.00 skrev I. Camps :
>>
>>> Dear SIESTers,
>>>
>>> In previous versions of SIESTA (aka 3.1), when running a spin polarized
>>> calculation, I got in the output the following information:
>>>
>>> *siesta: Total spin polarization (Qup-Qdown) =0.435246 *
>>>
>>> Now, running in SIESTA v4.1-b4, I just got:
>>>
>>> *spin moment: S , {S} =2.0   0.0   0.0   2.0*
>>>
>>> Is there any other file from were I can got the spin polarization
>>> information?
>>>
>>> Regards,
>>>
>>> Camps
>>>
>>
>>
>> --
>> Kind regards Nick
>>
>

-- 
Kind regards Nick

Re: [SIESTA-L] << Spin polarization output >>

[Nick Papior]

If you also store the xml output you can get the spin polarization
information there, key=siesta:stot and key=siesta:svec (only for
non-colinear).

Den tir. 6. aug. 2019 kl. 22.00 skrev I. Camps :

> Dear SIESTers,
>
> In previous versions of SIESTA (aka 3.1), when running a spin polarized
> calculation, I got in the output the following information:
>
> *siesta: Total spin polarization (Qup-Qdown) =0.435246 *
>
> Now, running in SIESTA v4.1-b4, I just got:
>
> *spin moment: S , {S} =2.0   0.0   0.0   2.0*
>
> Is there any other file from were I can got the spin polarization
> information?
>
> Regards,
>
> Camps
>


-- 
Kind regards Nick

Re: [SIESTA-L] With or without gold in the scattering region

[Nick Papior]

No, you probably cannot do this since you need a "screening" layer which
ensures the electrode has the electronic structure of a bulk part.

Den man. 8. jul. 2019 kl. 22.04 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good afternoon all.
>  I was wondering if I calculate a system made of gold electrodes but
> without including gold into the scattering region. But still managed to get
> PDOS SIESTA and PDOS TbTRANS (V=0) to be equivalent, would that be ok? Or
> is having gold in the scattering region mandatory?
> Thank you and eager to reading your reply.
> EL-ABed
>
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>

-- 
Kind regards Nick

Re: [SIESTA-L] Thoughts on PDOS siesta vs PDOS tbtrans

[Nick Papior]

Den tir. 2. jul. 2019 kl. 22.01 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> THank you again for the reply Nick
> I wanted to ask you then if PDOS siesta vs PDOS Tbtrans(V=0) are NOT
> similar which means that the system is not sufficiently built: Does that
> mean all results (T(E), current and PDOS) are not physical?
>
Probably yes, this would be a first guess.
I.e. you should try and increase the system size.

> IF so could it be because Transiesta and thus Tbtrans are z coordinate
> sensitive (in a sense that I should always build my system in an increasing
> z order)?
>
They are not z-coordinate sensitive.

> Thank you and looking forward to your reply!
> EL-abed
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
> --
> *From:* siesta-l-requ...@uam.es  on behalf of
> Nick Papior 
> *Sent:* Monday, 24 June 2019 8:23 PM
> *To:* siesta-l
> *Subject:* Re: [SIESTA-L] Thoughts on PDOS siesta vs PDOS tbtrans
>
> In general,
>
> A 0 bias calculation should yield a somewhat equivalent PDOS in siesta vs.
> tbtrans. If this is the case it means that you have set up your system in a
> sufficient manner. This is to say that the electrodes already screen off
> the junction sufficiently (please spend some time on why this is)!
> For non-zero bias they are (should) be different.
>
> Den fre. 21. jun. 2019 kl. 22.01 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Good evening all,
> I was wondering if anyone could give some insight on the difference
> between PDOS calculated in siesta as a DFT run vs PDOS calculated in
> tbtrans as a DFT+NEGF run.
> Should i expect for example PDOS to be different? Any computational or
> physical insight would be highly appreciated.
> Thank you and looking forward to the comments.
> EL-abed
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
> --
> Kind regards Nick
>


-- 
Kind regards Nick

Re: [SIESTA-L] Difference of K point for ribbons and layer in .TBtrans

[Nick Papior]

Hi,

Den ons. 26. jun. 2019 kl. 22.02 skrev Fazle Subhan :

> Dear Dr. Nick
>
> Previously I work on some nanoribbons for calculating the I-V curve where
> I simply use k-points along the z-direction. Therefore in the P.TRANS file
> I get only one k point (means is it due to the one dimension case?)
>
What you have to consider is how the system WITH self-energies is
physically perceived. When attaching semi-infinite leads you are
effectively removing a periodic direction. I.e. there is no need for *any*
k-points along non-periodic directions.
With this explanation you should be able to generalize for *any* system.

> Now, I calculate the IV curve of a sheet, where I also consider the
> y-direction beside z-direction and therefore I have 2 k points. Again I
> want to ask that is due to 2 directions?
>
> My next question is about the .TRANS file
>
> In my previous cases (for ribbons), I simply calculate the bias dependent
> DOS results from the .TRANS file, but here in case of the sheet can I apply
> the same concept or I have to calculate the bias dependent DOS results from
> the .TRANS file for both k-points?
>
You always have to converge your results in terms of k-point resolutions.
Always!

> Please guide me in this regard. I also read the same questions on the
> siesta forum but could not find an answer.
>
> Thanks in advance
> Regards
> Fazle Subhan
> PhD Student
> Deptt.of Physics
> Pukyung National University
> Nam-gu Busan, Korea
>


-- 
Kind regards Nick

Re: [SIESTA-L] Thoughts on PDOS siesta vs PDOS tbtrans

[Nick Papior]

You are correct. More k-points for transmission / Dos calculations using
tbtrans.

On Tue, 25 Jun 2019, 22:00 El-abed Haidar, 
wrote:

> Thank you very much for the reply. This is very interesting because I
> never knew that PDOS siesta should to good extent match PDOS Tbtrans at
> V=0.
> My question would be then in order to compare both results they should
> have really almost the same parameters. But one parameter i feel will be
> different is usually the K points because in Siesta DFT you would first
> create the charge density with certain k points. Then increase the K points
> to find PDOS or am I wrong?
> Thank you again Nick really appreciate your explanations.
> EL-abed
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
> --
> *From:* siesta-l-requ...@uam.es  on behalf of
> Nick Papior 
> *Sent:* Monday, 24 June 2019 8:23 PM
> *To:* siesta-l
> *Subject:* Re: [SIESTA-L] Thoughts on PDOS siesta vs PDOS tbtrans
>
> In general,
>
> A 0 bias calculation should yield a somewhat equivalent PDOS in siesta vs.
> tbtrans. If this is the case it means that you have set up your system in a
> sufficient manner. This is to say that the electrodes already screen off
> the junction sufficiently (please spend some time on why this is)!
> For non-zero bias they are (should) be different.
>
> Den fre. 21. jun. 2019 kl. 22.01 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Good evening all,
> I was wondering if anyone could give some insight on the difference
> between PDOS calculated in siesta as a DFT run vs PDOS calculated in
> tbtrans as a DFT+NEGF run.
> Should i expect for example PDOS to be different? Any computational or
> physical insight would be highly appreciated.
> Thank you and looking forward to the comments.
> EL-abed
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
> --
> Kind regards Nick
>

Re: [SIESTA-L] pDOS spin up vs spin down in tbrans

[Nick Papior]

Den fre. 21. jun. 2019 kl. 22.02 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good evening,
> I was wondering for the spin PDOS extracted from Tbtrans, should I
> multiply the values obtained by -1
>
No!

> because I have noticed PDOS spin down calculated via TBTRANs for many
> different elements tend to have a similar trend to PDOS spin up.
> If i should not multiply by -1 what does spin down PDOS mean if it has
> positive values?
>
Why should spin-down have a negative value?
A PDOS is a DOS and DOS tends to be positive. I guess you get the -1
convention due to plots showing the DOS (up/down) in mirrored graphs which
seems to suggest a negative spin-down.
Note this is simply a way to present the data. But do note that the DOS
*is* positive!

> I could not find in the tbrans manual any output insight.
> Any physical or computational insight  or comments would be highly
> appreciated. Thank you!
> EL-abed
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>

-- 
Kind regards Nick

Re: [SIESTA-L] Thoughts on PDOS siesta vs PDOS tbtrans

[Nick Papior]

In general,

A 0 bias calculation should yield a somewhat equivalent PDOS in siesta vs.
tbtrans. If this is the case it means that you have set up your system in a
sufficient manner. This is to say that the electrodes already screen off
the junction sufficiently (please spend some time on why this is)!
For non-zero bias they are (should) be different.

Den fre. 21. jun. 2019 kl. 22.01 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good evening all,
> I was wondering if anyone could give some insight on the difference
> between PDOS calculated in siesta as a DFT run vs PDOS calculated in
> tbtrans as a DFT+NEGF run.
> Should i expect for example PDOS to be different? Any computational or
> physical insight would be highly appreciated.
> Thank you and looking forward to the comments.
> EL-abed
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>

-- 
Kind regards Nick

Re: [SIESTA-L] << error compiling TBtrans-4.1-b4 >>

[Nick Papior]

Try a make clean, otherwise you may have some problematic flags in your
arch.make.
One should not need to edit the arch.make to compile tbtrans.

Den ons. 24. apr. 2019 kl. 22.07 skrev I. Camps :

> Hello,
>
> After successfully compiled siesta-4.1-b4, I moved to
> *siesta-4.1-b4/Util/TS/TBtrans* in order to compile TBtrans.
>
> Just calling *make*, result in the following errors:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *local_sys.F(48): error #7002: Error in opening the compiled module file.
> Check INCLUDE paths.   [PARALLEL]  use parallel, only :
> Node--^local_sys.F(68): error #6406: Conflicting attributes or
> multiple declaration of name.   [NODE]  write(6,'(a,i4)') 'Stopping
> Program from Node: ',
> Node^local_sys.F(69):
> error #6406: Conflicting attributes or multiple declaration of name.
> [NODE]  write(0,'(a,i4)') 'Stopping Program from Node: ',
> Node^local_sys.F(71):
> error #6406: Conflicting attributes or multiple declaration of name.
> [NODE]  if (Node .eq. 0) then--^local_sys.F(48): error #6580:
> Name in only-list does not exist or is not accessible.   [NODE]  use
> parallel, only : Node---^local_sys.F(91): error
> #7002: Error in opening the compiled module file.  Check INCLUDE paths.
> [PARALLEL]  use parallel, only : Node--^local_sys.F(101): error
> #6406: Conflicting attributes or multiple declaration of name.
> [NODE]  if (Node .eq. 0) then--^local_sys.F(91): error #6580:
> Name in only-list does not exist or is not accessible.   [NODE]  use
> parallel, only : Node---^local_sys.F(122): error
> #7002: Error in opening the compiled module file.  Check INCLUDE paths.
> [PARALLEL]  use parallel, only : Node--^local_sys.F(133): error
> #6406: Conflicting attributes or multiple declaration of name.
> [NODE]  if (Node.eq.0) then--^local_sys.F(122): error #6580:
> Name in only-list does not exist or is not accessible.   [NODE]  use
> parallel, only : Node---^compilation aborted for
> local_sys.F (code 1)../../../Obj/arch.make:118: recipe for target
> 'local_sys.o' failed*
> *make: *** [local_sys.o] Error 1*
>
> Is there a need to modify the *Makefile* or the *arch.make* used to
> compile SIESTA?
>
> []'s,
>
> Camps
>


-- 
Kind regards Nick

Re: [SIESTA-L] << Debian 9.8+Intel+NetCDF >>

[Nick Papior]

Great, yes, MUMPS can be quite tricky. It isn't necessary anyways. :)

Den ons. 24. apr. 2019 kl. 22.00 skrev I. Camps :

> Dear Nick,
>
> After cleaned up the arch.make, I successfully (semi)compiled
> siesta-4.1-b4. I wrote (semi) because I got several errors with MUMPS that
> I "solved" removing from arch.make.
>
> Thank you very much.
>
> Camps
>
> On Mon, Apr 22, 2019 at 5:01 PM Nick Papior  wrote:
>
>> You have a mixed usage of FPPFLAGS_* and LDFLAGS. So in the end you don't
>> have the include directories for NetCDF (or any of your other libraries) in
>> your FPPFLAGS variable (since you do FPPFLAGS = ... which overwrites what
>> you did).
>>
>> Simply carefully go through your variables/flags and either append them
>> directly to FPPFLAGS, or, be very consistent on your usage of FPPFLAGS_*
>> variables.
>>
>> Den ons. 17. apr. 2019 kl. 22.01 skrev I. Camps :
>>
>>> Hello,
>>>
>>> I am trying to compile siesta in a new box with the following
>>> configuration:
>>> OS: Debian 9.8 64bits
>>> Compilers: Intel(R) Fortran Intel(R) 64 Compiler for applications
>>> running on Intel(R) 64, Version 19.0.3.199 Build 20190206
>>> MPI: Intel(R) MPI Library for Linux* OS, Version 2019 Update 3 Build
>>> 20190214
>>>
>>> I am getting the following error message:
>>>
>>>
>>>
>>>
>>> *netcdf_ncdf.f90(59): error #7002: Error in opening the compiled module
>>> file.  Check INCLUDE paths.   [NETCDF]  use
>>> netcdf--^netcdf_ncdf.f90(95): error #8237: The character length in a
>>> component declaration shall either be a colon, be an initialization
>>> expression, or be a specification expression.   [GRP]...*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *netcdf_ncdf.f90(663): error #6404: This name does not have a type, and
>>> must have an explicit type.   [NF90_INQUIRE_DIMENSION]  call
>>> ncdf_err(nf90_inquire_dimension(this%id,i,name=key))^netcdf_ncdf.f90(2964):
>>> catastrophic error: Too many errors, exitingcompilation aborted for
>>> netcdf_ncdf.f90 (code
>>> 1)/home/icamps/temp/SIESTA/siesta-4.1-b4/Src/ncdf/smeka/Makefile.compiler:141:
>>> recipe for target 'netcdf_ncdf.o' failedmake[1]: *** [netcdf_ncdf.o] Error
>>> 1make[1]: Leaving directory
>>> '/home/icamps/temp/SIESTA/siesta-4.1-b4/tmp-orange/ncdf/obj'Makefile:317:
>>> recipe for target 'libncdf.a' failedmake: *** [libncdf.a] Error 2*
>>>
>>> This is driving me crazy as I used the same steps to compile siesta in
>>> other linux boxes (only changing the Intel compilers and MPI versions)
>>>
>>> The output from NetCDF and NetCDF-Fortran are:
>>>
>>> NetCDF:
>>> This netCDF 4.4.1 has been built with the following features:
>>>   --cc-> mpiicc
>>>   --cflags->  -I/software/LIBS/netcdf-4.4.1/include -fPIC
>>> -I/software/LIBS/hdf5-1.8.12/include -I/include
>>> -I/software/LIBS/pnetcdf-1.11.0/include
>>>   --libs  ->
>>>   --has-c++   -> no
>>>   --cxx   ->
>>>   --has-c++4  -> no
>>>   --cxx4  ->
>>>   --fc->
>>>   --fflags->
>>>   --flibs ->
>>>   --has-f90   -> no
>>>   --has-f03   -> no
>>>   --has-dap   -> yes
>>>   --has-nc2   -> yes
>>>   --has-nc4   -> yes
>>>   --has-hdf5  -> yes
>>>   --has-hdf4  -> no
>>>   --has-logging-> no
>>>   --has-pnetcdf-> yes
>>>   --has-szlib ->
>>>   --prefix-> /software/LIBS/netcdf-4.4.1
>>>   --includedir-> /software/LIBS/netcdf-4.4.1/include
>>>   --version   -> netCDF 4.4.1
>>>
>>> NetCDF-Fortran:
>>> This netCDF-Fortran 4.4.4 has been built with the following features:
>>>   --cc-> mpiicc
>>>   --cflags->  -I/software/LIBS/netcdf-fortran-4.4.4/include -fPIC
>>> -DgFortran -I/software/LIBS/hdf5-1.8.12/include -I/include
>>> -I/software/LIBS/netcdf-4.4.1/include
>>>   --fc-> mpiifort
>>>   --fflags-> -I/software/LIBS/netcdf-fortran-4.4.4/include
>>>   --flibs -> -L/software/LIBS/netcdf-fortran-4.4.4/lib -lnetcdff
>>> -lnetcdf -L/lib -Wl,-rpath=/lib -L/software/LIBS/hdf5-1.8.12/lib
>>> -Wl,-rpath=/software/LIBS/hdf5-1.8.12/lib -L/software/LIBS/netcdf-4.4.1/lib
>>> -Wl,-rpa

Re: [SIESTA-L] << Debian 9.8+Intel+NetCDF >>

[Nick Papior]

You have a mixed usage of FPPFLAGS_* and LDFLAGS. So in the end you don't
have the include directories for NetCDF (or any of your other libraries) in
your FPPFLAGS variable (since you do FPPFLAGS = ... which overwrites what
you did).

Simply carefully go through your variables/flags and either append them
directly to FPPFLAGS, or, be very consistent on your usage of FPPFLAGS_*
variables.

Den ons. 17. apr. 2019 kl. 22.01 skrev I. Camps :

> Hello,
>
> I am trying to compile siesta in a new box with the following
> configuration:
> OS: Debian 9.8 64bits
> Compilers: Intel(R) Fortran Intel(R) 64 Compiler for applications running
> on Intel(R) 64, Version 19.0.3.199 Build 20190206
> MPI: Intel(R) MPI Library for Linux* OS, Version 2019 Update 3 Build
> 20190214
>
> I am getting the following error message:
>
>
>
>
> *netcdf_ncdf.f90(59): error #7002: Error in opening the compiled module
> file.  Check INCLUDE paths.   [NETCDF]  use
> netcdf--^netcdf_ncdf.f90(95): error #8237: The character length in a
> component declaration shall either be a colon, be an initialization
> expression, or be a specification expression.   [GRP]...*
>
>
>
>
>
>
>
>
>
> *netcdf_ncdf.f90(663): error #6404: This name does not have a type, and
> must have an explicit type.   [NF90_INQUIRE_DIMENSION]  call
> ncdf_err(nf90_inquire_dimension(this%id,i,name=key))^netcdf_ncdf.f90(2964):
> catastrophic error: Too many errors, exitingcompilation aborted for
> netcdf_ncdf.f90 (code
> 1)/home/icamps/temp/SIESTA/siesta-4.1-b4/Src/ncdf/smeka/Makefile.compiler:141:
> recipe for target 'netcdf_ncdf.o' failedmake[1]: *** [netcdf_ncdf.o] Error
> 1make[1]: Leaving directory
> '/home/icamps/temp/SIESTA/siesta-4.1-b4/tmp-orange/ncdf/obj'Makefile:317:
> recipe for target 'libncdf.a' failedmake: *** [libncdf.a] Error 2*
>
> This is driving me crazy as I used the same steps to compile siesta in
> other linux boxes (only changing the Intel compilers and MPI versions)
>
> The output from NetCDF and NetCDF-Fortran are:
>
> NetCDF:
> This netCDF 4.4.1 has been built with the following features:
>   --cc-> mpiicc
>   --cflags->  -I/software/LIBS/netcdf-4.4.1/include -fPIC
> -I/software/LIBS/hdf5-1.8.12/include -I/include
> -I/software/LIBS/pnetcdf-1.11.0/include
>   --libs  ->
>   --has-c++   -> no
>   --cxx   ->
>   --has-c++4  -> no
>   --cxx4  ->
>   --fc->
>   --fflags->
>   --flibs ->
>   --has-f90   -> no
>   --has-f03   -> no
>   --has-dap   -> yes
>   --has-nc2   -> yes
>   --has-nc4   -> yes
>   --has-hdf5  -> yes
>   --has-hdf4  -> no
>   --has-logging-> no
>   --has-pnetcdf-> yes
>   --has-szlib ->
>   --prefix-> /software/LIBS/netcdf-4.4.1
>   --includedir-> /software/LIBS/netcdf-4.4.1/include
>   --version   -> netCDF 4.4.1
>
> NetCDF-Fortran:
> This netCDF-Fortran 4.4.4 has been built with the following features:
>   --cc-> mpiicc
>   --cflags->  -I/software/LIBS/netcdf-fortran-4.4.4/include -fPIC
> -DgFortran -I/software/LIBS/hdf5-1.8.12/include -I/include
> -I/software/LIBS/netcdf-4.4.1/include
>   --fc-> mpiifort
>   --fflags-> -I/software/LIBS/netcdf-fortran-4.4.4/include
>   --flibs -> -L/software/LIBS/netcdf-fortran-4.4.4/lib -lnetcdff
> -lnetcdf -L/lib -Wl,-rpath=/lib -L/software/LIBS/hdf5-1.8.12/lib
> -Wl,-rpath=/software/LIBS/hdf5-1.8.12/lib -L/software/LIBS/netcdf-4.4.1/lib
> -Wl,-rpath=/software/LIBS/netcdf-4.4.1/lib -lnetcdf -lhdf5hl_fortran
> -lhdf5_fortran -lhdf5_hl -lhdf5 -lz
>   --has-f90   -> no
>   --has-f03   -> yes
>   --has-nc2   -> yes
>   --has-nc4   -> yes
>   --prefix-> /software/LIBS/netcdf-fortran-4.4.4
>   --includedir-> /software/LIBS/netcdf-fortran-4.4.4/include
>   --version   -> netCDF-Fortran 4.4.4
>
> My arch.make file:
>
>
>
>
>
>
>
>
>
>
>
>
> *SIESTA_ARCH=intel-mpi##FC=mpiifortFC_SERIAL=ifortCC=mpiiccCXX=mpicxxRANLIB=ranlibMKLPATH=/opt/intel/mkl/lib/intel64FFLAGS=-O1
> -ipo -xHost -ip -prec-div -prec-sqrt -qopt-prefetch -mkl=parallel
> -I${MKLROOT}/includeFFLAGS_CHECKS=-g -O0 -debug full -traceback
> -CFFLAGS_DEBUG= -gDUMMY_FOX=--enable-dummy*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *INCFLAGS += -I/software/LIBS/netcdf-4.4.1/includeLDFLAGS +=
> -L/software/LIBS/zlib-1.2.8/lib
> -Wl,-rpath=/software/LIBS/zlib-1.2.8/libLDFLAGS +=
> -L/software/LIBS/hdf5-1.8.12/lib
> -Wl,-rpath=/software/LIBS/hdf5-1.8.12/libLDFLAGS +=
> -L/software/LIBS/netcdf-4.4.1/lib
> -Wl,-rpath=/software/LIBS/netcdf-4.4.1/libLIBS += -lnetcdff -lnetcdf
> -lhdf5_hl -lhdf5 -lzCOMP_LIBS += libncdf.a libfdict.aFPPFLAGS += -DCDF
> -DNCDF -DNCDF_4LDFLAGS += -static-intel
> -L$(MKLPATH)#MPI_INTERFACE=libmpi_f90.aMPI_INCLUDE=/opt/intel/impi/2019.3.199/intel64/include
> # Note . for no-opMPI_LIBS= -L/opt/intel/impi/2019.3.199/intel64/lib
> -lmpi_90FPPFLAGS_MPI=-DMPIMETIS_LIB=/software/LIBS/parmetis-4.0.3/lib/libparmetis.aFPPFLAGS
> += -DSIESTA__METIS# MUMPSLIBS += 

Re: [SIESTA-L] << Reduce number of nodes? >>

[Nick Papior]

Could you:

0) Send the FORCE_STRESS file?
1) Use siesta-4.1 b4 (you are using b3)
2) Add MinSCFIterations 3 to the options
3) I would probably try and relax the system a bit first in a non-polarized
calculation (but this is unrelated to the failure)

Also, you are compiling with Intel -O3 which I typically won't advice.
Intel compilers are extremely aggressive which may lead to small numerical
problems. I would stick with -O2 and compile atom.F with -O1.

It seems the output was truncated since the failing call is *after* the
atoms has been moved. I.e. try this:
$> unbuffer mpirun -np ... siesta RUN.fdf > RUN.out
or equivalent, then send the output again.

Den man. 15. apr. 2019 kl. 22.02 skrev I. Camps :

> Hi Nick,
>
> Here it is.
>
> []'s,
>
> Camps
>
>
> On Sun, Apr 14, 2019 at 5:02 PM Nick Papior  wrote:
>
>> Could you please do a tar.gz or zip file? rar is horrible ;)
>>
>> Den lør. 13. apr. 2019 kl. 22.01 skrev I. Camps :
>>
>>> Hello Nick,
>>>
>>> Here are the files.
>>>
>>> []'s,
>>>
>>> Camps
>>>
>>>
>>> On Fri, Apr 12, 2019 at 5:02 PM Nick Papior 
>>> wrote:
>>>
>>>> Could you attach the output, fdf and psf files?
>>>>
>>>> Den tor. 11. apr. 2019 kl. 22.01 skrev I. Camps :
>>>>
>>>>> Hello,
>>>>>
>>>>> My system is a nanotube with 123 atoms (B, N, Ni). I am running a
>>>>> geometry optimization and the calculations are stopped (after 10 CG steps)
>>>>> with the following message:
>>>>>
>>>>> "*Sparse pattern is oversubscribed with nodes, please reduce number
>>>>> of nodes*"
>>>>>
>>>>> The calculation are running using 7 and 3 cores (in the same node). In
>>>>> both cases, the error message is the same.
>>>>>
>>>>> System: OpenSUSE 64bits, Intel and siesta-4.1--736
>>>>>
>>>>>
>>>>> I appreciate any help.
>>>>>
>>>>> []'s,
>>>>>
>>>>> Camps
>>>>>
>>>>
>>>>
>>>> --
>>>> Kind regards Nick
>>>>
>>>
>>
>> --
>> Kind regards Nick
>>
>

-- 
Kind regards Nick

Re: [SIESTA-L] << Reduce number of nodes? >>

[Nick Papior]

Could you please do a tar.gz or zip file? rar is horrible ;)

Den lør. 13. apr. 2019 kl. 22.01 skrev I. Camps :

> Hello Nick,
>
> Here are the files.
>
> []'s,
>
> Camps
>
>
> On Fri, Apr 12, 2019 at 5:02 PM Nick Papior  wrote:
>
>> Could you attach the output, fdf and psf files?
>>
>> Den tor. 11. apr. 2019 kl. 22.01 skrev I. Camps :
>>
>>> Hello,
>>>
>>> My system is a nanotube with 123 atoms (B, N, Ni). I am running a
>>> geometry optimization and the calculations are stopped (after 10 CG steps)
>>> with the following message:
>>>
>>> "*Sparse pattern is oversubscribed with nodes, please reduce number of
>>> nodes*"
>>>
>>> The calculation are running using 7 and 3 cores (in the same node). In
>>> both cases, the error message is the same.
>>>
>>> System: OpenSUSE 64bits, Intel and siesta-4.1--736
>>>
>>>
>>> I appreciate any help.
>>>
>>> []'s,
>>>
>>> Camps
>>>
>>
>>
>> --
>> Kind regards Nick
>>
>

-- 
Kind regards Nick

Re: [SIESTA-L] << Reduce number of nodes? >>

[Nick Papior]

Could you attach the output, fdf and psf files?

Den tor. 11. apr. 2019 kl. 22.01 skrev I. Camps :

> Hello,
>
> My system is a nanotube with 123 atoms (B, N, Ni). I am running a geometry
> optimization and the calculations are stopped (after 10 CG steps) with the
> following message:
>
> "*Sparse pattern is oversubscribed with nodes, please reduce number of
> nodes*"
>
> The calculation are running using 7 and 3 cores (in the same node). In
> both cases, the error message is the same.
>
> System: OpenSUSE 64bits, Intel and siesta-4.1--736
>
>
> I appreciate any help.
>
> []'s,
>
> Camps
>


-- 
Kind regards Nick

Re: [SIESTA-L] Converting HSX file into a readable file

[Nick Papior]

Probably the easiest way is to use sisl (www.github.com/zerothi/sisl) which
is a Python module.

Something like this:

import sisl
H = sisl.get_sile('RUN.fdf').read_hamiltonian()
print(H[0, 1]) # the Hamiltonian element between orbital 1 and 2

Since H is a sparse matrix you can also loop the matrix elements:

for row, col in H:
print(row, col, H[row, col])

Good luck.


Den tor. 4. apr. 2019 kl. 22.02 skrev Brandon Miller :

> Hello Everyone,
>
> I am trying to make the .HSX file that is written from the SaveHS flag
> into a readable format, so that I can look at the elements of the
> hamiltonian and overlap matrices. Is there a built-in utility in siesta
> that will do this? Or does anyone know another way to convert the HSX file
> into a readable format?
>
>
> Thank You,
>
> Brandon Miller
>


-- 
Kind regards Nick

Re: [SIESTA-L] PHtrans

[Nick Papior]

Hi,
Den søn. 31. mar. 2019 kl. 22.02 skrev Rodrigo Garcia Amorim <
rgamo...@id.uff.br>:

> Dear developers,
>
> I saw in the manual that is possible calculate the phonon
> transmission. Regarding this topic, my questions are:
>
> 1) Could I  use similar setup of transport calculation?
>
Yes and no. Generally it would be extremely costly to perform phonon
transmission calculations using siesta since it requires a huge system to
ensure the phonons are "relaxed" in the electrode region. This is why we
(in the paper) did phonon transmissions using GULP which can calculate the
dynamical matrix.

>
> 2) For electrodes I need run FC with transiesta to obtain the dynamic
> matrix and frequencies?
>
If you wish to use siesta (transiesta is not needed) then yes, you need the
electrodes in a big enough cell such that you can decouple the cell
interactions. The problem is that phonons are long ranged and thus
intrinsically requires a very large system to get correct dynamical
matrices. I.e. for the graphene system in the paper we used a system of 128
atoms which reduces to an 8 atom big electrode and 32 big device region.
Since this is for the GULP MD scheme you may need an even bigger system in
siesta.

>
> 3) For scatter region I also need calculate using FC and transiesta?
>
See above.

>
> 4) In the paper (Improvements on non-equilibrium and transport Green
> function techniques: The next-generation transiesta)
>
> The authors claim that is possible use Nc>=1. For Nc=1. Should I consider
> just left electrode?
>
Do you mean number of electrodes? N_e?
If so yes. You can do as many (or as few as 1) electrodes. If you want
transmission you need at least 2 electrodes.

>
>
> Thanks
>
> Rodrigo
>
> --
> --
> Dr. Rodrigo G. Amorim
>
> ===
> Universidade Federal Fluminense - UFF
> Departamento de Física, ICEx
>
> R. Des. Ellis Hermydio Figueira, 783
> Aterrado, Volta Redonda - RJ, Brazil
> 27213-145
> ---
> webpage   :  http://rgamorim.wix.com/rodrigo
> e-mail: rgamo...@id.uff .br
> 
>


-- 
Kind regards Nick

Re: [SIESTA-L] Strange force/stress behavior in transiesta 4.1-b4

[Nick Papior]

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

Re: [SIESTA-L] TBTrans segfaults

[Nick Papior]

Hi,

No, said line shouldn't be the cause of anything... :( And fdf inputs
shouldn't generate a seg-fault.

Another try for debugging would be to add full traceback calls:
Intel:
 FFLAGS = -O0 -g -check bounds -traceback

Which should be more informative.
Also, Intel is notorious for using the stack, do you have ulimit -s
unlimited?

As a last resort, try with Gnu compilers. And if this doesn't work, then
please provide all inputs etc.



Den man. 25. mar. 2019 kl. 22.01 skrev Day, Zacharie :

>
> Deleting the TBTGF files did not solve the problem. So, my two guesses now
> are that there is an issue with the compilation of TBTrans (but it's
> compiled with stock Intel compiler, so I imagine someone else would have
> run into this) or there is an error in the input code. Would an error in
> the input (as in, the FDF files) be able to cause such a segfault?
>
> On Sat, Mar 9, 2019 at 4:00 PM Nick Papior  wrote:
>
>> Could you please delete all TBTGF* files, and rerun the calculation?
>>
>> Alternatively, see if increasing the eta value helps.
>>
>> Den fre. 8. mar. 2019 kl. 22.02 skrev Day, Zacharie :
>>
>>> Hello,
>>>
>>> A user on my cluster is trying to process something with Siesta 4.0.2
>>> TBTrans_rep. The process works up until this output:
>>>
>>>  ==
>>>   Projection Region: atoms : [ 183; 244]
>>>   Projection Region: states: [ 1639; 2172] Tot:  534
>>>  Reading GF file, with title:
>>>/home/rao/SIESTA/ODT/test/tbt/ODT-Au-1K.TBTGFL
>>>  Title: 'Generated GF file'
>>>
>>>  Reading GF file, with title:
>>>/home/rao/SIESTA/ODT/test/tbt/ODT-Au-1K.TBTGFR
>>>  Title: 'Generated GF file'
>>>
>>> # k-point: 1
>>> # k  = -0.026388,   0.026388,   0.00, w=   0.22
>>> # kb = -0.17,   0.17,   0.00, w=   0.22
>>> After this point, the program terminates after a short period with
>>> "Program received signal SIGSEGV, Segmentation fault." Furthermore, the
>>> issue occurs regardless of whether it's run alone or with MPI.
>>> GDB gives this:
>>>
>>> 0x005071fd in transmission (usebulk=@0x,
>>> nou=@0x2160f3c, hk=..., sk=...,
>>> nod=@0x6670216, nol=@0x6c00666, sfel=..., nor=@0x6c0,
>>> sfer=...,
>>> zenergy=@0xbfb2c0b552857fde, gf=..., gfrgf=..., tottrans=@0x0,
>>> tt=..., ierr=@0x0)
>>> at transmission.f90:94
>>> 94transmission.f90: No such file or directory.
>>> in transmission.f90
>>> I looked at transmission.f90 but I do not understand Siesta's code well
>>> enough to see any issues with line 94. Siesta is compiled on this cluster
>>> as follows:
>>>
>>> Siesta Version  : v4.0.2
>>> Architecture: intel-mkl
>>> Compiler version: ifort (IFORT) 13.0.1 20121010
>>> Compiler flags  : mpiifort -g -O0
>>> PP flags: -DFC_HAVE_FLUSH -DFC_HAVE_ABORT -DMPI
>>>
>>> I added the -O0 when I came across some mails suggesting that Intel's
>>> optimizations may be the culprit, however it would seem that that is not
>>> the case here. As I am entirely stuck on this issue, I would appreciate any
>>> assistance.
>>>
>>> --
>>> Zacharie Day
>>> Systems Analyst
>>> The George Washington University, SEAS Computing Facility
>>>
>>
>>
>> --
>> Kind regards Nick
>>
>
>
> --
> Zacharie Day
> Systems analyst
> The George Washington University, SEAS Computing Facility
> (202) 994-3963
>
>

-- 
Kind regards Nick

Re: [SIESTA-L] Qtot is not zero

[Nick Papior]

Hi,

Den lør. 23. mar. 2019 kl. 22.01 skrev Mina Sedighi :

> Dear Nick,
>
> Thank you for your reply. It is good news. But what is the reason of
> destroying MnO2 structure (Oxygen atoms are opened from the structure).
>
I don't know, I am no expert in your system.


> And how can I calculate Mulliken charge distribution on the system?
>
Search for Mulliken in the siesta manual, it explicitly specifies how this
is done. :)

>
> Best regards
> Mina
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
>
>
>
> On Fri, Mar 22, 2019 at 5:01 PM -0400, "Nick Papior"  > wrote:
>
> Qtot is the valence charge for your system. So everything seems fine!
>> NetCharge is an additional charge added to your system and thus would
>> change Qtot correspondingly.
>>
>> Den tor. 21. mar. 2019 kl. 22.11 skrev Mina Sedighi <
>> msedi...@uwaterloo.ca>:
>>
>>> Dear all,
>>>
>>>
>>> I solved SCF convergence problem by playing with SCF.Mixingweight and
>>> SCF.Mixing History. Now I have a problem with Qtot. I defined NetCharge
>>> flag to 0, but Mulliken atomic charges calculated by Siesta are wrong. Qtot
>>> in the system is 340! Oxygen atoms of water have positive charge of about
>>> 6. Zn2+ charge is about 11 and K+ charge is 0.1!! My .fdf commands are as
>>> follow:
>>>
>>>
>>> SystemName small
>>> SystemLabel small
>>> NumberOfAtoms 86
>>> NumberOfSpecies 6
>>> %block Chemical_Species_label
>>> 1 25 Mn
>>> 2 1 H
>>> 3 19 K
>>> 4 8 O
>>> 5 16 S
>>> 6 30 Zn
>>> %endblock Chemical_Species_label
>>> PAO.BasisType split
>>> PAO.BasisSize SZP
>>> PAO.EnergyShift 0.02 Ry
>>> MeshCutoff 200 Ry
>>> kgrid.Cutoff 3.655 Ang # half of the smallest lattice vector
>>> SCF.Mix Hamiltonian
>>> SCF.Mixer.Method Pulay
>>> MaxSCFIterations 1000
>>> SCF.H.Tolerance 2.d-3 eV
>>> SCF.Mixer.Weight 0.01
>>> SCF.Mixer.History 2
>>> ElectronicTemperature 300 K
>>> XC.Functional GGA
>>> XC.Authors PBE
>>> MD.TypeOfRun CG
>>> MD.NumCGsteps 200
>>> MD.MaxDispl 0.05 Ang
>>> MD.MaxForceTol 0.04 eV/Ang
>>> MD.VariableCell
>>> NetCharge 0
>>> %block Geometry.Constraints
>>> atom from 1 to 4
>>> %endblock Geometry.Constraints
>>>
>>> Can anyone guide me how I can solve this problem? Thank you so much.
>>>
>>>
>>> Regards,
>>>
>>> Mina
>>>
>>
>>
>> --
>> Kind regards Nick
>>
>

-- 
Kind regards Nick

Re: [SIESTA-L] Qtot is not zero

[Nick Papior]

Qtot is the valence charge for your system. So everything seems fine!
NetCharge is an additional charge added to your system and thus would
change Qtot correspondingly.

Den tor. 21. mar. 2019 kl. 22.11 skrev Mina Sedighi :

> Dear all,
>
>
> I solved SCF convergence problem by playing with SCF.Mixingweight and
> SCF.Mixing History. Now I have a problem with Qtot. I defined NetCharge
> flag to 0, but Mulliken atomic charges calculated by Siesta are wrong. Qtot
> in the system is 340! Oxygen atoms of water have positive charge of about
> 6. Zn2+ charge is about 11 and K+ charge is 0.1!! My .fdf commands are as
> follow:
>
>
> SystemName small
> SystemLabel small
> NumberOfAtoms 86
> NumberOfSpecies 6
> %block Chemical_Species_label
> 1 25 Mn
> 2 1 H
> 3 19 K
> 4 8 O
> 5 16 S
> 6 30 Zn
> %endblock Chemical_Species_label
> PAO.BasisType split
> PAO.BasisSize SZP
> PAO.EnergyShift 0.02 Ry
> MeshCutoff 200 Ry
> kgrid.Cutoff 3.655 Ang # half of the smallest lattice vector
> SCF.Mix Hamiltonian
> SCF.Mixer.Method Pulay
> MaxSCFIterations 1000
> SCF.H.Tolerance 2.d-3 eV
> SCF.Mixer.Weight 0.01
> SCF.Mixer.History 2
> ElectronicTemperature 300 K
> XC.Functional GGA
> XC.Authors PBE
> MD.TypeOfRun CG
> MD.NumCGsteps 200
> MD.MaxDispl 0.05 Ang
> MD.MaxForceTol 0.04 eV/Ang
> MD.VariableCell
> NetCharge 0
> %block Geometry.Constraints
> atom from 1 to 4
> %endblock Geometry.Constraints
>
> Can anyone guide me how I can solve this problem? Thank you so much.
>
>
> Regards,
>
> Mina
>


-- 
Kind regards Nick

Re: [SIESTA-L] Difference between PDOS in SIESTA vs TbTrans??

[Nick Papior]

Yes, there is a difference between the siesta and tbtrans.

Siesta is a fully periodic calculation.
TBtrans is a semi-infinite calculation where one or more directions are
replaced by bulk electrodes. Additionally, TBtrans allows non-equilibrium
calculations.

These two systems are not equivalent and thus one should not expect the
same PDOS.

As for the electrodes they are considered bulk so the PDOS calculated in
the corresponding electrode (siesta) calculation would be correct. What
changes is the PDOS in the scattering region (not bulk electrodes).

Den tir. 12. mar. 2019 kl. 22.21 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Hello!
> I was wondering what is the main difference between PDOS calculation in a
> SIESTA vs TbTrans run.
> If I have any molecule sandwiched between two gold electrodes, should the
> gold electrode's PDOS remain the same or not?
> Any further explanation would be appreciated and thank you!
> EL-Abed
>
>  El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group
>  | School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>

-- 
Kind regards Nick

Re: [SIESTA-L] TBTrans segfaults

[Nick Papior]

Could you please delete all TBTGF* files, and rerun the calculation?

Alternatively, see if increasing the eta value helps.

Den fre. 8. mar. 2019 kl. 22.02 skrev Day, Zacharie :

> Hello,
>
> A user on my cluster is trying to process something with Siesta 4.0.2
> TBTrans_rep. The process works up until this output:
>
>  ==
>   Projection Region: atoms : [ 183; 244]
>   Projection Region: states: [ 1639; 2172] Tot:  534
>  Reading GF file, with title:
>/home/rao/SIESTA/ODT/test/tbt/ODT-Au-1K.TBTGFL
>  Title: 'Generated GF file'
>
>  Reading GF file, with title:
>/home/rao/SIESTA/ODT/test/tbt/ODT-Au-1K.TBTGFR
>  Title: 'Generated GF file'
>
> # k-point: 1
> # k  = -0.026388,   0.026388,   0.00, w=   0.22
> # kb = -0.17,   0.17,   0.00, w=   0.22
> After this point, the program terminates after a short period with
> "Program received signal SIGSEGV, Segmentation fault." Furthermore, the
> issue occurs regardless of whether it's run alone or with MPI.
> GDB gives this:
>
> 0x005071fd in transmission (usebulk=@0x,
> nou=@0x2160f3c, hk=..., sk=...,
> nod=@0x6670216, nol=@0x6c00666, sfel=..., nor=@0x6c0, sfer=...,
> zenergy=@0xbfb2c0b552857fde, gf=..., gfrgf=..., tottrans=@0x0, tt=...,
> ierr=@0x0)
> at transmission.f90:94
> 94transmission.f90: No such file or directory.
> in transmission.f90
> I looked at transmission.f90 but I do not understand Siesta's code well
> enough to see any issues with line 94. Siesta is compiled on this cluster
> as follows:
>
> Siesta Version  : v4.0.2
> Architecture: intel-mkl
> Compiler version: ifort (IFORT) 13.0.1 20121010
> Compiler flags  : mpiifort -g -O0
> PP flags: -DFC_HAVE_FLUSH -DFC_HAVE_ABORT -DMPI
>
> I added the -O0 when I came across some mails suggesting that Intel's
> optimizations may be the culprit, however it would seem that that is not
> the case here. As I am entirely stuck on this issue, I would appreciate any
> assistance.
>
> --
> Zacharie Day
> Systems Analyst
> The George Washington University, SEAS Computing Facility
>


-- 
Kind regards Nick

Re: [SIESTA-L] Removing periodic boundary condition

[Nick Papior]

You can't, per see. :)

TranSiesta allows one to remove periodic boundary conditions by adding a
semi-infinite direction where a truly bulk semi-infinite electrode is
placed.

Siesta, however, intrinsically solves the potential in a periodic box.

Den tir. 26. feb. 2019 kl. 22.05 skrev Mina Sedighi :

> Dear all,
>
>
> How can I remove periodic boundary condition in siesta?
>
>
> Regards,
>
> Mina
>


-- 
Kind regards Nick

Re: [SIESTA-L] unit's physical dimensions don't match

[Nick Papior]

As the error message states:
One of your variables has unit eV but expects Ry/Bohr

This is your error: (a force is not eV, rather Ry/Bohr or its other
variants, eV/Ang)
MD.MaxForceTol 0.04 eV


Den man. 25. feb. 2019 kl. 22.01 skrev Mina Sedighi :

> Dear Siesta users and developers,
>
>
> I am performing a CG simulation on a battery system. at the first of
> simulation I receive the following error:
>
>
> ERROR
>
> FDF module: fdf_convfac:  unit's physical dimensions don't match: eV
>   , Ry/Bohr
>
> This is my .fdf parameters:
>
>
> SystemLabel batt_Without_G
> SystemName batt_control
>
> NumberOfSpecies  5
> NumberOfAtoms 2438
>
> %block ChemicalSpeciesLabel
> 1 25 Mn
> 2 8 O
> 3 1 H
> 4 30 Zn
> 5 16 S
> %endblock ChemicalSpeciesLabel
>
> PAO.BasisType split
> PAO.BasisSize DZP
> PAO.EnergyShift 0.01 RY
> MeshCutoff 400 Ry
> #kgrid.Cutoff 8.73 Ang # half of the smallest lattice vector
> SCF.Mix Hamiltonian
> SCF.Mixer.Method Pulay
> MaxSCFIterations 1
> SCF.H.Tolerance 1.d-3 ev
> SCF.Mixer.Weight 0.3
>
> ElectronicTemperature 300 K
>
> MD.TypeOfRun CG
> MD.Steps 1
> MD.MaxDispl 0.05 Ang
> MD.MaxForceTol 0.04 eV
> MD.UseSaveCG true
> MD.UseSaveXV true
>
> atom from 1 to 133
> LatticeConstant 1 Ang
> %block LatticeVectors
>  17.46 0.00 0.00
>  -10.00 17.3205080757 0.00
>  0.00 0.00 116.96
> %endblock LatticeVectors
>
> SystemLabel.STRUCT_OUT true
> SystemLabel.STRUCT_NEXT_ITER true
> LongOutput true
> WriteKpoints
> WriteKbands
> WriteCoorStep
> WriteForces
> WriteEigenvalues
> WriteWaveFunctions
> WriteMullikenPop 1
> WriteOrbMom
> SaveElectrostaticPotential
> SaveTotalPotential
>
> AtomicCoordinatesFormat Ang
>
> Please let me know what is wrong in my simulation. Thank you so much.
>
>
> Best regards,
>
> Mina
>
>

-- 
Kind regards Nick

Re: [SIESTA-L] Test shows "DIFFERENCE FOUND"

[Nick Papior]

Many of them *should* be very small. There are floating point round-off
errors which makes it very hard to reproduce exactly the same numbers.
So you should look at which quantities are un-equal, and if they are, are
they within a respectable difference.

Den man. 25. feb. 2019 kl. 22.03 skrev Andrés Lizano Villalobos <
lizanoandres...@gmail.com>:

> Dear Siesta users,
>
> I've compiled siesta using the arch.make file shown at the end of this
> message. When I ran the test available all of them show difference respect
> to the reference outputs in the Reference directory. Some of this appears
> to be small. I'll appreciate if someone can tell if this problem is caused
> by something in the compilation process or any information about it that
> can help.
>
>
> Thank you very much in advance.
>
>
>
> #arch.make#
> .SUFFIXES:
> .SUFFIXES: .f .F .o .c .a .f90 .F90
>
> SIESTA_ARCH = unknown
>
> CC = gcc
> FPP = $(FC) -E -P -x c
> FC = gfortran
> FC_SERIAL = gfortran
>
> FFLAGS = -O2 -fPIC -ftree-vectorize
>
> AR = ar
> RANLIB = ranlib
>
> SYS = nag
>
> SP_KIND = 4
> DP_KIND = 8
> KINDS = $(SP_KIND) $(DP_KIND)
>
> LDFLAGS =
>
> COMP_LIBS = libsiestaLAPACK.a libsiestaBLAS.a
>
> FPPFLAGS = $(DEFS_PREFIX)-DFC_HAVE_ABORT
>
>
> #LIBS = -L${MKLROOT}/lib/intel64 -Wl,--no-as-needed -lmkl_gf_ilp64
> -lmkl_sequential -lmkl_core -lpthread -lm -ldl
>
> FFLAGS += -fopenmp
> LIBS += -fopenmp
>
> # Dependency rules -
>
> FFLAGS_DEBUG = -g -O1   # your appropriate flags here...
>
> # The atom.f code is very vulnerable. Particularly the Intel compiler
> # will make an erroneous compilation of atom.f with high optimization
> # levels.
> atom.o: atom.F
> $(FC) -c $(FFLAGS_DEBUG) $(INCFLAGS) $(FPPFLAGS)
> $(FPPFLAGS_fixed_F) $<
>
> .c.o:
> $(CC) -c $(CFLAGS) $(INCFLAGS) $(CPPFLAGS) $<
> .F.o:
> $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_fixed_F)  $<
> .F90.o:
> $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_free_F90) $<
> .f.o:
> $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_fixed_f)  $<
> .f90.o:
> $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_free_f90)  $<
>
> ###
>


-- 
Kind regards Nick

Re: [SIESTA-L] Error in Cholesky factorisation in cdiag

[Nick Papior]

Then the problem is as I stated (see my last email).

Your atoms are too close.

Den ons. 20. feb. 2019 kl. 22.02 skrev Mina Sedighi :

> Dear Nick and Sullah,
>
>
> Thank you for your reply. My .fdf file commands are as follow:
>
>
> SystemLabel batt_str
> SystemName battery
> NumberOfSpecies  7
> NumberOfAtoms 4785
> %block ChemicalSpeciesLabel
> 1 7 N
> 2 6 C
> 3 8 O
> 4 1 H
> 5 16 S
> 6 30 Zn
> 7 25 Mn
> %endblock ChemicalSpeciesLabel
> PAO.BasisType split
> PAO.BasisSize DZP
> PAO.EnergyShift 0.01 RY
> MeshCutoff 500 Ry
> kgrid.Cutoff 8.73 Ang # half of the smallest lattice vector
> SCF.Mix Hamiltonian
> SCF.Mixer.Method Pulay
> MaxSCFIterations 1
> SCF.H.Tolerance 1.d-3 ev
> SCF.Mixer.Weight 0.3
> ElectronicTemperature 300 K
> MD.TypeOfRun CG
> MD.Steps 500
> MD.MaxDispl 0.05 Ang
> MD.MaxForceTol 0.04 ev/Ang
> atom from 4653 to 4785
> LatticeConstant 1 Ang
> %block LatticeVectors
>  17.46 0.00 0.00
>  -20.00 34.6410161514 0.00
>  0.00 0.00 116.96
> %endblock LatticeVectors
> SystemLabel.STRUCT_OUT true
> SystemLabel.STRUCT_NEXT_ITER true
> LongOutput true
> WriteKpoints
> WriteKbands
> WriteCoorStep
> WriteForces
> WriteEigenvalues
> WriteWaveFunctions
> WriteMullikenPop 1
> WriteOrbMom
> COOP.Write
> SaveElectrostaticPotential
> SaveTotalPotential
> AtomicCoordinatesFormat Ang
> %block  AtomicCoordinatesAndAtomicSpecies
> …
>
> …
>
> …
>
> %endblock  AtomicCoordinatesAndAtomicSpecies
>
>
> I perform this simulation on SHARCNET (Compute Canada) graham cluster with
> Siesta version 4.1-b3. Besides encountering the error that I mentioned in
> my last email, I receive the following warning for some atoms:
>
>
> siesta: WARNING: Atoms  "A"  "B" too close: rij =0.00 Ang
>
>
> Thank you for your advice.
>
>
> Best regards,
>
> Mina
> --
> *From:* siesta-l-requ...@uam.es  on behalf of
> Nick Papior 
> *Sent:* February 19, 2019 7:38:52 AM
> *To:* siesta-l
> *Subject:* Re: [SIESTA-L] Error in Cholesky factorisation in cdiag
>
> This may happen due to two atoms getting too close.
> Could you check your atomic coordinates at the given MD step?
>
> Den man. 18. feb. 2019 kl. 22.12 skrev Mina Sedighi  >:
>
>> Dear Siesta users,
>>
>>
>> I perform a parallel relaxation simulation with siesta version 4.1-b3 on
>> cluster. I face the following error during simulation:
>>
>>
>> Error in Cholesky factorisation in cdiag
>> Error in Cholesky factorisation in cdiag
>> Stopping Program from Node:  105
>> Stopping Program from Node:  105
>> --
>> MPI_ABORT was invoked on rank 105 in communicator MPI COMMUNICATOR 3
>> CREATE FROM 0
>> with errorcode 1.
>> NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
>> You may or may not see output from other processes, depending on
>> exactly when Open MPI kills them.
>>
>> Any help will be appreciated.
>>
>>
>> Best regards,
>>
>> Mina
>>
>
>
> --
> Kind regards Nick
>


-- 
Kind regards Nick

Re: [SIESTA-L] Error in Cholesky factorisation in cdiag

[Nick Papior]

This may happen due to two atoms getting too close.
Could you check your atomic coordinates at the given MD step?

Den man. 18. feb. 2019 kl. 22.12 skrev Mina Sedighi :

> Dear Siesta users,
>
>
> I perform a parallel relaxation simulation with siesta version 4.1-b3 on
> cluster. I face the following error during simulation:
>
>
> Error in Cholesky factorisation in cdiag
> Error in Cholesky factorisation in cdiag
> Stopping Program from Node:  105
> Stopping Program from Node:  105
> --
> MPI_ABORT was invoked on rank 105 in communicator MPI COMMUNICATOR 3
> CREATE FROM 0
> with errorcode 1.
> NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
> You may or may not see output from other processes, depending on
> exactly when Open MPI kills them.
>
> Any help will be appreciated.
>
>
> Best regards,
>
> Mina
>


-- 
Kind regards Nick

Re: [SIESTA-L] Error in TranSiesta

[Nick Papior]

Probably the electrode TSHS files are not present in the directory.
Please ensure you follow the correct steps of a transiesta calculation:
1) Calculate each of the electrodes with transiesta
2) Specify the electrode TSHS files in the device fdf file
3) Run the device system.

Den lør. 16. feb. 2019 kl. 22.02 skrev ziba torkashvand <
zitorkashv...@gmail.com>:

> Hello everybody,
> I've encountered a problem with the message ".TSHS File not found in
> TSiokp" while running transiesta even in running transiesta Tests. Any help
> in this regard would be appreciated.
>
> Cheers
> Ziba Torkashvand
>


-- 
Kind regards Nick

Re: [SIESTA-L] Graphene transmission dependence on unit cell size

[Nick Papior]

Dear Aleksandar,

This is not surprising, the referenced article does use the minimal
unit-cell for the fully periodic systems (3a and 3c). See the figure
text "Minimal unit-cells in the transverse transmission direction have been
used due to the periodicity.", it is also stated in the body text.

Hence your results are as expected and consistent with the article.


Den tir. 12. feb. 2019 kl. 22.07 skrev Aleksandar Tomovic <
atomo...@ipb.ac.rs>:

> Dear all,
>
> my question is related to graphene transmission calculation using
> transiesta (currently I'm using siesta 4.1b4).
>
> I tried to obtain transmission for graphene sheet using
> geometry given in Figure 3a
> (https://www.beilstein-journals.org/bjnano/articles/6/164)
> using the same set parameters. However while i get the correct shape of the
> curve, my
> transmission value is n times higher, where n would be be number of zigzag
> unit cells
> contained in the given graphene sheet.
> If I use single zigzag unit cell I am able to reproduce the correct result.
>
> My question would be, is there a problem with my siesta installation or is
> there
> a parameter that I am missing the would give correct value of transmission.
>
> If neither is the case, what is the implication of this when i want to
> calculate transmission
> of graphene gap with a molecule (when i need to use larger graphene sheet
> like
> the one from Figure 3a).
>
> Kind regards,
>
> Aleksandar
>


-- 
Kind regards Nick

Re: [SIESTA-L] Issue of writing WFSX file

[Nick Papior]

#WriteWaveFunctions .true.

is commented out. Remove the # and it should work. :)

Den man. 11. feb. 2019 kl. 22.19 skrev Xiaoning Zang <
xiaoning.z...@kaust.edu.sa>:

> Dear Siesta users,
>
> I need to get the real-space wave functions of molecules using denchar
> which requires the output file WFSX from SIESTA. However according to the
> manuscript I add the following to the input fdf file
> #setup for preparing files required by Denchar
> %block WaveFuncKPoints
>  0.000 0.000 0.000 from 1 to 2 #wave functions
> %endblock WaveFuncKPoints
> #COOP.Write .true. #this will give all wfs
> #WriteWaveFunctions .true.
> WriteDenchar .true.
>  but no WFSX is generated.
> I have been googling online and people are having this problem but did not
> find an solution to it so far. Does anyone know what is going on? is this
> an installation problem (how to compile)?
> Thank you very much for possible helps...
>
> Sincerely,
> Xiaoning
>
> Computational Physics & Materials Science
> Postdoc@KAUST
> Personal Web: https://xzang1990.wixsite.com/website
>
> --
> This message and its contents, including attachments are intended solely
> for the original recipient. If you are not the intended recipient or have
> received this message in error, please notify me immediately and delete
> this message from your computer system. Any unauthorized use or
> distribution is prohibited. Please consider the environment before printing
> this email.



-- 
Kind regards Nick

Re: [SIESTA-L] Structure got distorted after relaxation

[Nick Papior]

Since Siesta is a code using periodic boundary conditions any atomic
coordinate translated by a lattice vector is an equivalent system.
You can easily try this yourself by calculating two different structures
with one of them having a single atom displaced by a lattice vector.

Den ons. 6. feb. 2019 kl. 22.13 skrev Bibhas Manna :

> Dear SIESTA users,
>
> I am using SIESTA (4.1-b3) code for the relaxation of graphene-metal oxide
> interface structure. It has been seen that after few 'vc-relaxation'
> steps,  some atoms of the structure come outside the unit cell. Now, as I
> am continuing with the further simulation steps, it seems to me that these
> outside atoms may not get proper boundary/periodic conditions and results
> in a wrong converged *distorted structure*.
>
> Now I am bit confused as I don't know whether final relaxed structure is
> correct or not.
>
> I am very new to the SIESTA code. Could you please help me to clear my
> doubt?
>
> I am looking forward to hearing from you.
>
> Thanking you.
> With regards,
> Bibhas
>
>
>

-- 
Kind regards Nick

Re: [SIESTA-L] Segmentation fault In tbtrans run

[Nick Papior]

Could you please use Siesta 4.0 as that is the latest stable release, see
if that also seg-faults.

If you still see seg-faults you should try and compile siesta/tbtrans with
modified flags for debugging purposes, see here:
https://answers.launchpad.net/siesta/+faq/2779

Den ons. 6. feb. 2019 kl. 22.06 skrev Barnali Bhattacharya <
barnalidgbh...@gmail.com>:

> Dear Siesta Users
>
> I am using siesta-3.2 version ( intalled parallel using intel mkl libraries 
> and mpi libraries)for calculating I-V characteristics of some nanowires.
> The transiesta calculations finished successfully but when I am tring to run 
> the tbtrans calculations I get the following error.
> Even I have tried to run serially but the same segmentation fault occurs in 
> case of tbtrans calculations.
>  But the transiesta and tbtrans both are running for same input in an local 
> machine where  siesta-3.2 version is installed with gfortran.
>  The error I am getting is --
> .
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image  PCRoutineLineSource
> tbtrans0052C8A4  Unknown   Unknown  Unknown
> tbtrans004AC5A8  Unknown   Unknown  Unknown
> tbtrans004A9AC9  Unknown   Unknown  Unknown
> tbtrans0046CA39  Unknown   Unknown  Unknown
> tbtrans0043763B  Unknown   Unknown  Unknown
> tbtrans004351BD  Unknown   Unknown  Unknown
> tbtrans004597D5  Unknown   Unknown  Unknown
> tbtrans0040496C  Unknown   Unknown  Unknown
> libc.so.6  003FF541ECDD  Unknown   Unknown  Unknown
> tbtrans00404869  Unknown   Unknown  Unknown
> .
>
> Could anyone please help me in this regard?
> I am waiting for any suggestion.
> Thanking in advance
>
> Barnali Bhattacharya
> SENIOR RESEARCH FELLOW
> Department of Physics, Assam University
> Silchar-788011, India
>
>
>
>
> --
> Barnali Bhattacharya
> Ph. D student (CSIR SRF)
> Department of Physics
> Assam University, Silchar
>


-- 
Kind regards Nick

Re: [SIESTA-L] openmp

[Nick Papior]

In the Siesta 4.1 manual there is a clear description (Sec. 2.3.2) on how
to utilize hybrid MPI+OpenMP using OpenMPI.

For your architecture/cluster it may be different, I would advice you
contact your local HPC admin in that case.



Den tir. 5. feb. 2019 kl. 22.03 skrev 郑仁慧 :

> Dear Nick:
>  Thank you very much for your reply. I can not understand your
> explanation well. Would you like to give me an example using openmp or mpi?
> Thank you again for your kind help.
> Sincerely
> Ren-hui Zheng
>
>
>
>
>
>
> From: Nick Papior 
> Date: 2019-02-04 15:07:10
> To: siesta-l 
> Subject: Re: [SIESTA-L] openmp
>
> Dear Ren-hui Zheng,
>
> Siesta can benefit from MPI, OpenMP or both.
> The benefit may be briefly summarized as follows:
> MPI has distribution across orbitals, hence a basic advice is that you get
> performance scaling with # of cores == # of atoms (rule of thumb)
> OpenMP also distributes across orbitals, but on a finer level. Here you
> *may* get better scaling with more threads than atoms, however, generally I
> would still suspect the best performance scaling up to # of cores == # of
> atoms (rule of thumb).
>
> For the hybrid (MPI + OpenMP) the same thing applies, # of MPI-procs TIMES
> # of threads per MPI-proc == # of atoms should give you reasonable scaling.
>
> Again, these are rule-of-thumbs as it also depends on your basis etc.
> Note that OpenMP may be difficult to get correct scaling since affinity
> plays a big role. How you place threads depends on your architecture and I
> would advice you to do some benchmarks on your architecture to figure out
> how to do best OpenMP.
>
> Den søn. 3. feb. 2019 kl. 22.01 skrev 郑仁慧 :
>
>> Dear all:
>>Can the siesta improves calculation speed when it optimizes
>> molecular structure using openmp or mpi. When I  optimize molecular
>> structure with openmp or mpi, the calculation speed cannot be improved. I
>> don not know the reason. Would someone like to explain it? Thank you very
>> much for your help in advance.
>>
>> Sincerely
>> Ren-hui Zheng
>>
>>
>
> --
> Kind regards Nick
>
>
>

-- 
Kind regards Nick

Re: [SIESTA-L] << avoid SIESTA terminal ouput >>

[Nick Papior]

These messages are written to std-out and std-err.

Simply do:

siesta ... 2>/dev/null &

If you want to suppress those messages from stderr while running in the
background.

Den man. 4. feb. 2019 kl. 22.04 skrev I. Camps :

> Hi SIESTers,
>
> I would like to know how to avoid the output from SIESTA that is directed
> to the terminal window.
>
> After sending a calculation to run in background, I am getting message
> like these:
>
> Gamma-point calculation with multiply-connected orbital pairs
> Folding of H and S implicitly performed
>
> I am using siesta_4.1-b4. In previous versions and with the same system I
> did not get such messages.
>
> Regards,
>
> Camps
>


-- 
Kind regards Nick

Re: [SIESTA-L] openmp

[Nick Papior]

Dear Ren-hui Zheng,

Siesta can benefit from MPI, OpenMP or both.
The benefit may be briefly summarized as follows:
MPI has distribution across orbitals, hence a basic advice is that you get
performance scaling with # of cores == # of atoms (rule of thumb)
OpenMP also distributes across orbitals, but on a finer level. Here you
*may* get better scaling with more threads than atoms, however, generally I
would still suspect the best performance scaling up to # of cores == # of
atoms (rule of thumb).

For the hybrid (MPI + OpenMP) the same thing applies, # of MPI-procs TIMES
# of threads per MPI-proc == # of atoms should give you reasonable scaling.

Again, these are rule-of-thumbs as it also depends on your basis etc.
Note that OpenMP may be difficult to get correct scaling since affinity
plays a big role. How you place threads depends on your architecture and I
would advice you to do some benchmarks on your architecture to figure out
how to do best OpenMP.

Den søn. 3. feb. 2019 kl. 22.01 skrev 郑仁慧 :

> Dear all:
>Can the siesta improves calculation speed when it optimizes
> molecular structure using openmp or mpi. When I  optimize molecular
> structure with openmp or mpi, the calculation speed cannot be improved. I
> don not know the reason. Would someone like to explain it? Thank you very
> much for your help in advance.
>
> Sincerely
> Ren-hui Zheng
>
>

-- 
Kind regards Nick

Re: [SIESTA-L] rigid | molecule command

[Nick Papior]

In 4.0:
This would require you to implement this your self in the constr.f file,
then recompile siesta.

In 4.1:
There is no easy way, you have to do one line per molecule.
Note however, that the "rigid/molecule" flag only forces uniform
translation. I.e. the molecules are *not* allowed to rotate using the
current implementation.

Den fre. 25. jan. 2019 kl. 22.04 skrev Mina Sedighi :

> Dear Nick,
>
>
> Thank you for your reply. In my case there are several water molecules
> (more than 100) and it is difficult to define rigid | molecule in this way.
> How can I apply this command for all involved molecules?
>
>
> Best,
>
> Mina
> --
> *From:* siesta-l-requ...@uam.es  on behalf of
> Nick Papior 
> *Sent:* January 23, 2019 5:13:06 PM
> *To:* siesta-l
> *Subject:* Re: [SIESTA-L] rigid | molecule command
>
> Note this is only implemented in the 4.1-beta releases.
>
> The rigid specification goes in the Geometry.Constraint block:
>
> %block Geometry.Constraints
>   rigid [1 -- 3]
>   rigid [4 -- 10]
> %endblock
>
> "average" the force on atoms 1-3 and move 1-3 equivalently.
> "average" the force on atoms 4-10 and move 4-10 equivalently.
>
> For further details, please see the manual.
>
>
> Den ons. 23. jan. 2019 kl. 22.04 skrev Mina Sedighi  >:
>
>> Hello everyone,
>>
>>
>> I have a system containing water molecules in which two kind of salts
>> (ions) have been solved. I want to consider water and SO42- molecules rigid
>> during relaxation process. In this regard, how can I use "rigid | molecule"
>> command?
>>
>> Any help will be appreciated.
>>
>>
>> Regards,
>>
>> Mina
>>
>
>
> --
> Kind regards Nick
>


-- 
Kind regards Nick

Re: [SIESTA-L] rigid | molecule command

[Nick Papior]

Note this is only implemented in the 4.1-beta releases.

The rigid specification goes in the Geometry.Constraint block:

%block Geometry.Constraints
  rigid [1 -- 3]
  rigid [4 -- 10]
%endblock

"average" the force on atoms 1-3 and move 1-3 equivalently.
"average" the force on atoms 4-10 and move 4-10 equivalently.

For further details, please see the manual.


Den ons. 23. jan. 2019 kl. 22.04 skrev Mina Sedighi :

> Hello everyone,
>
>
> I have a system containing water molecules in which two kind of salts
> (ions) have been solved. I want to consider water and SO42- molecules rigid
> during relaxation process. In this regard, how can I use "rigid | molecule"
> command?
>
> Any help will be appreciated.
>
>
> Regards,
>
> Mina
>


-- 
Kind regards Nick