Re: [SIESTA-L] << SIESTA workflows systems >>

[Nick Papior]

Hi Camps,

I answered this here:
https://urldefense.com/v3/__https://mattermodeling.stackexchange.com/questions/12525/better-siesta-workflows-system__;!!D9dNQwwGXtA!RWrxZFGKJWOZ8ctQOqm5xNu4uLBq4jJbEsHb4oO6F3frBvWox134brbqZH3Oztkn93T9SXQa-Ke3uiBrgw$
 

Thanks!

Den ons. 6. mar. 2024 kl. 22.00 skrev I. Camps :

> Hello,
>
> Normally, I run all my SIESTA calculations manually and then go to
> post-processing the results, also manually.
>
> I would like to know which of the tools below is "better" (more complete?)
> in order to make a more efficient use of time when using SIESTA.
>
>- Atomic Simulation Environment (
>
> https://urldefense.com/v3/__https://wiki.fysik.dtu.dk/ase/index.html__;!!D9dNQwwGXtA!RWrxZFGKJWOZ8ctQOqm5xNu4uLBq4jJbEsHb4oO6F3frBvWox134brbqZH3Oztkn93T9SXQa-Ke0vufSOQ$
>  
>
> 
>)
>- AiiDA 
> (https://urldefense.com/v3/__https://www.aiida.net/index.html__;!!D9dNQwwGXtA!RWrxZFGKJWOZ8ctQOqm5xNu4uLBq4jJbEsHb4oO6F3frBvWox134brbqZH3Oztkn93T9SXQa-KdPAFe12g$
>  
>
> 
>)
>- SISL 
> (https://urldefense.com/v3/__https://zerothi.github.io/sisl/__;!!D9dNQwwGXtA!RWrxZFGKJWOZ8ctQOqm5xNu4uLBq4jJbEsHb4oO6F3frBvWox134brbqZH3Oztkn93T9SXQa-KdwM-ODQg$
>  
>
> 
>)
>
>
> []'s,
> Camps
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!RWrxZFGKJWOZ8ctQOqm5xNu4uLBq4jJbEsHb4oO6F3frBvWox134brbqZH3Oztkn93T9SXQa-KfaKOAk3w$
>  )
>


-- 
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] Grimm parameters

[Nick Papior]

Hi,

I don't see a problem, I think you misinterpret what the numbers should be?
The values are the sum of atomic vdW radii. Please see discussion in Grimme
paper ~ Eq. 12. So it looks correct, no?

Thanks.

/ Nick

Den fre. 15. dec. 2023 kl. 22.00 skrev Reza Behjatmanesh-Ardakani <
reza_b_...@yahoo.com>:

> Hi
> I used "Grimme" code in the "Utils" directory to see the Grimme
> parameters.  I got the following results for a molecule on TiO2:
>
> =
> MM.UnitsDistance Ang  # what this program prints out DO NOT CHANGE
> MM.UnitsEnergyeV  # what this program prints out DO NOT CHANGE
> MM.Grimme.S6 0.75 # Grimme-paper for PBE (correct for your functional)
> MM.Grimme.D 20.   # Grimme-paper (correct for your functional)
> %block MM.Potentials
> *  1   1 Grimme111.94  3.124 # Ti, 10.1002/jcc.20495*
>   1   2 Grimme 28.50  2.904 # Ti / O
>   1   3 Grimme 45.06  3.014 # Ti / C
>   1   4 Grimme 76.69  3.201 # Ti / Cl
>   1   5 Grimme 12.74  2.563 # Ti / H
> *  2   2 Grimme  7.26  2.684 # O, 10.1002/jcc.20495*
>   2   3 Grimme 11.47  2.794 # O / C
>   2   4 Grimme 19.53  2.981 # O / Cl
>   2   5 Grimme  3.24  2.343 # O / H
>   3   3 Grimme 18.14  2.904 # C, 10.1002/jcc.20495
>   3   4 Grimme 30.87  3.091 # C / Cl
>   3   5 Grimme  5.13  2.453 # C / H
>   4   4 Grimme 52.55  3.278 # Cl, 10.1002/jcc.20495
>   4   5 Grimme  8.73  2.640 # Cl / H
>   5   5 Grimme  1.45  2.002 # H, 10.1002/jcc.20495
> %endblock MM.Potentials
> ==
>
> I checked the reference of  DOI: 10.1002/jcc.20495 for O and Ti atoms.
>
> I found that the R0 for the O atom is 1.324 A in the paper, but the above
> code shows 2.684 A.
> For the Ti atom, the paper shows 1.562 A, while the code shows 3.124 A.
> I supposed that these R0 data are in Bohr, and convert them to Angstrom:
> for O: 1.42 A
> for Ti: 1.65 A
> which again both are incorrect.
>
> Please correct the Grimme code in Utils.
>
> Thanks
>
> With the Best Regards
> *Reza *
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!S9P09VHly-w_rxj2KobbEaEaJ3xhfhmVwA2_p1DWgWYlBnLObDbJLYtMVPAEGTgFtvUJjfrOLOHmzJHyjQ$
>  )
>


-- 
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 fatbands / building utilities in 5.0

[Nick Papior]

Hi Daniel,

Could you open an issue on our gitlab repository with an associated test?
That would be immensely helpful! Thanks!

Den ons. 25. okt. 2023 kl. 22.00 skrev Daniel Bennett :

> Thanks Alberto. I didn't know that cmake builds the utilities by default,
> very convenient! I was looking in siesta/Util instead of siesta/build/Util
>
> I ran the fat program from siesta 5.0, and I am getting the message:
>
> unknown HSX file version [0, 1]
>
> but I ran the calculations with the same version of siesta. I tried
> getting the *.HSX file with both COOP.Write true and Save-HS true in
> separate calculations and got the same error. Is there another way to get
> the *.HSX file?
>
>
> --
> *From:* siesta-l-requ...@uam.es  on behalf of
> Alberto Garcia 
> *Sent:* 24 October 2023 03:20
> *To:* siesta-l@uam.es 
> *Subject:* Re: [SIESTA-L] Siesta fatbands / building utilities in 5.0
>
> Hi Daniel,
>
> In Siesta 5.0 the CMake system builds all the utilities by default. If you
> install the package after building they will all be in the
> /path/to/installation/bin
> directory, together with the siesta executable itself.  If you do not
> install, they will be in _build/Util/, where _build stands for the
> CMake build directory and  for the appropriate subdirectory in the Util
> hierarchy.
>
> The build_all.sh script is a fossil we forgot to remove…
>
> If you used an old version of ‘fat’, the format of the HSX file might have
> changed. Please use the latest version.
>
>   Alberto
>
>
>
>
>
> On 20 Oct 2023, at 21:56, Daniel Bennett  wrote:
>
> Hi all,
>
> I'm trying to run a simple calculation of the fat bands, using the latest
> siesta version 5.0. I compiled with cmake and noticed that the build_all.sh
> script still uses the arch.make file, does anybody know how to build the
> utilities with 5.0 if using cmake to build siesta?
>
> Anyway, I'm using an older version of siesta util/COOP/fat. Attached is a
> simple example of graphene, I'm trying to get the fatbands for the p_z
> orbitals. I run
>
> ln -s Graphene.bands.WFSX Graphene.WFSX
> /path/to/util/COOP/fat fatbands
>
> And the output is
>
> Reading wf file: Graphene.WFSX
>  Minimum/Maximum number of wfs per k-point:26   26
> Min_eigval, max_eigval on WFS file: -23.7976191.4211
> Min_eigval, max_eigval in band set : -23.7976191.4211
> Band set used: (min, max):   1  26
>  Graphene.HSX nnao, no_s, nspin, nh:   1   0   0
> 0
> nnao, no_s...
>
> It seems to stop short of writing the EIGFAT files.
>
> Can anyone advise? I tried following both this (old) and this (newer),
> but always get the same thing. Also any advice on building the utilities
> with siesta 5.0 appreciated too
>
> Thanks,
>
> Daniel Bennett
> 
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (
> https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!QI4qwP-wiDpydqflVwrSkysOntWyR5FS9_AHJq0WaTFZGIQGK6v79-PoUS7xjbU6AHVjNu4GqF977sUH4g$
>  )
>
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!VUsPavKDODI2izsA1Li8LOL6jalW7ePRdUbhVlnIzXYrV6f1JwhT6aNEyXuUSZZ2Ymy1AyvJ07NwtVOmPw$
>  )
>


-- 
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] 3 Terminal STM device.

[Nick Papior]

No transfer matrix generally happens when you do electrode runs without
k-points, or if you are using a vacuum region along the semi-infinite
direction (which is clearly wrong).

Try and figure out these two conditions for your input files.

Den tors. 28. sep. 2023 kl. 22.00 skrev Mohammed Ghadiyali <
mohammed.ghadiy...@kaust.edu.sa>:

> Hello,
>
> I’m trying to reproduce the calculations form paper “Control of the local
> magnetic states in graphene with voltage and gating”, it has three terminal
> STM device I’m getting following error:
>
> Electrode el-1 has no transfer matrix.
> The self-energy cannot be calculated with a zero transfer matrix!
> Elec: transfer matrix has 0 elements. The self-energy cannot be
> calculated. Please check your electrode electronic structure.
>
> Form the pervious forum post it could be due to two reasons:
>
>1. Missing periodic boundary condition
>2. Incorrect semi-inf-direction
>
> I’ve checked both and it’s still giving me the error.
> I’ve used the "-fdf TS.Analyze” for getting the pivoting scheme, it runs
> and prints that the electrodes are perfect.
>
> I’ve attached the inputs of the electrodes and scattering region, as well
> as the output of the scattering region with the error.
>
> PS. As I'm testing, I’m not using the magnetic moment to save cost and
> time.
>
> Regards,
> Ghadiyali Mohammed Kader
> Post Doctoral Fellow
> King Abdullah University of Science and Technology
>
> --
> 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.
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!Sn69R-oiAl1xdIb8Vk3x8f2oUaHeGqY_jTnIfZpUxhuIWJ0WrpSx6SyYFyDesXe15vBDC9kdKLTaQOd9qQ$
>  )
>


-- 
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 tselecs.sh

[Nick Papior]

Thanks for reporting.

You should be able to download a working script from here:
https://urldefense.com/v3/__https://gitlab.com/siesta-project/siesta/-/raw/ec17c43607c75741701766fc360a01dc9b471692/Util/TS/tselecs.sh?inline=false__;!!D9dNQwwGXtA!R7LzVg_Ad7zuUrs0lizbVzH71PZlK4YS6F2IkTSpOdkDvRQc3YtI_nLUFWd-Ksc4DpIFwNp2xcd3W9P1oA$
 

It should be available in the next siesta release. Thanks!

Den ons. 13. sep. 2023 kl. 22.01 skrev Mohammed Ghadiyali <
mohammed.ghadiy...@kaust.edu.sa>:

> Hello,
>
> I’m trying to use the utility tselecs.sh, howerve it is giving following
> error “Unknown option”, even if I use the given example
>
> ./tselecs.sh -2 -el3 name=Top,mu=Left,inf-dir=+a2,end-pos=-1
>
> Regards,
> Ghadiyali Mohammed Kader
> Post Doctoral Fellow
> King Abdullah University of Science and Technology
>
> --
> 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.
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!R7LzVg_Ad7zuUrs0lizbVzH71PZlK4YS6F2IkTSpOdkDvRQc3YtI_nLUFWd-Ksc4DpIFwNp2xccj8RjXSQ$
>  )
>


-- 
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] ***SPAM*** Re: ***SPAM*** Re: Question about Gate (Infinite plane) in SIESTA

[Nick Papior]

The message from y...@rice.edu was correct.

Whether the arrow starts at the intersection point or not, will not change
the vector.
The intersection point has a unit.
But the vector direction is determined as yh46 says. Starting at 0, 0, 0
with the direction of the last vector coordinates as given. Unitless, by
definition

Den fre. 1. sep. 2023 kl. 22.00 skrev 肖威 :

> Hello, Yuefei Huang
>
> From Papior's reply, I think the normal vector starts at (1.0 1.0 1.0) and
> ends at (1.0 0.5 0.2). Please refer to the correspondence between Nick
> Papior and me.
>
> Now my understanding for (Gate, Infinite plane) is as follows:
>
>- When determining the direction of the normal vector, the coordinate
>system and point (1.0 1.0 1.0) and point (1.0 0.5 0.2) have no units.
>- When determining the intersection points in the plane, the unit of
>point (1.0 1.0 1.0)  is Ang.
>
>
> I sincerely invite Nick Papior to comment on the above. Many thanks.
>
> Example of (Infinite plane):
> %block Geometry.Hartree
> plane 1. eV # The lifting potential on the geometry
> delta
> 1.0 1.0 1.0 Ang# An intersection point, in the plane
> 1.0 0.5 0.2# The normal vector to the plane
> %endblock Geometry.Hartree
>
> 肖威
> xiaowei951...@163.com
>
> <https://urldefense.com/v3/__https://dashi.163.com/projects/signature-manager/detail/index.html?ftlId=1=**E=xiaowei951020*40163.com=https*3A*2F*2Fmail-online.nosdn.127.net*2Fqiyelogo*2FdefaultAvatar.png=*5B*22xiaowei951020*40163.com*22*5D__;6IKW5aiBJSUlJSUlJSUlJSU!!D9dNQwwGXtA!QJE7m5jLqhlIUxQ3cUJUVfPUq4gmfp-PANjZdaBrw6Regb7NzfLExWoIZBrwGXI0WQy0XJO4_X-iqiCdQRjP7Q$>
>  Replied Message 
> From yh46 
> Date 8/29/2023 04:00
> To  
> Subject Re: [SIESTA-L] ***SPAM*** Re: ***SPAM*** Re: Question about Gate
> (Infinite plane) in SIESTA
> Wei,
> The normal vector in this case is just (1.0, 0.5, 0.2). There is
> nothing to do with the line "1.0   1.0   1.0   Ang".
>
> If you still don't understand, the starting point of your vector is
> (0, 0, 0), and the end point of the vector is (1.0, 0.5, 0.2). So no
> unit is needed.
>
>
> Quoting 肖威 :
>
> Dear Nick Papior,
>
>
> Please give me some more guidance on the direction of the plane's
> normal vector. (Gate, Infinite plane)
>
>
>
> Many thanks.
> Wei
> | |
> 肖威
> |
> |
> xiaowei951...@163.com
> |
>  Replied Message 
> | From | Nick Papior |
> | Date | 8/27/2023 04:00 |
> | To | siesta-l |
> | Subject | Re: [SIESTA-L] ***SPAM*** Re: ***SPAM*** Re: Question
> about Gate (Infinite plane) in SIESTA |
> Your understanding is wrong, it is not inserted into the box before
> determining the direction.
>
>
> It is a direction first.
>
>
> On Fri, 25 Aug 2023, 22:00 肖威,  wrote:
>
> Dear Nick Papior,
>
>
> Here is an example of the use of (Infinite plane) in the SIESTA
> 4.1.5 manual (Page 105) :
> %block Geometry.Hartree
> plane 1. eV  # The lifting potential on the geometry
> delta
> 1.0   1.0   1.0   Ang  # An intersection point, in the plane
> 1.0   0.5   0.2# The normal vector to the plane
> %endblock Geometry.Hartree
>
>
> As shown in the example above, [(1.0   1.0   1.0 ) Ang] is the
> starting point of the normal vector and its unit is Ang.Assuming 1.0
> Bohr = 0.5 Angstrom (Ang), then the end point of the normal vector
> (1.0  0.5  0.2) in Ang and Bohr gives different point positions M
> and N, respectively, and ultimately leads to different normal vector
> directions n1 and n2 (see diagram below,same as the attachment). So
> I can't determine the spatial position of the (Infinite plane).
>
> Please kindly point out if my understanding is wrong.
>
>
>
>
>
>
> Thank you very much!
>
>
> Wei
>
>
>
>
>
>
> | |
> 肖威
> |
> |
> xiaowei951...@163.com
> |
>  Replied Message 
> | From | Nick Papior |
> | Date | 8/25/2023 04:00 |
> | To | siesta-l |
> | Subject | [SIESTA-L] ***SPAM*** Re: ***SPAM*** Re: Question about
> Gate (Infinite plane) in SIESTA |
> Hi,
> I understand that you want to know if the normal vector is in ang or Bohr.
>
>
> But, a normal vector is, by definition, unit less. It is a
> direction, nothing more.
> Once siesta has read in the vector, it will normalise it to unit length.
>
>
> On Wed, 23 Aug 2023, 22:00 肖威,  wrote:
>
> Dear Nick Papior,
>
>
> Take the blue font below for example:
> The normal vector consists of two points, pointing from (1.0   1.0
> 1.0) to (1.0   0.5   0.2). What I want to ask is whether the unit of
> (1.0   0.5   0.2) is Ang.
>
>
> Here is an example of the use of (Infinite plane) in t

Re: [SIESTA-L] ***SPAM*** Re: ***SPAM*** Re: Question about Gate (Infinite plane) in SIESTA

[Nick Papior]

The specification is done in a unit less box.
I don't know what else to say... Others, feel free to chip in.


On Sun, 27 Aug 2023, 22:00 肖威,  wrote:

> Dear Nick Papior,
>
> Please give me some more guidance on the direction of the plane's normal
> vector. (Gate, Infinite plane)
>
> Many thanks.
> Wei
> 肖威
> xiaowei951...@163.com
>
> <https://urldefense.com/v3/__https://dashi.163.com/projects/signature-manager/detail/index.html?ftlId=1=**E=xiaowei951020*40163.com=https*3A*2F*2Fmail-online.nosdn.127.net*2Fqiyelogo*2FdefaultAvatar.png=*5B*22xiaowei951020*40163.com*22*5D__;6IKW5aiBJSUlJSUlJSUlJSU!!D9dNQwwGXtA!URpSF7zEPUo2pgnDAu-R8G2ylzEB4WJvVMj6ieteqAMMZPkxWDoJvxO4K0mmRZZT9CKicYpb-gKpQV9QpZ8gtg$>
> ---- Replied Message 
> From Nick Papior 
> Date 8/27/2023 04:00
> To siesta-l 
> Subject Re: [SIESTA-L] ***SPAM*** Re: ***SPAM*** Re: Question about Gate
> (Infinite plane) in SIESTA
> Your understanding is wrong, it is not inserted into the box before
> determining the direction.
>
> It is a direction first.
>
> On Fri, 25 Aug 2023, 22:00 肖威,  wrote:
>
>> Dear Nick Papior,
>>
>> Here is an example of the use of (Infinite plane) in the SIESTA 4.1.5
>> manual (Page 105) :
>> %block Geometry.Hartree
>> plane 1. eV  # The lifting potential on the geometry
>> delta
>> 1.0   1.0   1.0   Ang  # An intersection point, in the plane
>> 1.0   0.5   0.2# The normal vector to the plane
>> %endblock Geometry.Hartree
>>
>> As shown in the example above, [(1.0   1.0   1.0 ) Ang] is the starting
>> point of the normal vector and its unit is Ang. Assuming 1.0 Bohr = 0.5
>> Angstrom (Ang), then the end point of the normal vector (1.0  0.5  0.2)
>> in Ang and Bohr gives different point positions *M* and *N*,
>> respectively, and ultimately leads to different normal vector directions
>> *n*1 and *n*2 (see diagram below, same as the attachment). So I can't
>> determine the spatial position of the (Infinite plane).
>>
>> Please kindly point out if my understanding is wrong.
>>
>>
>>
>> Thank you very much!
>>
>> Wei
>>
>>
>>
>> 肖威
>> xiaowei951...@163.com
>>
>> <https://urldefense.com/v3/__https://dashi.163.com/projects/signature-manager/detail/index.html?ftlId=1=**E=xiaowei951020*40163.com=https*3A*2F*2Fmail-online.nosdn.127.net*2Fqiyelogo*2FdefaultAvatar.png=*5B*22xiaowei951020*40163.com*22*5D__;6IKW5aiBJSUlJSUlJSUlJSU!!D9dNQwwGXtA!VFQgeaV15IKXua_zRoesnR7rsdevDVKZKQknv-TE8-HYY-5QFHZhg4xOux4tlej4xq7sVSgd2BXFSC9LGgKb-w$>
>>  Replied Message 
>> From Nick Papior 
>> Date 8/25/2023 04:00
>> To siesta-l 
>> Subject [SIESTA-L] ***SPAM*** Re: ***SPAM*** Re: Question about Gate
>> (Infinite plane) in SIESTA
>> Hi,
>> I understand that you want to know if the normal vector is in ang or
>> Bohr.
>>
>> But, a normal vector is, by definition, unit less. It is a direction,
>> nothing more.
>> Once siesta has read in the vector, it will normalise it to unit length.
>>
>> On Wed, 23 Aug 2023, 22:00 肖威,  wrote:
>>
>>> Dear Nick Papior,
>>>
>>> Take the blue font below for example:
>>> The normal vector consists of two points, pointing from (1.0   1.0
>>> 1.0) to (1.0   0.5   0.2). What I want to ask is whether the unit of  (1.0
>>>   0.5   0.2) is Ang.
>>>
>>> Here is an example of the use of (Infinite plane) in the SIESTA 4.1.5
>>> manual (Page 101):
>>> %block Geometry.Hartree
>>> plane 1. eV  # The lifting potential on the geometry
>>> delta
>>> 1.0   1.0   1.0   Ang  # An intersection point, in the plane
>>> 1.0   0.5   0.2# The normal vector to the plane
>>> %endblock Geometry.Hartree
>>>
>>> Thank you very much!
>>> Wei
>>>
>>>
>>> 肖威
>>> xiaowei951...@163.com
>>>
>>> <https://urldefense.com/v3/__https://dashi.163.com/projects/signature-manager/detail/index.html?ftlId=1=**E=xiaowei951020*40163.com=https*3A*2F*2Fmail-online.nosdn.127.net*2Fqiyelogo*2FdefaultAvatar.png=*5B*22xiaowei951020*40163.com*22*5D__;6IKW5aiBJSUlJSUlJSUlJSU!!D9dNQwwGXtA!X3APsp0SY6XOonK2EDMii3S20GGPWca2WF43qXZGk2cw86KZN-bZgk05od2AIY7P_7UhmSNmF1716nm4Oyl9oA$>
>>>  Replied Message 
>>> From Nick Papior 
>>> Date 8/10/2023 04:00
>>> To  
>>> Subject [SIESTA-L] ***SPAM*** Re: Question about Gate (Infinite plane)
>>> in SIESTA
>>> Hi,
>>>
>>> 1. Yes, a plane is defined by a point in the plane, a

Re: [SIESTA-L] Compiling siesta 4.1.5b, problem with libfdf

[Nick Papior]

Hi,

4.1.5b does not contain the psml stuff.. So I am not fully sure what you
mean?

Secondly,
- if you want a stable release, use 4.1.5, this does NOT contain PSML.
- if you want psml support, download the latest 'master' commit at
gitlab.com/siesta-project/siesta

Den tors. 24. aug. 2023 kl. 22.00 skrev Daniel Bennett :

> Hi all,
>
> I am trying to compile siesta 4.1.5b manually and am having some problems.
> (I was previously using the psml version, but psml support is now in the
> main branch so I want to upgrade)
>
> The build process is a little different, requiring an explicit build of
> libfdf. I downloaded and compiled libfdf with the same compilers and
> modules as I use for the siesta build, but when I try to build siesta, it
> can't seem to find libfdf. arch.make file and a log file for make are
> attached. I tried setting FDF_ROOT to /path/to/libfdf as well as
> /path/to/libfdf/lib/pkgconfig, which is where the libfdf.pc file is
> located. Neither of these worked for me.
>
> Has anyone else had similar problems? Any advice greatly appreciated.
>
> Thanks,
>
> Daniel Bennett
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!QNYgtRVBdTms0eegc1QBISe8IP7G12h9jf2gBR_fBZ_Aqb_JZ3UPJs1vCcnNLiGBJRW8vElNYd4jAZwiFA$
>  )
>


-- 
Kind regards Nick

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

[SIESTA-L] ***SPAM*** Re: ***SPAM*** Re: Question about Gate (Infinite plane) in SIESTA

[Nick Papior]

Hi,
I understand that you want to know if the normal vector is in ang or Bohr.

But, a normal vector is, by definition, unit less. It is a direction,
nothing more.
Once siesta has read in the vector, it will normalise it to unit length.

On Wed, 23 Aug 2023, 22:00 肖威,  wrote:

> Dear Nick Papior,
>
> Take the blue font below for example:
> The normal vector consists of two points, pointing from (1.0   1.0   1.0)
> to (1.0   0.5   0.2). What I want to ask is whether the unit of  (1.0
> 0.5   0.2) is Ang.
>
> Here is an example of the use of (Infinite plane) in the SIESTA 4.1.5
> manual (Page 101):
> %block Geometry.Hartree
> plane 1. eV  # The lifting potential on the geometry
> delta
> 1.0   1.0   1.0   Ang  # An intersection point, in the plane
> 1.0   0.5   0.2# The normal vector to the plane
> %endblock Geometry.Hartree
>
> Thank you very much!
> Wei
>
>
> 肖威
> xiaowei951...@163.com
>
> <https://urldefense.com/v3/__https://dashi.163.com/projects/signature-manager/detail/index.html?ftlId=1=**E=xiaowei951020*40163.com=https*3A*2F*2Fmail-online.nosdn.127.net*2Fqiyelogo*2FdefaultAvatar.png=*5B*22xiaowei951020*40163.com*22*5D__;6IKW5aiBJSUlJSUlJSUlJSU!!D9dNQwwGXtA!X3APsp0SY6XOonK2EDMii3S20GGPWca2WF43qXZGk2cw86KZN-bZgk05od2AIY7P_7UhmSNmF1716nm4Oyl9oA$>
>  Replied Message 
> From Nick Papior 
> Date 8/10/2023 04:00
> To  
> Subject [SIESTA-L] ***SPAM*** Re: Question about Gate (Infinite plane) in
> SIESTA
> Hi,
>
> 1. Yes, a plane is defined by a point in the plane, and a normal vector,
> nothing else is needed.
> 2. A normal vector needs no units, it is a vector describing direction,
> not distance. Hence no unit is required.
> 3. Please use 4.1.5 (check the gitlab hosting site for the latest
> release), do not use 4.1-b4.
>
> Den tirs. 8. aug. 2023 kl. 22.00 skrev 肖威 :
>
>> Dear SIESTA developers and users,
>>
>> Here is an example of the use of (Infinite plane) in the SIESTA 4.1-b4
>> manual (Page 101):
>>
>> %block Geometry.Hartree
>> plane 1. eV  # The lifting potential on the geometry
>> delta
>> 1.0   1.0   1.0   Ang  # An intersection point, in the plane
>> 1.0   0.5   0.2# The normal vector to the plane
>> %endblock Geometry.Hartree
>>
>> I have two questions about the above example:
>> 1, Does the normal vector start at (1.0   1.0   1.0) and end at (1.0
>> 0.5   0.2) ?
>> 2, The unit of coordinate (1.0   0.5   0.2) is not marked, is it Ang ?
>>
>> I'm really looking forward to some help.
>>
>> Thank you very much!
>>
>> Wei
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 肖威
>> xiaowei951...@163.com
>>
>> <https://urldefense.com/v3/__https://dashi.163.com/projects/signature-manager/detail/index.html?ftlId=1=**E=xiaowei951020*40163.com=https*3A*2F*2Fmail-online.nosdn.127.net*2Fqiyelogo*2FdefaultAvatar.png=*5B*22xiaowei951020*40163.com*22*5D__;6IKW5aiBJSUlJSUlJSUlJSU!!D9dNQwwGXtA!XtcB5cnvnut0f-GSXNjOU06txE4U6qlwKdryLpHu-Py2F6cpG1AAmVSVTkfHoKS6_7mnI1q6fDNdnq4iZD-8zw$>
>>
>> --
>> SIESTA is supported by the Spanish Research Agency (AEI) and by the
>> European H2020 MaX Centre of Excellence 
>> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!UOa65RD3GZxBZZUcwXOkxuudk5V1A4b_er85agHrZToJczDLPBt_sJ1t0bPR2llKSRPsH70dCVXPAnm45g$
>>  
>> <https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!TTj_HNxltCl3ezM3mCK0ZlEqBsrhmBQXmMAF0HrMX1kzpH5HJLBlOyUA0tVY1XnMZPJ9NEagiJqxsYn9XA$>
>> )
>>
>
>
> --
> Kind regards Nick
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!UOa65RD3GZxBZZUcwXOkxuudk5V1A4b_er85agHrZToJczDLPBt_sJ1t0bPR2llKSRPsH70dCVXPAnm45g$
>  )
>

-- 
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] Transmission Spectrum

[Nick Papior]

It is hard to know what went wrong.

But!
You seem to be mixing old flags (pre 4.1) and new flags (4.1 and newer).
As far as I remember LDA+U was first introduced in 4.1. And your TS options
are for 4.0 or older.

Please double check your output whether all your options are correct, this
is vital.

Den lør. 19. aug. 2023 kl. 22.01 skrev Fazle Subhan :

> Dear Siesta Users,
> Hope you all will be fine, I have a problem in TBT.Trans calculations.
> Although I use this software in many articles now it is a ferromagnetic
> system with GGA+U I want to calculate the transmission spectrum at zero
> bias. Although, the calculations run smoothly and I hope correctly but when
> I plot the transmission spectrum it was weird. Therefore, I am sending you
> the RUN,fdf, and transmission spectrum files and the plotted file also in
> the attachment. Please let me know where I make the mistake.
> Thanks in advance and waiting for your kind reply.
> *Fazle Subhan PhD, *
> *Postdoctoral Fellow*
> *State Key Laboratory of Advanced Design and Manufacturing for Vehicle
> Body, College of Mechanical and Vehicle Engineering*
> *Hunan University, Changsha 410082, People's Republic of China*
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!QF1MQw780j5sMK062gEtBOwtEyv991QSdESFw7LAmZhOoBSmIewrId6A265ziYeGSFJGqI6JVsyAXgBPjA$
>  )
>


-- 
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] Question about (TS.Voltage, %block TS.Elecs) in TRANSIESTA

[Nick Papior]

This is a way to specify the "last atom of the electrode"

electrode-position <>
means that the first atom of the electrode starts at <>

electrode-position end <>
means that the last atom of the electrode is placed at <>

A negative number will count from the *end* of the full geometry, so -1 is
the last atom, -2 is the 2nd last atom etc.

Hope this helps.

Den tors. 17. aug. 2023 kl. 22.00 skrev 肖威 :

> Dear Nick Papior,
>
> Thank you very much for your reply.
>
> I realized that I didn't find the answers to some questions because I
> didn't check the latest 4.1.5 manual and the (.out) file that was output by
> calculation. However, after checking the latest 4.1.5 manual and the (.out)
> file, I still have the following question that I don't understand. I don't
> know if this is because my approach to finding answers is still flawed, and
> I hope you can enlighten me. Many thanks.
>
> Question:  In the following example, I can't understand what the (-1) in 
> (electrode-position
> end -1) stands for.
>
> (Some modifications were made according to article "N. Papior et al.
> Manipulating the voltage drop in graphene nanojunctions using a gate
> potential. Physical Chemistry Chemical Physics, 2016, 18(2):1025-1031.
> [DOI: 10.1039/c5cp04613k]")
> %block TS.Elecs
>   Left
>   Right
> %endblock
> %block TS.Elec.Left
>   HS../../lead.TSHS
>   semi-inf-direction-a3
>   chemical-potential   Left
>   electrode-position1
>   used-atoms   10
> %endblock
> %block TS.Elec.Right
>   HS../../lead.TSHS
>   semi-inf-direction+a3
>   chemical-potential   Right
>   electrode-position end  -1
>   used-atoms   10
> %endblock
>
> Thank you very much!
>
> Wei
>
> 肖威
> xiaowei951...@163.com
>
> <https://urldefense.com/v3/__https://dashi.163.com/projects/signature-manager/detail/index.html?ftlId=1=**E=xiaowei951020*40163.com=https*3A*2F*2Fmail-online.nosdn.127.net*2Fqiyelogo*2FdefaultAvatar.png=*5B*22xiaowei951020*40163.com*22*5D__;6IKW5aiBJSUlJSUlJSUlJSU!!D9dNQwwGXtA!SxLyWC01B6AeL3kmEC1A3xVpoGpwQIBsrLylYVlBspzJ2WlwjZz5xESZAgs-tQrAXnImxenCfz2mACQ6rJTSaA$>
>  Replied Message 
> From Nick Papior 
> Date 8/16/2023 04:00
> To  
> Subject Re: [SIESTA-L] Question about (TS.Voltage, %block TS.Elecs) in
> TRANSIESTA
> Hi Wei,
>
> Have you read the manual?
>
> If not, I would highly recommend you to read that, and if there are still
> some clarifications needed, then please let us know:
> 1. What was not clear enough in the manual
> 2. A possible suggestion to improve it
>
> Thanks!
>
>
>
> --
> Kind regards Nick
> Den lør. 12. aug. 2023 kl. 22.00 skrev 肖威 :
>
>> Dear SIESTA developers and users,
>>
>> I have the following two questions about TRANSIESTA and I'm really
>> looking forward to getting some help.
>>
>> 1. In the two-electrode calculation (N = 2 electrode calculations), when
>> I set (TS.Voltage = 0.4 eV), does the potential of the left electrode drop
>> by -0.2 eV and that of the right electrode rise by 0.2 eV ?
>>
>> 2. In the following example, what do (-a3), (1), (+a3) and (-1) stand for
>> respectively ?
>>
>> (Some modifications were made according to article "N. Papior et al.
>> Manipulating the voltage drop in graphene nanojunctions using a gate
>> potential. Physical Chemistry Chemical Physics, 2016, 18(2):1025-1031.
>> [DOI: 10.1039/c5cp04613k]")
>> %block TS.Elecs
>>   Left
>>   Right
>> %endblock
>> %block TS.Elec.Left
>>   HS../../lead.TSHS
>>   semi-inf-direction-a3
>>   chemical-potential   Left
>>   electrode-position1
>>   used-atoms   90
>> %endblock
>> %block TS.Elec.Right
>>   HS../../lead.TSHS
>>   semi-inf-direction+a3
>>   chemical-potential   Right
>>   electrode-position end  -1
>>   used-atoms   90
>> %endblock
>>
>> Thank you very much!
>> Wei
>>
>>
>> 肖威
>> xiaowei951...@163.com
>>
>> <https://urldefense.com/v3/__https://dashi.163.com/projects/signature-manager/detail/index.html?ftlId=1=**E=xiaowei951020*40163.com=https*3A*2F*2Fmail-online.nosdn.127.net*2Fqiyelogo*2FdefaultAvatar.png=*5B*22xiaowei951020*40163.com*22*5D__;6IKW5aiBJSUlJSUlJSUlJSU!!D9dNQwwGXtA!T8lXkEKRbPNtHcW8RQCWxXniZwwkFjuIrcRObLtywnJm4czoJMQq42WkKKbOYqm4zUAV54OgfQ3nEgb

Re: [SIESTA-L] Question about (TS.Voltage, %block TS.Elecs) in TRANSIESTA

[Nick Papior]

Hi Wei,

Have you read the manual?

If not, I would highly recommend you to read that, and if there are still
some clarifications needed, then please let us know:
1. What was not clear enough in the manual
2. A possible suggestion to improve it

Thanks!

Den lør. 12. aug. 2023 kl. 22.00 skrev 肖威 :

> Dear SIESTA developers and users,
>
> I have the following two questions about TRANSIESTA and I'm really looking
> forward to getting some help.
>
> 1. In the two-electrode calculation (N = 2 electrode calculations), when I
> set (TS.Voltage = 0.4 eV), does the potential of the left electrode drop by
> -0.2 eV and that of the right electrode rise by 0.2 eV ?
>
> 2. In the following example, what do (-a3), (1), (+a3) and (-1) stand for
> respectively ?
>
> (Some modifications were made according to article "N. Papior et al.
> Manipulating the voltage drop in graphene nanojunctions using a gate
> potential. Physical Chemistry Chemical Physics, 2016, 18(2):1025-1031.
> [DOI: 10.1039/c5cp04613k]")
> %block TS.Elecs
>   Left
>   Right
> %endblock
> %block TS.Elec.Left
>   HS../../lead.TSHS
>   semi-inf-direction-a3
>   chemical-potential   Left
>   electrode-position1
>   used-atoms   90
> %endblock
> %block TS.Elec.Right
>   HS../../lead.TSHS
>   semi-inf-direction+a3
>   chemical-potential   Right
>   electrode-position end  -1
>   used-atoms   90
> %endblock
>
> Thank you very much!
> Wei
>
>
> 肖威
> xiaowei951...@163.com
>
> 
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!WukSOFdB8A5RMsaz_TtzTa4G0SNJIe_7hHBefefaG67mDVhFqVz46xSJJr8PE26-miUgOQ4cKFMkt9doog$
>  )
>


-- 
Kind regards Nick

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

[SIESTA-L] ***SPAM*** Re: Question about Gate (Infinite plane) in SIESTA

[Nick Papior]

Hi,

1. Yes, a plane is defined by a point in the plane, and a normal vector,
nothing else is needed.
2. A normal vector needs no units, it is a vector describing direction, not
distance. Hence no unit is required.
3. Please use 4.1.5 (check the gitlab hosting site for the latest release),
do not use 4.1-b4.

Den tirs. 8. aug. 2023 kl. 22.00 skrev 肖威 :

> Dear SIESTA developers and users,
>
> Here is an example of the use of (Infinite plane) in the SIESTA 4.1-b4
> manual (Page 101):
>
> %block Geometry.Hartree
> plane 1. eV  # The lifting potential on the geometry
> delta
> 1.0   1.0   1.0   Ang  # An intersection point, in the plane
> 1.0   0.5   0.2# The normal vector to the plane
> %endblock Geometry.Hartree
>
> I have two questions about the above example:
> 1, Does the normal vector start at (1.0   1.0   1.0) and end at (1.0
> 0.5   0.2) ?
> 2, The unit of coordinate (1.0   0.5   0.2) is not marked, is it Ang ?
>
> I'm really looking forward to some help.
>
> Thank you very much!
>
> Wei
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 肖威
> xiaowei951...@163.com
>
> 
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!TTj_HNxltCl3ezM3mCK0ZlEqBsrhmBQXmMAF0HrMX1kzpH5HJLBlOyUA0tVY1XnMZPJ9NEagiJqxsYn9XA$
>  )
>


-- 
Kind regards Nick

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

[SIESTA-L] TranSIESTA + TBtrans + sisl school -- November 13 - 17 ; 2023

[Nick Papior]

Dear colleagues,

We would like to announce the upcoming workshop for sisl, TBtrans and
TranSIESTA, which will run at the Technical University of Denmark in Lyngby
in the week of November 13th - November 17th 2023.
The workshop will cost ~200 EUR (1.500 DKK) which will be used for lunches,
a workshop dinner and coffee breaks.

For general information and registration(link at the bottom of the page):

https://urldefense.com/v3/__https://siesta-project.github.io/web-portal/events/TranSIESTA_School-2023/__;!!D9dNQwwGXtA!QGidx5z5Vp3rsXYCoeuqqaTEbFCZiHf1ug_ZXYPURNR3f9L7v-uGenXh8BZYBGXEncPdrmulLn5YkmG-AA$
 

The introductory school is aimed at students and researchers from different
disciplines who plan to use, or want more understanding of the sisl +
TBtrans + TranSIESTA framework.
The sisl framework allows creation and manipulation of tight-binding and
LCAO matrices. Participants will learn about the essentials of the
tight-binding
procedure and how to interact with the TBtrans and TranSIESTA outputs for
post-processing.
The participants are required to have basic knowledge of solid-state
physics, density functional theory (DFT), and hands-on experience with
SIESTA or similar DFT codes.

The school will consist of lectures and hands-on sessions where experts
will be available for discussion and guidance.

Registering for the school can be done through the links in the above
mentioned information link.

NOTE: There is a limited amount of seats as it is a physical meeting.

With best wishes,

the organizers

sisl: 
https://urldefense.com/v3/__https://github.com/zerothi/sisl__;!!D9dNQwwGXtA!QGidx5z5Vp3rsXYCoeuqqaTEbFCZiHf1ug_ZXYPURNR3f9L7v-uGenXh8BZYBGXEncPdrmulLn5T2858MA$
 

-- 
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 specifying the type of an atom!. Atoms specified is above the total number of atoms!

[Nick Papior]

You are requesting the last electrode to start at the last atom, thus
resulting in requesting non-existing atoms. It should be "elec-pos end -1".

Den fre. 4. aug. 2023 kl. 22.00 skrev El-Abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good evening all,
>
> I am studying a graphene system and would like to know why am I getting
> this error.
>
> The siesta calculations for both left and right electrodes were correctly
> done as shown in left.out and right.out.
>
> However when I tried:
>
>
>
> siesta -fdf TS.Analyze *fdf > analyze.out
>
> I get this error which implies that the number of atoms I have is above 94
> which is not the case. I have 32 on the left, 30 in the middle and 32 on
> the right. So, I was wondering what could this error mean?
>
>
>
> Thank you! Hope to hear from you soon!
>
> Cheers,
>
> EL-Abed
>
>
>
> *EL-ABED HAIDAR *
>
> |Doctor of Philosophy (Science) |THE UNIVERSITY OF SYDNEY | NSW | 2006
>
> Current Staff Scientist |NCI Australia
> 
>  |The
> Australian National University
>
> 143 Ward Road, Acton, ACT 2601
>
> M: +61 416625261
>
> E: el-abed.hai...@anu.edu.au
>
>
>
> Want the latest *news* from NCI? 
> https://urldefense.com/v3/__http://nci.org.au/research-news/news/__;!!D9dNQwwGXtA!X3juCGdJaxJtX21sGPeUOJLpj6jKFPjn472aGE9RQbQew2Udyt5l1Xp5C4exiBR3Zn5_ZhrYDuS5_ZydXQ$
>  
> 
>
> Find out more about NCI: YouTube
> 
> / Facebook
> 
>  / Twitter
> 
> / LinkedIn
> 
>
> [image: NCI Australia logo black PNG transparent]  [image: MHFAider
> Accredited Digital Badge]
>
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!X3juCGdJaxJtX21sGPeUOJLpj6jKFPjn472aGE9RQbQew2Udyt5l1Xp5C4exiBR3Zn5_ZhrYDuT5-ukqwA$
>  )
>


-- 
Kind regards Nick

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

[SIESTA-L] ***SPAM*** Re: ***SPAM*** Compiling SIESTA with flook

[Nick Papior]

Hi,

Please do NOT use 4.1-b4!

It looks like you are mixing the different locations of flook. Please be
consistent about the -L in both LIBS and LDFLAGS and then
try again.
Did you explicitly add the flags mentioned at the end of `install_flook.sh`
script to the arch.make file? That exact wording of that output is
important.

Lastly, DO NOT USE 4.1-b4. 4.1.5 is out.


Den tors. 8. jun. 2023 kl. 22.00 skrev yh46 :

> Dear SIESTA developers and users,
> I am trying to compile SIESTA-4.1b4 with flook library. I am using
> intel compiler and I have executed the install_flook.bash script to
> install flook. This is the error message I get:
>
>
> ==> Incorporating information about present compilation (compiler and
> flags)
> make "FPPFLAGS=-DMPI -DCDF -DNCDF -DNCDF_4 -DNCDF_PARALLEL
> -DSIESTA__FLOOK" compinfo.o
> make[1]: Entering directory
> `/home1/05762/tg850616/Compile/Compile_SIESTA/siesta-4.1-b4-Intel/Obj'
> mpiifort -c -O2 -fPIC -fp-speculation=strict -fp-model strict -I
> -I/home1/05762/tg850616/Compile/Compile_SIESTA/siesta-4.1-b4-Intel/Docs/build/flook/0.7.0/include
> -DMPI -DCDF -DNCDF -DNCDF_4 -DNCDF_PARALLEL -DSIESTA__FLOOK
> compinfo.F90
> make[1]: Leaving directory
> `/home1/05762/tg850616/Compile/Compile_SIESTA/siesta-4.1-b4-Intel/Obj'
>
> mpiifort -c -O2 -fPIC -fp-speculation=strict -fp-model strict -I
> -I/home1/05762/tg850616/Compile/Compile_SIESTA/siesta-4.1-b4-Intel/Docs/build/flook/0.7.0/include
> -DMPI -DCDF -DNCDF -DNCDF_4 -DNCDF_PARALLEL -DSIESTA__FLOOK
>
> /home1/05762/tg850616/Compile/Compile_SIESTA/siesta-4.1-b4-Intel/Src/siesta_options.F90
> /home1/05762/tg850616/Compile/Compile_SIESTA/siesta-4.1-b4-Intel/Src/siesta_options.F90(11):
> error #7002: Error in opening the compiled module file.  Check INCLUDE
> paths.
> [FLOOK]
>use flook, only : luaState
> --^
> /home1/05762/tg850616/Compile/Compile_SIESTA/siesta-4.1-b4-Intel/Src/siesta_options.F90(230):
> error #6406: Conflicting attributes or multiple declaration of name.
> [LUASTATE]
>type(luaState) :: LUA
> ---^
> /home1/05762/tg850616/Compile/Compile_SIESTA/siesta-4.1-b4-Intel/Src/siesta_options.F90(11):
> error #6580: Name in only-list does not exist or is not accessible.
> [LUASTATE]
>use flook, only : luaState
> ^
> compilation aborted for
> /home1/05762/tg850616/Compile/Compile_SIESTA/siesta-4.1-b4-Intel/Src/siesta_options.F90
> (code
> 1)
> make: *** [siesta_options.o] Error 1
>
>
> Can someone give me some advice on how to solve this error? Thank you
> very much!
>
> Best,
> Yuefei
>
> --
> Yuefei Huang
> Graduate Student
> Department of Material Science and NanoEngineering
> Rice University
> email: yuefei.hu...@rice.edu
> phone: +1-832-499-9169
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!Rq9BEWqUpc8BrD2HVsKHR5eGeIDwIEIrRoAuZjGabnmt6xg_K8KYbQksq2jo6MoReQZMhpTlSFK_zT4VOQ$
>  )
>


-- 
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] about the 'Electrode connectivity is not perfect'

[Nick Papior]

Please see this question on matter modelling:
https://urldefense.com/v3/__https://mattermodeling.stackexchange.com/questions/9424/tbt-transiesta-calculation-error__;!!D9dNQwwGXtA!Q0B4ku0Ggr5WGLRlqQanAhMDQgCsmcwv4nk4V4yVTmXyu0RdrGo-Nwh_WVdR97nasmLA7ityvqMRA22Sjg$
 

Den tirs. 21. mar. 2023 kl. 22.03 skrev Bo Xiao :

> Dear siesta users
>
> I meet the problem in carrying out the transiesta simulation.
> The electrode calculation is all right, while it always show the error
> message in calculating the current/voltage curves, 'Electrode connectivity
> is not perfect'.
> When i substitue the metal atoms in electrode by other metals, the
> calculation is all right.
> The attachement is the input and output files.
> I am looking forward to your message.
>
> Best Wishes
> xiaoboy
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!Q0B4ku0Ggr5WGLRlqQanAhMDQgCsmcwv4nk4V4yVTmXyu0RdrGo-Nwh_WVdR97nasmLA7ityvqPHnOD2nA$
>  )
>


-- 
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] Memory problems with SOC

[Nick Papior]

I think that this is a memory leak in MKL, could you try a later revision?
Please see details here:
https://urldefense.com/v3/__https://gitlab.com/siesta-project/siesta/-/issues/29__;!!D9dNQwwGXtA!VJ6dNL-0-ztPLYjo9nyf0U6oWg9E4yUL2dpwIavhqG8_fCPtLxlZBt0ZW4ZCD8oJSNuN_S5CVgp2mkfOgg$
 

So I think it can easily be mitigated. :)


Den lør. 25. feb. 2023 kl. 22.16 skrev Daniel Bennett :

> Hi all,
>
> I'm running some calculations with SOC for a slab-like system with ~100
> atoms, ~1300 orbitals, and am having some issues running out of memory. I
> ran the same calculations with no SOC and things went fine.
>
> I'm using the PSML version with intel/mkl 2021.2.0. The calculations are
> running on 48 cores with just under 4GB memory per cpu. The calculations
> run and eventually crash, either in the SCF loop or when computing the
> bands. From my submission script: "srun: error: holy7c02611: task 5:
> Killed" it looks like one of the cores gets stopped, and then the
> calculation hangs. I tried setting ulimit -s unlimited and ulimit -m
> unlimited, but that didn't help. I also decreased the mesh cutoff and
> kpoints from 600Ry to 400Ry and 12x12x1 to 8x8x1, but the calculations
> still run out of memory eventually.
>
> Does anybody have any general advice for getting larger calculations with
> SOC to run without running out of memory? I could try increasing the number
> of cores, but I wanted to see if anybody had some advice first because the
> wait time is a lot longer for a larger number of cores, which makes it take
> a long time to troubleshoot. I did try going up to 96 cores (2 nodes), but
> it still crashes.
>
> I'm not sure if I can send attachments to the mailing list, but if not I
> can send inputs / outputs privately
>
> Thanks,
>
> Daniel Bennett
>
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!VJ6dNL-0-ztPLYjo9nyf0U6oWg9E4yUL2dpwIavhqG8_fCPtLxlZBt0ZW4ZCD8oJSNuN_S5CVgphwWrjeg$
>  )
>


-- 
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] Does siesta consider periodicity in scattering region?

[Nick Papior]

Hi,

Yes, transiesta considers periodicity in the transverse directions to the
transport direction (if it is unidirectional).

If you want to remove periodic images (which inherently contains your
scattering region) and retain a pristine electrode surrounding your device,
then you could use the method described here:
https://urldefense.com/v3/__https://journals.aps.org/prb/abstract/10.1103/PhysRevB.100.195417__;!!D9dNQwwGXtA!WKnZp4uPc19PmX7kqD78Q-8P2BoURiy8PMb83q-gQNKdFZDmZrh96D7SEtMquj2bGpH9cyb8bKDKRRivMQ$
 

Den fre. 24. feb. 2023 kl. 22.03 skrev msz228074 :

> Hi,
>
> I want to know, does siesta consider periodicity for scattering region
> in a transport calculation?
> Of course the structure is not periodic in the transport direction but
> does it consider periodicity in the transverse direction?
> if not, what is the significance of K-points and why do we give lattice
> parameters as input in the scattering region input file?
>
> Thanks & Regards
> Srest
>
> --
> Srest Somay
> Ph.D. Scholar
> Department of Material Science and Engineering
> Indian Institute of Technology Delhi
> email: msz228...@iitd.ac.in
> Ph- +(91) 7667324869
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!WKnZp4uPc19PmX7kqD78Q-8P2BoURiy8PMb83q-gQNKdFZDmZrh96D7SEtMquj2bGpH9cyb8bKDM0b2ptQ$
>  )
>


-- 
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] Radial part of basis orbital

[Nick Papior]

Hi

Probably the easiest is to use sisl to read in the geometry + orbital
information.
Then something like this:

R = np.linspace(0, 10, 100)
geometry.atoms[0].orbitals[0].radial(R)

this should give you the radial component for the first orbital on the
first atom. The indexing should be manageable. See here:
https://urldefense.com/v3/__https://zerothi.github.io/sisl/api/generated/sisl.AtomicOrbital.html*sisl.AtomicOrbital.radial__;Iw!!D9dNQwwGXtA!Sqvl4Ft1XqqthjCXriRxYT5mgwHOXe_i0k0uXK-YcUvTeVjadlCAO3ASZe4Z0FTxrDcfsdF8XMklaFSUqw$
 

Den tir. 14. feb. 2023 kl. 22.02 skrev Francisco Garcia <
garcia.ff@gmail.com>:

> Dear Users,
>
> I would like to know how to obtain the data for the radial part of a given
> basis orbital for plotting. E.g. the radial part of Al 3s and Al 3p for SZ
> basis.
>
> Thank you.
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!Sqvl4Ft1XqqthjCXriRxYT5mgwHOXe_i0k0uXK-YcUvTeVjadlCAO3ASZe4Z0FTxrDcfsdF8XMnU8obmPw$
>  )
>


-- 
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 file path for pseudos?

[Nick Papior]

Currently this is not implemented.

But, we have an issue for this and it will most likely be in the next major
release of Siesta! :)

Thanks for bringing this up!

Den fre. 3. feb. 2023 kl. 22.04 skrev Daniel Bennett :

> Hi all,
>
> I was wondering if anybody knows if there is a way to specify a path to
> the pseudopotential files, rather than just having them in the same
> directory as the calculation? I want to avoid having many copies of the
> pseudos when running a large set of calculations.
>
> Thanks,
>
> Daniel Bennett
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!WvSLVYWShXZjGRCnm6uH5dvc5bdXM46_2Ol4r1mEaB-88KHqY8Sx0VjZdrvrHy4Ub5-LnvQbknqHVtV6EA$
>  )
>


-- 
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] Restarting calculations with different spin orientations

[Nick Papior]

Hi,

You should be able to use sisl to rotate the spin-box matrices.
sisl is a python tool aiding dft calculations and has a root in the siesta
environment. 
https://urldefense.com/v3/__https://github.com/zerothi/sisl__;!!D9dNQwwGXtA!U063I_Qr34-kBiMp8zdrQCtf7Lnq_oz_i0SYauze1EBb0cUQ1Zu-GuxOPHvhrhN2eNz39Iez2wF77lrncQ$
 

For instance I would do something like this:

import sisl as si
fdf = si.get_sile("RUN.fdf")
DM = fdf.read_density_matrix()
DMrot = DM.spin_rotate([45, 30, 15])
DMrot.write("siesta.DM")

this will rotate the spin by 45 around x, 30 around y and 15 around z.
Any feedback on this would be very much appreciated!

So let me know how it works!

Den tir. 31. jan. 2023 kl. 22.03 skrev Andres Tellez Mora <
at00...@mix.wvu.edu>:

> Dear Siesta users and developers.
>
> I am running calculations of the same structure with different spin
> orientations. Since I am performing spin-orbit calculations with DFT+U,
> they can take a decent amount of time to converge. Hence, I was trying to
> use the .DM file of one of the calculations to start the others; however,
> the DM.InitSpin block information is overridden and the calculation starts
> using the same spin orientation from the converged .DM file. This even
> happens when using a .DM file from a non-polarized calculation, which gives
> a starting magnetization of 0.0. Is it possible to use the information of a
> .DM file and start with a given spin orientation simultaneously? If this is
> not possible, what else could I do to improve the convergence? I appreciate
> any help you can provide.
>
> Best Regards,
> Andres Tellez.
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!U063I_Qr34-kBiMp8zdrQCtf7Lnq_oz_i0SYauze1EBb0cUQ1Zu-GuxOPHvhrhN2eNz39Iez2wFdPHAwqg$
>  )
>


-- 
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] DFT-D3 in Siesta package

[Nick Papior]

Yes!

The latest development included this:
https://urldefense.com/v3/__https://gitlab.com/siesta-project/siesta/-/merge_requests/70__;!!D9dNQwwGXtA!Q99mAou4w_f6DS5APAYiRuFOwHe_dR4vyLSsRG6A9YjMGfDR6qQ-in8aTdRcju9oCo2JHrn_QylshcJ7Qw$
 

The next major release will have this enabled!

Den ons. 25. jan. 2023 kl. 22.04 skrev Mahbubeh Amiri <
amirimahbu...@gmail.com>:

> Dear siesta users
>
> Does support DFT-D3 model of Grimme in siesta package?
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!Q99mAou4w_f6DS5APAYiRuFOwHe_dR4vyLSsRG6A9YjMGfDR6qQ-in8aTdRcju9oCo2JHrn_QyltKRumcA$
>  )
>


-- 
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] should I choose the conda-version of siesta?

[Nick Papior]

There should be a performance difference between manually compiled siesta.
But the conda version is most useful for testing and getting to play with
siesta. :)

Den tir. 7. jun. 2022 kl. 22.02 skrev LQChen :

> Dear Community;
>
> Is the conda-version of siesta for learning? Or it is suit for real work,
> too?
> I am new to siesta, and wondering if there is a performance difference
> between the conda-version of siesta and the manually compiled version?
>
> Best regards
> Chen
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!XXpEIOs_n49OCWwov90JAR9US3alA0oy0oAY2Sdx1iGXb-t-iwgjEa1g2yN0vGxyeUD6sxxT7beNURjerw$
>  )
>


-- 
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] Plotting Spin Density in Supercell

[Nick Papior]

Hi,

It depends on what you want to do. For instance if you have already stored
the RHO file (or Rho.grid.nc) file you could do the following to get the
spin density along z for a polarized calculation.

sgrid Rho.grid.nc{0} --diff Rho.grid.nc{1} --geometry RUN.fdf --tile 10 a
test.cube

or, equivalently

sgrid Rho.grid.nc{1,-1} --geometry RUN.fdf --tile 10 a test.cube

which would do the sum using the factors present in the list.

this would write out a cube file with the charge density tiled 10 times
along the first lattice vector.

This requires the sisl python library located here:
https://urldefense.com/v3/__https://github.com/zerothi/sisl__;!!D9dNQwwGXtA!SYJWyF-CyilmgfRZvy50hsVlp2GnO_5JMtXcjyuoaPHaoVi8-HsgiyNfFgOs22Jse49pHkbZJ7_TwCxYYQ$
 

Den søn. 19. jun. 2022 kl. 22.10 skrev Fanmiao Kong <
fanmiao.k...@materials.ox.ac.uk>:

> Hello,
>
>
>
> I am using Denchar to plot the spin density. I want to plot it in a
> supercell of 10x1x1, but I found that the maximum number of unit cells is
> limited by 5x1x1 in my case. I found that this information is read from
> .PLD file and it looks like the internal auxiliary supercell (which also
> happens to be 5x1x1). I am wondering how can I plot the spin density in
> more unit cells?
>
>
>
> Best regards,
>
> Fanmiao
>
>
>
> Fanmiao Kong
>
> Department of Materials, Trinity College, University of Oxford
>
> Tel: +44 (0)7529931806 / +86 13162054601
>
> 16 Parks Road, OX1 3PH, Oxford, UK
>
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!SYJWyF-CyilmgfRZvy50hsVlp2GnO_5JMtXcjyuoaPHaoVi8-HsgiyNfFgOs22Jse49pHkbZJ79B5eTApA$
>  )
>


-- 
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] Current or transmission direction

[Nick Papior]

This is defined via the semi-inf-direction option provided for each of the
electrodes.

The output of siesta (transiesta) clearly denotes which semi-infinite
directions each electrode has. Please note, that there is *per see* not a
transport direction. There is only semi-infinite directions, and the
electrons travel between these regions (think of an L-junction for
instance). So always check that the semi-infinite direction points away
from your device region along the respective electrode axis.

Den tir. 8. nov. 2022 kl. 22.20 skrev Yelda Kadıoglu <
yeldaakadio...@gmail.com>:

> Hi developers,
> I was using siesta 4.0 before and now I started using 4.1. Previously the
> transmission could only be calculated in the z direction. So we didn't need
> to do anything extra. In this version I placed my material along the x
> direction, but how can I be sure that the current is flowing in the x
> direction? From the manual I understood it as if the transiesta
> automatically detects according to the position of the electrodes. How do
> we adjust the current (transmission) direction?
> Thanks in advance
> Yelda Kadioglu
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!Q70umj9jo7LzodTc9VOaVWK9CH6lpUEVbFC05mXHi9LEBOvCyuexIk-dhYyDJ-txjJCuVE6_tN8B4tXAhQ$
>  )
>


-- 
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] Question about Gate in SIESTA

[Nick Papior]

Hi,

On Fri, 1 Jul 2022, 22:00 肖威,  wrote:

> Dear SIESTA developers and users,
>
> I recently read Papior et al. 's article on Phys. Chem. Chem. Phys.
> entitled "Manipulating the voltage drop in graphene nanojunctions using a
> gate potential (DOI: 10.1039/C5CP04613K)". I am very interested in the
> method of adding gate voltage to a system in this article and try to learn
> how to use it. However, I have encountered some difficulties in the
> process, and I'm really looking forward to some help.
>
> 1. When I use the square (Bounded plane) option in Gate, I need to set
> the starting point of the square and two spanning vectors. As shown below
> (copied from the SIESTA 4.1-b4 manual).
>
> %block Geometry.Hartree
>
> square 1. eV  # The lifting potential on the geometry
>
> gauss 1. 2. Ang  # the std. and the cut-off length
>
> 1.0  1.0  1.0  Ang  # The starting point of the square
>
> 2.0  0.5  0.2  Ang  # The first spanning vector
>
> 0.0  2.5  0.2  Ang  # The second spanning vector
>
> %endblock Geometry.Hartree
>
> But we all know that two points define a vector, so do the coordinates
> that define the spanning vector in the example above represent the end
> point of the vector? If so, what is the starting point of this spanning
> vector? Is the spanning vector starting at the origin (0  0  0) or at the
> starting point of the square (1.0  1.0  1.0) defined in the example above?
>
> I have the same question about plane (Infinite plane, a vector) and Box
> (three vectors) in Gate.
>

There are 3 points, (1,2,3) the vectors go from 1-2 and 1-3.
In the square geometry the vectors form a bounded surface, in the infinite
plane the length of them doesn't matter as they will be considered
infinite.


> 2. Whether a shorter vacuum layer in the direction of adding Gate makes
> self-consistency difficult to converge. How to determine the appropriate
> length of vacuum layer?
>

The most simple thing is (if you don't have periodicity along the field
generated by the gate) to add a slab dipole correction, and add vacuum
corresponding to 1.5 times the distance between your structure and the
gate.

Note however that the hartree gate merely changes the electrostatic
potential in the defined region, i.e. it is not a boundary condition in the
generic sense.

> I'm really looking forward to some help.
>
> Thank you very much!
>
> Wei
>
> 肖威
> xiaowei951...@163.com
>
> 
>
> --
> 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] TBtrans and broadening matrix

[Nick Papior]

Hi,

As for details regarding the projected transmissions and other scalar
quantities, you may find this useful:
https://www.youtube.com/watch?v=ERGksOfikb8=PLwM2jMcWDGDAMkCAmGOi19Pe8rL0-CJtU=15

Also, the discussion related to the tutorial on projected transmissions is
still present on the discord channel, that may come in handy.

Ensuring the correct input is not so simple, one should carefully examine
the details and follow the manual very carefully.

Hope this helps.

Den man. 27. jun. 2022 kl. 22.01 skrev Aleksandar Tomovic <
atomo...@ipb.ac.rs>:

> Dear all,
>
> I'm interested in finding the coupling of my device with the L/R
> electrode.
> In the paper "Improvements on non-equilibrium and transport Green
> function techniques: The next-generation transiesta" there is a sentence
> that says that tbtrans saves all scalar quantities ⟨Mj|Γ L|Mj′ ⟩.
> However, after reviewing TBtrans manual chapter related to projected
> transmission and sisl documentation on tbtprojncSileTBtrans, I was still
> unable to retrieve that information. I would appreciate any hints that
> you could provide.
>
> Kind regards,
>
> Aleksandar Tomovic
>
>
> --
> 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] << two set of charge calculations >>

[Nick Papior]

The 2nd data output relates to your ldos range. So they are effectively not
equivalent. The first is the final scf, the 2nd ldos.

I think this is the case, but I am not 100 sure (not at my computer to
check).

On Tue, 21 Jun 2022, 22:00 I. Camps,  wrote:

> I completely agree with Tamas and Emilio BUT my question *is not* related
> to which charge calculation scheme is "better".
>
> My question is that in my calculations, two different sets of data of the
> same type of charges are appearing in the output file, instead only one for
> each. I have two outputs for Hirshfeld and two outputs for Voronoi charges.
>
> []'s,
>
> Camps
>
>
> On Mon, Jun 20, 2022 at 5:02 PM Emilio Artacho 
> wrote:
>
>> Tamas’s reply is correct, I just want to add a reminder of the fact
>> that atomic charges have a fundamental definition problem and none of
>> the proposals gives the ‘good’ answer. This is a direct consequence
>> of its responding to an ill-posed question: how many electrons ‘belong’
>> to a given atom (or can be assigned to it). It is perfectly defined if
>> the atoms
>> are infinitely separated from each other, but not otherwise.
>>
>> It is clear, however, that concepts like charge transfer etc are useful
>> in chemistry and very much support chemical analysis and intuition.
>> Atomic charges schemes (when used sensibly) are valuable. Just remember
>> to use them with care (qualitatively, trends etc). There are good
>> comparative
>> studies assessing their reliability in various chemistry situations.
>>
>> There are situations for which the question can be rephrased
>> into something physically well defined (see e,g, the Born effective
>> charges, or other questions relating to dielectric polarisation).
>>
>> One can also find claims in the literature for a particular scheme to be
>> the ‘right’ one. To my mind they all rely on arbitrary choices, which can
>> be more or less sensible or well motivated, but still arbitrary (as Tamas
>> says, some depend on the basis set choice while other do not, for
>> instance).
>>
>> best
>>
>> Emilio
>>
>> On Jun 19, 2022, at 2:47 PM, Tamas Karpati  wrote:
>>
>> Dear Camps,
>>
>> Please note that an argument is going on for decades about how to
>> calculate atomic charges. Different methods/schemes give different
>> results, each is giving better/worse results for different
>> applications. It is recommended to check how well each performs at
>> your actual problem and choose which one is to be used. Also
>> remarkable is the basis set dependence of atomic charges, consider
>> this a parameter to be calibrated.
>>
>> Regards,
>>  t
>>
>> On Fri, Jun 17, 2022 at 10:02 PM I. Camps  wrote:
>>
>>
>> Hello Alberto,
>>
>> Here it is the info about the SIESTA version:
>>
>> Siesta Version  : siesta-max-R3--710-676-597
>> Architecture: unknown
>> Compiler version: ifort (IFORT) 19.1.1.217 20200306
>> Compiler flags  : mpifort -fPIC -O2 -march=core-avx2 -axCore-AVX512
>> -fp-model precise
>> PP flags: -DFC_HAVE_ABORT -DF2003 -DMPI -DCDF -DNCDF -DNCDF_4
>> -DNCDF_PARALLEL -I/cvmfs//
>> soft.computecanada.ca/easybuild/software/2020/avx2/MPI/intel2020/openmpi4/netcdf-fortran-mpi/4.5.2/include
>> Libraries   : libncdf.a libfdict.a -Wl,-Bstatic -Wl,--start-group
>> -lmkl_scalapack_lp64 -lmkkl_blacs_openmpi_lp64 -lmkl_intel_lp64
>> -lmkl_sequential -lmkl_core -Wl,--end-group -Wl,-Bdynamic -lnetcdff
>> PARALLEL version
>> NetCDF support
>> NetCDF-4 support
>> NetCDF-4 MPI-IO support
>>
>> And here is the output section:
>>
>> siesta: Final energy (eV):
>> siesta:  Band Struct. =   -8272.290139
>> siesta:   Kinetic =   19960.524774
>> siesta:   Hartree =  151423.860682
>> siesta:   Eldau   =   0.00
>> siesta:   Eso =   0.00
>> siesta:Ext. field =   0.00
>> siesta:   Enegf   =   0.00
>> siesta:   Exch.-corr. =  -11180.064205
>> siesta:  Ion-electron = -320401.282309
>> siesta:   Ion-ion =  129282.468462
>> siesta:   Ekinion =   0.00
>> siesta: Total =  -30914.492596
>> siesta: Fermi =  -4.212218
>>
>> siesta: Stress tensor (static) (eV/Ang**3):
>> siesta: 0.0001260.00   -0.00
>> siesta: 0.000.000101   -0.49
>> siesta:-0.00   -0.49   -0.016465
>>
>> siesta: Cell volume =   7672.635004 Ang**3
>>
>> siesta: Pressure (static):
>> siesta:SolidMolecule  Units
>> siesta:   0.5895  0.5941  Ry/Bohr**3
>> siesta:   0.00541292  0.00545494  eV/Ang**3
>> siesta:   8.67254766  8.73987328  kBar
>> (Free)E+ p_basis*V_orbitals  =  -30859.763440
>> (Free)Eharris+ p_basis*V_orbitals  =  -30859.763491
>> spin moment: S , {S} =0.0   0.0   0.0   0.0
>>
>> siesta: Electric dipole (a.u.)  =0.000.0432460.00
>> siesta: Electric dipole (Debye) =0.010.1099190.00
>>
>> Hirshfeld Net Atomic Populations:
>> 

Re: [SIESTA-L] Installation error while using NetCDF

[Nick Papior]

Hi,

The error is a spelling mistake:

make: *** No rule to make target `*ibncdf.a*', needed by `siesta'.  Stop.

A missing *l* in front.

Den tir. 12. apr. 2022 kl. 22.02 skrev Mohammed Ghadiyali <
mohammed.ghadiy...@kaust.edu.sa>:

> Hello,
>
> I’m able to install Siesta 4.1.5 without NetCDF support, however when I
> try to install it with, it always gives the flowing error:
>
> make: *** No rule to make target `ibncdf.a', needed by `siesta'.  Stop.
>
> I’ve give the library’s the direct path, but still the error is present;
> please attached the make file and the log file of the install.
>
> Regards,
> Ghadiyali Mohammed Kader
> Post Doctoral Fellow
> King Abdullah University of Science and Technology
>
> --
> 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.
> --
> 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] Using prior calculation for spin-orbit calculation

[Nick Papior]

Hi,

Siesta is able to expand/contract any spin-dimension matrix to a smaller
spin matrix configuration.
The spin-transformations are the simplest one could imagine, for instance,
going from unpolarized to polarized will equally divide the density matrix
electrons in spin-up/down.


Den søn. 27. mar. 2022 kl. 22.01 skrev Francisco Garcia <
garcia.ff@gmail.com>:

> Dear Users,
>
> Is it allowed for me to add spin-orbit coupling (SOC) to a prior regular
> calculation? Or do I have to start the SOC calculation from scratch?
>
> Thanks!
>
> --
> 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] TBtrans output

[Nick Papior]

Right
> 57586 Mar 14 14:22 scat.TBT_UP.AVTEIG_Left-Right
> 57586 Mar 14 14:22 scat.TBT_UP.AVTEIG_Right-Left
> 17574 Mar 14 14:22 scat.TBT_UP.AVTRANS_Left-Left
> 17574 Mar 14 14:22 scat.TBT_UP.AVTRANS_Left-Right
> 17574 Mar 14 14:22 scat.TBT_UP.AVTRANS_Right-Left
> 17574 Mar 14 14:22 scat.TBT_UP.AVTRANS_Right-Right
>158263 Mar 14 14:22 scat.TBT_UP.BDOS_Left
>158263 Mar 14 14:22 scat.TBT_UP.BDOS_Right
>158272 Mar 14 14:22 scat.TBT_UP.BTRANS_Left
>158272 Mar 14 14:22 scat.TBT_UP.BTRANS_Right
>518294 Mar 14 14:22 scat.TBT_UP.CEIG_Left
>518294 Mar 14 14:22 scat.TBT_UP.CEIG_Right
>158282 Mar 14 14:22 scat.TBT_UP.CORR_Left
>158282 Mar 14 14:22 scat.TBT_UP.CORR_Right
>  186434408059 Mar 14 14:22 scat.TBT_UP.nc
>518279 Mar 14 14:22 scat.TBT_UP.TEIG_Left-Right
>518279 Mar 14 14:22 scat.TBT_UP.TEIG_Right-Left
>158267 Mar 14 14:22 scat.TBT_UP.TRANS_Left-Left
>158267 Mar 14 14:22 scat.TBT_UP.TRANS_Left-Right
>158267 Mar 14 14:22 scat.TBT_UP.TRANS_Right-Left
>158267 Mar 14 14:22 scat.TBT_UP.TRANS_Right-Right
> ---
>
>
>
> On 3/11/22 15:08, Nick Papior wrote:
>
> Hi,
>
> And could you attach the input and output again... The last output clearly
> showed that you had not put those flags in. So I am guessing you are doing
> the same thing again
>
> Please, always attach input and output!
>
> And you write something about tbt.t.eig true which does not make sense...
> As I suggested previously, please check the output to see if it will write
> the things requested, when you attach the output, could you comment on the
> output and your interpretation of what it says about transmission
> eigenvalues etc.
>
>
> On Fri, 11 Mar 2022, 09:39 Neculai PLUGARU, 
> wrote:
>
>> Hi, All
>>
>> I have the following flags in the input: section for TBT :
>>
>>  ...
>>
>> TBT.DOS.A.All true
>>
>> TS.SolutionMethod btd
>>
>> TS.BTD.Pivot atom+rev-CM+Left
>>
>>
>>
>> %block TBT.k
>>
>> diag 3 3 1
>>
>> %endblock
>>
>>
>>
>> %block TBT.Contours
>>
>> line
>>
>> %endblock TBT.Contours
>>
>> %block TBT.Contour.line
>>
>> part line
>>
>> from -15. eV to 10. eV
>>
>> delta 0.02 eV
>>
>> method mid-rule
>>
>> %endblock TBT.Contour.line
>>
>> TBT.T.Bulk true
>>
>> TBT.DOS.Elecs true
>>
>> TBT.T.Eig 5
>>
>> TBT.T.All true
>>
>> TBT.T.Out true
>>
>> TBT.Symmetry.TimeReversal false
>>
>> TBT.Current.Orb  true
>>
>> However, the code does not yield "the equivalent eigenvalue files" for
>> TBT.T.Eig   true
>> Nor the *.nc files for spin_UP/DN
>> Here I list the TBT output files I get:
>>
>>  195116 Feb 12 18:54 scat.TBT.CC
>>  350488 Feb 12 19:19 scat.TBT_DN.ADOS_Left
>>  350488 Feb 12 19:19 scat.TBT_DN.ADOS_Right
>>   70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Left
>>   70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Right
>>   70074 Feb 12 19:19 scat.TBT_DN.AVTRANS_Left-Right
>>  350459 Feb 12 19:19 scat.TBT_DN.TRANS_Left-Right
>> 297 Feb 12 18:54 scat.TBT.KP
>>  350488 Feb 12 19:06 scat.TBT_UP.ADOS_Left
>>  350488 Feb 12 19:06 scat.TBT_UP.ADOS_Right
>>   70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Left
>>   70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Right
>>   70074 Feb 12 19:06 scat.TBT_UP.AVTRANS_Left-Right
>>  350459 Feb 12 19:06 scat.TBT_UP.TRANS_Left-Right
>>
>> What is wrong/missing in my TBT input ?
>>
>> Thank you for your comments,
>> Neculai
>>
>>
>>
>> On 3/11/22 07:36, Nick Papior wrote:
>>
>> Please see my response 2 days ago, it seems that you are missing flags in
>> the input file.
>>
>> /Nick
>>
>> On Thu, 10 Mar 2022, 22:02 Neculai PLUGARU, 
>> wrote:
>>
>>>
>>> Hi, Nick
>>>
>>> Thank you, very much, for the checks and your time.
>>>
>>> 1) your scat.fdf does not ask for transmission eigenvalues. I.e. I can't
>>> find TBT.T.Eig in scat.fdf, this is also reflected in tbt.out which lists 0
>>> transmission eigenvalues should be calculated. So nothing wrong there.
>>> Absolutely correct. The meaning of this piece of information was to show
>>> that without specifications for additional data,  particularly TBT.T.EIG,
>>> the code works alright.
>>> 2) your scat-dn and scat-up. The output of the tbtrans runs tbt-dn.out
>>>

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

[Nick Papior]

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

/Nick

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

>
> Hi, Nick
>
> Thank you, very much, for the checks and your time.
>
> 1) your scat.fdf does not ask for transmission eigenvalues. I.e. I can't
> find TBT.T.Eig in scat.fdf, this is also reflected in tbt.out which lists 0
> transmission eigenvalues should be calculated. So nothing wrong there.
> Absolutely correct. The meaning of this piece of information was to show
> that without specifications for additional data,  particularly TBT.T.EIG,
> the code works alright.
> 2) your scat-dn and scat-up. The output of the tbtrans runs tbt-dn.out and
> tbt-up.out have these lines:
>
> ===
> =   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
> 
>
> Correct. This happens when one follows the discussion since 2017, trying
> to perform two calculations (but using TBT 4.1.5) for spin_UP/DN. The code
> produces the (empty) scat.TBT_UP/DN.CEIG_Left   files and huge
> scat.TBT_UP/DN.nc files. It has been just a test of that approach, it
> failed and this is understandable because it is a different version. Now,
> just to complete the information, this is what one gets with TBT 4.1.5
> when using the attached scat.fdf input asking for specific output data (I
> also attach the tbt.out)
>
>
>   195116 Feb 12 18:54 scat.TBT.CC
>   350488 Feb 12 19:19 scat.TBT_DN.ADOS_Left
>   350488 Feb 12 19:19 scat.TBT_DN.ADOS_Right
>70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Left
>70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Right
>70074 Feb 12 19:19 scat.TBT_DN.AVTRANS_Left-Right
>   350459 Feb 12 19:19 scat.TBT_DN.TRANS_Left-Right
>  297 Feb 12 18:54 scat.TBT.KP
>   350488 Feb 12 19:06 scat.TBT_UP.ADOS_Left
>   350488 Feb 12 19:06 scat.TBT_UP.ADOS_Right
>70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Left
>70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Right
>70074 Feb 12 19:06 scat.TBT_UP.AVTRANS_Left-Right
>   350459 Feb 12 19:06 scat.TBT_UP.TRANS_Left-Right
>
> Still, no output for
> SystemLabel.TEIG_<1>_<2>
> SystemLabel.BDOS_<>
> SystemLabel.BTRANS_<>
> SystemLabel.CORR_<>
> SystemLabel.TRANS_<1>_<1>
> as well as for SystemLabel.TBT_UP/DN.nc files, although tbt.out says that
> the job was executed without error.
>
> I have just completed the ts_graphene test in the 4.1.5 release in a
> spin-polarized configuration with transmission eigenvalues, and everything
> seems correctly written.
>
> Please, is there anything wrong in the here-attached *fdf file comparing
> with your input for the spin polarized graphene input ?
>
> Thank you, very much, for your comments and suggestion wrt the compilation
> of TBT when using intel compilers; I have had painstaking experiences in
> the past with that. I will ask the system administrator to recompile the
> code paying more attention to the optimization flags, indeed.
>  Kind regards,
>
> Neculai
> On 3/9/22 14:15, Nick Papior wrote:
>
> Hi,
>
> This is what I can find:
>
> 1) your scat.fdf does not ask for transmission eigenvalues. I.e. I can't
> find TBT.T.Eig in scat.fdf, this is also reflected in tbt.out which lists 0
> transmission eigenvalues should be calculated. So nothing wrong there.
>
> 2) your scat-dn and scat-up. The output of the tbtrans runs tbt-dn.out and
> tbt-up.out have these lines:
>
> ===
> =   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
> =   RANK 46 PID 17638 RUNNING AT imt01
> =   KILLED BY SIGNAL: 9 (Killed)
> ===
>
>
> indicating a prematurely ending job. Always check whether your jobs are
> done. That information could be of a number of reasons that I don't have
> any knowledge about.
> Sometimes intel compilers are extremely aggressive in optimizations, and
> this could be what is causing problems. Try lowering the optimization
> level, or ask the admins on your cluster why the jobs ended prematurely.
>
> I have just completed the ts_graphene test in the 4.1.5 release in a
> spin-polarized configuration with transmission eigenvalues, and everything
> seems correctly written.
>
> / Nick
>
>
> Den man. 7. mar. 2022 kl. 17.32 skrev Neculai PLUGARU <
> neculai.plug...@imt.ro>:
>
>>
>> Hello, Nick
>>
>> Thank you for your help. I have delayed my message because I have made
>> several tests to be more explicit about the problems I face with TBT 4.1.5.
>> So, here are the answers to you

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

[Nick Papior]

Hi,

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

Please, always attach input and output!

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


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

> Hi, All
>
> I have the following flags in the input: section for TBT :
>
>  ...
>
> TBT.DOS.A.All true
>
> TS.SolutionMethod btd
>
> TS.BTD.Pivot atom+rev-CM+Left
>
>
>
> %block TBT.k
>
> diag 3 3 1
>
> %endblock
>
>
>
> %block TBT.Contours
>
> line
>
> %endblock TBT.Contours
>
> %block TBT.Contour.line
>
> part line
>
> from -15. eV to 10. eV
>
> delta 0.02 eV
>
> method mid-rule
>
> %endblock TBT.Contour.line
>
> TBT.T.Bulk true
>
> TBT.DOS.Elecs true
>
> TBT.T.Eig 5
>
> TBT.T.All true
>
> TBT.T.Out true
>
> TBT.Symmetry.TimeReversal false
>
> TBT.Current.Orb  true
>
> However, the code does not yield "the equivalent eigenvalue files" for
> TBT.T.Eig   true
> Nor the *.nc files for spin_UP/DN
> Here I list the TBT output files I get:
>
>  195116 Feb 12 18:54 scat.TBT.CC
>  350488 Feb 12 19:19 scat.TBT_DN.ADOS_Left
>  350488 Feb 12 19:19 scat.TBT_DN.ADOS_Right
>   70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Left
>   70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Right
>   70074 Feb 12 19:19 scat.TBT_DN.AVTRANS_Left-Right
>  350459 Feb 12 19:19 scat.TBT_DN.TRANS_Left-Right
> 297 Feb 12 18:54 scat.TBT.KP
>  350488 Feb 12 19:06 scat.TBT_UP.ADOS_Left
>  350488 Feb 12 19:06 scat.TBT_UP.ADOS_Right
>   70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Left
>   70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Right
>   70074 Feb 12 19:06 scat.TBT_UP.AVTRANS_Left-Right
>  350459 Feb 12 19:06 scat.TBT_UP.TRANS_Left-Right
>
> What is wrong/missing in my TBT input ?
>
> Thank you for your comments,
> Neculai
>
>
>
> On 3/11/22 07:36, Nick Papior wrote:
>
> Please see my response 2 days ago, it seems that you are missing flags in
> the input file.
>
> /Nick
>
> On Thu, 10 Mar 2022, 22:02 Neculai PLUGARU, 
> wrote:
>
>>
>> Hi, Nick
>>
>> Thank you, very much, for the checks and your time.
>>
>> 1) your scat.fdf does not ask for transmission eigenvalues. I.e. I can't
>> find TBT.T.Eig in scat.fdf, this is also reflected in tbt.out which lists 0
>> transmission eigenvalues should be calculated. So nothing wrong there.
>> Absolutely correct. The meaning of this piece of information was to show
>> that without specifications for additional data,  particularly TBT.T.EIG,
>> the code works alright.
>> 2) your scat-dn and scat-up. The output of the tbtrans runs tbt-dn.out
>> and tbt-up.out have these lines:
>>
>> ===
>> =   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
>> 
>>
>> Correct. This happens when one follows the discussion since 2017, trying
>> to perform two calculations (but using TBT 4.1.5) for spin_UP/DN. The code
>> produces the (empty) scat.TBT_UP/DN.CEIG_Left   files and huge
>> scat.TBT_UP/DN.nc files. It has been just a test of that approach, it
>> failed and this is understandable because it is a different version. Now,
>> just to complete the information, this is what one gets with TBT 4.1.5
>> when using the attached scat.fdf input asking for specific output data (I
>> also attach the tbt.out)
>>
>>
>>   195116 Feb 12 18:54 scat.TBT.CC
>>   350488 Feb 12 19:19 scat.TBT_DN.ADOS_Left
>>   350488 Feb 12 19:19 scat.TBT_DN.ADOS_Right
>>70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Left
>>70103 Feb 12 19:19 scat.TBT_DN.AVADOS_Right
>>70074 Feb 12 19:19 scat.TBT_DN.AVTRANS_Left-Right
>>   350459 Feb 12 19:19 scat.TBT_DN.TRANS_Left-Right
>>  297 Feb 12 18:54 scat.TBT.KP
>>   350488 Feb 12 19:06 scat.TBT_UP.ADOS_Left
>>   350488 Feb 12 19:06 scat.TBT_UP.ADOS_Right
>>70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Left
>>70103 Feb 12 19:06 scat.TBT_UP.AVADOS_Right
>>70074 Feb 12 19:06 scat.TBT_UP.AVTRANS_Left-Right
>>   350459 Feb 12 19:06 scat.TBT_UP.TRANS_Left-Right
>>
>> Still, no output for
>> SystemLabel.TEIG_<1>_<2>
>> SystemLabel.BDOS_<>
>> SystemLabel.BTRANS_<>
>> SystemLabel.CORR_&

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

[Nick Papior]

Den ons. 9. mar. 2022 kl. 14.35 skrev Neculai PLUGARU <
neculai.plug...@imt.ro>:

> Hi, Nick
>
> Thank you, very much, for the checks and your time.
>
> 1) your scat.fdf does not ask for transmission eigenvalues. I.e. I can't
> find TBT.T.Eig in scat.fdf, this is also reflected in tbt.out which lists 0
> transmission eigenvalues should be calculated. So nothing wrong there.
>
> Absolutely correct. The meaning of this piece of information was to show
> that without specifications for additional data,  particularly TBT.T.EIG,
> the code works alright.
> 2) your scat-dn and scat-up. The output of the tbtrans runs tbt-dn.out and
> tbt-up.out have these lines:
>
> ===
> =   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
> 
>
> Correct. This happens when one follows the discussion since 2017, trying
> to perform two calculations (but using TBT 4.1.5) for spin_UP/DN. The code
> produces the (empty) scat.TBT_UP/DN.CEIG_Left   files and huge
> scat.TBT_UP/DN.nc files. It has been just a test of that approach, it
> failed and this is understandable because it is a different version.
>
> Now, just to complete the information, this is what one gets with TBT
> 4.1.5  when using the attached scat.fdf input asking for specific output
> data (I also attach the tbt.out)
>


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

No, and that is because you don't request them in your input file? So you
get what you asked for?

SystemLabel.TEIG_<1>_<2>
> SystemLabel.BDOS_<>
> SystemLabel.BTRANS_<>
> SystemLabel.CORR_<>
> SystemLabel.TRANS_<1>_<1>
>
> as well as for SystemLabel.TBT_UP/DN.nc files, although tbt.out says that
> the job was executed without error.
>
> I have just completed the ts_graphene test in the 4.1.5 release in a
> spin-polarized configuration with transmission eigenvalues, and everything
> seems correctly written.
>
> Please, is there anything wrong in the here-attached *fdf file comparing
> with your input for the spin polarized graphene input ?
>
> Thank you, very much, for your comments and suggestion wrt the compilation
> of TBT when using intel compilers; I have had painstaking experiences in
> the past with that. I will ask the system administrator to recompile the
> code paying more attention to the optimization flags, indeed.
>
>  Kind regards,
>
> Neculai
> On 3/9/22 14:15, Nick Papior wrote:
>
> Hi,
>
> This is what I can find:
>
> 1) your scat.fdf does not ask for transmission eigenvalues. I.e. I can't
> find TBT.T.Eig in scat.fdf, this is also reflected in tbt.out which lists 0
> transmission eigenvalues should be calculated. So nothing wrong there.
>
> 2) your scat-dn and scat-up. The output of the tbtrans runs tbt-dn.out and
> tbt-up.out have these lines:
>
> ===
> =   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
> =   RANK 46 PID 17638 RUNNING AT imt01
> =   KILLED BY SIGNAL: 9 (Killed)
> ===
>
>
> indicating a prematurely ending job. Always check whether your jobs are
> done. That information could be of a number of reasons that I don't have
> any knowledge about.
> Sometimes intel compilers are extremely aggressive in optimizations, and
> this could be what is causing problems. Try lowering the optimization
> level, or ask the admins on your cluster why the jobs ended prematurely.
>
> I have just completed the ts_graphene test in the 4.1.5 release in a
> spin-polarized configuration with transmission eigenvalues, and everything
> seems correctly written.
>
> / Nick
>
>
> Den man. 7. mar. 2022 kl. 17.32 skrev Neculai PLUGARU <
> neculai.plug...@imt.ro>:
>
>>
>> Hello, Nick
>>
>> Thank you for your help. I have delayed my message because I have made
>> several tests to be more explicit about the problems I f

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

[Nick Papior]

Hi,

This is what I can find:

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

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

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

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

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

/ Nick


Den man. 7. mar. 2022 kl. 17.32 skrev Neculai PLUGARU <
neculai.plug...@imt.ro>:

>
> Hello, Nick
>
> Thank you for your help. I have delayed my message because I have made
> several tests to be more explicit about the problems I face with TBT 4.1.5.
> So, here are the answers to your questions:
>
> 1) I attach my input files; now there are three of them, because I found
> and followed this discussion since 2017-01-24, regarding TBT 4.1-b3,  and
> somehow the present situation with TBT 4.1.5 is similar, but still
> different.
>
> https://bugs.launchpad.net/siesta/+bug/1658896
>  "spin polarized tbtrans calculation"
>
> In my calculations of the eigen channels, the first one (denoted here
> below scat-up) stops after producing the files for the spin UP. Then, in an
> independent TBT calculation, scat-dn, with the line
>
> TBT.Spin 2
>
> included in *fdf, one obtains all the files for the spin-DOWN channel.
> However, the code gives the output for both spin channels (but not the
> files mentioned in my first message) in the case that one does not specify
> in the input the request for the eigen channels and other data,( this is
> calculation denoted scat).
>
> 2) I also attach the tbt.out files, for conformity;
>
> 3) Below, I list the files generated by TBtrans 4.1.5 for the two
> independent calculations spin-up/spin-dn, as well as for the calculation
> without the TBT.T.Eig 5, and other supplimentary lines.
>
>
> scat-up
>195116 Mar  7 10:17 scat.TBT.CC
>   529 Mar  7 10:17 scat.TBT.KP
>630796 Mar  7 11:58 scat.TBT_UP.ADOS_Left
> 70103 Mar  7 11:58 scat.TBT_UP.AVADOS_Left
> 70070 Mar  7 11:58 scat.TBT_UP.AVBDOS_Left
> 70079 Mar  7 11:58 scat.TBT_UP.AVBTRANS_Left
> 70089 Mar  7 11:58 scat.TBT_UP.AVCORR_Left
>630763 Mar  7 11:58 scat.TBT_UP.BDOS_Left
>630772 Mar  7 11:58 scat.TBT_UP.BTRANS_Left
>   178 Mar  7 11:58 scat.TBT_UP.CEIG_Left
>630782 Mar  7 11:58 scat.TBT_UP.CORR_Left
>  745686907872 Mar  7 11:58 scat.TBT_UP.nc
> --
>
> scat-dn
> 78116 Mar  7 14:29 scat.TBT.CC
>252796 Mar  7 15:11 scat.TBT_DN.ADOS_Left
> 28103 Mar  7 15:11 scat.TBT_DN.AVADOS_Left
> 28070 Mar  7 15:11 scat.TBT_DN.AVBDOS_Left
> 28079 Mar  7 15:11 scat.TBT_DN.AVBTRANS_Left
> 28089 Mar  7 15:11 scat.TBT_DN.AVCORR_Left
>252763 Mar  7 15:11 scat.TBT_DN.BDOS_Left
>252772 Mar  7 15:11 scat.TBT_DN.BTRANS_Left
>   178 Mar  7 15:11 scat.TBT_DN.CEIG_Left
>252782 Mar  7 15:11 scat.TBT_DN.CORR_Left
>  298284813762 Mar  7 15:11 scat.TBT_DN.nc
>   529 Mar  7 14:29 scat.TBT.KP
> --
> scat
>  195116 Feb 11 06:11 scat.TBT.CC
>  350488 Feb 11 06:36 scat.TBT_DN.ADOS_Left
>  350488 Feb 11 06:36 scat.TBT_DN.ADOS_Right
>   70103 Feb 11 06:36 scat.TBT_DN.AVADOS_Left
>   70103 Feb 11 06:36 scat.TBT_DN.AVADOS_Right
>   70074 Feb 11 06:36 scat.TBT_DN.AVTRANS_Left-Right
>   225823297 Feb 11 06:36 scat.TBT_DN.nc
>  350459 Feb 11 06:36 scat.TBT_DN.TRANS_Left-Right
> 297 Feb 11 06:11 scat.TBT.KP
>  350488 Feb 11 06:24 scat.TBT_UP.ADOS_Left
>  350488 Feb 11 06:24 scat.TBT_UP.ADOS_Right
>   70103 Feb 11 06:24 scat.TBT_UP.AVADOS_Left
>   70103 Feb 11 06:24 scat.TBT_UP.AVADOS_Right
>   70074 Feb 11 06:24 scat.TBT_UP.AVTRANS_Left-Right
>   225823295 Feb 11 06:24 scat.TBT_UP.nc
>  350459 Feb 11 06:24 scat.TBT_UP.TRANS_Left-Right
> --
>
> I have also tested the example for graphe

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

[Nick Papior]

Hi,

1) what is your input file
2) what does the top 10 lines of the tbtrans output say?
3) do you have the netcdf file SystemLabel.TBT.nc present in your
calculation folder?


Den fre. 4. mar. 2022 kl. 22.07 skrev Neculai PLUGARU <
neculai.plug...@imt.ro>:

> Dear SIESTA Community
>
> I use SIESTA 4.1.5 and the associated TS and TBT. TBtrans was compiled
> following the instructions in the TBtrans manual, using NETCDF-4 and MKL
> libs.
>
> I want to calculate the eigen channels for the transmission matrix for a
> spin-polarized system. For that purpose we have set the following flags in
> the TBT input:
>
> TBT.Verbosity 8
> TBT.T.Bulk true
> TBT.T.All true
> TBT.T.Eig  true
> TBT.T.Eig 5
> TBT.T.Out true
> TBT.Symmetry.TimeReversal F
> TBT.Current.Orb  true
>
> But the TBT calculation does not provide the files
>
> SystemLabel.TEIG_<1>_<2>
> SystemLabel.BDOS_<>
> SystemLabel.BTRANS_<>
> SystemLabel.CORR_<>
> SystemLabel.TRANS_<1>_<1>
>
> Is the information in these files listed only in the  netcdf format (*.nc
> files) ?
>
> Thank you for your help,
> Neculai
> ***
> Dr. Neculai Plugaru
> National Institute for R in Microtechnologies (IMT-Bucharest)
> Simulation, Modelling and Computer-Aided Design - Laboratory L5
> 126A, Erou Iancu Nicolae Street, 077190, Ilfov
> Bucharest, ROMANIA
>
> E-mail: neculai.plug...@imt.ro
> Tel:  +4021 269 0777
> https://www.imt.ro
> ***
>
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>


-- 
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] Transmission spectrum varies greatly with TBT.Contours.Eta

[Nick Papior]

Hi,

No, I would say you need to conduct more experiments in trying to
understand your system's sensitivity and convergences a bit better.

Den tor. 3. mar. 2022 kl. 22.02 skrev Sukhito Teh :

> Thank you Nick, I benefited a lot for going through the tutorials that you
> provided.
> Since the transmission varies greatly with eta, can I say that the
> absolute value of the transmission function (and thus the current
> calculated) is not really meaningful?
>
> Best regards,
> Sukhito Teh
> University of National Tsing Hua University
>
> On Sat, Feb 26, 2022 at 5:02 AM Nick Papior  wrote:
>
>> There isn't per see a problem with the calculations. When the
>> transmission is low, increasing the ETA value will generally smear out the
>> transmissions, lowering the overall T. Please do understand what the Eta
>> value does and what it means in the physical picture.
>>
>> Instead of looking at the transmission, I would look at the DOS on
>> certain sites and check how they evolve with eta values, also take into
>> account the energy spacing in your integration window. For example please
>> carefully understand slide 6 in this presentation:
>> https://github.com/zerothi/ts-tbt-sisl-tutorial/releases/download/v2021.05/Slide_Monday_0900.pdf
>> The discussion about energies and eta values is very important in what
>> you are experiencing.
>>
>> Den tor. 24. feb. 2022 kl. 22.03 skrev Sukhito Teh > >:
>>
>>> Dear developers and users,
>>> I am trying to calculate the spin polarized current flowing
>>> through magnetic junction MoS2/graphene/MoS2 with Co as electrodes (
>>> https://journals.aps.org/prb/abstract/10.1103/PhysRevB.103.165407). For
>>> the spin up current (parallel to both Co electrode's spins), the
>>> transmission function seems to retain its feature with increasing value of
>>> TBT.Contours.Eta, but the transmission function for spin down current
>>> varies greatly with it.
>>> Does this imply my calculation with transiesta is actually problematic?
>>> Or is it normal to use an Eta as large as 100 meV in order to get converged
>>> results for tbtrans calculation?
>>> I had attached the figures for transmission functions, and also input
>>> files for the calculation.
>>> Thank you for your attention.
>>>
>>> Link to Figures of Transmission Spectrum
>>> https://ibb.co/kQ4kL70
>>> https://ibb.co/8P7JtbD
>>> https://ibb.co/VVVkf8z
>>>
>>> Best regards,
>>> Sukhito Teh
>>> University of National Tsing Hua University
>>>
>>> --
>>> 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] Question about sisl codes

[Nick Papior]

Hi Anita,

Thanks for finding this missing information in the documentation. The link
is dead, and there is no atom_01.rst. I will fix this!

I would encourage you to read the documentation about the Atom and Geometry
class which can be found here:
https://zerothi.github.io/sisl/api/generated/sisl.Atom.html#sisl.Atom
and
https://zerothi.github.io/sisl/api/generated/sisl.Geometry.html#sisl.Geometry


Den søn. 27. feb. 2022 kl. 22.01 skrev anita dameh :

> Dear sisl users,
>
> In sisl tutorial I have found this statement "See 
> on how to create different atoms."
> where is the  atom_01.rst is located? is this a code ?
>
> Another question is Geometry object. what is this object exactly and
> where I can read more about that?
>
> Regardes
> Anita
>
> --
> 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] Bug or incorrect application

[Nick Papior]

Hi,

The PAO.Basis block is a way to define the basis set.
So if you don't have it, you'll use some general settings for creating the
PAO.Basis block.
So what you are asking is whether basis set A is better than basis set B.
I simply don't know, it is your system, your basis sets and you'll have to
investigate whether the system is correctly described using the basis set
you are using.

Den fre. 25. feb. 2022 kl. 22.02 skrev Mohammed Ghadiyali <
mohammed.ghadiy...@kaust.edu.sa>:

> Dear Prof. Nick,
>
> I reposted the question with some additional details, before receiving
> your answer.
> I looked in the manual and it helped.
> But accuracy wise which is better, giving the PAO.Basis block or not?
>
> Regards,
> Ghadiyali Mohammed Kader
> Post Doctoral Fellow
> King Abdullah University of Science and Technology
>
>
> On Fri, Feb 25, 2022 at 12:02 AM Nick Papior  wrote:
>
>> Hi, it is not a bug, it is because the basis set range is different when
>> you have the PAO.Basis block, compared to not having it.
>>
>> Did you read my suggested block in the manual? That is the reason.
>>
>> Quote:
>> "It is extremely important that the electrodes only interact with one
>> neighboring supercell due to the
>> self-energy calculation [13]"
>>
>> / Nick
>>
>> Den ons. 23. feb. 2022 kl. 22.01 skrev Mohammed Ghadiyali <
>> mohammed.ghadiy...@kaust.edu.sa>:
>>
>>> Hello,
>>>
>>> I'm a novice user of Siesta and working on computing IV of a 6-ZGNR with
>>> magnetic edges.
>>> I'm using pseudopotentials from simuneatomistics website along with the
>>> provided basis set, given below:
>>>
>>> %block PAO.Basis
>>> H 2
>>> n=1 0 2 E 40 -0.9
>>> 7.38657734676 2.5578156
>>> n=1 1 1 E 40 -0.9 Q 9.4900562 1.5464743
>>> 7.38657734676
>>> C 3
>>> n=2 0 2 E 40 -0.9
>>> 5.94869034392 2.5090419
>>> n=2 1 2 E 40 -0.9
>>> 7.63838693570 2.6226139
>>> n=2 2 1 E 40 -0.9 Q 6.4005365 .010
>>> 7.63838693570
>>> %endblock PAO.Basis
>>>
>>> However, I've noticed that if I use these basis sets I get an error
>>> "Electrode connectivity is not perfect". If I remove them the calculation
>>> works fine. It is a bug or I'm doing something incorrectly?
>>> I've attached the input files and the pseudopotentials along with this
>>> mail.
>>>
>>> Regards,
>>> Ghadiyali Mohammed Kader
>>> Post Doctoral Fellow
>>> King Abdullah University of Science and Technology
>>>
>>> --
>>> 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.
>>> --
>>> SIESTA is supported by the Spanish Research Agency (AEI) and by the
>>> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/
>>> <https://urldefense.com/v3/__http://www.max-centre.eu/__;!!Nmw4Hv0!l3dD61gwUWVqbx53Ub62uJgpQXu0smIB2YvZZgG6qwga88Xs_AhmEhFNK6xav8nq_8iKVr4gNAU$>
>>> )
>>>
>>
>>
>> --
>> Kind regards Nick
>>
>> --
>> SIESTA is supported by the Spanish Research Agency (AEI) and by the
>> European H2020 MaX Centre of Excellence (
>> https://urldefense.com/v3/__http://www.max-centre.eu/__;!!Nmw4Hv0!l3dD61gwUWVqbx53Ub62uJgpQXu0smIB2YvZZgG6qwga88Xs_AhmEhFNK6xav8nq_8iKVr4gNAU$
>> )
>>
>
> --
> 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.
> --
> 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] Transmission spectrum varies greatly with TBT.Contours.Eta

[Nick Papior]

There isn't per see a problem with the calculations. When the transmission
is low, increasing the ETA value will generally smear out the
transmissions, lowering the overall T. Please do understand what the Eta
value does and what it means in the physical picture.

Instead of looking at the transmission, I would look at the DOS on certain
sites and check how they evolve with eta values, also take into account the
energy spacing in your integration window. For example please carefully
understand slide 6 in this presentation:
https://github.com/zerothi/ts-tbt-sisl-tutorial/releases/download/v2021.05/Slide_Monday_0900.pdf
The discussion about energies and eta values is very important in what you
are experiencing.

Den tor. 24. feb. 2022 kl. 22.03 skrev Sukhito Teh :

> Dear developers and users,
> I am trying to calculate the spin polarized current flowing
> through magnetic junction MoS2/graphene/MoS2 with Co as electrodes (
> https://journals.aps.org/prb/abstract/10.1103/PhysRevB.103.165407). For
> the spin up current (parallel to both Co electrode's spins), the
> transmission function seems to retain its feature with increasing value of
> TBT.Contours.Eta, but the transmission function for spin down current
> varies greatly with it.
> Does this imply my calculation with transiesta is actually problematic? Or
> is it normal to use an Eta as large as 100 meV in order to get converged
> results for tbtrans calculation?
> I had attached the figures for transmission functions, and also input
> files for the calculation.
> Thank you for your attention.
>
> Link to Figures of Transmission Spectrum
> https://ibb.co/kQ4kL70
> https://ibb.co/8P7JtbD
> https://ibb.co/VVVkf8z
>
> Best regards,
> Sukhito Teh
> University of National Tsing Hua University
>
> --
> 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] Bug or incorrect application

[Nick Papior]

Hi, it is not a bug, it is because the basis set range is different when
you have the PAO.Basis block, compared to not having it.

Did you read my suggested block in the manual? That is the reason.

Quote:
"It is extremely important that the electrodes only interact with one
neighboring supercell due to the
self-energy calculation [13]"

/ Nick

Den ons. 23. feb. 2022 kl. 22.01 skrev Mohammed Ghadiyali <
mohammed.ghadiy...@kaust.edu.sa>:

> Hello,
>
> I'm a novice user of Siesta and working on computing IV of a 6-ZGNR with
> magnetic edges.
> I'm using pseudopotentials from simuneatomistics website along with the
> provided basis set, given below:
>
> %block PAO.Basis
> H 2
> n=1 0 2 E 40 -0.9
> 7.38657734676 2.5578156
> n=1 1 1 E 40 -0.9 Q 9.4900562 1.5464743
> 7.38657734676
> C 3
> n=2 0 2 E 40 -0.9
> 5.94869034392 2.5090419
> n=2 1 2 E 40 -0.9
> 7.63838693570 2.6226139
> n=2 2 1 E 40 -0.9 Q 6.4005365 .010
> 7.63838693570
> %endblock PAO.Basis
>
> However, I've noticed that if I use these basis sets I get an error
> "Electrode connectivity is not perfect". If I remove them the calculation
> works fine. It is a bug or I'm doing something incorrectly?
> I've attached the input files and the pseudopotentials along with this
> mail.
>
> Regards,
> Ghadiyali Mohammed Kader
> Post Doctoral Fellow
> King Abdullah University of Science and Technology
>
> --
> 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.
> --
> 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 connectivity.

[Nick Papior]

Please check the manual for this section: Principal layer interactions

It is most likely this problem.

Den tir. 22. feb. 2022 kl. 22.02 skrev Ghadiyali Mohammed <
ghadiyali.m...@gmail.com>:

> Hello,
>
> I'm facing the error "Electrode connectivity is not perfect", however I'm
> not able to find the error. For creating the structure, I've copied the
> same coordinates for the left electrode and for the right one I've scaled
> it along the c-axis. I've attached both of the file along this mail.
>
> Regards,
> --
> Ghadiyali Mohammed Kader
> Post Doctoral Fellow
> King Abdullah University of Science and Technology
>
>
>
> --
> 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 does siesta calculate bands in a gamma-point-only scf calculation?

[Nick Papior]

Hi,

Simply add this to your fdf file:

ForceAuxCell true


Den fre. 28. jan. 2022 kl. 22.01 skrev Chong Wang :

> Dear siesta developers,
>
>
>
> I am trying to read HSX file and calculate corresponding band structure
> myself (because I need wave function information). The HSX file is
> generated with a gamma-point-only scf calculation, and thus it is necessary
> to do some modification to the `xij` variable.
>
>
>
> For example, suppose I have a ten-atom chain:
>
> 1-2-3-4-5-6-7-8-9-10
>
>
>
> A gamma point calculation will introduce hopping between atom 1 and atom
> 10 (<1|H|10>) due to periodic boundary condition. To calculate band
> structure, it is necessary to realize the hopping is across the cell
> boundaries. Currently, `xij` is the vector pointing from 1 to 10 in the
> home unit cell:
>
> 1>10.
>
> Some modification is needed such that it points to the left side of the
> unit cell:
>
> 10<-1-2-3-4-5-6-7-8-9-10.
>
>
>
> I can do this modification myself, but I guess there is already a
> subroutine in siesta that does this trick. Where is it?
>
>
>
> Best
>
> Chong Wang
>
>
>
> --
> 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] Problems of Siesta Calculation with Large Electric Field

[Nick Papior]

Great, I have now added this to the manual to help new users.

Den ons. 24. nov. 2021 kl. 22.04 skrev Fanmiao Kong <
fanmiao.k...@materials.ox.ac.uk>:

> Dear Nick,
>
>
>
> Thanks for your kind reminder. I will avoid using rar format later.
>
> I followed Daniel’s advice and have successfully re-run my calculation.
> The problem has been solved.
>
>
>
> Best wishes,
>
>
>
> Fanmiao
>
>
>
> Fanmiao Kong
>
> Department of Materials, Trinity College, University of Oxford
>
> Tel: +44 (0)7529931806 / +86 13162054601
>
> 16 Parks Road, OX1 3PH, Oxford, UK
>
>
>
> *From:* siesta-l-requ...@uam.es  *On Behalf Of *Nick
> Papior
> *Sent:* 23 November 2021 12:07
> *To:* siesta-l 
> *Subject:* Re: [SIESTA-L] Problems of Siesta Calculation with Large
> Electric Field
>
>
>
> HI, Daniel gave an excellent solution.
>
>
>
> Could you report back whether that solved the problem?
>
>
>
> Also for future reference, rar compressed files are generally not
> advised... zip/tar.gz/tar.* are generally better (more portable).
>
>
>
> Den fre. 19. nov. 2021 kl. 22.05 skrev Fanmiao Kong <
> fanmiao.k...@materials.ox.ac.uk>:
>
> Hi Nick,
>
>
>
> Thanks a lot for your reply!
>
>
>
> I attached the fdf and psf files here.
>
>
>
> Best regards,
>
>
>
> Fanmiao
>
>
>
> Fanmiao Kong
>
> Department of Materials, Trinity College, University of Oxford
>
> Tel: +44 (0)7529931806 / +86 13162054601
>
> 16 Parks Road, OX1 3PH, Oxford, UK
>
>
>
> *From:* siesta-l-requ...@uam.es  *On Behalf Of *Nick
> Papior
> *Sent:* 17 November 2021 21:08
> *To:* siesta-l 
> *Subject:* Re: [SIESTA-L] Problems of Siesta Calculation with Large
> Electric Field
>
>
>
> Hi,
>
>
>
> Could you attach a complete workable example (fdf and psf files)?
>
>
>
> Den ons. 17. nov. 2021 kl. 22.03 skrev Fanmiao Kong <
> fanmiao.k...@materials.ox.ac.uk>:
>
> Hi All,
>
>
>
> I met some bugs when I do Siesta calculation under electric field.
> Sometimes the calculation doesn’t converge after 500 steps in a SCF cycle,
> or sometimes the hydrogen atoms in my structure are ionized. I attached the
> output file here where the calculation didn’t converge and I stopped it. I
> suppose this is because of the very large electric field ( between 1.5 –
> 2.1 V/Ang), since I don’t have this problem with electric field below 0.1
> V/Ang. Does anyone know how to fix this problem?
>
>
>
> Many thanks!
>
>
>
> Cheers,
>
>
>
> Fanmiao
>
>
>
> Fanmiao Kong
>
> Department of Materials, Trinity College, University of Oxford
>
> Tel: +44 (0)7529931806 / +86 13162054601
>
> 16 Parks Road, OX1 3PH, Oxford, 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/)
>
>
>
> --
>
> 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/)
>


-- 
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] Problems of Siesta Calculation with Large Electric Field

[Nick Papior]

HI, Daniel gave an excellent solution.

Could you report back whether that solved the problem?

Also for future reference, rar compressed files are generally not
advised... zip/tar.gz/tar.* are generally better (more portable).

Den fre. 19. nov. 2021 kl. 22.05 skrev Fanmiao Kong <
fanmiao.k...@materials.ox.ac.uk>:

> Hi Nick,
>
>
>
> Thanks a lot for your reply!
>
>
>
> I attached the fdf and psf files here.
>
>
>
> Best regards,
>
>
>
> Fanmiao
>
>
>
> Fanmiao Kong
>
> Department of Materials, Trinity College, University of Oxford
>
> Tel: +44 (0)7529931806 / +86 13162054601
>
> 16 Parks Road, OX1 3PH, Oxford, UK
>
>
>
> *From:* siesta-l-requ...@uam.es  *On Behalf Of *Nick
> Papior
> *Sent:* 17 November 2021 21:08
> *To:* siesta-l 
> *Subject:* Re: [SIESTA-L] Problems of Siesta Calculation with Large
> Electric Field
>
>
>
> Hi,
>
>
>
> Could you attach a complete workable example (fdf and psf files)?
>
>
>
> Den ons. 17. nov. 2021 kl. 22.03 skrev Fanmiao Kong <
> fanmiao.k...@materials.ox.ac.uk>:
>
> Hi All,
>
>
>
> I met some bugs when I do Siesta calculation under electric field.
> Sometimes the calculation doesn’t converge after 500 steps in a SCF cycle,
> or sometimes the hydrogen atoms in my structure are ionized. I attached the
> output file here where the calculation didn’t converge and I stopped it. I
> suppose this is because of the very large electric field ( between 1.5 –
> 2.1 V/Ang), since I don’t have this problem with electric field below 0.1
> V/Ang. Does anyone know how to fix this problem?
>
>
>
> Many thanks!
>
>
>
> Cheers,
>
>
>
> Fanmiao
>
>
>
> Fanmiao Kong
>
> Department of Materials, Trinity College, University of Oxford
>
> Tel: +44 (0)7529931806 / +86 13162054601
>
> 16 Parks Road, OX1 3PH, Oxford, 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/)
>


-- 
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] Problems of Siesta Calculation with Large Electric Field

[Nick Papior]

Hi,

Could you attach a complete workable example (fdf and psf files)?

Den ons. 17. nov. 2021 kl. 22.03 skrev Fanmiao Kong <
fanmiao.k...@materials.ox.ac.uk>:

> Hi All,
>
>
>
> I met some bugs when I do Siesta calculation under electric field.
> Sometimes the calculation doesn’t converge after 500 steps in a SCF cycle,
> or sometimes the hydrogen atoms in my structure are ionized. I attached the
> output file here where the calculation didn’t converge and I stopped it. I
> suppose this is because of the very large electric field ( between 1.5 –
> 2.1 V/Ang), since I don’t have this problem with electric field below 0.1
> V/Ang. Does anyone know how to fix this problem?
>
>
>
> Many thanks!
>
>
>
> Cheers,
>
>
>
> Fanmiao
>
>
>
> Fanmiao Kong
>
> Department of Materials, Trinity College, University of Oxford
>
> Tel: +44 (0)7529931806 / +86 13162054601
>
> 16 Parks Road, OX1 3PH, Oxford, 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] transiesta yields negative total energy and TBTrans starts with positive total energy

[Nick Papior]

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

Probably what you are seeing is that the charge is leaking out of the
device region during your SCF. This is an indication of one or a
combination of the following:
- your initial Hamiltonian is far from the open-boundary one. I.e. your
electrode regions are too close to the scattering in the device
- your mixing weight is too high
- your convergence parameters too loose during the Siesta SCF
- your integration variables in TranSiesta could be better (more points)
- you started a biased calculation (V) from a previous TranSiesta
calculation (V'), and the difference V - V' is too large for the system to
converge properly, try a smaller dV

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

Den fre. 12. nov. 2021 kl. 22.08 skrev Neculai PLUGARU <
neculai.plug...@imt.ro>:

> Dear SIESTA community
>
> I attempt to perform conductance calculations on a heterostructure with
> two interfaces, (slab geometry) which was previously relaxed and then
> the SCF calculation produced correct results.
>
> I use SIESTA v4.1-b4, Compiler version: ifort (IFORT) 18.0.5 20180823,
> PARALLEL version.
>
> However, although the SIESTA cycle in the transport calculation
> converges and the Harris, KS and Free energies are negative, TS starts
> from (huge) positive energy values, then the calculation converges
> according to the DM tolerance criterion, the energies are still
> positive, the forces on atoms are huge and the populations on orbitals
> are wrong. The leads are cut from the electrodes, so that the scattering
> region comprises the interfaces and the leads still are about one
> nanometer long each.
>
> I would greatly appreciate your comments to solve this issue.
>
> Thank you,
>
> Neculai
>
> ***
> N. Plugaru
> National Institute for R in Microtechnologies (IMT-Bucharest)
> Simulation, Modelling and Computer-Aided Design - Laboratory L5
> 126A, Erou Iancu Nicolae Street, 077190, Ilfov
> Bucharest, ROMANIA
>
> E-mail: neculai.plug...@imt.ro
> Tel:  +4021 269 0777
> https://www.imt.ro
> ***
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>


-- 
Kind regards Nick

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

Re: [SIESTA-L] Confusion about bond current

[Nick Papior]

Hi,

It is correct that for V=0 and dT=0 there is no current.

The *bond currents*, or lets call them orbital currents, can be viewed as
how the electrons would pass through the structure at a given k-point and
at a specific energy.
So if you consider an infinitesimal V the bond-current at E=Ef would be how
the electrons pass through the device.

One can then calculate how the full current passes through the device by
integrating the bond-currents (as one would do for the transmission) for
the entire bias window.

You should be able to cut the orbital-currents such that you find the total
transmission. However, the cut must cut the full device in 2; but how you
make that cut is up to you.
So I don't know how you did it, but I think something went wrong then ;)

As for getting the incoming and reflection waves. That is not as trivial
and we have not tried to do it with the current quantities that can be
calculated (I think you need one more term).
But what you can do is calculate the reflected transmission. You calculate
the bulk transmission and the total transmission. Subtract the two and you
have the reflected transmission.


Den lør. 30. okt. 2021 kl. 22.00 skrev zhyphy :

> Dear All，
> I want to do some analysis of the relationship between structures and
> currents. I can successfully extract  data with SISL program.But I'm
> confused about the physical sense of bond current. I noticed that, in some
> literatures, they used equilibrium results to obtain bond-current at some
> incident energy. But in equilibrium, isn't there no current through the
> device? So what does this bond current stand for?
> When the current is stable, the current flowing in and out of the cross
> section at any position of the device should be equal.Therefore, the sum of
> the bond-currents in any section should be equal. But my calculation is
> not so.Is there something wrong with my understanding of bond current?
> Due to the potential barrier between atoms, the wave function between
> bonds should be the superposition of incident wave and reflected wave. Can
> I extract the contribution of incoming and outgoing waves to the total
> current respectively?
> I really appreciate that someone can help me understand the sense of bond
> current.
>
>  best regards,
> 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] Running TranSIESTA for geometry relaxation

[Nick Papior]

Hi,

1. Generally you want to use buffer atoms behind a single electrode to make
it behave as bulk as possible. So this makes sense. Especially with the
option "DM-init force-bulk". In fact, using this option which results in
large charge differences is a clear indicator that your initial electrode
region is really not behaving bulk-like. So the obvious thing here is that
*if* you swap the density matrix elements on the electrode atoms in the
device calculation with density matrix elements from the electrode
calculation AND the charge difference when entering the transiesta cycle is
not close to 0, then your electrode region in the device is not behaving as
a bulk-like electrode.

2. The Poisson solution is not used when performing V=0 calculations,
equilibrium. So it does not matter at all in this case. Also, for
1-electrode calculations you can't apply a bias. However, you can do it
assuming you have a "capacitor" setup. Just use 1 electrode and apply an
electric field.

3. When doing single electrode calculations you should use the slab dipole
correction to account for the charge build-up.

4. When doing geometry relaxations you should play with the options of
re-using density matrices between different geometry steps. Probably it
does not work well :(
TranSiesta is more prone to go into bad convergence, and so testing how the
mixing options + what you mix + geometry step mixing of density matrix
elements is required. Also smaller time-steps/displacements may be required
to reduce the noise, again testing ;)

Hope this helps.

Den fre. 29. okt. 2021 kl. 20.09 skrev Karen Fidanyan <
karen.fidan...@mpsd.mpg.de>:

> Dear Nick,
>
> if possible, I would appreciate further advice/discussion.
>
> I try to do a single electrode setup (Nc=1). I discovered that if I don't
> put any layers *behind *the electrode and set `DM-init force-bulk`, I
> have a large error in total charge. It is somewhat inobvious - I would
> naively expect that the electrode is implicitly attached to its own
> repetitions in the semi-infinite direction. Related to that - I defined the
> Poisson solution as "ramp", hoping to use it for linear field later on
> (right now I do V=0 only) - could the problem be related to this? If "ramp"
> is not okay, what would be the right way to define a Poisson solution for
> Nc=1 with vacuum on the other side of the cell? It is unclear from the
> manual how one can produce a file for TS.Poisson  option.
>
> Thank you!
>
> Sincerely,
> Karen Fidanyan
> PhD student
> Max Planck Institute for the Structure and Dynamics of Matter
> Hamburg, Germany
> On 10/21/21 10:11 PM, Nick Papior wrote:
>
> Hi,
>
> I haven't checked your output. But you generally need to be even more
> careful about the electrode + extended electrode region in the device. You
> really need to make sure the potential is screened towards the electrode +
> constraining some atoms close to the electrode.
>
> Den tor. 21. okt. 2021 kl. 22.03 skrev Karen Fidanyan <
> karen.fidan...@mpsd.mpg.de>:
>
>> Dear Siesta users,
>>
>> I try to run CG with TranSIESTA and face the following behavior:
>> 1. The first geometry step, which consists of SIESTA and then
>> TranSIESTA, is fine.
>> 2. But at the second step, which is TranSIESTA only, the total energy
>> goes to a high positive value and kind-of-converges to something
>> unreasonable (see siesta.out in the attachment). It happens even though
>> I constrain the electrode and 2 crystal layers directly adjacent to the
>> electrode.
>>
>> Do you know how to interpret it and what is the trick to make TranSIESTA
>> work with moving atoms?
>>
>> Many thanks,
>> Karen Fidanyan
>> PhD student
>> Max Planck Institute for the Structure and Dynamics of Matter
>> Hamburg, Germany
>>
>>
>> --
>> 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
>
>

-- 
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] Running TranSIESTA for geometry relaxation

[Nick Papior]

Hi,

I haven't checked your output. But you generally need to be even more
careful about the electrode + extended electrode region in the device. You
really need to make sure the potential is screened towards the electrode +
constraining some atoms close to the electrode.

Den tor. 21. okt. 2021 kl. 22.03 skrev Karen Fidanyan <
karen.fidan...@mpsd.mpg.de>:

> Dear Siesta users,
>
> I try to run CG with TranSIESTA and face the following behavior:
> 1. The first geometry step, which consists of SIESTA and then
> TranSIESTA, is fine.
> 2. But at the second step, which is TranSIESTA only, the total energy
> goes to a high positive value and kind-of-converges to something
> unreasonable (see siesta.out in the attachment). It happens even though
> I constrain the electrode and 2 crystal layers directly adjacent to the
> electrode.
>
> Do you know how to interpret it and what is the trick to make TranSIESTA
> work with moving atoms?
>
> Many thanks,
> Karen Fidanyan
> PhD student
> Max Planck Institute for the Structure and Dynamics of Matter
> Hamburg, Germany
>
>
> --
> 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] K-points output from siesta

[Nick Papior]

Hi,

They are in 1/Bohr.

Den tir. 12. okt. 2021 kl. 22.00 skrev Pasan Henadeera <
henadeer...@gmail.com>:

> Dear Prof. Papior,
> In the output file SYSTEM_NAME.KP
> ,
> what is the unit using which the k-point coordinates are printed?
>
> Thanks
>
> --
> 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] Question about new methods in Transiesta+Removing all periodic boundary conditions:

[Nick Papior]

Hi,


Please see the tutorial t08 here
https://github.com/zerothi/ts-tbt-sisl-tutorial

It should have everything you need.

On Mon, 20 Sep 2021, 22:02 Zerota Achili,  wrote:

> Dear Prof. Papior,
>
>
> Recently I've read your paper "Removing all periodic boundary conditions:
> Efficient nonequilibrium Green’s function calculations".
> This new method in which version of Transiesta is implemented? And would
> you please share a simple input file to show how this method
> should be used in simulations? Any new blocks or flags with respect to the
> simple periodic case.
>
>
> Thanks for your nice attention.
> All the best,
> Zerota
>
>
>
> --
> 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] Query regarding transmission spectrum results

[Nick Papior]

Question and answer given here:
https://mattermodeling.stackexchange.com/questions/6696/can-transmission-spectrum-value-exceed-1-within-bias-window

Den fre. 3. sep. 2021 kl. 22.00 skrev Sankushkrishna Maheshuni <
sankushnov2...@gmail.com>:

> Hello siesta users,
> I'm trying to simulate a ZnO nanoribbon structure in siesta. When I
> performed the transport calculations, for a few bias points within the bias
> window, the transmission spectrum value exceeded 1. The transmission
> spectrum gives the probability of transmission of electrons. Since it is a
> probability function, its value shouldn't exceed 1. Can someone help me
> where could I be possibly going wrong? How can I solve this issue?
> 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] Nanowire bandgap issues

[Nick Papior]

Hi,

The kgrid_Monkhorst_Pack block is in units of reciprocal lattice vectors.
Secondly the displacement should only be used along periodic directions.
Here you seem to have just added them for no particular reason.

I think your block should look like this instead:
%block kgrid.MonkhorstPack
 1 0 0 0.
 0 1 0 0.
 0 0 32 0.5
%endblock
Please try and understand the difference between my block and what you had?

Den ons. 1. sep. 2021 kl. 22.02 skrev Pasan Henadeera :

> Dear sir,
> As per my understanding, the reciprocal lattice vectors (A,B,C) in 3D are
> defined as
> A=(2pi bxc)/(a (bxc))
> where, a,b,c represent real space vectors with x marking cross product.
>
> Hence for a set of a,b,c vectors perpendicular to each other in the
> positive real space, the reciprocal lattice vector A would fall along the
> same direction as the real space vector a.
>
> If so, the specification of my k points for the band structure calculation
> lie along the first lattice direction whereas my requirement is in the
> third dimension (completely my fault).
>
> However, I do not understand your statement that my s*election of k
> points are along a diagonal line of the 1st and 3rd lattice vectors*. Can
> you please clarify regarding this and help me understand the fault.
>
>
> Thank you
>
>
> On Tue, 31 Aug 2021 at 06:39, Pasan Henadeera 
> wrote:
>
>> Hi, thank you for the reply.
>> 1. I tried with and without fractional coordinates and the results were
>> similar.
>> 2. The atomic mass was specified because I wanted to make sure that the
>> problem was not caused due to that.
>> 3. Yes, the k points could be a source of the problem.
>> 4. I tried both SZ and DZ and there was not much variation in the
>> results. I shall try using SZP and DZP as well.
>>
>> I shall work on your suggestions and let you know what happens. Thanks
>> for the assistance.
>>
>>
>> Thank you
>>
>> On Tue, 31 Aug 2021 at 01:30, Nick Papior  wrote:
>>
>>> Hi,
>>>
>>> A couple of notes on the input. Why are you using fractional coordinates
>>> for such a system, it seems a bit weird to me. But ok, the system looks ok.
>>>
>>> You don't need to use the AtomicMass block in case you want to use the
>>> default mass of Si (which if I recall is 28.09).
>>>
>>> Your k-point input indicates to me that you don't understand what it
>>> does? The k-points you have selected are along a diagonal line of the 1st
>>> and 3rd lattice vector. You probably only want along the 3rd? Please
>>> carefully go through your input options and what they mean.
>>>
>>> Lastly, did you try and converge the basis set? Using only SZ might not
>>> be good enough here.
>>>
>>> Den søn. 29. aug. 2021 kl. 22.00 skrev Pasan Henadeera <
>>> henadeer...@gmail.com>:
>>>
>>>> Hello Siesta users,
>>>> I am trying to evaluate the band gap variation in Si nanowires (without
>>>> any passivation). However, I have been unable to obtain a reasonable band
>>>> structure comparable to available literature (
>>>> https://doi.org/10.1016/j.physe.2005.12.094).
>>>>
>>>> Any ideas or suggestions?
>>>>
>>>>
>>>> SystemName  Si
>>>> SystemLabel Si
>>>>
>>>> NumberOfSpecies 1
>>>> NumberOfAtoms   57
>>>>
>>>> %block ChemicalSpeciesLabel
>>>>   1  14  Si
>>>> %endblock ChemicalSpeciesLabel
>>>>
>>>> %block AtomicMass
>>>>   1  28
>>>> %endblock AtomicMass
>>>>
>>>> LatticeConstant 5.3162811000 Ang
>>>>
>>>> %block LatticeVectors
>>>>   0.00 17.00 0.00
>>>>   0.00 0.00 17.00
>>>>   1.00 0.00 0.00
>>>> %endblock LatticeVectors
>>>>
>>>>
>>>> AtomicCoordinatesFormat Fractional
>>>> %block AtomicCoordinatesAndAtomicSpecies
>>>> 0.4218750001 0.4531250001 0.750009 1
>>>> 0.4218750001 0.4843750001 0.250009 1
>>>> 0.4208485475 0.5157487486 0.7512270222 1
>>>> 0.4205211402 0.5462557586 0.2323127590 1
>>>> 0.4842479144 0.4208701616 0.2481823356 1
>>>> 0.4537269539 0.4205721769 0.7671556118 1
>>>> 0.4386097200 0.4385553039 0.9829884767 1
>>>> 0.4689609805 0.4376984553 0.5053350471 1
>>>> 0.4688488746 0.4688446650 0.0003473838 1
>>>> 0.43

Re: [SIESTA-L] Nanowire bandgap issues

[Nick Papior]

Hi,

A couple of notes on the input. Why are you using fractional coordinates
for such a system, it seems a bit weird to me. But ok, the system looks ok.

You don't need to use the AtomicMass block in case you want to use the
default mass of Si (which if I recall is 28.09).

Your k-point input indicates to me that you don't understand what it does?
The k-points you have selected are along a diagonal line of the 1st and 3rd
lattice vector. You probably only want along the 3rd? Please carefully go
through your input options and what they mean.

Lastly, did you try and converge the basis set? Using only SZ might not be
good enough here.

Den søn. 29. aug. 2021 kl. 22.00 skrev Pasan Henadeera <
henadeer...@gmail.com>:

> Hello Siesta users,
> I am trying to evaluate the band gap variation in Si nanowires (without
> any passivation). However, I have been unable to obtain a reasonable band
> structure comparable to available literature (
> https://doi.org/10.1016/j.physe.2005.12.094).
>
> Any ideas or suggestions?
>
>
> SystemName  Si
> SystemLabel Si
>
> NumberOfSpecies 1
> NumberOfAtoms   57
>
> %block ChemicalSpeciesLabel
>   1  14  Si
> %endblock ChemicalSpeciesLabel
>
> %block AtomicMass
>   1  28
> %endblock AtomicMass
>
> LatticeConstant 5.3162811000 Ang
>
> %block LatticeVectors
>   0.00 17.00 0.00
>   0.00 0.00 17.00
>   1.00 0.00 0.00
> %endblock LatticeVectors
>
>
> AtomicCoordinatesFormat Fractional
> %block AtomicCoordinatesAndAtomicSpecies
> 0.4218750001 0.4531250001 0.750009 1
> 0.4218750001 0.4843750001 0.250009 1
> 0.4208485475 0.5157487486 0.7512270222 1
> 0.4205211402 0.5462557586 0.2323127590 1
> 0.4842479144 0.4208701616 0.2481823356 1
> 0.4537269539 0.4205721769 0.7671556118 1
> 0.4386097200 0.4385553039 0.9829884767 1
> 0.4689609805 0.4376984553 0.5053350471 1
> 0.4688488746 0.4688446650 0.0003473838 1
> 0.4381741853 0.4690624505 0.5037780301 1
> 0.4533432439 0.4532006119 0.2542710091 1
> 0.4844977098 0.4534676431 0.7520747802 1
> 0.4843956661 0.4844028848 0.2508846043 1
> 0.4535760099 0.4845509954 0.7526387478 1
> 0.4379725900 0.5001831894 0.9964957459 1
> 0.4689187754 0.518849 0.4997524134 1
> 0.4688466704 0.5311626528 0.9994608317 1
> 0.4376911579 0.5310443690 0.4943530582 1
> 0.4535076989 0.5155265650 0.2484398088 1
> 0.4843981130 0.5156022583 0.7489904851 1
> 0.4845031869 0.5465300316 0.2479006330 1
> 0.4532537185 0.5467402717 0.7445710047 1
> 0.4386536374 0.5613490668 0.0209871088 1
> 0.4689504767 0.5623096662 0.4943742384 1
> 0.4537407911 0.5794778627 0.2321660756 1
> 0.4842634606 0.5791191600 0.7515145823 1
> 0.5462628443 0.4205258128 0.2322107930 1
> 0.5157447994 0.4208750213 0.7517376987 1
> 0.469254 0.4377903480 0.9998958351 1
> 0.5310470849 0.4376968379 0.4943589947 1
> 0.5311609069 0.4688409117 0.9995670075 1
> 0.482405 0.4689091066 0.4999235161 1
> 0.5154961788 0.4534701711 0.2478658343 1
> 0.5467429914 0.4532536631 0.7446390767 1
> 0.5465316338 0.4845048549 0.2478709280 1
> 0.5155991333 0.4843974423 0.7490231357 1
> 0.512391 0.512294 0.860448 1
> 0.5310933384 0.512038 0.4999818520 1
> 0.5311584743 0.5311590261 0.0003877805 1
> 0.506752 0.5310898094 0.4999793991 1
> 0.5155993795 0.5156016028 0.2509924240 1
> 0.5465322721 0.5154974225 0.7521165594 1
> 0.5467453831 0.5467413239 0.2554397791 1
> 0.5154934165 0.5465280455 0.7521133862 1
> 0.525233 0.5622200175 0.154108 1
> 0.5310541581 0.5623080249 0.5055918525 1
> 0.5157243943 0.5791157145 0.2486224609 1
> 0.5462587742 0.5794774930 0.7678772422 1
> 0.5613462417 0.4386515218 0.0210208787 1
> 0.5623109375 0.4689459928 0.4943827650 1
> 0.5794716486 0.4537426560 0.2321699186 1
> 0.5791173816 0.4842648445 0.7515189669 1
> 0.5622181911 0.506977 0.456673 1
> 0.5623061750 0.5310497879 0.5056290910 1
> 0.5791238231 0.5157378818 0.2484404107 1
> 0.5794790635 0.5462573038 0.7678478138 1
> 0.5613422586 0.5613429826 0.9788443617 1
> %endblock AtomicCoordinatesAndAtomicSpecies
>
> %block kgrid_Monkhorst_Pack
>0   1   0   0.5
>0   0   1   0.5
>32  0   0   0.5
> %endblock kgrid_Monkhorst_Pack
>
> XC.functional   LDA
> XC.authors  CA
> SpinPolarized   .false.
> MeshCutoff  300 Ry
> kgrid_cutoff100.0 Ang
>
> PAO.BasisSize   SZ
>
> MD.TypeOfRun   CG
> MD.VariableCelltrue
> MD.NumCGsteps  500
> MD.MaxCGDispl  0.1 Bohr
> MD.MaxForceTol 0.1 eV/Ang
> MD.MaxStressTol0.001 eV/Ang**3
> %block GeometryConstraints
>position   1   2
>stress 4   5   6
> %endblock GeometryConstraints
>
> MD.UseSaveXV true
>
> MaxSCFIterations  500
> DM.MixingWeight   0.01
> DM.NumberPulay3
> DM.Tolerance  1.d-3
> ElectronicTemperature 25 meV
> SolutionMethod   diagon
>
> BandLinesScale   pi/a
> %block BandLines
> 1  -0.590938025   0.00 0.00 Y # -Y
> 50  0.00  0.00   0.00 

Re: [SIESTA-L] Atomic coordinates affect the auxiliary supercell

[Nick Papior]

Hi,

I have opened up this as an issue here:
https://gitlab.com/siesta-project/siesta/-/issues/129

If you could please follow I may have something that you can test?

Den fre. 6. aug. 2021 kl. 22.02 skrev Karen Fidanyan <
karen.fidan...@mpsd.mpg.de>:

> Dear Siesta users,
>
> I have a question about how exactly periodicity works in Siesta and how
> the size of an auxiliary supercell is decided.
>
> Why I ask: I want to run calculations with Siesta being driven by an
> external code (i-PI). I have two options how to treat periodicity:
> a) I can wrap atoms to the unit cell inside the master code. This causes
> troubles with reusing the DM from a previous geometry if there were jumps
> of atoms to the opposite side of the cell. I'll write another email for
> this problem.
> b) I can pass the coordinates as they are, which implies possibility that
> some molecules will diffuse far away from the origin.
>
> In this email, I ask about (b) only.
> I do a simple test and put one atom far away from the box
> ##
> %block kgridMonkhorstPack
>  2 0 0  0.0
>  0 2 0  0.0
>  0 0 1  0.0
> %endblock kgridMonkhorstPack
>
> LatticeConstant 1. Bohr
> %block LatticeVectors
>  10.   0.   0.
>   0.  10.   0.
>   0.   0.  10.
> %endblock LatticeVectors
>
> AtomicCoordinatesFormat Bohr
> %block AtomicCoordinatesAndAtomicSpecies
>1.21.61.  2  O
>2.62.81.  1  H
>2.0   -0.91.  1  H
>  105.   105.   105.  1  H
> %endblock AtomicCoordinatesAndAtomicSpecies
> ##
>
> Doing this, I get crazy auxiliary supercell:
> **
> superc: Internal auxiliary supercell:23 x23 x23  =   12167
> superc: Number of atoms, orbitals, and projectors:  48668 340676 523181
> **
> It's unclear how Siesta treats atoms outside the unit cell, the manual
> just states "*Notice that the atomic positions (shifted or not) need not
> be within the cell formed by LatticeVectors, since periodic boundary
> conditions are always assumed*". Could you please explain this and maybe
> point to literature or to the relevant pieces of the code?
>
> Many thanks,
> Karen Fidanyan
> PhD student
> Max Planck Institute for the Structure and Dynamics of Matter
> Hamburg, Germany
>
> --
> 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] << SCF convergence issues >>

[Nick Papior]

What did you play with for mixing weights and kick etc?

A mixing weight of 0.25 is pretty high, if not excessively high in this
case. :)

Did you try, say 0.02, or something like that?

Also, kicks are *only* necessary when you have problems with stalls in
convergence. If you stall after 50 SCF, you should have a kick at that
point, but definitely not at every 3rd SCF, that may worsen your
convergence.

Den tor. 12. aug. 2021 kl. 22.02 skrev I. Camps :

> Hello SIESTers,
>
> I am trying to optimize some 4 atom Ni clusters. There are 4 types: one
> linear, one zigzag, one 2D and one 3D.
>
> Using the setup below, I don't get the calculations to converge even after
> 1000 SCF steps (which is huge!).
>
> I already play with DM.MixingWeight, SCF.Mixer.History, SCF.Mixer.Variant,
> SCF.Mixer.Kick, and nothing works.
>
> The tolerance is not even high, it is only 1E-3.
>
> The input is below.
>
> Any ideas, suggestions?
>
> Regards,
>
> Camps
>
> ###
> SystemName  NiM4-1Dlinear
> SystemLabel NiM4-1Dlinear
>
> LatticeConstant 12.787740 Ang
> %block LatticeVectors
>  1.394587   0.00 0.00
>  0.00   1.394587 0.00
>  0.00   0.00 1.00
> %endblock LatticeVectors
>
> NumberOfSpecies1
> NumberOfAtoms  4
>
> %block ChemicalSpeciesLabel
>   1  28  Ni
> %endblock ChemicalSpeciesLabel
>
> AtomicCoordinatesFormat Ang
>
> %block AtomicCoordinatesAndAtomicSpecies
>   8.9168000  8.7888600  9.6866000 1
>   8.9168000  8.7888600  7.5067061 1
>   8.9168000  8.7888600  3.1011000 1
>   8.9168000  8.7888600  5.2809939 1
> %endblock AtomicCoordinatesAndAtomicSpecies
>
>  -- SELF-CONSISTENT FIELD --
> PAO.BasisSize DZP
> MD.TypeOfRun  CG
> MD.NumCGsteps 1000
> MinSCFIterations  3
> MaxSCFIterations  1000
> SpinPolarized T
> MeshCutoff500 Ry
> DM.MixingWeight   0.25
> SCF.Mixer.History  6   # replace DM.NumberPulay
> #SCF.Mixer.Variant  GR
> SCF.Mixer.Kick 3
> DM.Tolerance  0.001
> XC.functional GGA
> XC.authorsPBE
> SolutionMethod diagon
>
> --
> 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] Compiling and running Siesta with openMPI-2.0.2, gfortran-6.3.0 (Debian 9)

[Nick Papior]

Hmm... That's quite annoying... :(

Thanks for reporting back!

Den ons. 30. jun. 2021 kl. 15.39 skrev Karen Fidanyan <
karen.fidan...@mpsd.mpg.de>:

> Dear Nick,
>
> I've tried Divide-and-Conquer, Expert and QR, they all fail with the same
> backtrace.
> I couldn't compile MRRR, I think my ScaLAPACK misses some routines.
>
> But, following your idea about a bug in ScaLAPACK, I recompiled Siesta
> with the MKL libraries from the Debian-9 repo. They are from 2019, not that
> old.
> It also failed for Divide-and-Conquer, but MRRR, Expert and QR work fine.
> I think it's enough for my purposes, I'll use MRRR. But I don't know what
> is wrong with D I attach the output of the D with MKL, maybe you find
> it useful.
>
> Thank you for help!
>
> Best,
> Karen
> On 6/30/21 11:25 AM, Nick Papior wrote:
>
> I have now tried to rerun it with 4.1.
> And I get no error, even in debug mode.
>
> My bet is that the scalapack library is an old and buggy one. But I could
> be wrong.
>
> Could you rerun with the different possibilities for Diag.Algorithm?
> I.e. try them all and see which ones works, and which doesn't, then report
> back.
>
> Den ons. 30. jun. 2021 kl. 11.16 skrev Karen Fidanyan <
> karen.fidan...@mpsd.mpg.de>:
>
>> Dear Nick,
>>
>> thanks for helping!
>>
>> I redid it with -Og flag. The input, *.psf and the output are attached. I
>> also attach debug.* files obtained with -DDEBUG.
>> I run as `mpirun -np 2 ~/soft/siesta-4.1/Obj-dbg-Og/siesta control.fdf
>> 2>&1 | tee siesta.out`.
>>
>> Sincerely,
>> Karen Fidanyan
>> On 6/28/21 10:22 PM, Nick Papior wrote:
>>
>> I can't rerun without psf files.
>>
>> Could you try and compile with -Og -g -fbacktrace (without fcheck=all).
>>
>> Then try again. :)
>>
>> Den man. 28. jun. 2021 kl. 22.01 skrev Karen Fidanyan <
>> karen.fidan...@mpsd.mpg.de>:
>>
>>> Dear Siesta users,
>>>
>>> I'm having a hard time trying to run SIESTA on my Debian-9 laptop.
>>> I have:
>>>
>>> GNU Fortran (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
>>> OpenMPI-2.0.2-2
>>> libblas 3.7.0-2, liblapack 3.7.0-2
>>> libscalapack-openmpi1 1.8.0-13
>>>
>>> My arch.make is the following:
>>> **
>>> .SUFFIXES:
>>> .SUFFIXES: .f .F .o .a .f90 .F90 .c
>>>
>>> SIESTA_ARCH = gfortran_openMPI
>>>
>>> FPP = $(FC) -E -P -x c
>>> FC = mpifort
>>> FC_SERIAL = gfortran
>>> FFLAGS = -O0 -g -fbacktrace -fcheck=all #-Wall
>>> FFLAGS_DEBUG = -g -O0
>>>
>>> PP = gcc -E -P -C
>>> CC = gcc
>>> CFLAGS = -O0 -g -Wall
>>>
>>> AR = ar
>>> RANLIB = ranlib
>>> SYS = nag
>>>
>>> LDFLAGS = -static-libgcc -ldl
>>>
>>> BLASLAPACK_LIBS = -llapack  -lblas \
>>>  -lscalapack-openmpi -lblacs-openmpi
>>> -lblacsF77init-openmpi \
>>>  -lblacsCinit-openmpi \
>>>  -lpthread -lm
>>>
>>> MPI_INTERFACE = libmpi_f90.a
>>> MPI_INCLUDE   = .
>>>
>>> FPPFLAGS_MPI = -DMPI -DMPI_TIMING -D_DIAG_WORK
>>> FPPFLAGS = $(DEFS_PREFIX) -DFC_HAVE_FLUSH -DFC_HAVE_ABORT $(FPPFLAGS_MPI)
>>>
>>> INCFLAGS = $(MPI_INCLUDE)
>>>
>>> LIBS = $(BLASLAPACK_LIBS) $(MPI_LIBS)
>>>
>>> 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)  $<
>>> **
>>>
>>> The code compiles without errors.
>>> If I run with Diag.ParallelOverK  True, I can run on multiple cores, no
>>> errors.
>>> With Diag.ParallelOverK  False, I can run `mpirun -np 1` without errors,
>>> but if I try to use >=2 cores, it fails with:
>>> **
>>> Program received signal SIGSEGV: Segmentation fa

Re: [SIESTA-L] Compiling and running Siesta with openMPI-2.0.2, gfortran-6.3.0 (Debian 9)

[Nick Papior]

I have now tried to rerun it with 4.1.
And I get no error, even in debug mode.

My bet is that the scalapack library is an old and buggy one. But I could
be wrong.

Could you rerun with the different possibilities for Diag.Algorithm?
I.e. try them all and see which ones works, and which doesn't, then report
back.

Den ons. 30. jun. 2021 kl. 11.16 skrev Karen Fidanyan <
karen.fidan...@mpsd.mpg.de>:

> Dear Nick,
>
> thanks for helping!
>
> I redid it with -Og flag. The input, *.psf and the output are attached. I
> also attach debug.* files obtained with -DDEBUG.
> I run as `mpirun -np 2 ~/soft/siesta-4.1/Obj-dbg-Og/siesta control.fdf
> 2>&1 | tee siesta.out`.
>
> Sincerely,
> Karen Fidanyan
> On 6/28/21 10:22 PM, Nick Papior wrote:
>
> I can't rerun without psf files.
>
> Could you try and compile with -Og -g -fbacktrace (without fcheck=all).
>
> Then try again. :)
>
> Den man. 28. jun. 2021 kl. 22.01 skrev Karen Fidanyan <
> karen.fidan...@mpsd.mpg.de>:
>
>> Dear Siesta users,
>>
>> I'm having a hard time trying to run SIESTA on my Debian-9 laptop.
>> I have:
>>
>> GNU Fortran (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
>> OpenMPI-2.0.2-2
>> libblas 3.7.0-2, liblapack 3.7.0-2
>> libscalapack-openmpi1 1.8.0-13
>>
>> My arch.make is the following:
>> **
>> .SUFFIXES:
>> .SUFFIXES: .f .F .o .a .f90 .F90 .c
>>
>> SIESTA_ARCH = gfortran_openMPI
>>
>> FPP = $(FC) -E -P -x c
>> FC = mpifort
>> FC_SERIAL = gfortran
>> FFLAGS = -O0 -g -fbacktrace -fcheck=all #-Wall
>> FFLAGS_DEBUG = -g -O0
>>
>> PP = gcc -E -P -C
>> CC = gcc
>> CFLAGS = -O0 -g -Wall
>>
>> AR = ar
>> RANLIB = ranlib
>> SYS = nag
>>
>> LDFLAGS = -static-libgcc -ldl
>>
>> BLASLAPACK_LIBS = -llapack  -lblas \
>>  -lscalapack-openmpi -lblacs-openmpi
>> -lblacsF77init-openmpi \
>>  -lblacsCinit-openmpi \
>>  -lpthread -lm
>>
>> MPI_INTERFACE = libmpi_f90.a
>> MPI_INCLUDE   = .
>>
>> FPPFLAGS_MPI = -DMPI -DMPI_TIMING -D_DIAG_WORK
>> FPPFLAGS = $(DEFS_PREFIX) -DFC_HAVE_FLUSH -DFC_HAVE_ABORT $(FPPFLAGS_MPI)
>>
>> INCFLAGS = $(MPI_INCLUDE)
>>
>> LIBS = $(BLASLAPACK_LIBS) $(MPI_LIBS)
>>
>> 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)  $<
>> **
>>
>> The code compiles without errors.
>> If I run with Diag.ParallelOverK  True, I can run on multiple cores, no
>> errors.
>> With Diag.ParallelOverK  False, I can run `mpirun -np 1` without errors,
>> but if I try to use >=2 cores, it fails with:
>> **
>> Program received signal SIGSEGV: Segmentation fault - invalid memory
>> reference.
>>
>> Backtrace for this error:
>> #0  0x2ba6eb754d1d in ???
>> #1  0x2ba6eb753f7d in ???
>> #2  0x2ba6ec95405f in ???
>> #3  0x2ba70ec1cd8c in ???
>> #4  0x2ba6eab438a4 in ???
>> #5  0x2ba6eab44336 in ???
>> #6  0x563b3f1cfead in __m_diag_MOD_diag_c
>>  at /home/fidanyan/soft/siesta-4.1/Src/diag.F90:709
>> #7  0x563b3f1d2ef9 in cdiag_
>>  at /home/fidanyan/soft/siesta-4.1/Src/diag.F90:2253
>> #8  0x563b3ebc7c8d in diagk_
>>  at /home/fidanyan/soft/siesta-4.1/Src/diagk.F:195
>> #9  0x563b3eb9d714 in __m_diagon_MOD_diagon
>>  at /home/fidanyan/soft/siesta-4.1/Src/diagon.F:265
>> #10  0x563b3ed897cb in __m_compute_dm_MOD_compute_dm
>>  at /home/fidanyan/soft/siesta-4.1/Src/compute_dm.F:172
>> #11  0x563b3edbfaa5 in __m_siesta_forces_MOD_siesta_forces
>>  at /home/fidanyan/soft/siesta-4.1/Src/siesta_forces.F:315
>> #12  0x563b3f9a4005 in siesta
>>  at /home/fidanyan/soft/siesta-4.1/Src/siesta.F:73
>> #13  0x563b3f9a408a in main
>>  at /home/fidanyan/soft/siesta-4.1/Src/siesta.F:10
>> --
>> mpirun notice

Re: [SIESTA-L] Compiling and running Siesta with openMPI-2.0.2, gfortran-6.3.0 (Debian 9)

[Nick Papior]

I can't rerun without psf files.

Could you try and compile with -Og -g -fbacktrace (without fcheck=all).

Then try again. :)

Den man. 28. jun. 2021 kl. 22.01 skrev Karen Fidanyan <
karen.fidan...@mpsd.mpg.de>:

> Dear Siesta users,
>
> I'm having a hard time trying to run SIESTA on my Debian-9 laptop.
> I have:
>
> GNU Fortran (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
> OpenMPI-2.0.2-2
> libblas 3.7.0-2, liblapack 3.7.0-2
> libscalapack-openmpi1 1.8.0-13
>
> My arch.make is the following:
> **
> .SUFFIXES:
> .SUFFIXES: .f .F .o .a .f90 .F90 .c
>
> SIESTA_ARCH = gfortran_openMPI
>
> FPP = $(FC) -E -P -x c
> FC = mpifort
> FC_SERIAL = gfortran
> FFLAGS = -O0 -g -fbacktrace -fcheck=all #-Wall
> FFLAGS_DEBUG = -g -O0
>
> PP = gcc -E -P -C
> CC = gcc
> CFLAGS = -O0 -g -Wall
>
> AR = ar
> RANLIB = ranlib
> SYS = nag
>
> LDFLAGS = -static-libgcc -ldl
>
> BLASLAPACK_LIBS = -llapack  -lblas \
>  -lscalapack-openmpi -lblacs-openmpi
> -lblacsF77init-openmpi \
>  -lblacsCinit-openmpi \
>  -lpthread -lm
>
> MPI_INTERFACE = libmpi_f90.a
> MPI_INCLUDE   = .
>
> FPPFLAGS_MPI = -DMPI -DMPI_TIMING -D_DIAG_WORK
> FPPFLAGS = $(DEFS_PREFIX) -DFC_HAVE_FLUSH -DFC_HAVE_ABORT $(FPPFLAGS_MPI)
>
> INCFLAGS = $(MPI_INCLUDE)
>
> LIBS = $(BLASLAPACK_LIBS) $(MPI_LIBS)
>
> 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)  $<
> **
>
> The code compiles without errors.
> If I run with Diag.ParallelOverK  True, I can run on multiple cores, no
> errors.
> With Diag.ParallelOverK  False, I can run `mpirun -np 1` without errors,
> but if I try to use >=2 cores, it fails with:
> **
> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
>
> Backtrace for this error:
> #0  0x2ba6eb754d1d in ???
> #1  0x2ba6eb753f7d in ???
> #2  0x2ba6ec95405f in ???
> #3  0x2ba70ec1cd8c in ???
> #4  0x2ba6eab438a4 in ???
> #5  0x2ba6eab44336 in ???
> #6  0x563b3f1cfead in __m_diag_MOD_diag_c
>  at /home/fidanyan/soft/siesta-4.1/Src/diag.F90:709
> #7  0x563b3f1d2ef9 in cdiag_
>  at /home/fidanyan/soft/siesta-4.1/Src/diag.F90:2253
> #8  0x563b3ebc7c8d in diagk_
>  at /home/fidanyan/soft/siesta-4.1/Src/diagk.F:195
> #9  0x563b3eb9d714 in __m_diagon_MOD_diagon
>  at /home/fidanyan/soft/siesta-4.1/Src/diagon.F:265
> #10  0x563b3ed897cb in __m_compute_dm_MOD_compute_dm
>  at /home/fidanyan/soft/siesta-4.1/Src/compute_dm.F:172
> #11  0x563b3edbfaa5 in __m_siesta_forces_MOD_siesta_forces
>  at /home/fidanyan/soft/siesta-4.1/Src/siesta_forces.F:315
> #12  0x563b3f9a4005 in siesta
>  at /home/fidanyan/soft/siesta-4.1/Src/siesta.F:73
> #13  0x563b3f9a408a in main
>  at /home/fidanyan/soft/siesta-4.1/Src/siesta.F:10
> --
> mpirun noticed that process rank 0 with PID 0 on node fenugreek exited
> on signal 11 (Segmentation fault).
> **
>
> I ran it by
> `mpirun -np 2 ~/soft/siesta-4.1/Obj-debug-O0/siesta control.fdf | tee
> siesta.out`
>
> The header of the broken calculation:
> 
>
>
> Siesta Version  : v4.1.5-1-g384057250
> Architecture: gfortran_openMPI
> Compiler version: GNU Fortran (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
> Compiler flags  : mpifort -O0 -g -fbacktrace -fcheck=all
> PP flags:  -DFC_HAVE_FLUSH -DFC_HAVE_ABORT -DMPI -DMPI_TIMING
> -D_DIAG_WORK
> Libraries   :  -llapack -lblas -lscalapack-openmpi -lblacs-openmpi
> -lblacsF77init-openmpi -lblacsCinit-openmpi -lpthread -lm
> PARALLEL version
>
> * Running on 2 nodes in parallel
> 
>
>
>
> I also attach the fdf file and the full output with an error.
> Do you have an idea what is wrong?
>
> Sincerely,
> Karen Fidanyan
> PhD student
> Max Planck Institute for the Structure and Dynamics of Matter
> Hamburg, Germany
>
>
> --
> 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] Question about sisl geometry creation

[Nick Papior]

That is because the geometry will be stored in the geometry object.

It seems you are new to Python? In any case reading up on using Python and
scripting in Python seems appropriate.
To write any geometry object, you would do: geometry.write("filename.xyz")
or what-ever file format implemented.

Den man. 28. jun. 2021 kl. 22.06 skrev Zerota Achili :

> Dear Prof. Papior,
>
> I am a beginner with your code sisl .
>
> I have noticed in the sisl introduction part you mentioned that for
> graphen  geometry creation
> we can use for example the following code:
>
> import sisl
> graphene = sisl.geom.graphene(1.42).repeat(100, 0).repeat(100, 1)
>
> I write to ask where this geometry will be stored (positon and cell
> structural parameters).
> I ran these few lines in my Jupyter notebook but could not see the
> geometry or any out file?
>
>
> Best regards,
> Zerota
>
>
>
>
>
>
>
>
>
>
>
> --
> 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] Transport calculation of long molecules

[Nick Papior]

We need more information to be able to help you.

Den tor. 17. jun. 2021 kl. 22.00 skrev zhyphy :

> Dear All，
> I want to calculate the transport properties of long molecules.
> when I set the kpoints for 1 1 100, the program will stop at
>
> transiesta: created H and S sparsity pattern:
>nrows_g=2364 nrows=2364 sparsity=.1379 nnzs=770702, refcount: 1>
>
> When the kpoints is set to  1 1 1   orI shorten the molecular length ,
> the program will work normally.
> How to solve this problem?
>
> 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] Transiesta calsulation not converging due to 'charge'

[Nick Papior]

Probably your screening towards the electrodes isn't good enough. So add
more electrode layers towards the electrode.

Den fre. 4. jun. 2021 kl. 22.02 skrev Shubham Tyagi <
shubhamtyagi...@gmail.com>:

> Dear SIESTA users,
>
> I am currently working on finding zero-bias transmission using TranSIESTA.
> My calculations are converged but the output is showing not converged. I
> guess it is due to 'dq' (charge not being converged). What can be the
> possible solution or source of error for charge not converging.
> THe error part of the output is as follows:
>
>
>
> SCF Convergence by DM+H criterion
> max |DM_out - DM_in| : 0.506445
> max |H_out - H_in|  (eV) : 0.649631
> SCF cycle converged after 616 iterations
> SCF_NOT_CONV: SCF did not converge in maximum number of steps (required).
> Geom step, scf iteration, dmax:0   616 0.05
> ABNORMAL_TERMINATION
> Geom step, scf iteration, dq:0   6167.437410
>
> Regards,
> Shubham Tygai
> Ph.D.  Scholar
>
> --
> 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] cube for non-cubic lattice

[Nick Papior]

Yes this is true. The denchar program can, currently, only write out cubic
grid files.

Den tir. 1. jun. 2021 kl. 22.02 skrev Reza Behjatmanesh-Ardakani <
reza.b@gmail.com>:

> yes,
> it seems that siesta converts rho to cube file in cubic format, even for
> non-cubic lattice.
>
>
> در تاریخ شنبه 29 مهٔ 2021،‏ 0:30 Nick Papior  نوشت:
>
>> Could you be more specific?
>> Would you like to convert the rho grid file into a cube file for a non
>> cubic lattice?
>>
>> On Thu, 27 May 2021, 22:01 Reza Behjatmanesh-Ardakani, <
>> reza.b@gmail.com> wrote:
>>
>>> Hi,
>>> How can generate cube file for non-cubic lattice?
>>> Thanks
>>>
>>> --
>>> 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] cube for non-cubic lattice

[Nick Papior]

Could you be more specific?
Would you like to convert the rho grid file into a cube file for a non
cubic lattice?

On Thu, 27 May 2021, 22:01 Reza Behjatmanesh-Ardakani, 
wrote:

> Hi,
> How can generate cube file for non-cubic lattice?
> Thanks
>
> --
> 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] constr.f problems

[Nick Papior]

Hi all,

Please do not complicate things... :)

Geometry.Constraints is quite sufficient for the things you mention here
(constraining all forces on a set of atoms).

Secondly, @Roberto the constr is called by all nodes, so it need not be MPI
aware.

Bottom line, if you can use the Geometry.Constraints, please stick with it.
Do _NOT_ use constr unless you are dealing with specialized constraints.

Den fre. 21. maj 2021 kl. 22.04 skrev Oscar :

> Hi,
>
> I think that the coordinates "xa" can only be used as an input. In this
> constr.f routine you can only change the values of the forces and stresses
> of the system, as they are the only outputs coming from this routine. I
> guess that you are also including the section:
>
> %block GeometryConstraints
>
> routine constr
>
> %endblock GeometryConstraints
>
> In your input "*.fdf" file. To constrain for example the movement of the
> "5" first atoms of the system I suggest to use this kind of code:
>
> n=5
>
> do i = 1, n
>
> fa ( 1 , i ) = 0.d0
>
> fa ( 2 , i ) = 0.d0
>
> fa ( 3 , i ) = 0.d0
>
> end do
>
> I hope this helps
>
> Óscar
>
>
> El 20/5/21 a las 10:40, Pablo Álvarez Rodríguez escribió:
>
> Dear SIESTA users.
> I am currently struggling to make constraints to certain atom blocks in
> SIESTA. For so, I use *constr.f* modified by nullifying the atomic forces
> by including the code line :
>
> *fa(1:3,1:i)=0*
>
> where *i* is the number of atoms I want to constrain. Afterwards I
> compile the new siesta file with the modified constr.f in order to use it,
> but it seems it doesn't work properly, as atoms still suffer movements even
> after constraining them with constr.f.
> I don't really understand how *constr.f* works as I may forget something.
> Do I need to include anything more in order to make a working constraint,
> like for example, rewrite the coordinates with xa?
>
> --
>
> Yours Sincerely
>
> *Pablo Álvarez Rodríguez.*
> .
>
>
> *AVISO LEGAL*. Este mensaje puede contener información reservada y
> confidencial. Si usted no es el destinatario no está autorizado a copiar,
> reproducir o distribuir este mensaje ni su contenido. Si ha recibido este
> mensaje por error, le rogamos que lo notifique al remitente.
> Le informamos de que sus datos personales, que puedan constar en este
> mensaje, serán tratados en calidad de responsable de tratamiento por la
> UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA (UNED) c/ Bravo Murillo, 38,
> 28015-MADRID-, con la finalidad de mantener el contacto con usted. La base
> jurídica que legitima este tratamiento, será su consentimiento, el interés
> legítimo o la necesidad para gestionar una relación contractual o similar.
> En cualquier momento podrá ejercer sus derechos de acceso, rectificación,
> supresión, oposición, limitación al tratamiento o portabilidad de los
> datos, ante la UNED, Departamento de Política Jurídica de Seguridad de la
> Información , o a través de la Sede electrónica
>  de la Universidad.
> Para más información visite nuestra Política de Privacidad
> .
>
> --
> 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] << Increasing RHO mesh >>

[Nick Papior]

I have looked into it. And as far as I can see, it just takes a really long
time... Like, many hours (at least).
I can't really say how long it will take for this system.

Denchar is sadly not parallel and could use an overhaul on that part.

Den fre. 16. apr. 2021 kl. 22.02 skrev I. Camps :

> Hi Nick,
>
> Here are two links with all the inputs for DENCHAR:
> Link 1:
> https://lamodel.unifal-mg.edu.br/downloads/Camps_DencharInput.tar.gz
> Link 2:
> https://drive.google.com/file/d/1GyjLmpOEZ553-A7R8r9oXqwlzx9NcQGb/view?usp=sharing
>
> Also, I compiled DENCHAR with *-debug all -g* options (I am using Intel
> suite), but no new message appear.
>
> Thank you for your disponibility.
>
> []'s,
>
> Camps
>
>
> On Wed, Apr 14, 2021 at 5:01 PM Nick Papior  wrote:
>
>> Could you perhaps create a complete tar.gz so that I can test.
>> Otherwise, you may recompile denchar with full debug options, that should
>> give more details when it crashes.
>>
>> Den fre. 9. apr. 2021 kl. 22.07 skrev I. Camps :
>>
>>> Hello Nick,
>>>
>>> My input file is below. I duplicate the grid size.
>>>
>>> Also, I save the output from DENCHAR to a file and keep monitoring the
>>> CPU and memory usage.
>>>
>>> In the output there is no indication of error and the memory usage keep
>>> above 4GB with a 49% use (my note have 8GB).
>>>
>>> ### INPUT
>>> SystemLabel BN-Ni-p4-dCRITIC2
>>> NumberOfSpecies3
>>> %block ChemicalSpeciesLabel
>>>   1   5  B
>>>   2   7  N
>>>   3  28  Ni
>>> %endblock ChemicalSpeciesLabel
>>> Denchar.TypeOfRun  3D
>>> Denchar.PlotCharge T
>>> Denchar.CoorUnits   Ang   # Format for coordinate of the
>>> points
>>># Bohr
>>># Ang
>>> Denchar.DensityUnits   Ele/Ang**3 # Units of Charge Density
>>># Ele/bohr**3
>>># Ele/Ang**3
>>># Ele/UnitCell
>>> Denchar.NumberPointsX  480
>>> Denchar.NumberPointsY  480
>>> Denchar.NumberPointsZ  360
>>>
>>> Denchar.MinX  0  Ang
>>> Denchar.MaxX  17.833623 Ang
>>> Denchar.MinY  0 Ang
>>> Denchar.MaxY  17.833623  Ang
>>> Denchar.MinZ  0  Ang
>>> Denchar.MaxZ  12.171076 Ang
>>> ###
>>>
>>> ### OUTPUT
>>> ...
>>> ...
>>>  115 23.089612.3513 2.6562
>>>116 23.041412.373710.7105
>>>    117     23.060412.365518.7637
>>>118 24.088814.5243 1.3261
>>>119 24.059614.5373 9.3802
>>>120 24.062314.539317.4349
>>>121 14.8510 5.857515.3723
>>>
>>>Generating Charge Density values on the grid now
>>>Please, wait
>>> ###
>>>
>>>
>>> Regards,
>>>
>>> Camps
>>>
>>>
>>> On Wed, Apr 7, 2021 at 5:17 PM Nick Papior  wrote:
>>>
>>>> Hi,
>>>>
>>>> Hmm.. That depends on the options you use. It could be that you run out
>>>> of memory?
>>>> Perhaps some more information about what was before this would be
>>>> useful? I.e. what does denchar print before writing "Killed"?
>>>>
>>>> Den tor. 1. apr. 2021 kl. 22.02 skrev I. Camps :
>>>>
>>>>> Thank you very much Nick!
>>>>>
>>>>> I am using the second option...
>>>>>
>>>>> The original mesh is 240x240x180. I tried to double it, but DENCHAR
>>>>> just stopped with a simple text: "Killed", without any information about.
>>>>>
>>>>> Do you have a recommendation about the best form to select the grid?
>>>>>
>>>>> []'s,
>>>>>
>>>>> Camps
>>>>>
>>>>>
>>>>> On Mon, Mar 29, 2021 at 5:02 PM Nick Papior 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> You can use sisl to interpolate and write out the a cube file.
>>>>>>
>>>>>> For instan

Re: [SIESTA-L] << Increasing RHO mesh >>

[Nick Papior]

Could you perhaps create a complete tar.gz so that I can test.
Otherwise, you may recompile denchar with full debug options, that should
give more details when it crashes.

Den fre. 9. apr. 2021 kl. 22.07 skrev I. Camps :

> Hello Nick,
>
> My input file is below. I duplicate the grid size.
>
> Also, I save the output from DENCHAR to a file and keep monitoring the CPU
> and memory usage.
>
> In the output there is no indication of error and the memory usage keep
> above 4GB with a 49% use (my note have 8GB).
>
> ### INPUT
> SystemLabel BN-Ni-p4-dCRITIC2
> NumberOfSpecies3
> %block ChemicalSpeciesLabel
>   1   5  B
>   2   7  N
>   3  28  Ni
> %endblock ChemicalSpeciesLabel
> Denchar.TypeOfRun  3D
> Denchar.PlotCharge T
> Denchar.CoorUnits   Ang   # Format for coordinate of the points
># Bohr
># Ang
> Denchar.DensityUnits   Ele/Ang**3 # Units of Charge Density
># Ele/bohr**3
># Ele/Ang**3
># Ele/UnitCell
> Denchar.NumberPointsX  480
> Denchar.NumberPointsY  480
> Denchar.NumberPointsZ  360
>
> Denchar.MinX  0  Ang
> Denchar.MaxX  17.833623 Ang
> Denchar.MinY  0 Ang
> Denchar.MaxY  17.833623  Ang
> Denchar.MinZ  0  Ang
> Denchar.MaxZ  12.171076 Ang
> ###
>
> ### OUTPUT
> ...
> ...
>  115 23.089612.3513 2.6562
>116 23.041412.373710.7105
>117 23.060412.365518.7637
>118 24.088814.5243 1.3261
>119 24.059614.5373 9.3802
>120 24.062314.539317.4349
>121 14.8510 5.857515.3723
>
>Generating Charge Density values on the grid now
>Please, wait
> ###
>
>
> Regards,
>
> Camps
>
>
> On Wed, Apr 7, 2021 at 5:17 PM Nick Papior  wrote:
>
>> Hi,
>>
>> Hmm.. That depends on the options you use. It could be that you run out
>> of memory?
>> Perhaps some more information about what was before this would be useful?
>> I.e. what does denchar print before writing "Killed"?
>>
>> Den tor. 1. apr. 2021 kl. 22.02 skrev I. Camps :
>>
>>> Thank you very much Nick!
>>>
>>> I am using the second option...
>>>
>>> The original mesh is 240x240x180. I tried to double it, but DENCHAR just
>>> stopped with a simple text: "Killed", without any information about.
>>>
>>> Do you have a recommendation about the best form to select the grid?
>>>
>>> []'s,
>>>
>>> Camps
>>>
>>>
>>> On Mon, Mar 29, 2021 at 5:02 PM Nick Papior 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> You can use sisl to interpolate and write out the a cube file.
>>>>
>>>> For instance,
>>>>
>>>> sgrid siesta.RHO --interp 300 400 400 --out rho.cube
>>>>
>>>> will interpolate the RHO grid to a size of 300, 400, 400, x, y, z
>>>> directions. Please refer to sgrid --help for more information. For instance
>>>> the interpolation method may be quite important in your case.
>>>>
>>>> Alternatively you can use denchar to replot the density matrix files
>>>> using a denser grid. This is of course more precise since it isn't
>>>> interpolation but using the same DM to recreate the full grid on a
>>>> different mesh.
>>>>
>>>> Good luck!
>>>>
>>>> Den søn. 28. mar. 2021 kl. 23.01 skrev I. Camps :
>>>>
>>>>> Dear SIESTers,
>>>>>
>>>>> I am doing a critical point study using the package CRITIC2, but for
>>>>> SIESTA, it only accepts the RHO density in cube format, so its results are
>>>>> dependent on the quality of the used grid.
>>>>>
>>>>> Is it possible to increase the mesh for the grid where RHO is
>>>>> calculated?
>>>>>
>>>>> []'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/)
>>
>
> --
> 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] extracting band gap from EIG file

[Nick Papior]

Yes. That could be done.

Den tor. 8. apr. 2021 kl. 22.03 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Oh in that case then I just have to go through the band structure. Then I
> go through the EIG file to find the exact values.
>
> Is that 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: *Thursday, 8 April 2021 6:06 AM
> *To: *siesta-l 
> *Subject: *Re: [SIESTA-L] extracting band gap from EIG file
>
>
>
> This depends on which bandgap you want?
>
>
>
> 1) An indirect bandgap
>
> Here you should take the lowest unoccupied state for *all* kpoints, and
> the highest occupied state for *all* kpoints. Then the difference between
> the two is the indirect bandgab.
>
> 2) A direct bandgap
>
> Here you should take the lowest unoccupied state for ONE kpoint, and the
> highest occupied state for the same kpoint. The difference between the two
> is the direct bandgap for that k-point. You then repeat this for *all*
> kpoints and take the lowest one of them all. That is the direct bandgap.
>
>
>
> Note however, that it is important you have a sufficiently dense kgrid to
> get reasonable results. This is of course material dependent.
>
>
>
>
>
>
>
> Den ons. 31. mar. 2021 kl. 22.04 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Good afternoon,
>
>1. I was wondering if I want to extract the bandgap other than from
>the PDOS, is it possible to do so from the EIG file?
>2. I heard it before but I am not sure by looking at the different k
>points in the EIG file, which k pt to choose? Is it based on the band
>structure and closest to the Fermi energy?
>
> Thank you and looking forward to everyones’ thoughts
>
> Thank you,
>
> 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/
> <https://protect-au.mimecast.com/s/i_nGCD1vlpT5jyDP0fWtCDg?domain=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/)
>


-- 
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] << Increasing RHO mesh >>

[Nick Papior]

Hi,

Hmm.. That depends on the options you use. It could be that you run out of
memory?
Perhaps some more information about what was before this would be useful?
I.e. what does denchar print before writing "Killed"?

Den tor. 1. apr. 2021 kl. 22.02 skrev I. Camps :

> Thank you very much Nick!
>
> I am using the second option...
>
> The original mesh is 240x240x180. I tried to double it, but DENCHAR just
> stopped with a simple text: "Killed", without any information about.
>
> Do you have a recommendation about the best form to select the grid?
>
> []'s,
>
> Camps
>
>
> On Mon, Mar 29, 2021 at 5:02 PM Nick Papior  wrote:
>
>> Hi,
>>
>> You can use sisl to interpolate and write out the a cube file.
>>
>> For instance,
>>
>> sgrid siesta.RHO --interp 300 400 400 --out rho.cube
>>
>> will interpolate the RHO grid to a size of 300, 400, 400, x, y, z
>> directions. Please refer to sgrid --help for more information. For instance
>> the interpolation method may be quite important in your case.
>>
>> Alternatively you can use denchar to replot the density matrix files
>> using a denser grid. This is of course more precise since it isn't
>> interpolation but using the same DM to recreate the full grid on a
>> different mesh.
>>
>> Good luck!
>>
>> Den søn. 28. mar. 2021 kl. 23.01 skrev I. Camps :
>>
>>> Dear SIESTers,
>>>
>>> I am doing a critical point study using the package CRITIC2, but for
>>> SIESTA, it only accepts the RHO density in cube format, so its results are
>>> dependent on the quality of the used grid.
>>>
>>> Is it possible to increase the mesh for the grid where RHO is calculated?
>>>
>>> []'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] about the transiesta/tbtrans in the system with hexagonal cells

[Nick Papior]

Isn't this the same question as you posted here:
https://answers.launchpad.net/siesta/+question/696322
?
Otherwise, have a look there.

Den ons. 31. mar. 2021 kl. 22.04 skrev Bo Xiao :

> ​
>
> Dear all,
>
>
> I am trying to calculate the current values in the system with hexagonal
> cell.
>
> I am wondering whether my input files are correct.?
>
> The input files for electrode and scattering region calculations could be
> found in attachments.
>
> Note that the structures of scattering region are set up using different
> methods, while the calculated current values are quite different. What is
> wrong?
>
>
> Best Wishes
>
> Xiaoboy
>
> --
> 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] extracting band gap from EIG file

[Nick Papior]

This depends on which bandgap you want?

1) An indirect bandgap
Here you should take the lowest unoccupied state for *all* kpoints, and the
highest occupied state for *all* kpoints. Then the difference between the
two is the indirect bandgab.
2) A direct bandgap
Here you should take the lowest unoccupied state for ONE kpoint, and the
highest occupied state for the same kpoint. The difference between the two
is the direct bandgap for that k-point. You then repeat this for *all*
kpoints and take the lowest one of them all. That is the direct bandgap.

Note however, that it is important you have a sufficiently dense kgrid to
get reasonable results. This is of course material dependent.



Den ons. 31. mar. 2021 kl. 22.04 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good afternoon,
>
>1. I was wondering if I want to extract the bandgap other than from
>the PDOS, is it possible to do so from the EIG file?
>2. I heard it before but I am not sure by looking at the different k
>points in the EIG file, which k pt to choose? Is it based on the band
>structure and closest to the Fermi energy?
>
> Thank you and looking forward to everyones’ thoughts
>
> Thank you,
>
> 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] MD.Annealing

[Nick Papior]

Hi,

Thanks for reporting the bug on the targetpressure. This will be fixed in
the next release.

Could you share your complete input file?

Den ons. 24. mar. 2021 kl. 22.10 skrev Sergey Lisenkov :

> Dear users,
>
> I am trying to anneal a structure from high temperature to low temperature
> under pressure. For this I used experimental parameters at high temperature
> and the following parameters in my input file:
>
> ===
> MD.TypeOfRunAnneal
>
> MD.TargetPressure XXX GPa
>
> MD.InitialTimeStep  1
> MD.FinalTimeStep   1
> MD.LengthTimeStep  1 fs
>
> MD.InitialTemperature 500.0 K
> MD.TargetTemperature  1 K
>
> MD.AnnealOption TemperatureAndPressure
> =
> here, XXX=0,..., 10 (target pressure).
>
> First of all, manual for 4.1.5 version tells that I can use
> "Target.Pressure" option instead of "MD.TargetPressure", but it seem it was
> ignored. Anyway, when I look how the MD is going, I see that lattice angles
> do not change at all:
>
> initial:
>
> %block LatticeVectors
> 9.5229997635 0.00 0.00
> 0.0016.4943199158 0.00
> 0.00 0.00 6.638114
> %endblock LatticeVectors
>
> and after 300 steps:
>9.535672771 0.0 0.0
>  0.016.513421151 0.0
>  0.0 0.0 6.647209416
>
> so, angles are 90 degrees all the time.
>
> It confuses me. If I do a structural relaxation of high temperature phase
> (not MD) it should transform to monoclinic structure with beta angle ~ 95
> degrees. But it doesn't happen here. Am I missing some input parameter(s)
> for my calculations?
>
> Thanks,
>  Sergey
>
>
> --
> 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] Finding fat bands without redoing the calculation

[Nick Papior]

If you have the hamiltonian output from siesta, then yes. sisl can do it.
However, for large systems it may take quite some time since sisl is a
serial code (with the possibility of using threaded LAPACK/BLAS).

This tutorial
http://zerothi.github.io/sisl/docs/latest/tutorials/tutorial_siesta_2.html#Calculating-DOS-and-PDOS
will show you how to do a fat-band calculation.
While the tutorial is for graphene, it can be followed for any system.

Otherwise, you should follow Alberto's suggestion about redoing the
calculation by reusing the DM, this should bypass a large fraction of the
computation time.

Den fre. 2. apr. 2021 kl. 22.01 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> I was wondering if there is an alternative as I already have done
> calculations which have taken up to 40 hrs to work.
>
> That is why I needed to find an alternative.
>
> Thank you Alberto though for the insight.
>
> EL-abed
>
>
>
> El-abed Haidar | Doctor of Philosophy (Science)
>  Condensed Matter Theory (CMT) Group| School of Physics
>  THE UNIVERSITY OF SYDNEY  | NSW | 2006
>
>
>
> *From: *Alberto Garcia 
> *Sent: *Friday, 2 April 2021 7:01 AM
> *To: *siesta-l 
> *Subject: *Re: [SIESTA-L] Finding fat bands without redoing the
> calculation
>
>
>
> Hi,
>
> You can follow the standard procedure of carrying out the ground-state
> calculation first, and then re-using the density-matrix to start a new
> calculation for
> the analysis you require. That will save you the work of re-converging the
> electronic structure. Please see the manual for the option dm-use-save-dm.
>
>  Alberto
>
> - El 31 de Marzo de 2021, a las 18:56, El-abed Haidar
> ehai2...@uni.sydney.edu.au escribió:
>
> | Good evening,
> |
> |1. I was wondering for a large SIESTA calculation, if I forgot the
> commands in
> |the fdf file to do a fat band calculation and do not want to repeat
> the
> |calculation, is there an alternative ? Maybe sisl can?
> |2. Does anyone have another way around this? Or am I forced to redo
> it with the
> |fatband commands?
> |3. If so, may I ask any advice by mentioning all the required fatband
> commands?
> |
> |
> | Thank you and looking forward to everyone’s 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 (
> https://protect-au.mimecast.com/s/wGTOC81V0PT6Xy7zNtnFnSY?domain=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] << Increasing RHO mesh >>

[Nick Papior]

Hi,

You can use sisl to interpolate and write out the a cube file.

For instance,

sgrid siesta.RHO --interp 300 400 400 --out rho.cube

will interpolate the RHO grid to a size of 300, 400, 400, x, y, z
directions. Please refer to sgrid --help for more information. For instance
the interpolation method may be quite important in your case.

Alternatively you can use denchar to replot the density matrix files using
a denser grid. This is of course more precise since it isn't interpolation
but using the same DM to recreate the full grid on a different mesh.

Good luck!

Den søn. 28. mar. 2021 kl. 23.01 skrev I. Camps :

> Dear SIESTers,
>
> I am doing a critical point study using the package CRITIC2, but for
> SIESTA, it only accepts the RHO density in cube format, so its results are
> dependent on the quality of the used grid.
>
> Is it possible to increase the mesh for the grid where RHO is calculated?
>
> []'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] Electrode connectivity is not perfect

[Nick Papior]

Hi,

Den tor. 18. mar. 2021 kl. 22.03 skrev Dwaipayan Chakraborty <
dc...@snu.edu.in>:

> Dear All,
>
> I am doing I-V calculations for a 2D sheet in the siesta 4.1-b4 version.
> The electrode calculation has completed successfully but the scattering
> region calculation is showing the error:
>
Please use siesta 4.1.5! Update immediately :)

>
> Electrode connectivity is not perfect, refer to the manual for achieving a
> perfect electrode.
>
Did you read the manual? See section 10.4.2.
Basically your orbital ranges extends beyond the neighbouring cell thus
connecting to the 2nd nearest cell. This violates the calculation of the
self-energy if one is not careful.

>
> Previously in the 4.0 version, I did the calculation with the same
> structure without any problem. I have attached the electrode and scattering
> region files for reference.
>
Yes, but 4.0 did not check for connectivity. And thus one could more easily
do something unphysical in 4.0 and prior versions.

>
> Any help will be highly appreciated.
>
> Thanks,
> Dwaipayan Chakraborty
> --
> *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/)
>


-- 
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] About TbTrans and K points

[Nick Papior]

Yes. :)

Den ons. 3. mar. 2021 kl. 13.21 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Thank you very much.
>
> I think I understand now.
>
> Converge k_{electrode} then k_{TranSIESTA} and from there you increase
> TBT.k to get better pdos and T(E,V)
>
> 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
>
>
>
> *From: *Nick Papior 
> *Sent: *Tuesday, 2 March 2021 6:33 PM
> *To: *El-abed Haidar 
> *Cc: *siesta-l@uam.es
> *Subject: *Re: [SIESTA-L] About TbTrans and K points
>
>
>
> Hi,
>
>
>
> Den man. 1. mar. 2021 kl. 23.50 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Thank you Nick for the reply.
>
>1. So long story short, 1 1 100 is considered a converged K pt set for
>the electrode but not necessary for the entire system.
>
> No! That was not what I wrote, and it is wrong. :)
>
>
>
> When you said:
>
> 2) start with this k-point sampling for your transiesta calculation and
> check if the electronic structure changes if you further increase k-points
>
> *Does that mean I can just start with TranSIESTA at 1 1 100, then look at
> its total energy or PDOS. Then try 3 1 100, 5 1 100 and so on and do a
> convergence test WITHOUT DOING THE SAME FOR THE ELECTRODES? Is that
> correct? OR should I start from the electrode calculations every single
> time? I am asking that because I was surprised from 1):*
>
> No, as I wrote, start converging the electrodes. *Then* converge
> transiesta.
>
>
>
> Could you please read section 10.5 in the 4.1.5 manual? It has some clear
> steps to do.
>
> 1) converge your electrode transverse k-points, using 100 k-points along
> the semi-infinite direction is fine
>
>
>
>
>
> The reason for all what I have asked is because I assumed number 3 is
> enough to converge my k points but it does not seem to be the case.
>
>
>
> Looking forward to your thoughts Nick.
>
> 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, 2 March 2021 8:06 AM
> *To: *siesta-l 
> *Subject: *Re: [SIESTA-L] About TbTrans and K points
>
>
>
> Like any other DFT calculation you have to converge the physical
> properties with k-points. With TranSiesta + TBtrans this is no different.
>
>
>
> A basic scheme could be this:
>
> 1) converge your electrode transverse k-points, using 100 k-points along
> the semi-infinite direction is fine
>
> 2) start with this k-point sampling for your transiesta calculation and
> check if the electronic structure changes if you further increase k-points
>
> 3) Once you have found a suitable k-point sampling for the electronic
> structure you need to converge the current + DOS in tbtrans, this usually
> takes many more k-points than transiesta. But you shouldn't redo the
> transiesta calculations with these k-points samplings!
>
>
>
>
>
> Den lør. 27. feb. 2021 kl. 22.01 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Good evening everyone,
>
> Sorry if this question has been answered before but I was wondering:
>
>
>
> When we start with a transport study we choose 1 1 100  for electrode and
> then scattering calculations to save time. The reason is to make sure we
> have a large k point set with 100 in the transport direction and as a
> result I get myself some I-V curve.
>
> My question is if I want to increase the number of K points can I start
> with the TbTrans and increase the k points using TBT.k[ a 1 100] with a >1
> ? Or am I suppose to start from the beginning with increasing K points ?
> Why 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
>
>
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/
> <https://protect-au.mimecast.com/s/WBCBCANpgjCDo4GmfGbJvG?domain=max-centre.eu/>
> )
>
>
>
>
> --
>
> Kind regards Nick
>
>
>
>
>
>
> --
>
> Kind regards Nick
>
>
>


-- 
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] About TbTrans and K points

[Nick Papior]

Hi,

Den man. 1. mar. 2021 kl. 23.50 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Thank you Nick for the reply.
>
>1. So long story short, 1 1 100 is considered a converged K pt set for
>the electrode but not necessary for the entire system.
>
> No! That was not what I wrote, and it is wrong. :)

>
>
> When you said:
>
> 2) start with this k-point sampling for your transiesta calculation and
> check if the electronic structure changes if you further increase k-points
>
> *Does that mean I can just start with TranSIESTA at 1 1 100, then look at
> its total energy or PDOS. Then try 3 1 100, 5 1 100 and so on and do a
> convergence test WITHOUT DOING THE SAME FOR THE ELECTRODES? Is that
> correct? OR should I start from the electrode calculations every single
> time? I am asking that because I was surprised from 1):*
>
No, as I wrote, start converging the electrodes. *Then* converge transiesta.

Could you please read section 10.5 in the 4.1.5 manual? It has some clear
steps to do.

> 1) converge your electrode transverse k-points, using 100 k-points along
> the semi-infinite direction is fine
>
>
>
>
>
> The reason for all what I have asked is because I assumed number 3 is
> enough to converge my k points but it does not seem to be the case.
>
>
>
> Looking forward to your thoughts Nick.
>
> 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, 2 March 2021 8:06 AM
> *To: *siesta-l 
> *Subject: *Re: [SIESTA-L] About TbTrans and K points
>
>
>
> Like any other DFT calculation you have to converge the physical
> properties with k-points. With TranSiesta + TBtrans this is no different.
>
>
>
> A basic scheme could be this:
>
> 1) converge your electrode transverse k-points, using 100 k-points along
> the semi-infinite direction is fine
>
> 2) start with this k-point sampling for your transiesta calculation and
> check if the electronic structure changes if you further increase k-points
>
> 3) Once you have found a suitable k-point sampling for the electronic
> structure you need to converge the current + DOS in tbtrans, this usually
> takes many more k-points than transiesta. But you shouldn't redo the
> transiesta calculations with these k-points samplings!
>
>
>
>
>
> Den lør. 27. feb. 2021 kl. 22.01 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Good evening everyone,
>
> Sorry if this question has been answered before but I was wondering:
>
>
>
> When we start with a transport study we choose 1 1 100  for electrode and
> then scattering calculations to save time. The reason is to make sure we
> have a large k point set with 100 in the transport direction and as a
> result I get myself some I-V curve.
>
> My question is if I want to increase the number of K points can I start
> with the TbTrans and increase the k points using TBT.k[ a 1 100] with a >1
> ? Or am I suppose to start from the beginning with increasing K points ?
> Why 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
>
>
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/
> <https://protect-au.mimecast.com/s/jFLZCNLJyQUg7A6DFmrwJs?domain=max-centre.eu/>
> )
>
>
>
>
> --
>
> Kind regards Nick
>
>
>


-- 
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] About TbTrans and K points

[Nick Papior]

Like any other DFT calculation you have to converge the physical properties
with k-points. With TranSiesta + TBtrans this is no different.

A basic scheme could be this:
1) converge your electrode transverse k-points, using 100 k-points along
the semi-infinite direction is fine
2) start with this k-point sampling for your transiesta calculation and
check if the electronic structure changes if you further increase k-points
3) Once you have found a suitable k-point sampling for the electronic
structure you need to converge the current + DOS in tbtrans, this usually
takes many more k-points than transiesta. But you shouldn't redo the
transiesta calculations with these k-points samplings!


Den lør. 27. feb. 2021 kl. 22.01 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good evening everyone,
>
> Sorry if this question has been answered before but I was wondering:
>
>
>
> When we start with a transport study we choose 1 1 100  for electrode and
> then scattering calculations to save time. The reason is to make sure we
> have a large k point set with 100 in the transport direction and as a
> result I get myself some I-V curve.
>
> My question is if I want to increase the number of K points can I start
> with the TbTrans and increase the k points using TBT.k[ a 1 100] with a >1
> ? Or am I suppose to start from the beginning with increasing K points ?
> Why 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
>
>
>
> --
> 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] << Compiling Utils using build_all scrip >>

[Nick Papior]

Yeah, that is something we need to address.

Could you please add this to your arch.make file:

NETCDF_LIBS += -lnetcdff -lnetcdf -lhdf5_hl -lhdf5 -lz

Den tir. 16. feb. 2021 kl. 22.00 skrev I. Camps :

> Hi Nick,
>
> Thank you for your email.
>
> 1. We can't see your arch.make, so there may be problems related to that.
>>
> The used arch.make file is attached here.
> I successfully compiled SIESTA, both v4.1.5 and PSML version, without any
> errors with it
>
>
>> 2. You shouldn't do any manual copies, so I bet your copy of the
>> xmlparser folder causes problems. Could you please try from a clean
>> pdosxml folder, it should only contain these files:
>> total 196K
>> -rw-r--r-- 1 nicpa nicpa  28K Oct  9  2019 f2kcli-manual.txt
>> -rw-r--r-- 1 nicpa nicpa 141K Oct  9  2019 h2o_dos.PDOS
>> -rw-r--r-- 1 nicpa nicpa 1.6K Feb  4 08:22 makefile
>> -rw-r--r-- 1 nicpa nicpa 1.2K Nov 17 13:48 m_orbital_chooser.f90
>> -rw-r--r-- 1 nicpa nicpa 5.9K Feb  4 08:22 m_pdos.f90
>> -rw-r--r-- 1 nicpa nicpa 1.3K Feb  4 08:22 pdosxml.f90
>> -rw-r--r-- 1 nicpa nicpa 1.7K Oct  9  2019 README
>>
> This was Ok.
>
> 3. Utilities depend on the Obj directory. So if you hadn't done
>> ../Src/obj_setup.sh in the Obj directory this may be the root cause of the
>> problem.
>>
> This did the trick! But there following packages:
>
>
>
>
>
>
>
>
>
>
>
>
>  All failed directories: *** (Some programs have to be compiled after
> compiling Siesta)   ./WFS   ./SiestaSubroutine/ProtoNEB/Src
>  ./SiestaSubroutine/SimpleTest/Src   ./ON   ./Grid   ./Gen-basis
>  ./STM/simple-stm   ./DensityMatrix   ./MPI_test   ./Helpers:*
>
> Had the same complaint finding NETCDF. For example, this is the output of
> running *make* inside the WFS folder:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *fort  -L/software/SIESTA-Libs/zlib-1.2.8/lib
> -Wl,-rpath=/software/SIESTA-Libs/zlib-1.2.8/lib
> -L/software/SIESTA-Libs/hdf5-1.8.12/lib
> -Wl,-rpath=/software/SIESTA-Libs/hdf5-1.8.12/lib
> -L/software/SIESTA-Libs/netcdf-4.4.1/lib
> -Wl,-rpath=/software/SIESTA-Libs/netcdf-4.4.1/lib
> -L/software/SIESTA-Libs/netcdf-fortran-4.4.4/lib
> -Wl,-rpath=/software/SIESTA-Libs/netcdf-fortran-4.4.4/lib -static-intel
> -L/software/intel/compilers_and_libraries_2020.4.304/linux/mkl/lib/intel64
> -o wfsnc2wfsx wfsnc2wfsx.o ld: wfsnc2wfsx.o: in function
> `MAIN__':wfsnc2wfsx.F90:(.text+0x66): undefined reference to
> `netcdf_mp_nf90_open_'ld: wfsnc2wfsx.F90:(.text+0x97): undefined reference
> to `netcdf_mp_nf90_inq_dimid_'ld: wfsnc2wfsx.F90:(.text+0xc4): undefined
> reference to `netcdf_mp_nf90_inquire_dimension_'ld:
> wfsnc2wfsx.F90:(.text+0xfe): undefined reference to
> `netcdf_mp_nf90_inq_dimid_'ld: wfsnc2wfsx.F90:(.text+0x128): undefined
> reference to `netcdf_mp_nf90_inquire_dimension_'ld:
> wfsnc2wfsx.F90:(.text+0x155): undefined reference to
> `netcdf_mp_nf90_inq_dimid_'ld: wfsnc2wfsx.F90:(.text+0x182): undefined
> reference to `netcdf_mp_nf90_inquire_dimension_'ld:
> wfsnc2wfsx.F90:(.text+0x1af): undefined reference to
> `netcdf_mp_nf90_inq_dimid_'ld: wfsnc2wfsx.F90:(.text+0x1dc): undefined
> reference to `netcdf_mp_nf90_inquire_dimension_'ld:
> wfsnc2wfsx.F90:(.text+0x209): undefined reference to
> `netcdf_mp_nf90_inq_dimid_'ld: wfsnc2wfsx.F90:(.text+0x236): undefined
> reference to `netcdf_mp_nf90_inquire_dimension_'ld:
> wfsnc2wfsx.F90:(.text+0x263): undefined reference to
> `netcdf_mp_nf90_inq_varid_'ld: wfsnc2wfsx.F90:(.text+0x28d): undefined
> reference to `netcdf_mp_nf90_inq_varid_'ld: wfsnc2wfsx.F90:(.text+0x1856):
> undefined reference to `netcdf_mp_nf90_get_var_1d_fourbytereal_'ld:
> wfsnc2wfsx.F90:(.text+0x19ec): undefined reference to
> `netcdf_mp_nf90_get_var_1d_fourbytereal_'ld: wfsnc2wfsx.F90:(.text+0x1b3a):
> undefined reference to `netcdf_mp_nf90_get_var_1d_fourbytereal_'ld:
> wfsnc2wfsx.F90:(.text+0x1bf3): undefined reference to
> `netcdf_mp_nf90_get_var_1d_fourbytereal_'ld: wfsnc2wfsx.F90:(.text+0x1d71):
> undefined reference to `netcdf_mp_nf90_close_'ld:
> wfsnc2wfsx.F90:(.text+0x1dcf): undefined reference to
> `netcdf_mp_nf90_strerror_'ld: wfsnc2wfsx.o: in function
> `wfsnc2wfsx_IP_check_':wfsnc2wfsx.F90:(.text+0x1f65): undefined reference
> to `netcdf_mp_nf90_strerror_'make: *** [makefile:58: wfsnc2wfsx] Error 1*
>
> Regards,
>
> 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] << Compiling Utils using build_all scrip >>

[Nick Papior]

Hi,

1. We can't see your arch.make, so there may be problems related to that.
2. You shouldn't do any manual copies, so I bet your copy of the xmlparser
folder causes problems. Could you please try from a clean pdosxml folder,
it should only contain these files:
total 196K
-rw-r--r-- 1 nicpa nicpa  28K Oct  9  2019 f2kcli-manual.txt
-rw-r--r-- 1 nicpa nicpa 141K Oct  9  2019 h2o_dos.PDOS
-rw-r--r-- 1 nicpa nicpa 1.6K Feb  4 08:22 makefile
-rw-r--r-- 1 nicpa nicpa 1.2K Nov 17 13:48 m_orbital_chooser.f90
-rw-r--r-- 1 nicpa nicpa 5.9K Feb  4 08:22 m_pdos.f90
-rw-r--r-- 1 nicpa nicpa 1.3K Feb  4 08:22 pdosxml.f90
-rw-r--r-- 1 nicpa nicpa 1.7K Oct  9  2019 README
3. Utilities depend on the Obj directory. So if you hadn't done
../Src/obj_setup.sh in the Obj directory this may be the root cause of the
problem.

Den ons. 3. feb. 2021 kl. 22.02 skrev I. Camps :

> Hello SIESTers,
>
> I am trying to compile all the utilities from the Util folder (from SIESTA
> PSML distro).
>
> When start compiling *pdosxml*, I got the following messages:
>
>
>
>
> */bin/sh: 1: cd: can't cd to
> ../..//home/icamps/Downloads/SIESTA/siesta-psml/Obj/xmlparsermake[4710]:
> Entering directory
> '/home/icamps/Downloads/SIESTA/siesta-psml/Util/pdosxml'Making sure that
> the xmlparser library is compiled...(cd
> ../..//home/icamps/Downloads/SIESTA/siesta-psml/Obj/xmlparser ; make
> "VPATH=../../Src/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser*
>
> This is endless, keep filing the terminal and also making my computer to
> extremely slowdown.
>
> I compiled SIESTA and copy the *xmlparser *folder (which has the library
> file *libxmlparser.a*) inside* Obj,* so, the folder is there.
>
> Also, I excecuted the script *clean_all.sh*.
>
> Any help/idea will be appreciated.
>
> []'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] SIESTA (GitLab version) installation failure

[Nick Papior]

Let me note that rarely do users need MUMPS.
As far as I remember it is only used for transiesta, and it is not the
fastests solution method.

So if you don't know if you are going to use it. Then don't compile it in :)

Den fre. 29. jan. 2021 kl. 22.00 skrev Tamas Karpati :

> Dear Camps,
>
> I can get and send it to you but i'm not sure it will help you as much
> as you wish.
> FYI, I use a ${HOME}-local installed set of all the dependencies and
> thus the file looks like a mess.
> Could you check the one that I shared for the second time? It is the
> working
> one except that I removed the MUMPS related lines: only I could build
> SIESTA without it.
> Indeed, building the newest MUMPS itself was a weird thing: its make
> completed
> at its 7th invocation!
>
> HTH,
>   toma
>
>
> On Fri, Jan 29, 2021 at 2:04 PM I. Camps  wrote:
> >
> > Hello Toma,
> >
> > Could you share your arch.make file?
> >
> > Thanks in advance.
> >
> > []'s,
> >
> > Camps
> >
> >
> > On Fri, Jan 8, 2021 at 6:02 PM Tamas Karpati  wrote:
> >>
> >> Dear Nick, dear Alberto,
> >>
> >> I want to thank you for your valuable help.
> >> I could build SIESTA/GitLab successfully following your hints.
> >>
> >> I'm happy to go on exploring the realm of SIESTA :)
> >>
> >> Best regards,
> >>   toma
> >>
> >>
> >> On Fri, Dec 18, 2020 at 8:57 AM Tamas Karpati 
> wrote:
> >> >
> >> > Dear Nick, Alberto,
> >> >
> >> > Thanks for the hints and directions. I can now go further :)
> >> >
> >> > Best regards,
> >> >   toma
> >> >
> >> > On Thu, Dec 17, 2020 at 10:21 PM Nick Papior 
> wrote:
> >> > >
> >> > > Like I said.
> >> > >
> >> > > COMP_LIBS should only contain specific library names. No paths.
> >> > >
> >> > > Also, you still have redundancies... ;)
> >> > >
> >> > > Delete this line:
> >> > > COMP_LIBS = -L/prghome/Siesta1/Obj
> >> > >
> >> > > Lastly, please always post the exact error everytime you post
> something new. It makes it much easier for us to see (regardless of whether
> you see the "same" error).
> >> > >
> >> > > Den ons. 16. dec. 2020 kl. 22.04 skrev Tamas Karpati <
> tkarp...@gmail.com>:
> >> > >>
> >> > >> Hi,
> >> > >>
> >> > >> Sorry for bothering you with such a messy file last time.
> >> > >> I noticed and removed the redundancies (and still have the same
> result).
> >> > >> Also made it easier to read, I hope. Can you please take a look at
> it?
> >> > >> I'm afraid that there is an issue with the ordering of flags for
> each pkg
> >> > >> (MPI, ELPA etc) or something is missing.
> >> > >>
> >> > >> Best regards,
> >> > >>   toma
> >> > >>
> >> > >> On Sun, Dec 13, 2020 at 12:59 PM Tamas Karpati 
> wrote:
> >> > >> >
> >> > >> > Dear Prof. Papior,
> >> > >> >
> >> > >> > Thank you for your quick response. Please find arch.make
> attached.
> >> > >> >
> >> > >> > For your information: this file was auto-generated by my
> home-made
> >> > >> > pkg. manager which added all flags for all the dependencies. The
> code
> >> > >> > is based on my understanding of Obj/DOCUMENTED-TEMPLATE.make.
> >> > >> >
> >> > >> > I appreciate your aid very much, thank you.
> >> > >> >
> >> > >> > With regards,
> >> > >> >   toma
> >> > >> >
> >> > >> > On Sat, Dec 12, 2020 at 10:01 PM Nick Papior <
> nickpap...@gmail.com> wrote:
> >> > >> > >
> >> > >> > > Please attach your arch.make file
> >> > >> > >
> >> > >> > > On Fri, 11 Dec 2020, 22:03 Tamas Karpati, 
> wrote:
> >> > >> > >>
> >> > >> > >> Dear fellow developers,
> >> > >> > >>
> >> > >> > >>
> >> > >> > >> Please help my first attempt to build SIESTA as I'm stuck
> after
>

Re: [SIESTA-L] FW: Concerning Denchar

[Nick Papior]

Hi,

Den lør. 23. jan. 2021 kl. 22.00 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Thank you for the reply.
>
>1. Because it was a different issue concerning Denchar but you are
>right!
>2. Will try to understand whats going on with such scripts
>3. I assume that is in python correct?
>
> Yes :)

>
>1. NA
>2. I understand.
>3. I was wondering for denchar version 3, where did you get the
>command from? Denchar -w 3 -k 4 ?? There is a manual for which you got that
>command from right?
>
> It is written in the denchar manual. Ok, it seems it was added after
4.1-b4 was released. So the next release will have it :)

> Thank you!
>
>
>
>
>
> 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: *Saturday, 23 January 2021 8:02 AM
> *To: *siesta-l 
> *Subject: *Re: [SIESTA-L] FW: Concerning Denchar
>
>
>
> Hi,
>
>
>
> 1. You have created issue here https://github.com/zerothi/sisl/issues/290
> <https://protect-au.mimecast.com/s/FV8mCq71mwf52MOKsZs6UF?domain=github.com>,
> great!
>
> 2. You have to do some scripting, see tutorials here:
> http://zerothi.github.io/sisl/docs/latest/tutorials/tutorial_siesta_1.html
> <https://protect-au.mimecast.com/s/34h2Cr81nytvmBAPszZlDd?domain=zerothi.github.io>
> and
> http://zerothi.github.io/sisl/docs/latest/tutorials/tutorial_siesta_2.html
> <https://protect-au.mimecast.com/s/yHC7Cvl1rKi6lkWpFzNTyY?domain=zerothi.github.io>
>
> 3. You can read in the Hamiltonian from sisl, then do es = H.eigenstate()
> (produces Gamma-point eigenstates), then filter out the eigenvalues close
> to 0 (sisl automatically shifts electronic structure to Fermi-level)
>
> 4. See 2.
>
> 5. None, you have to write a small python script. :), but something like
>
> es_state4 =
> sisl.get_sile("RUN.fdf").read_hamiltonian().eigenstate(k=[0.25, 0.25,
> 0.25]).sub(3) # note C-indexing
>
> 6. I don't know what you mean here...
>
>
>
> Den lør. 16. jan. 2021 kl. 22.04 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Hello Nick, Thank you for the reply:
>
>
>
>1. Sisl can do what denchar can? That’s fantastic, I was wondering how
>because I will give you my feedback 
>2. Can you let me know how though? As far I understand, sisl is made
>of 3 parts: sdata, sgeom, and sgrid. My guess to do a denchar calculation
>is to use sgrid. Then the real questions are:
>3. Which nc file should I use to get the homo and lumo as in denchar?
>4. Is there a specific sisl page tutorial for such?
>5. What are the main sisl commands that would be equivalent to*:
>denchar -k 3 -w 4  file.fdf  ??*
>6. Since there is no GitHub for denchar and since I could not find the
>command in the denchar manual, where can I find the commands mentioned in
>4??
>
>
>
> 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
>
>
>
> *From: *Nick Papior 
> *Sent: *Saturday, 16 January 2021 8:02 AM
> *To: *siesta-l 
> *Subject: *Re: [SIESTA-L] FW: Concerning Denchar
>
>
>
> Hmm.
>
>
>
> Den tor. 14. jan. 2021 kl. 22.02 skrev ehai2584 <
> ehai2...@uni.sydney.edu.au>:
>
> Good evening,
>
>1. I was wondering if Denchar has problems with systems which are not
>orthorhombic as it was in 1.3 version? Because when I studied a molecule
>inside orthorhombic system, I could visualize cube files. When I study for
>example graphene in an hexagonal system, even though the file is not empty
>(13000 kb) I could not visualize it.
>
> I am pretty sure it works for other than orthorhombic cells. However, the
> output can only be in an orthorhomic cell.
>
>
>1.
>2. Does Denchar have its own GitHub like sisl? Alberto once gave a
>great advice of using denchar -k 3 -w 4  file.fdf  which will plot only the
>wave-function with (original) index 4 of the third  k-point in the (WFSX)
>file. An
>
> No, denchar is part of the siesta distribution.
>
> sisl can in principle do what denchar does, however it is not as tested as
> denchar (so any feedback on them would be really nice!)
>
>
>1.
>2. May I convert the output cube file to xsf files in siesta?
>
> You can do this with sisl
>
>
>
> sgrid input.cube output.xsf
>
> or
>
> sdata input.cube output.xsf
>

Re: [SIESTA-L] FW: Concerning Denchar

[Nick Papior]

Hi,

1. You have created issue here https://github.com/zerothi/sisl/issues/290,
great!
2. You have to do some scripting, see tutorials here:
http://zerothi.github.io/sisl/docs/latest/tutorials/tutorial_siesta_1.html
and
http://zerothi.github.io/sisl/docs/latest/tutorials/tutorial_siesta_2.html
3. You can read in the Hamiltonian from sisl, then do es = H.eigenstate()
(produces Gamma-point eigenstates), then filter out the eigenvalues close
to 0 (sisl automatically shifts electronic structure to Fermi-level)
4. See 2.
5. None, you have to write a small python script. :), but something like
es_state4 = sisl.get_sile("RUN.fdf").read_hamiltonian().eigenstate(k=[0.25,
0.25, 0.25]).sub(3) # note C-indexing
6. I don't know what you mean here...

Den lør. 16. jan. 2021 kl. 22.04 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Hello Nick, Thank you for the reply:
>
>
>
>1. Sisl can do what denchar can? That’s fantastic, I was wondering how
>because I will give you my feedback 
>2. Can you let me know how though? As far I understand, sisl is made
>of 3 parts: sdata, sgeom, and sgrid. My guess to do a denchar calculation
>is to use sgrid. Then the real questions are:
>3. Which nc file should I use to get the homo and lumo as in denchar?
>4. Is there a specific sisl page tutorial for such?
>5. What are the main sisl commands that would be equivalent to*: d**enchar
>-k 3 -w 4  file.fdf  ??*
>6. Since there is no GitHub for denchar and since I could not find the
>command in the denchar manual, where can I find the commands mentioned in
>4??
>
>
>
> 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
>
>
>
> *From: *Nick Papior 
> *Sent: *Saturday, 16 January 2021 8:02 AM
> *To: *siesta-l 
> *Subject: *Re: [SIESTA-L] FW: Concerning Denchar
>
>
>
> Hmm.
>
>
>
> Den tor. 14. jan. 2021 kl. 22.02 skrev ehai2584 <
> ehai2...@uni.sydney.edu.au>:
>
> Good evening,
>
>1. I was wondering if Denchar has problems with systems which are not
>orthorhombic as it was in 1.3 version? Because when I studied a molecule
>inside orthorhombic system, I could visualize cube files. When I study for
>example graphene in an hexagonal system, even though the file is not empty
>(13000 kb) I could not visualize it.
>
> I am pretty sure it works for other than orthorhombic cells. However, the
> output can only be in an orthorhomic cell.
>
>
>1.
>2. Does Denchar have its own GitHub like sisl? Alberto once gave a
>great advice of using denchar -k 3 -w 4  file.fdf  which will plot only the
>wave-function with (original) index 4 of the third  k-point in the (WFSX)
>file. An
>
> No, denchar is part of the siesta distribution.
>
> sisl can in principle do what denchar does, however it is not as tested as
> denchar (so any feedback on them would be really nice!)
>
>
>1.
>2. May I convert the output cube file to xsf files in siesta?
>
> You can do this with sisl
>
>
>
> sgrid input.cube output.xsf
>
> or
>
> sdata input.cube output.xsf
>
>
>
> Denchar does not write out xsf files.
>
>
>1.
>
>
>
> 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/
> <https://protect-au.mimecast.com/s/3lWHC3QNPBiE3LELIgu0O3?domain=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/)
>


-- 
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] Denchar command "denchar -k 3 -w 4 file.fdf " not working ?

[Nick Papior]

Yeah, you need to use at least 3.0 denchar.

Den tor. 21. jan. 2021 kl. 15.24 skrev Nick Papior :

> From which version of siesta did you take this version?
>
> Den tir. 19. jan. 2021 kl. 22.01 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
>> 2.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:* Tuesday, January 19, 2021 2:01:27 AM
>> *To:* siesta-l 
>> *Subject:* Re: [SIESTA-L] Denchar command "denchar -k 3 -w 4 file.fdf "
>> not working ?
>>
>> Which version of denchar did you work with?
>>
>>
>> Den lør. 16. jan. 2021 kl. 22.01 skrev El-abed Haidar <
>> ehai2...@uni.sydney.edu.au>:
>>
>> Good evening,
>>
>> I was trying to use dencar command denchar -k 3 -w 4  file.fdf  which
>> will plot only the wave-function with (original) index 4 of the third
>> k-point in the (WFSX) file.
>>
>> But when I tried to use it in denchar 2.2 it just would not go through
>> the specified k point nor wave function.
>>
>> Is there a reason??
>>
>> Here is my proof in the update file where I used the command : denchar -k
>> 3 -w 4  file.fdf >update.txt.
>>
>> Denchar works but not as commanded
>>
>> Any advice ?
>>
>> 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/
>> <https://protect-au.mimecast.com/s/_AD9CGv0oyCMJB2jTKGm-W?domain=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/)
>>
>
>
> --
> Kind regards Nick
>


-- 
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] Denchar command "denchar -k 3 -w 4 file.fdf " not working ?

[Nick Papior]

From which version of siesta did you take this version?

Den tir. 19. jan. 2021 kl. 22.01 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> 2.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:* Tuesday, January 19, 2021 2:01:27 AM
> *To:* siesta-l 
> *Subject:* Re: [SIESTA-L] Denchar command "denchar -k 3 -w 4 file.fdf "
> not working ?
>
> Which version of denchar did you work with?
>
>
> Den lør. 16. jan. 2021 kl. 22.01 skrev El-abed Haidar <
> ehai2...@uni.sydney.edu.au>:
>
> Good evening,
>
> I was trying to use dencar command denchar -k 3 -w 4  file.fdf  which will
> plot only the wave-function with (original) index 4 of the third  k-point
> in the (WFSX) file.
>
> But when I tried to use it in denchar 2.2 it just would not go through the
> specified k point nor wave function.
>
> Is there a reason??
>
> Here is my proof in the update file where I used the command : denchar -k
> 3 -w 4  file.fdf >update.txt.
>
> Denchar works but not as commanded
>
> Any advice ?
>
> 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/
> <https://protect-au.mimecast.com/s/_AD9CGv0oyCMJB2jTKGm-W?domain=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/)
>


-- 
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] problem with the DOS

[Nick Papior]

If you are calculating the DOS from the EIG file, then most likely you
don't use enough k-points?

If you want to retain the currently used k-point sampling for the SCF, you
may use PDOS.kgrid.MonkhorstPack to increase the precision for the DOS
calculation. Then simply sum the PDOS to get the full DOS at increased
k-point sampling.

Den søn. 17. jan. 2021 kl. 22.02 skrev AK- HYDRA :

> Hello siesta Admin,
> Is it possible to use tetrahedra for DOS in SIESTA? I am working on a
> metallic system and the plotted band & dos are not agreed enough to each
> other. I would really appreciate, If anyone has a solution.
> Thank you
>
> --
> 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] Denchar command "denchar -k 3 -w 4 file.fdf " not working ?

[Nick Papior]

Which version of denchar did you work with?


Den lør. 16. jan. 2021 kl. 22.01 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good evening,
>
> I was trying to use dencar command denchar -k 3 -w 4  file.fdf  which will
> plot only the wave-function with (original) index 4 of the third  k-point
> in the (WFSX) file.
>
> But when I tried to use it in denchar 2.2 it just would not go through the
> specified k point nor wave function.
>
> Is there a reason??
>
> Here is my proof in the update file where I used the command : denchar -k
> 3 -w 4  file.fdf >update.txt.
>
> Denchar works but not as commanded
>
> Any advice ?
>
> 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: Concerning Denchar

[Nick Papior]

Hmm.

Den tor. 14. jan. 2021 kl. 22.02 skrev ehai2584 :

> Good evening,
>
>1. I was wondering if Denchar has problems with systems which are not
>orthorhombic as it was in 1.3 version? Because when I studied a molecule
>inside orthorhombic system, I could visualize cube files. When I study for
>example graphene in an hexagonal system, even though the file is not empty
>(13000 kb) I could not visualize it.
>
> I am pretty sure it works for other than orthorhombic cells. However, the
output can only be in an orthorhomic cell.

>
>1.
>2. Does Denchar have its own GitHub like sisl? Alberto once gave a
>great advice of using denchar -k 3 -w 4  file.fdf  which will plot only the
>wave-function with (original) index 4 of the third  k-point in the (WFSX)
>file. An
>
> No, denchar is part of the siesta distribution.
sisl can in principle do what denchar does, however it is not as tested as
denchar (so any feedback on them would be really nice!)

>
>1.
>2. May I convert the output cube file to xsf files in siesta?
>
> You can do this with sisl

sgrid input.cube output.xsf
or
sdata input.cube output.xsf

Denchar does not write out xsf files.

>
>1.
>
>
>
> 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] Linux distro that is 100% ready for SIESTA?

[Nick Papior]

Hi,

Basically all linux distros are Siesta compatible.

I would suggest you use the OS you are most comfortable with, then try and
do a compilation of Siesta with an arch.make. If that fails, please put
forth the arch.make and any errors you may see when executing "make"


Den man. 21. dec. 2020 kl. 22.02 skrev Boucher, Dr. Derrick <
dbouc...@fgcu.edu>:

> Hello SIESTA users,
> Has anyone built a Linux distro that comes with ALL the libraries and
> packages that SIESTA needs? I have very limited time to spend on an
> installation, and I am not very good with operating systems.
> -details follow if you are inclined to answer--- Thank you,
> Derrick
> I have previously used SIESTA but due to a hard drive failure I had to
> reinstall my Linux and SIESTA. I've tried Centos and SuSe recently but keep
> finding that linking to libraries, math packages, etc. is the problem. I
> may have the packages but they are not linked in the SIESTA-expected places.
>
> I have an older 4-core processor machine with 48Gb RAM but have no
> proprietary software; I would use all GPL software; gcc, gnu fortran, etc.
> I'd like to run parallel, but can use a single processor if I must.
>
> Any help is appreciated.
>
> Derrick E. Boucher, Ph.D.
> Associate Professor of Physics and Physics Coordinator
> Florida Gulf Coast University
> 10501 FGCU Blvd. South
> Fort Myers, FL 33965
> U.S.A.
> Phone: (239) 590-7170
> [image: Eagle]
> Florida has a very broad public records law.  As a result, any written
> communication created or received by Florida Gulf Coast University
> employees is subject to disclosure to the public and the media, upon
> request, unless otherwise exempt.  Under Florida law, e-mail addresses are
> public records.  If you do not want your email address released in response
> to a public records request, do not send electronic mail to this entity.
> Instead, contact this office by phone or in writing.
>
> --
> 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 (GitLab version) installation failure

[Nick Papior]

Like I said.

COMP_LIBS should only contain specific library names. No paths.

Also, you still have redundancies... ;)

Delete this line:
COMP_LIBS = -L/prghome/Siesta1/Obj

Lastly, please always post the exact error everytime you post something
new. It makes it much easier for us to see (regardless of whether you see
the "same" error).

Den ons. 16. dec. 2020 kl. 22.04 skrev Tamas Karpati :

> Hi,
>
> Sorry for bothering you with such a messy file last time.
> I noticed and removed the redundancies (and still have the same result).
> Also made it easier to read, I hope. Can you please take a look at it?
> I'm afraid that there is an issue with the ordering of flags for each pkg
> (MPI, ELPA etc) or something is missing.
>
> Best regards,
>   toma
>
> On Sun, Dec 13, 2020 at 12:59 PM Tamas Karpati  wrote:
> >
> > Dear Prof. Papior,
> >
> > Thank you for your quick response. Please find arch.make attached.
> >
> > For your information: this file was auto-generated by my home-made
> > pkg. manager which added all flags for all the dependencies. The code
> > is based on my understanding of Obj/DOCUMENTED-TEMPLATE.make.
> >
> > I appreciate your aid very much, thank you.
> >
> > With regards,
> >   toma
> >
> > On Sat, Dec 12, 2020 at 10:01 PM Nick Papior 
> wrote:
> > >
> > > Please attach your arch.make file
> > >
> > > On Fri, 11 Dec 2020, 22:03 Tamas Karpati,  wrote:
> > >>
> > >> Dear fellow developers,
> > >>
> > >>
> > >> Please help my first attempt to build SIESTA as I'm stuck after
> > >> several attempts. No similar symptoms I could find in the archives.
> > >>
> > >> Shortly: make stops without both executables and error messages.
> > >>
> > >>
> > >> Details: after having
> > >>   * OpenMPI-4.0.5, OpenBLAS-0.3.10, ScaLAPACK-2.1.0,
> > >> Elpa-2020.005.001, Metis-5.1.0 and MUMPS-5.3.5 built,
> > >>   * downloaded from GitLab the Dec. 11, 2020 master version of SIESTA,
> > >>   * applied the install scripts in Doc for both NetCDF and FLOOK,
> > >>   * created the arch.make and finally invoked
> > >>   * make (either without arguments or adding the "-j N" option).
> > >>
> > >> Without a better guess I followed siesta-4.1-b4.pdf/Section 2.
> > >>
> > >>
> > >> Two observations:
> > >>
> > >>   1, there neither executables (ie. siesta)
> > >>  nor error messages appear
> > >>
> > >>   2, when I run make several times:
> > >>  - first time libwxml.a and libmpi_f90.a appear,
> > >>  - second time libfdf.a and MatrixSwitch.a appear,
> > >>  - third time libSiestaXC.a materialized but
> > >>  - starting from the fourth invokation of make I got
> > >>
> > >>"No rule to make target '-L/home/atom/Siesta/Obj',
> > >>needed by 'posix_calls.o'.  Stop."
> > >>
> > >>(iteration converged, this method gives me no more fruit)
> > >>
> > >> Looking in Obj/Makefile did not help either. Still shut a few with
> > >> "make lib", "make siesta" even "make dep" but to no avail.
> > >> Apparently I need to learn.
> > >>
> > >>
> > >> I kindly ask your help (instructions or written method on the Web).
> > >> Thank you in advance.
> > >>
> > >> Best regards,
> > >>   toma
> > >>
> > >> --
> > >> 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] SIESTA (GitLab version) installation failure

[Nick Papior]

Ok.

Delete this line:
COMP_LIBS = -L/home/atom/programs/Siesta-pine-1/Obj

COMP_LIBS should only contain names of shipped libraries, i.e. libfdict.a,
libncdf.a

Also, you have libfdict.a 3 times, delete 2 of them (the lone ones).

Den søn. 13. dec. 2020 kl. 22.00 skrev Tamas Karpati :

> Dear Prof. Papior,
>
> Thank you for your quick response. Please find arch.make attached.
>
> For your information: this file was auto-generated by my home-made
> pkg. manager which added all flags for all the dependencies. The code
> is based on my understanding of Obj/DOCUMENTED-TEMPLATE.make.
>
> I appreciate your aid very much, thank you.
>
> With regards,
>   toma
>
> On Sat, Dec 12, 2020 at 10:01 PM Nick Papior  wrote:
> >
> > Please attach your arch.make file
> >
> > On Fri, 11 Dec 2020, 22:03 Tamas Karpati,  wrote:
> >>
> >> Dear fellow developers,
> >>
> >>
> >> Please help my first attempt to build SIESTA as I'm stuck after
> >> several attempts. No similar symptoms I could find in the archives.
> >>
> >> Shortly: make stops without both executables and error messages.
> >>
> >>
> >> Details: after having
> >>   * OpenMPI-4.0.5, OpenBLAS-0.3.10, ScaLAPACK-2.1.0,
> >> Elpa-2020.005.001, Metis-5.1.0 and MUMPS-5.3.5 built,
> >>   * downloaded from GitLab the Dec. 11, 2020 master version of SIESTA,
> >>   * applied the install scripts in Doc for both NetCDF and FLOOK,
> >>   * created the arch.make and finally invoked
> >>   * make (either without arguments or adding the "-j N" option).
> >>
> >> Without a better guess I followed siesta-4.1-b4.pdf/Section 2.
> >>
> >>
> >> Two observations:
> >>
> >>   1, there neither executables (ie. siesta)
> >>  nor error messages appear
> >>
> >>   2, when I run make several times:
> >>  - first time libwxml.a and libmpi_f90.a appear,
> >>  - second time libfdf.a and MatrixSwitch.a appear,
> >>  - third time libSiestaXC.a materialized but
> >>  - starting from the fourth invokation of make I got
> >>
> >>"No rule to make target '-L/home/atom/Siesta/Obj',
> >>needed by 'posix_calls.o'.  Stop."
> >>
> >>(iteration converged, this method gives me no more fruit)
> >>
> >> Looking in Obj/Makefile did not help either. Still shut a few with
> >> "make lib", "make siesta" even "make dep" but to no avail.
> >> Apparently I need to learn.
> >>
> >>
> >> I kindly ask your help (instructions or written method on the Web).
> >> Thank you in advance.
> >>
> >> Best regards,
> >>   toma
> >>
> >> --
> >> 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] Issue with Denchar

[Nick Papior]

That option is for siesta, not for Denchar.

Could you build denchar with debug options:
  FFLAGS = -Og -g -pedantic -Wall -fcheck=all -fbacktrace -Warray-bounds
-Wunused -Wuninitialized

then rerun denchar.

Optionally, ensure that your stack size is unlimited:
ulimit -s unlimited

Den man. 14. dec. 2020 kl. 22.17 skrev El-abed Haidar <
ehai2...@uni.sydney.edu.au>:

> Good evening all,
>
> I have been using denchar for quite some time. It has been working until I
> changed the WFS min and max energy.
>
> #DENCHAR
>
> *WFS.Energy.Min -5 eV*
>
> *WFS.Energy.Max -4 eV*
>
>
>
> Denchar.TypeOfRun 3D
>
> Denchar.PlotCharge true
>
> Denchar.PlotWaveFunctions true
>
> Denchar.CoorUnits Ang
>
> Denchar.NumberPointsX 100
>
> Denchar.NumberPointsY 100
>
> Denchar.NumberPointsZ 100
>
> WriteDenchar true
>
> Denchar.MinX 0 Ang
>
> Denchar.MaxX 20 Ang
>
> Denchar.MinY 0 Ang
>
> Denchar.MaxY 10 Ang
>
> Denchar.MinZ 0 Ang
>
> Denchar.MaxZ 20 Ang
>
> COOP.Write true
>
> Denchar.PlotCharge
>
>
>
>
>
> As a result of this change I got the following error:
>
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>
> Image  PCRoutineLineSource
>
> denchar0504053  UnknownUnknown  Unknown
>
> libpthread-2.28.s  1553B3CD4DD0  Unknown   Unknown  Unknown
>
> denchar04B8595  UnknownUnknown  Unknown
>
> denchar04CE32B  UnknownUnknown  Unknown
>
> denchar04030E2  UnknownUnknown  Unknown
>
> libc-2.28.so   1553B39236A3  __libc_start_main Unknown
> Unknown
>
> denchar0402FEE  UnknownUnknown  Unknown
>
>
>
> May I know why changing the energy range caused that problem?
>
> 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] SIESTA (GitLab version) installation failure

[Nick Papior]

Please attach your arch.make file

On Fri, 11 Dec 2020, 22:03 Tamas Karpati,  wrote:

> Dear fellow developers,
>
>
> Please help my first attempt to build SIESTA as I'm stuck after
> several attempts. No similar symptoms I could find in the archives.
>
> Shortly: make stops without both executables and error messages.
>
>
> Details: after having
>   * OpenMPI-4.0.5, OpenBLAS-0.3.10, ScaLAPACK-2.1.0,
> Elpa-2020.005.001, Metis-5.1.0 and MUMPS-5.3.5 built,
>   * downloaded from GitLab the Dec. 11, 2020 master version of SIESTA,
>   * applied the install scripts in Doc for both NetCDF and FLOOK,
>   * created the arch.make and finally invoked
>   * make (either without arguments or adding the "-j N" option).
>
> Without a better guess I followed siesta-4.1-b4.pdf/Section 2.
>
>
> Two observations:
>
>   1, there neither executables (ie. siesta)
>  nor error messages appear
>
>   2, when I run make several times:
>  - first time libwxml.a and libmpi_f90.a appear,
>  - second time libfdf.a and MatrixSwitch.a appear,
>  - third time libSiestaXC.a materialized but
>  - starting from the fourth invokation of make I got
>
>"No rule to make target '-L/home/atom/Siesta/Obj',
>needed by 'posix_calls.o'.  Stop."
>
>(iteration converged, this method gives me no more fruit)
>
> Looking in Obj/Makefile did not help either. Still shut a few with
> "make lib", "make siesta" even "make dep" but to no avail.
> Apparently I need to learn.
>
>
> I kindly ask your help (instructions or written method on the Web).
> Thank you in advance.
>
> Best regards,
>   toma
>
> --
> 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] spin polarized bands

[Nick Papior]

Which version of siesta are you using.

When I do
gnubands -s 1 ...
gnubands -s 2 ...

it works as expected!
And the bands are different in up and down channel.

Den man. 7. dec. 2020 kl. 22.03 skrev veerpal kaur dhiman <
v.veerpa...@gmail.com>:

> Please find attached the .bands file
>
> Thank you
>
> On Sat, Dec 5, 2020 at 2:31 AM Sankushkrishna Maheshuni <
> sankushnov2...@gmail.com> wrote:
>
>> Hello Veerpal Kaur Dhiman.
>>  Could you please send your ". bands" file so that I can have a clear
>> idea of the bandstructure you are getting.
>>
>> On Fri, Dec 4, 2020, 2:31 AM veerpal kaur dhiman 
>> wrote:
>>
>>> Dear Siesa users ,
>>> I have been trying to calculate the spin polarized band structure for
>>> my system. I got only two columns in band.dat file one for k and
>>> another for E. There is no column for spin.
>>>
>>> Is there something in fdf file to distinguish spin up and down parts
>>> like may be any index 1 for up and 2 for down ??
>>>
>>> Is there any special pseudopotentials which may be used spin polarized
>>> calculations ? I have used GGA-PBE pseudopotentials.
>>>
>>> Is there any difference in utility gnubands or gnubands -F or
>>> gnubands.new?? may be there is any change in my utility gnubands...Is
>>> it possible?
>>>
>>>
>>> First of all i optimized my system with
>>> "variable cell' true
>>> num of cg steps 500 and
>>> spinpolarized option false
>>>
>>> then using the relaxed coordinates and relaxed lattice parameters and
>>> with options
>>>
>>> variable cell false
>>> num of cg steps 0
>>> spinpolarized option true
>>> %block DM.InitSpin
>>>  3   +2.0
>>> %endblock DM.InitSpin
>>>
>>> .bands file is calculated
>>>  where "3" is used for denoting the atom iron  Fe in my system in fdf
>>> file.
>>>
>>> then i converted .bands file into .dat file using
>>> gnubands <.bands| band.dat
>>>
>>> but i have got a single file for bands i am unable to separate the
>>> spin up and spin down bands how to get these? is there any mistake.
>>>
>>>
>>> I also tried this
>>> gnubands -s 1 < .bands > band_up.dat
>>> gnubands -s 2 < .bands > band_dn.dat
>>>
>>> But i got the exactly same bands for up and down.
>>>
>>> Where may be the problem ?
>>> Please help.
>>> Thank you
>>> Veerpal Kaur
>>>
>>> --
>>> 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] Denchar software inquiry

[Nick Papior]

No, denchar is sadly not MPI parallelised.

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

> Good afternoon,
>
> I was wondering when utilizing the Denchar software, if the system is very
> large can we use mpirun?
>
> I tried but it does not seem to be going fast.
>
> Curious to anyone’s thoughts especially the developers.
>
> 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] [***Posible SPAM***]Sin Asunto/Subject is blank

[Nick Papior]

The spin index is the last value in each row.

So everything is compressed as a flat file format.

Alternatively you can do:

gnubands -s 1 < .bands > band_up.dat
gnubands -s 2 < .bands > band_dn.dat

to split them in two files.

Den fre. 27. nov. 2020 kl. 22.00 skrev veerpal kaur dhiman <
v.veerpa...@gmail.com>:

> Dear siesta users
>
> I have been trying to calculate the spin polarized band structure for my
> system.
> First of all i optimized my system with
> "variable cell' true
> num of cg steps 500 and
> spinpolarized option false
>
> then using the relaxed coordinates and relaxed lattice parameters and
> with options
>
> variable cell false
> num of cg steps 0
> spinpolarized option true
> %block DM.InitSpin
>  3   +2.0
> %endblock DM.InitSpin
>
> .bands file is calculated
>  where "3" is used for denoting the atom iron  Fe in my system in fdf file.
>
> then i converted .bands file into .dat file using
> gnubands <.bands| band.dat
>
> but i have got a single file for bands i am unable to separate the
> spin up and spin down bands how to get these? is there any mistake.
>
> please help if anyone can
>
> Thank you
> Veerpal Kaur.
>
> --
> 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] 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/)