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] Problem using Vibra utility

[El-Abed Haidar]

Hi Sunetra,
>From the website 
>https://urldefense.com/v3/__https://siesta-project.org/SIESTA_MATERIAL/Docs/list.html__;!!D9dNQwwGXtA!RxHJm2MCashIuvFYxBV08uyZ9nd_FhgAyf-fKq_B2IV5F0qFwZ1fkZKV3kVFn3_Lz9CdUVLk0GIKeeJ7VXzqNsL4$
> 
To leave the list just send an e-mail to sy...@uam.es<mailto:sy...@uam.es>  
with the following in its subject:
SIGNOFF SIESTA-L

The body of the message should be blank.

Cheers,
EL-Abed

EL-ABED HAIDAR
|Doctor of Philosophy (Science) |THE UNIVERSITY OF SYDNEY | NSW | 2006
Current Staff Scientist |NCI 
Australia<https://urldefense.com/v3/__http://www.nci.org.au/__;!!D9dNQwwGXtA!RxHJm2MCashIuvFYxBV08uyZ9nd_FhgAyf-fKq_B2IV5F0qFwZ1fkZKV3kVFn3_Lz9CdUVLk0GIKeeJ7VUXUnppL$
 > |The Australian National University
143 Ward Road, Acton, ACT 2601
M: +61 416625261
E: el-abed.hai...@anu.edu.au<mailto:el-abed.hai...@anu.edu.au>

Want the latest news from NCI? 
https://urldefense.com/v3/__http://nci.org.au/research-news/news/__;!!D9dNQwwGXtA!RxHJm2MCashIuvFYxBV08uyZ9nd_FhgAyf-fKq_B2IV5F0qFwZ1fkZKV3kVFn3_Lz9CdUVLk0GIKeeJ7VS6TSm4t$
 
Find out more about NCI: 
YouTube<https://urldefense.com/v3/__http://www.youtube.com/user/NCINationalFacility__;!!D9dNQwwGXtA!RxHJm2MCashIuvFYxBV08uyZ9nd_FhgAyf-fKq_B2IV5F0qFwZ1fkZKV3kVFn3_Lz9CdUVLk0GIKeeJ7VfJmi_-_$
 >  / 
Facebook<https://urldefense.com/v3/__https://www.facebook.com/NCIAustralia/__;!!D9dNQwwGXtA!RxHJm2MCashIuvFYxBV08uyZ9nd_FhgAyf-fKq_B2IV5F0qFwZ1fkZKV3kVFn3_Lz9CdUVLk0GIKeeJ7VdQNVBMA$
 > / 
Twitter<https://urldefense.com/v3/__https://twitter.com/NCInews__;!!D9dNQwwGXtA!RxHJm2MCashIuvFYxBV08uyZ9nd_FhgAyf-fKq_B2IV5F0qFwZ1fkZKV3kVFn3_Lz9CdUVLk0GIKeeJ7Vc7tp_mE$
 > / 
LinkedIn<https://urldefense.com/v3/__https://www.linkedin.com/company/national-computational-infrastructure/__;!!D9dNQwwGXtA!RxHJm2MCashIuvFYxBV08uyZ9nd_FhgAyf-fKq_B2IV5F0qFwZ1fkZKV3kVFn3_Lz9CdUVLk0GIKeeJ7VW6jSi4R$
 >
[NCI Australia logo black PNG transparent]  [MHFAider Accredited Digital Badge]

From: Sunetra Das<mailto:sunetra.das...@gmail.com>
Sent: Friday, 15 September 2023 6:00 AM
To: siesta-l@uam.es<mailto:siesta-l@uam.es>
Subject: Re: [SIESTA-L] Problem using Vibra utility

Hello,
I want to unsubscribe from Siesta emails.
Kindly cancel my email address from subscription.
Thank you.

Regards,
Sunetra Das.

On Thu, 14 Sep, 2023, 1:30 am Andrei Postnikov, 
mailto:andrei.postni...@univ-lorraine.fr>> 
wrote:
Dear Diego,

as your case is q=0 only, you can try your luck
with my shortcut version of vibra, to be compiled from the attached zip.
It does not need an .fdf file, just .XV and .FC
(.XV serves just to identify the atoms; exact coordinates are not important).
Tell me if you'd encounter any difficulties.

Best regards

Andrei Postnikov


- Le 12 Sep 23, à 12:16, Diego Lopez Alcala 
diego.lo...@uv.es<mailto:diego.lo...@uv.es> a écrit :

> Dear Siesta users,
>
> I have been trying to compute the modes of vibrations of a molecule adsorbed 
> on
> a semiconducting monolayer, but I am having some problems. First I run this
> input:
>
> # General System descriptors
>
> SystemName vibra-2   # Descriptive name of the system
> SystemLabel   vibra-2# Short name for naming files
>
> NumberOfAtoms   164   # Number of atoms
> NumberOfSpecies 5   # Number of species
>
> md.typeofrun fc
>
> MD.FCFirst 151
> MD.FCLast 164
>
> AtomicCoordinatesFormat NotScaledCartesianAng
>
> 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 # Cr, 10.1002/jcc.20495
>  1   2 Grimme 80.39  3.245 # Cr / S
>  1   3 Grimme120.28  3.311 # Cr / Br
>  1   4 Grimme 45.06  3.014 # Cr / C
>  1   5 Grimme 12.74  2.563 # Cr / H
>  2   2 Grimme 57.73  3.366 # S, 10.1002/jcc.20495
>  2   3 Grimme 86.38  3.432 # S / Br
>  2   4 Grimme 32.36  3.135 # S / C
>  2   5 Grimme  9.15  2.684 # S / H
>  3   3 Grimme129.24  3.498 # Br, 10.1002/jcc.20495
>  3   4 Grimme 48.42  3.201 # Br / C
>  3   5 Grimme 13.69  2.750 # Br / H
>  4   4 Grimme 18.14  2.904 # C, 10.1002/jcc.20495
>  4   5 Grimme  5.13  2.453 # C / H
>  5   5 Grimme  1.45  2.002 # H, 10.1002/jcc.20495
> %endblock MM.Potentials
>
> %block Chemical_Species_Label
>  1   24 Cr
>  2   16 S
>  3   35 Br
>  46 C
>  51 H
> %endblock Chemical_Species_Label
>
> PAO.BasisSize  SZ
>
> DFTU.ProjectorGenerationMethod 1
> DFTU.PotentialShift .true.
>
> %block DFTU.Proj # Define DFTU projecto

Re: [SIESTA-L] Problem using Vibra utility

[Sunetra Das]

Hello,
I want to unsubscribe from Siesta emails.
Kindly cancel my email address from subscription.
Thank you.

Regards,
Sunetra Das.

On Thu, 14 Sep, 2023, 1:30 am Andrei Postnikov, <
andrei.postni...@univ-lorraine.fr> wrote:

> Dear Diego,
>
> as your case is q=0 only, you can try your luck
> with my shortcut version of vibra, to be compiled from the attached zip.
> It does not need an .fdf file, just .XV and .FC
> (.XV serves just to identify the atoms; exact coordinates are not
> important).
> Tell me if you'd encounter any difficulties.
>
> Best regards
>
> Andrei Postnikov
>
>
> - Le 12 Sep 23, à 12:16, Diego Lopez Alcala diego.lo...@uv.es a écrit
> :
>
> > Dear Siesta users,
> >
> > I have been trying to compute the modes of vibrations of a molecule
> adsorbed on
> > a semiconducting monolayer, but I am having some problems. First I run
> this
> > input:
> >
> > # General System descriptors
> >
> > SystemName vibra-2   # Descriptive name of the system
> > SystemLabel   vibra-2# Short name for naming files
> >
> > NumberOfAtoms   164   # Number of atoms
> > NumberOfSpecies 5   # Number of species
> >
> > md.typeofrun fc
> >
> > MD.FCFirst 151
> > MD.FCLast 164
> >
> > AtomicCoordinatesFormat NotScaledCartesianAng
> >
> > 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 # Cr, 10.1002/jcc.20495
> >  1   2 Grimme 80.39  3.245 # Cr / S
> >  1   3 Grimme120.28  3.311 # Cr / Br
> >  1   4 Grimme 45.06  3.014 # Cr / C
> >  1   5 Grimme 12.74  2.563 # Cr / H
> >  2   2 Grimme 57.73  3.366 # S, 10.1002/jcc.20495
> >  2   3 Grimme 86.38  3.432 # S / Br
> >  2   4 Grimme 32.36  3.135 # S / C
> >  2   5 Grimme  9.15  2.684 # S / H
> >  3   3 Grimme129.24  3.498 # Br, 10.1002/jcc.20495
> >  3   4 Grimme 48.42  3.201 # Br / C
> >  3   5 Grimme 13.69  2.750 # Br / H
> >  4   4 Grimme 18.14  2.904 # C, 10.1002/jcc.20495
> >  4   5 Grimme  5.13  2.453 # C / H
> >  5   5 Grimme  1.45  2.002 # H, 10.1002/jcc.20495
> > %endblock MM.Potentials
> >
> > %block Chemical_Species_Label
> >  1   24 Cr
> >  2   16 S
> >  3   35 Br
> >  46 C
> >  51 H
> > %endblock Chemical_Species_Label
> >
> > PAO.BasisSize  SZ
> >
> > DFTU.ProjectorGenerationMethod 1
> > DFTU.PotentialShift .true.
> >
> > %block DFTU.Proj # Define DFTU projectors
> > Cr 1 # Label, l_shells
> > n=3 2  # n (opt if not using semicore levels),l,Softconf(opt)
> > 4.00 0.0 # U(eV), J(eV) for this shell
> > 0.0 # rc (Bohr), \omega(Bohr) (Fermi cutoff function)
> > %endblock DFTU.Proj
> >
> > # Lattice, coordinates, k-sampling
> >
> > AtomicCoorFormatOut Ang
> >
> > %block AtomicCoordinatesAndAtomicSpecies
> > 4.44717269  3.68308271  0.75902034  3   79.904
> > .
> > . (Rest of atomic coordinates)
> > .
> > 5.10327585  14.06972694 8.19442056  5   1.007
> > %endblock AtomicCoordinatesAndAtomicSpecies
> >
> > LatticeConstant 1.0 Ang
> >
> > %block LatticeVectors
> >   17.8287990.000.00
> >0.00   24.3147200.00
> >0.000.00   25.236237
> > %endblock LatticeVectors
> >
> > %block kgrid_Monkhorst_Pack
> > 1   0   0  0.0
> > 0   1   0  0.0
> > 0   0   1  0.0
> > %endblock kgrid_Monkhorst_Pack
> >
> > # DFT, Grid, SCF
> >
> > XC.functional   GGA # Exchange-correlation functional
> type
> > XC.authors  PBE # Particular parametrization of xc
> func
> > SpinPolarized   .true.  # Spin unpolarized calculation
> > MeshCutoff  400. Ry # Equivalent planewave cutoff for
> the grid
> > MaxSCFIterations300 # Maximum number of SCF iterations
> per step
> > SCF.DM.Converge true
> > SCF.H.Converge  true
> >
> > # Eigenvalue problem: order-N or diagonalization
> >
> > SolutionMethod  diagon  # OrderN or Diagon
> > ElectronicTemperature   300 K# Temp. for Fermi smearing
> >
> > # Output options
> >
> > WriteCoorInitial
> > WriteCoorStep
> > WriteForces
> > WriteMullikenPop1 # Write Mulliken Population Analysis
> > WriteCoorXmol   .false.
> > WriteMDCoorXmol .false.
> > WriteMDhistory  .false.
> > WriteCoorXmol   .false.
> >
> > Once it is done I add the following lines to the input (as suggested
> here:
> >
> 

Re: [SIESTA-L] Problem using Vibra utility

[Andrei Postnikov]

Dear Diego,

as your case is q=0 only, you can try your luck
with my shortcut version of vibra, to be compiled from the attached zip.
It does not need an .fdf file, just .XV and .FC 
(.XV serves just to identify the atoms; exact coordinates are not important).
Tell me if you'd encounter any difficulties.

Best regards

Andrei Postnikov 


- Le 12 Sep 23, à 12:16, Diego Lopez Alcala diego.lo...@uv.es a écrit :

> Dear Siesta users,
> 
> I have been trying to compute the modes of vibrations of a molecule adsorbed 
> on
> a semiconducting monolayer, but I am having some problems. First I run this
> input:
> 
> # General System descriptors
> 
> SystemName vibra-2   # Descriptive name of the system
> SystemLabel   vibra-2# Short name for naming files
> 
> NumberOfAtoms   164   # Number of atoms
> NumberOfSpecies 5   # Number of species
> 
> md.typeofrun fc
> 
> MD.FCFirst 151
> MD.FCLast 164
> 
> AtomicCoordinatesFormat NotScaledCartesianAng
> 
> 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 # Cr, 10.1002/jcc.20495
>  1   2 Grimme 80.39  3.245 # Cr / S
>  1   3 Grimme120.28  3.311 # Cr / Br
>  1   4 Grimme 45.06  3.014 # Cr / C
>  1   5 Grimme 12.74  2.563 # Cr / H
>  2   2 Grimme 57.73  3.366 # S, 10.1002/jcc.20495
>  2   3 Grimme 86.38  3.432 # S / Br
>  2   4 Grimme 32.36  3.135 # S / C
>  2   5 Grimme  9.15  2.684 # S / H
>  3   3 Grimme129.24  3.498 # Br, 10.1002/jcc.20495
>  3   4 Grimme 48.42  3.201 # Br / C
>  3   5 Grimme 13.69  2.750 # Br / H
>  4   4 Grimme 18.14  2.904 # C, 10.1002/jcc.20495
>  4   5 Grimme  5.13  2.453 # C / H
>  5   5 Grimme  1.45  2.002 # H, 10.1002/jcc.20495
> %endblock MM.Potentials
> 
> %block Chemical_Species_Label
>  1   24 Cr
>  2   16 S
>  3   35 Br
>  46 C
>  51 H
> %endblock Chemical_Species_Label
> 
> PAO.BasisSize  SZ
> 
> DFTU.ProjectorGenerationMethod 1
> DFTU.PotentialShift .true.
> 
> %block DFTU.Proj # Define DFTU projectors
> Cr 1 # Label, l_shells
> n=3 2  # n (opt if not using semicore levels),l,Softconf(opt)
> 4.00 0.0 # U(eV), J(eV) for this shell
> 0.0 # rc (Bohr), \omega(Bohr) (Fermi cutoff function)
> %endblock DFTU.Proj
> 
> # Lattice, coordinates, k-sampling
> 
> AtomicCoorFormatOut Ang
> 
> %block AtomicCoordinatesAndAtomicSpecies
> 4.44717269  3.68308271  0.75902034  3   79.904
> .
> . (Rest of atomic coordinates)
> .
> 5.10327585  14.06972694 8.19442056  5   1.007
> %endblock AtomicCoordinatesAndAtomicSpecies
> 
> LatticeConstant 1.0 Ang
> 
> %block LatticeVectors
>   17.8287990.000.00
>0.00   24.3147200.00
>0.000.00   25.236237
> %endblock LatticeVectors
> 
> %block kgrid_Monkhorst_Pack
> 1   0   0  0.0
> 0   1   0  0.0
> 0   0   1  0.0
> %endblock kgrid_Monkhorst_Pack
> 
> # DFT, Grid, SCF
> 
> XC.functional   GGA # Exchange-correlation functional type
> XC.authors  PBE # Particular parametrization of xc func
> SpinPolarized   .true.  # Spin unpolarized calculation
> MeshCutoff  400. Ry # Equivalent planewave cutoff for the grid
> MaxSCFIterations300 # Maximum number of SCF iterations per 
> step
> SCF.DM.Converge true
> SCF.H.Converge  true
> 
> # Eigenvalue problem: order-N or diagonalization
> 
> SolutionMethod  diagon  # OrderN or Diagon
> ElectronicTemperature   300 K# Temp. for Fermi smearing
> 
> # Output options
> 
> WriteCoorInitial
> WriteCoorStep
> WriteForces
> WriteMullikenPop1 # Write Mulliken Population Analysis
> WriteCoorXmol   .false.
> WriteMDCoorXmol .false.
> WriteMDhistory  .false.
> WriteCoorXmol   .false.
> 
> Once it is done I add the following lines to the input (as suggested  here:
> https://urldefense.com/v3/__https://docs.siesta-project.org/projects/siesta/en/latest/tutorials/basic/vibrational-properties/Benzene/index.html__;!!D9dNQwwGXtA!UewEzyC8ZoPpI3i_PmoF3Vbbcs86V_CEf3F-hofbAGex6SS1dlsBvcgSPg7HdC2VlFmiZZGfJEXGqNlpcyY$
> ) and I run the vibra utility, obtaining this error message. The
> SystemLabel.bands is formed but not the SystemLabel.vectors.
> 
> Eigenvectors.true.# Compute both phonon eigenvalues and 
> eigenvectors
> BandLinesScale  pi/a
> %block BandLines
> 1   0.0   0.0   0.0   \Gamma  # Only the Gamma point (enough for a molecule)
> %endblock BandLines
> 
> But when I run the vibra utility I always have this message:
> 
> redata: System Name  

[SIESTA-L] Error in tselecs.sh

[Mohammed Ghadiyali]

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 (http://www.max-centre.eu/)

Re: [SIESTA-L] GPU install siesta

[Mohammed Ghadiyali]

Hello,

Any update on my query?

Regards,
Ghadiyali Mohammed Kader
Post Doctoral Fellow
King Abdullah University of Science and Technology
On 20 Aug 2023 at 4:54 PM +0300, Mohammed Ghadiyali 
, wrote:
> Hello,
>
> I’m trying to install siesta on GPU and using the attached make file. I’ve 
> used the instructions from pervious forum post (link). The compilation is 
> successful, but siesta is not using any GPU, I’ve check the NVIDIA SMI 
> command and it prints following in the output:
>
> “Skipping GPU init, should have already been initialized"
>
> I've added following tags in the input file:
>
> diag-algorithm elpa-2
> diag-elpa-usegpu T
> diag-blocksize 16
>
> And running the calculations using the following mpirun command on 4 V100 
> gpus (with and without gpu_bind script):
>
> mpirun --map-by socket:PE=1 --report-bindings -np 4 ./gpu_bind.sh siesta < 
> run.fdf > run.out
>
> Any help would be appreciated.
>
> 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/)

[SIESTA-L] forrtl: severe (174): SIGSEGV, segmentation fault occurred

[Yelda Kadıoglu]

Hi developers
Im using transiesta 4.1.5 and after the electrode calculation, for
scattering part at 0 V i had the error below. If I use 1node 1cpu it seems
work, but i cant finish my work like this. Could you please help



forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource

siesta 00BB510D  Unknown   Unknown  Unknown
libpthread-2.17.s  2B2FCE77B370  Unknown   Unknown  Unknown
libmpi.so.12.0 2B2FCF351600  Unknown   Unknown  Unknown
libmpi.so.12.0 2B2FCF34E560  Unknown   Unknown  Unknown
libmpi.so.12.0 2B2FCF35892E  Unknown   Unknown  Unknown
libmpi.so.12   2B2FCF357E33  MPI_Bcast Unknown  Unknown
libmkl_blacs_inte  2B2FCE55373F  MKLMPI_Bcast  Unknown  Unknown
libmkl_scalapack_  2B2FC80B4016  pzhbrdb_  Unknown  Unknown
libmkl_scalapack_  2B2FC7FC565C  pzherdb_  Unknown  Unknown
libmkl_scalapack_  2B2FC7F322B9  mkl_pzheevd0_ Unknown  Unknown
libmkl_scalapack_  2B2FC7F30984  mkl_pzheevdm_ Unknown  Unknown
libmkl_scalapack_  2B2FC7F2F91C  pzheevd_  Unknown  Unknown
siesta 007FA47C  Unknown   Unknown  Unknown
siesta 0046A0D0  Unknown   Unknown  Unknown
siesta 00437FC2  Unknown   Unknown  Unknown
siesta 00571C20  Unknown   Unknown  Unknown
siesta 005B6332  Unknown   Unknown  Unknown
siesta 00AE8B7D  Unknown   Unknown  Unknown
siesta 0040769E  Unknown   Unknown  Unknown
libc-2.17.so   2B2FD00EFB35  __libc_start_main Unknown  Unknown
siesta 004075A9  Unknown   Unknown  Unknown

-- 
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] Problem using Vibra utility

[Diego Lopez Alcala]

Dear Siesta users,

I have been trying to compute the modes of vibrations of a molecule adsorbed on 
a semiconducting monolayer, but I am having some problems. First I run this 
input:

# General System descriptors

SystemName vibra-2   # Descriptive name of the system
SystemLabel   vibra-2# Short name for naming files

NumberOfAtoms   164   # Number of atoms
NumberOfSpecies 5   # Number of species

md.typeofrun fc

MD.FCFirst 151
MD.FCLast 164

AtomicCoordinatesFormat NotScaledCartesianAng

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 # Cr, 10.1002/jcc.20495
  1   2 Grimme 80.39  3.245 # Cr / S
  1   3 Grimme120.28  3.311 # Cr / Br
  1   4 Grimme 45.06  3.014 # Cr / C
  1   5 Grimme 12.74  2.563 # Cr / H
  2   2 Grimme 57.73  3.366 # S, 10.1002/jcc.20495
  2   3 Grimme 86.38  3.432 # S / Br
  2   4 Grimme 32.36  3.135 # S / C
  2   5 Grimme  9.15  2.684 # S / H
  3   3 Grimme129.24  3.498 # Br, 10.1002/jcc.20495
  3   4 Grimme 48.42  3.201 # Br / C
  3   5 Grimme 13.69  2.750 # Br / H
  4   4 Grimme 18.14  2.904 # C, 10.1002/jcc.20495
  4   5 Grimme  5.13  2.453 # C / H
  5   5 Grimme  1.45  2.002 # H, 10.1002/jcc.20495
%endblock MM.Potentials

%block Chemical_Species_Label
  1   24 Cr
  2   16 S
  3   35 Br
  46 C
  51 H
%endblock Chemical_Species_Label

PAO.BasisSize  SZ

DFTU.ProjectorGenerationMethod 1
DFTU.PotentialShift .true.

%block DFTU.Proj # Define DFTU projectors
Cr 1 # Label, l_shells
n=3 2  # n (opt if not using semicore levels),l,Softconf(opt)
4.00 0.0 # U(eV), J(eV) for this shell
0.0 # rc (Bohr), \omega(Bohr) (Fermi cutoff function)
%endblock DFTU.Proj

# Lattice, coordinates, k-sampling

AtomicCoorFormatOut Ang

%block AtomicCoordinatesAndAtomicSpecies
4.44717269  3.68308271  0.75902034  3   79.904
.
. (Rest of atomic coordinates)
.
5.10327585  14.06972694 8.19442056  5   1.007
%endblock AtomicCoordinatesAndAtomicSpecies

LatticeConstant 1.0 Ang

%block LatticeVectors
   17.8287990.000.00
0.00   24.3147200.00
0.000.00   25.236237
%endblock LatticeVectors

%block kgrid_Monkhorst_Pack
 1   0   0  0.0
 0   1   0  0.0
 0   0   1  0.0
%endblock kgrid_Monkhorst_Pack

# DFT, Grid, SCF

XC.functional   GGA # Exchange-correlation functional type
XC.authors  PBE # Particular parametrization of xc func
SpinPolarized   .true.  # Spin unpolarized calculation
MeshCutoff  400. Ry # Equivalent planewave cutoff for the grid
MaxSCFIterations300 # Maximum number of SCF iterations per step
SCF.DM.Converge true
SCF.H.Converge  true

# Eigenvalue problem: order-N or diagonalization

SolutionMethod  diagon  # OrderN or Diagon
ElectronicTemperature   300 K# Temp. for Fermi smearing

# Output options

WriteCoorInitial
WriteCoorStep
WriteForces
WriteMullikenPop1 # Write Mulliken Population Analysis
WriteCoorXmol   .false.
WriteMDCoorXmol .false.
WriteMDhistory  .false.
WriteCoorXmol   .false.

Once it is done I add the following lines to the input (as suggested  here: 
https://urldefense.com/v3/__https://docs.siesta-project.org/projects/siesta/en/latest/tutorials/basic/vibrational-properties/Benzene/index.html__;!!D9dNQwwGXtA!UewEzyC8ZoPpI3i_PmoF3Vbbcs86V_CEf3F-hofbAGex6SS1dlsBvcgSPg7HdC2VlFmiZZGfJEXGqNlpcyY$
 ) and I run the vibra utility, obtaining this error message. The 
SystemLabel.bands is formed but not the SystemLabel.vectors.

Eigenvectors.true.# Compute both phonon eigenvalues and eigenvectors
BandLinesScale  pi/a
%block BandLines
1   0.0   0.0   0.0   \Gamma  # Only the Gamma point (enough for a molecule)
%endblock BandLines

But when I run the vibra utility I always have this message:

redata: System Name  = vibra-2  

redata: System Label = vibra-2  

Number of Atoms  =   164
Lattice Constant=1.88973  Bohr
Lattice vectors (in units of Lattice Constant) =
  17.82880   0.0   0.0
   0.0  24.31472   0.0
   0.0   0.0  25.23624
Lattice vectors (in Bohr) =
  33.69156   0.0   0.0
   0.0  45.94818   0.0
   0.0   0.0  47.68960

[SIESTA-L] siesta master branch, Intel MKL FATAL ERROR

[Daniel Bennett]

Hi all,

I recently compiled the siesta master branch using cmake. It is running fine in 
serial, but there is a problem when running with parallel:

...
dipole: A dipole layer will be introduced in the vacuum
dipole: region to compensate the system dipole
Dipole moment in unit cell =   0.   0.   0. D
Electric field for dipole correction = 0.00 0.00-0.00 
eV/Ang/e
Intel MKL FATAL ERROR: Cannot load symbol MKLMPI_Get_wrappers.
Intel MKL FATAL ERROR: Cannot load symbol MKLMPI_Get_wrappers.
Intel MKL FATAL ERROR: Cannot load symbol MKLMPI_Get_wrappers.
Intel MKL FATAL ERROR: Cannot load symbol MKLMPI_Get_wrappers.
Intel MKL FATAL ERROR: Cannot load symbol MKLMPI_Get_wrappers.
Intel MKL FATAL ERROR: Cannot load symbol MKLMPI_Get_wrappers.
Intel MKL FATAL ERROR: Cannot load symbol MKLMPI_Get_wrappers.
Intel MKL FATAL ERROR: Cannot load symbol MKLMPI_Get_wrappers.
Intel MKL FATAL ERROR: Cannot load symbol MKLMPI_Get_wrappers.
Intel MKL FATAL ERROR: Cannot load symbol MKLMPI_Get_wrappers.


The error gets printed once by each core. I'm not sure if this is an error 
introduced due to incorrect linking when compiling (the compilation went quite 
smoothly), or it is just an error from running the code incorrectly. When I run 
the code, I have

module load intel/23.0.0-fasrc01 intel-mkl/23.0.0-fasrc01 openmpi/4.1.4-fasrc01
export LD_LIBRARY_PATH=/path/to/siesta/Docs/build/lib:$LD_LIBRARY_PATH

in my submission script, and am running with mpirun -np $numtasks siesta ...

I compiled with cmake using the following options:

module load intel/23.0.0-fasrc01 intel-mkl/23.0.0-fasrc01 openmpi/4.1.4-fasrc01

# Point to libraries
LIBXC_ROOT=/path/to/lib/libs-libxc
GRIDXC_ROOT=/path/to/siesta/External/libgridxc
XMLF90_ROOT=/path/to/siesta/External/xmlf90
PSML_ROOT=/path/to/siesta/External/libpsml
LIBFDF_ROOT=/path/to/siesta/External/libfdf


### MKL STUFF ###
MKLPATH=${MKLROOT}/lib/intel64
SCALAPACK=${MKLPATH}/libmkl_scalapack_lp64.a
BLACS=${MKLPATH}/libmkl_blacs_openmpi_lp64.a
LAPACK=${MKLPATH}/libmkl_lapack95_lp64.a

cmake -S. -Bbuild \
  -DCMAKE_INSTALL_PREFIX=/path/to/siesta/siesta/build \
  
-DCMAKE_PREFIX_PATH="$XMLF90_ROOT;$PSML_ROOT;$GRIDXC_ROOT;$LIBXC_ROOT;$LIBFDF_ROOT"
 \
  -DSCALAPACK_LIBRARY="-lmkl_scalapack_lp64;$BLACS" \
  -DWITH_LIBXC=ON \
  -DWITH_LUA=OFF -DWITH_FLOOK=OFF \
  -DLAPACK_LIBRARY="$LAPACK" \
  -DLIBFDF_FIND_METHOD=source \
  -DLIBFDF_SOURCE_DIR=/path/to/siesta/External/libfdf \
  -DNetCDF_ROOT=/path/to/siesta/Docs/build \


Can anyone advise?

Thanks,

Daniel Bennettt


-- 
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] Vacancy formation energy with Ghost orbitals

[Francisco Garcia]

Dear Users,

I computed the vacancy formation energy, E_vac_f, of a crystal as follows:

E_vac_f = E(crystal with one vacant site) - ((n-1)/n)*E(pristine crystal).

In computing E(crystal with one vacant site), I kept a floating/ghost
orbital at the vacant site during the geometry relaxation to account for
BSSE (i.e., the net number of basis functions in the defected and pristine
crystals are the same).

I would like to know from the experts if the procedure is correct.

Thank you.

Francisco

-- 
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

[肖威]

I've learned that, and it helps me a lot. 


Thank you Nick Papior and Yuefei Huang for your reply.


| |
肖威
|
|
xiaowei951...@163.com
|
 Replied Message 
| From | Nick Papior |
| Date | 9/3/2023 04:00 |
| To |  |
| Subject | Re: [SIESTA-L] ***SPAM*** Re: ***SPAM*** Re: Question about Gate 
(Infinite plane) in SIESTA |
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
|
 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 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
|
 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 

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

[肖威]

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
|
 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 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
|
 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 

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

[yh46]

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 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
|
 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
|

--
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!URpSF7zEPUo2pgnDAu-R8G2ylzEB4WJvVMj6ieteqAMMZPkxWDoJvxO4K0mmRZZT9CKicYpb-gKpQV-vtdNxDg$  
)




--

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!URpSF7zEPUo2pgnDAu-R8G2ylzEB4WJvVMj6ieteqAMMZPkxWDoJvxO4K0mmRZZT9CKicYpb-gKpQV-vtdNxDg$  
)



--
SIESTA is supported by the Spanish Research Agency (AEI) and by the  
European H2020 MaX Centre of Excellence  
(https://urldefense.com/v3/__http

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

[肖威]

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 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
|
 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
|

--
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!URpSF7zEPUo2pgnDAu-R8G2ylzEB4WJvVMj6ieteqAMMZPkxWDoJvxO4K0mmRZZT9CKicYpb-gKpQV-vtdNxDg$
 )



--

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!URpSF7zEPUo2pgnDAu-R8G2ylzEB4WJvVMj6ieteqAMMZPkxWDoJvxO4K0mmRZZT9CKicYpb-gKpQV-vtdNxDg$
 )


--
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!URpSF7zEPUo2pgnDAu-R8G2ylzEB4WJvVMj6ieteqAMMZPkxWDoJvxO4K0mmRZZT9CKicYpb-gKpQV-vtdNxDg$
 )

-- 
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 siesta 4.1.5b, problem with libfdf

[Daniel Bennett]

Thanks Nick, I got mixed up between the master branch and 4.1.5, and which one 
had psml support, I will try compiling the master branch instead

Danny



From: siesta-l-requ...@uam.es  on behalf of Nick 
Papior 
Sent: 25 August 2023 02:56
To: siesta-l@uam.es 
Subject: Re: [SIESTA-L] Compiling siesta 4.1.5b, problem with libfdf

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<https://urldefense.com/v3/__http://gitlab.com/siesta-project/siesta__;!!D9dNQwwGXtA!QNYgtRVBdTms0eegc1QBISe8IP7G12h9jf2gBR_fBZ_Aqb_JZ3UPJs1vCcnNLiGBJRW8vElNYd5iKxVmgg$>

Den tors. 24. aug. 2023 kl. 22.00 skrev Daniel Bennett 
mailto:db...@cantab.ac.uk>>:
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!SIGMWIf1_yaecJiAt9ilom6T2Wp1eVzN19SkmmtX_DmK2bPbA3htf7OA_y6jg3U-_XAM0b4XdQKJli89$
 
<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/)

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] Transiesta convergence

[MANOJ N MATTUR]

Hi,

PFA my fdf file for scattering region...

It's just not converging. It didn't with cut off 200Ry. Now I have reduced
it to 150Ry, still hasn't converged in 24hrs, job's still running. Any
suggestions on what could be done to speed up the convergence...

Regards,
Manoj

-- 
*Disclaimer: *This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they 
are addressed. If you have received this email in error please notify the 
system manager. This message contains confidential information and is 
intended only for the individual named. If you are not the named addressee 
you should not disseminate, distribute or copy this e-mail. Please notify 
the sender immediately by e-mail if you have received this e-mail by 
mistake and delete this e-mail from your system. If you are not the 
intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on the contents of this information is 
strictly prohibited.


scattering.fdf
Description: application/vnd.fdf

-- 
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] Compiling siesta 4.1.5b, problem with libfdf

[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


arch.make
Description: arch.make
GRIDXC was compiled with MPI
GRIDXC was compiled with libxc support
GRIDXC was compiled with libxc support
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/build.mk:512: warning: overriding recipe for target '.c.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/arch.make:94: warning: ignoring old recipe for target '.c.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/build.mk:514: warning: overriding recipe for target '.F.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/arch.make:96: warning: ignoring old recipe for target '.F.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/build.mk:516: warning: overriding recipe for target '.F90.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/arch.make:98: warning: ignoring old recipe for target '.F90.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/build.mk:518: warning: overriding recipe for target '.f.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/arch.make:100: warning: ignoring old recipe for target '.f.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/build.mk:520: warning: overriding recipe for target '.f90.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/arch.make:102: warning: ignoring old recipe for target '.f90.o'
(cd Src; make siesta )
make[1]: Entering directory '/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/Src'
GRIDXC was compiled with MPI
GRIDXC was compiled with libxc support
GRIDXC was compiled with libxc support
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/build.mk:512: warning: overriding recipe for target '.c.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/arch.make:94: warning: ignoring old recipe for target '.c.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/build.mk:514: warning: overriding recipe for target '.F.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/arch.make:96: warning: ignoring old recipe for target '.F.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/build.mk:516: warning: overriding recipe for target '.F90.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/arch.make:98: warning: ignoring old recipe for target '.F90.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/build.mk:518: warning: overriding recipe for target '.f.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/arch.make:100: warning: ignoring old recipe for target '.f.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/build.mk:520: warning: overriding recipe for target '.f90.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/arch.make:102: warning: ignoring old recipe for target '.f90.o'

Compilation architecture to be used: build-mk-scheme
If this is not what you want, create the right
arch.make file using the models in Src/Sys

Hit ^C to abort...
SIESTA_VERSION = 5.0.0-alpha-74-g87d74b5ec

WARNING: This is *not* an official SIESTA release.
WARNING:
WARNING: Unless you are trying a feature or fix that has not
WARNING: been released yet, we strongly recommend the use of
WARNING: official releases of SIESTA, which can be downloaded from
WARNING: https://gitlab.com/siesta-project/siesta/-/releases .


==> Incorporating information about present compilation (compiler and flags)
make "FPPFLAGS=-DF2003  " compinfo.o
make[2]: Entering directory '/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/Src'
GRIDXC was compiled with MPI
GRIDXC was compiled with libxc support
GRIDXC was compiled with libxc support
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/build.mk:512: warning: overriding recipe for target '.c.o'
/net/fs2k02/srv/export/kaxiras/share_root/software/siesta/siesta-4.1.5/build/arch.make:94: warning: ignoring 

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

[肖威]

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
|
 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
|

--
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!X3APsp0SY6XOonK2EDMii3S20GGPWca2WF43qXZGk2cw86KZN-bZgk05od2AIY7P_7UhmSNmF1716nmf_LfAtA$
 )



--

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

[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/)

[SIESTA-L] GPU install siesta

[Mohammed Ghadiyali]

Hello,

I’m trying to install siesta on GPU and using the attached make file. I’ve used 
the instructions from pervious forum post (link). The compilation is 
successful, but siesta is not using any GPU, I’ve check the NVIDIA SMI command 
and it prints following in the output:

“Skipping GPU init, should have already been initialized"

I've added following tags in the input file:

diag-algorithm elpa-2
diag-elpa-usegpu T
diag-blocksize 16

And running the calculations using the following mpirun command on 4 V100 gpus 
(with and without gpu_bind script):

mpirun --map-by socket:PE=1 --report-bindings -np 4 ./gpu_bind.sh siesta < 
run.fdf > run.out

Any help would be appreciated.

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.


arch.make
Description: Binary data

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

Re: [SIESTA-L] 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

[肖威]

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
|
 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
|

--
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!SxLyWC01B6AeL3kmEC1A3xVpoGpwQIBsrLylYVlBspzJ2WlwjZz5xESZAgs-tQrAXnImxenCfz2mACR9-FLj0A$
 )

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

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

[肖威]

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

[肖威]

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 (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!

[MANOJ N MATTUR]

I did that and now it says Erroneous electrode setup, check out-put

On Sat, Aug 5, 2023 at 3:00 PM Nick Papior  wrote:

> 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!WJJL7yHcot6DEWDswSP7PMvjjcf7KVHlMl148_9F7SVdiJXjHDb3_VQm-VNqZ0E-NVIgLsbf-cAnQtFb$
>>  
>> 
>>
>> 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!WJJL7yHcot6DEWDswSP7PMvjjcf7KVHlMl148_9F7SVdiJXjHDb3_VQm-VNqZ0E-NVIgLsbf-ShsaNZd$
>>  
>> 
>> )
>>
>
>
> --
> 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!WJJL7yHcot6DEWDswSP7PMvjjcf7KVHlMl148_9F7SVdiJXjHDb3_VQm-VNqZ0E-NVIgLsbf-ShsaNZd$
>  )
>

-- 
*Disclaimer: *This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity to whom they 
are addressed. If you have received this email in error please notify the 
system manager. This message contains confidential information and is 
intended only for the individual named. If you are not the named addressee 
you should not disseminate, distribute or copy this e-mail. Please notify 
the sender immediately by e-mail if you have received this e-mail by 
mistake and delete this e-mail from your system. If you are not the 
intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on the contents of this information is 
strictly prohibited.

-- 
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/)

Re: [SIESTA-L] Dipole correction for slab calculation

[Diego Lopez Alcala]

Dear Emilio,

Thanks for your suggestions. Finally I could converge the symmetric slab after 
many SCF iterations, but I noticed that the Slab.DipoleCorrection keyword is 
not helping my calculations. I noticed that at each SCF iteration the applied E 
field is different, so the calculation diverges a lot. In the case of the 
symmetric slab I have a small dipole, but in the future I want to study the 
adsorption of some molecules so I assume that I will need the dipole correction 
and I do not know if I am using this tool properly. Any further suggestion on 
how to manage this situation?

Best regards,
Diego

El Jueves 27 Julio 2023 10:17 CEST, Emilio Artacho  Ha 
escrito:

> Dear Diego
>
> 1. Depending how you make the surface you may be breaking bonds,
> which can give SCF trouble. (not sure about garnet, and depending
> on particular surface). You may need to saturate bonds, depending on
> what makes sense chemically, and/or you would expect of that garnet
> surface in reality.
>
> 2. There are many tools for difficult scf convergence (reduce mixing
> weight, Pulay mixing, converging on H etc). In the docs.
>
> best
>
> Emilio
>
>
> On 26 Jul 2023, at 13:14, Diego Lopez Alcala 
> mailto:diego.lo...@uv.es>> wrote:
>
> Dear SIESTA users,
>
> I am currently working on the adsorption of some molecules on a garnet 
> surface. My calculations on the bulk structure of the garnet using SIESTA are 
> working quite good, but when I try to converge a slab model (adding vacuum on 
> one axis) the calculations are not converging. I tried to use 
> Slab.DipoleCorrection with the avaiable different options but none of them 
> are converging.
>
> I would really appreciate some guideance to improve my results. Thank you in 
> advanced.
>
> Best regards,
> Diego
>
>
> --
> 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!Vuwg2Az-3hcT-jzFcHjRtgdZS4oFYMVARXQRjmhZl21z-yU-Pg4Z5jl9EJRfcaXvW47PnVDKN-viVpFVE2_G$
>  )
>
> --
> Emilio Artacho
>
> Theory Group, Nanogune, 20018 San Sebastian, Spain, and
> Theory of Condensed Matter, Department of Physics,
> Cavendish Laboratory, University of Cambridge, Cambridge CB3 0HE, UK
>
>
>







-- 
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] Dipole correction for slab calculation

[Emilio Artacho]

Dear Diego

1. Depending how you make the surface you may be breaking bonds,
which can give SCF trouble. (not sure about garnet, and depending
on particular surface). You may need to saturate bonds, depending on
what makes sense chemically, and/or you would expect of that garnet
surface in reality.

2. There are many tools for difficult scf convergence (reduce mixing
weight, Pulay mixing, converging on H etc). In the docs.

best

Emilio


On 26 Jul 2023, at 13:14, Diego Lopez Alcala 
mailto:diego.lo...@uv.es>> wrote:

Dear SIESTA users,

I am currently working on the adsorption of some molecules on a garnet surface. 
My calculations on the bulk structure of the garnet using SIESTA are working 
quite good, but when I try to converge a slab model (adding vacuum on one axis) 
the calculations are not converging. I tried to use Slab.DipoleCorrection with 
the avaiable different options but none of them are converging.

I would really appreciate some guideance to improve my results. Thank you in 
advanced.

Best regards,
Diego


--
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!Vuwg2Az-3hcT-jzFcHjRtgdZS4oFYMVARXQRjmhZl21z-yU-Pg4Z5jl9EJRfcaXvW47PnVDKN-viVpFVE2_G$
 )

--
Emilio Artacho

Theory Group, Nanogune, 20018 San Sebastian, Spain, and
Theory of Condensed Matter, Department of Physics,
Cavendish Laboratory, University of Cambridge, Cambridge CB3 0HE, UK




-- 
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] Dipole correction for slab calculation

[Diego Lopez Alcala]

Dear SIESTA users,

I am currently working on the adsorption of some molecules on a garnet surface. 
My calculations on the bulk structure of the garnet using SIESTA are working 
quite good, but when I try to converge a slab model (adding vacuum on one axis) 
the calculations are not converging. I tried to use Slab.DipoleCorrection with 
the avaiable different options but none of them are converging.

I would really appreciate some guideance to improve my results. Thank you in 
advanced.

Best regards,
Diego


-- 
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

[El-Abed Haidar]

Thank you very much I. Camps
However, there are 94 atoms in AtomicCoordinatesAndAtomicSpecies.
The student numbered 1-32 for left electrode 1-30 scattering and 1-32 right 
electrode.
Can you see that? If so, any other suggestions?

Cheers,
EL-Abed

EL-ABED HAIDAR
|Doctor of Philosophy (Science) |THE UNIVERSITY OF SYDNEY | NSW | 2006
Current Staff Scientist |NCI 
Australia<https://urldefense.com/v3/__http://www.nci.org.au/__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2KwdUfvFCb$
 > |The Australian National University
143 Ward Road, Acton, ACT 2601
M: +61 416625261
E: el-abed.hai...@anu.edu.au<mailto:el-abed.hai...@anu.edu.au>

Want the latest news from NCI? 
https://urldefense.com/v3/__http://nci.org.au/research-news/news/__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2KwU4M3Cns$
 
Find out more about NCI: 
YouTube<https://urldefense.com/v3/__http://www.youtube.com/user/NCINationalFacility__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2KwZ66eeph$
 >  / 
Facebook<https://urldefense.com/v3/__https://www.facebook.com/NCIAustralia/__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2KwRP5_E-u$
 > / 
Twitter<https://urldefense.com/v3/__https://twitter.com/NCInews__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2Kwc4-BcjC$
 > / 
LinkedIn<https://urldefense.com/v3/__https://www.linkedin.com/company/national-computational-infrastructure/__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2KwUwwchvR$
 >
[NCI Australia logo black PNG transparent]  [MHFAider Accredited Digital Badge]

From: I. Camps<mailto:ica...@gmail.com>
Sent: Wednesday, 26 July 2023 6:00 AM
To: siesta-l@uam.es<mailto:siesta-l@uam.es>
Subject: Re: [SIESTA-L] Error in specifying the type of an atom

Hi,

In the AtomicCoordinatesAndAtomicSpecies  block, you only have 32 atoms, but 
you declared that there are 94.
[]'s

Camps

Em sex., 21 de jul. de 2023 17:00, El-Abed Haidar 
mailto:ehai2...@uni.sydney.edu.au>> escreveu:
Good day all,
I was wondering if anyone could help me understand why I got this error:

Error in specifying the type of an atom!. Atoms specified is above the total 
number of atoms!

even though we have the same number of atoms and we only have carbon atoms. Any 
thoughts?

Cheers,
EL-Abed

EL-ABED HAIDAR
|Doctor of Philosophy (Science) |THE UNIVERSITY OF SYDNEY | NSW | 2006
Current Staff Scientist |NCI 
Australia<https://urldefense.com/v3/__https://protect-au.mimecast.com/s/oLn3CE8wmrtlRx1WrTNei1W?domain=urldefense.com__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2KwYHQ0-ME$
 > |The Australian National University
143 Ward Road, Acton, ACT 2601
M: +61 416625261
E: el-abed.hai...@anu.edu.au<mailto:el-abed.hai...@anu.edu.au>

Want the latest news from NCI? 
https://urldefense.com/v3/__http://nci.org.au/research-news/news/__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2KwU4M3Cns$
 
<https://urldefense.com/v3/__https://protect-au.mimecast.com/s/yM22CJyBrGfB0wp8Gcz4LFG?domain=urldefense.com__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2KwXsKrQgp$
 >
Find out more about NCI: 
YouTube<https://urldefense.com/v3/__https://protect-au.mimecast.com/s/y-oACK1DvKTD3W8qghALm_e?domain=urldefense.com__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2KwQmPXyLU$
 >  / 
Facebook<https://urldefense.com/v3/__https://protect-au.mimecast.com/s/CqzDCL7EwMfkE9NPxsjJz5b?domain=urldefense.com__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2Kwedt1wi7$
 > / 
Twitter<https://urldefense.com/v3/__https://protect-au.mimecast.com/s/Rnw_CMwGxOt2E3x5KI1mCsk?domain=urldefense.com__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2KwZ83HWJb$
 > / 
LinkedIn<https://urldefense.com/v3/__https://protect-au.mimecast.com/s/cRcaCNLJyQUZv3VNKiz4crx?domain=urldefense.com__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2KwVmUFjE7$
 >
[NCI Australia logo black PNG transparent]  [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!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9z2KwcvYCObB$
 
<https://urldefense.com/v3/__https://protect-au.mimecast.com/s/m8F6COMKzVTNqx5AVhjlO_B?domain=urldefense.com__;!!D9dNQwwGXtA!WIHkTVGNL8-BP1lT0UnHTkKpV5shocThKTpw8GOAbDUD3t4Ggchx300DytVMx70TrcRy7WgovYns9

Re: [SIESTA-L] Error in specifying the type of an atom

[I. Camps]

Hi,

In the AtomicCoordinatesAndAtomicSpecies  block, you only have 32 atoms,
but you declared that there are 94.

[]'s

Camps

Em sex., 21 de jul. de 2023 17:00, El-Abed Haidar <
ehai2...@uni.sydney.edu.au> escreveu:

> Good day all,
>
> I was wondering if anyone could help me understand why I got this error:
>
>
>
> *Error in specifying the type of an atom!. Atoms specified is above the
> total number of atoms!*
>
>
>
> even though we have the same number of atoms and we only have carbon
> atoms. Any thoughts?
>
>
>
> 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!S_E3MGS_H2nGE-46GPpJDRARcDpIVPtAZNb348LBywNX9oUF0wrSHiDxUvUz9HIFrdHlMIjM4IKK$
>  
> 
>
> 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!S_E3MGS_H2nGE-46GPpJDRARcDpIVPtAZNb348LBywNX9oUF0wrSHiDxUvUz9HIFrdHlMMElTSjZ$
>  )
>

-- 
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] Assunto: Re: Lattice parameters shorter than crystal after optimization

[José Xavier]

Dear, 
It's not a metallic system.. it is a crystal of organic molecules. Like in the 
article there are four amino acids in the unit cell. 

Could it be the eggbox effect? I'm performing a new optimization with higher 
k-points, and the result is the same.. the lattice parameters increase during 
~650 CG steps. After it, the parameters decrease 
outcell:  14.051222    7.857754    5.223328outcell:  14.052645    7.858561    
5.223709outcell:  14.054069    7.859367    5.224090outcell:  14.055492    
7.860173    5.224471outcell:  14.056915    7.860979    5.224852outcell:  
14.058338    7.861786    5.225233outcell:  14.057030    7.861045    
5.224883outcell:  14.056670    7.861153    5.225075outcell:  14.056310    
7.861261    5.225267outcell:  14.055949    7.861369    5.225459outcell:  
14.055589    7.861478    5.225650
-- 
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] Unfolding phonon dispersion

[Francisco Garcia]

Dear Users

I computed the phonon eigenvalues of a 108-atom FCC supercell (3x3x3
supercell built from a 4-atom FCC conventional unit cell). I was forced to
do so because of a special magnetic configuration required to obtain the
ground state.

Is it possible to unfold the supercell phonon dispersion to obtain the
primitive cell phonon dispersion in SIESTA?

I know that electronic bands can be unfolded (SIESTA has a utility for
this), but I couldn't find anything for phonons.

Any advice or assistance would be highly appreciated.

Thank you.

Francisco.

-- 
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] Lattice parameters shorter than crystal after optimization

[fthenak]

It is not an issue that you find lattice parameters smaller than the
experimental ones. This may depend on several factors, including the
selection of the functional you use.
The k-points should be inverse proportional to the lattice parameters.
They don't have to be equal. The energy for increasing k-points should
converge. According to what you wrote, maybe you need more k-points. On
the other hand the number of steps for convergence is too high. If the
system is metallic, you may introduce a small electronic temperature, or
introduce some mixing.
I hope this helps.

Zacharias Fthenakis

> Dear,
>
>
> Making some tests, I observed 2 things: 
>
>
> 1- The system takes ~1800 steps to converge the optimization. During ~700
> steps the lattice parameters (a, b, c) increase (beta almost isn't
> changing). It takes some more steps to the beta angle starts to change,
> while a, b, c decrease. It repeats in all tests I run. 
>
>
> 2- Using non-equal k points (2x4x2 and 4x6x4) the lattice parameter values
> are closer to the experimental than 4x4x4. 
>
>
> However, I continue getting values shorter than experimental. 
>
>
>
>
> --
> 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!TuCr_mMwS9nHTS06MagdjGH7Bi3JjX9pzEVRBcsRwSkdmZv2gCrAZkXyZzYPBlb9FtOIxjaXpFmaAhtaRQU$
>  )
>


*
Dr Zacharias G. Fthenakis
**


-- 
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] Lattice parameters shorter than crystal after optimization

[José Xavier]

Dear,


Making some tests, I observed 2 things: 


1- The system takes ~1800 steps to converge the optimization. During ~700 steps 
the lattice parameters (a, b, c) increase (beta almost isn't changing). It 
takes some more steps to the beta angle starts to change, while a, b, c 
decrease. It repeats in all tests I run. 


2- Using non-equal k points (2x4x2 and 4x6x4) the lattice parameter values are 
closer to the experimental than 4x4x4. 


However, I continue getting values shorter than experimental. 




-- 
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] Lattice parameters shorter than crystal after optimization

[fthenak]

Maybe the selection of an improper pseudopotential can cause problems. You
may have a look here
https://departments.icmab.es/leem/siesta/Pseudopotentials/index.html
for pseudopotentials for SIESTA. An option is to use the "atoms" code to
produce your own pseudopotential, but this is something that has to be
done with caution. Maybe trying a different pseudopotential, among those
which have already been tested, will solve your problem.

> Dear Dr. Fthenakis,
>
> Thank you again for answering my questions. 
>
> My main doubt isn't only the beta angle, but the whole changes in the
> lattice parameters. There are several crystal structures obtained for this
> neurotransmitter, and all of them have closer lattice parameters. Besides,
> it's common to find in the literature that lattice parameters are larger
> than experimental ones after geometry optimization performed with GGA-PBE
> functional. However, my results are the opposite. "a", "b", and "c" are
> ~10% shorter. 
>
> I'm new to Siesta, so I don't know if there are some forces acting to
> rearrange the internal parameters... like something trying to push the
> unit cell. I don't know..
>
> Could be easier to observe if there are any mistakes if I send the input
> file?
>
> By the way, I got the pseudopotentials from Simune website and the NNINC.
> I mentioned it because a friend had a similar problem when working with
> Quantum Espresso, and solved it by changing the source of the
> pseudopotential... I don't know if it could be the same here...
>


*
Dr Zacharias G. Fthenakis
**


-- 
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] Lattice parameters shorter than crystal after optimization

[José Xavier]

Dear Dr. Fthenakis,

Thank you again for answering my questions. 

My main doubt isn't only the beta angle, but the whole changes in the lattice 
parameters. There are several crystal structures obtained for this 
neurotransmitter, and all of them have closer lattice parameters. Besides, it's 
common to find in the literature that lattice parameters are larger than 
experimental ones after geometry optimization performed with GGA-PBE 
functional. However, my results are the opposite. "a", "b", and "c" are ~10% 
shorter. 

I'm new to Siesta, so I don't know if there are some forces acting to rearrange 
the internal parameters... like something trying to push the unit cell. I don't 
know..

Could be easier to observe if there are any mistakes if I send the input file?

By the way, I got the pseudopotentials from Simune website and the NNINC. I 
mentioned it because a friend had a similar problem when working with Quantum 
Espresso, and solved it by changing the source of the pseudopotential... I 
don't know if it could be the same here...

-- 
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] Lattice parameters shorter than crystal after optimization

[fthenak]

I can not find any mistake in your calculations. Maybe you can use a
different base. But, how do you know that the correct angle is 96^o and
not 99^o ? Is this difference very important for you? I mean several
theoretical approaches may have some differences with respect to the
experiment, but they sill can be used to derive useful results.


> Dear Siesta users,
> I'm trying to perform the optimization of an unit cell composed by four
> molecules of the a neurotransmitter (for reference, the type of system is
> similar to: J. Appl. Phys. 129, 234702 (2021);
> https://urldefense.com/v3/__https://doi.org/10.1063/5.0054383__;!!D9dNQwwGXtA!VFwPgy7nicqJ4IHnnPgVwKcU8-H_FqWGOqP4Sbhw1XjlP5vvlaNC3lgewdXOsPI0ygo0IQ2_Io4V3TxayhNCrw$
> ). It's a monoclinic crystal with equal alpha and gamma angles. 
> When I run the geometry optimization, the result is always the shortening
> of the a, b, c, alpha and gamma, and the increase of beta (from 96° to
> 98-99°). However, it is expected that the a, b, and c parameters to
> increase. I thought it could be something related with the
> pseudopotencial, and downloaded the PBE Pseudopotencial from different
> sources, but nothing change. 
> Could someone help me to understand what's wrong? 
> I'm including the parameters I used to control the simulation
> #MD.TypeOfRun           CG               MD.Steps                   
>  2000            MD.MaxDispl               0.001 Bohr      MD.MaxForceTol 
>        0.01 eV/Ang      MD.VariableCell         T             
>   MD.MaxStressTol        0.02 GPa         MD.TargetPressure      0.0 GPa 
>         
> # WriteCoorStep           TWriteForces             TWriteMDHistory       
>   TWriteCoorInitial        T
> # DM.UseSaveDM            TMD.UseSaveXV            TMD.UseSaveCG         
>   T
> Thank you for your help
> --
> 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!UqJJRS4uVg7t-Dbd_eAjfVnwWZ1t2C6FcN2aIQ3zMnpwP4Ll9vMlgtpcq4qP80YzOBfKsToR3FKvor_wWQ0$
>  )
>


*
Dr Zacharias G. Fthenakis
**


-- 
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] Lattice parameters shorter than crystal after optimization

[José Xavier]

Dear Siesta users,
I'm trying to perform the optimization of an unit cell composed by four 
molecules of the a neurotransmitter (for reference, the type of system is 
similar to: J. Appl. Phys. 129, 234702 (2021); 
https://urldefense.com/v3/__https://doi.org/10.1063/5.0054383__;!!D9dNQwwGXtA!VFwPgy7nicqJ4IHnnPgVwKcU8-H_FqWGOqP4Sbhw1XjlP5vvlaNC3lgewdXOsPI0ygo0IQ2_Io4V3TxayhNCrw$
 ). It's a monoclinic crystal with equal alpha and gamma angles. 
When I run the geometry optimization, the result is always the shortening of 
the a, b, c, alpha and gamma, and the increase of beta (from 96° to 98-99°). 
However, it is expected that the a, b, and c parameters to increase. I thought 
it could be something related with the pseudopotencial, and downloaded the PBE 
Pseudopotencial from different sources, but nothing change. 
Could someone help me to understand what's wrong? 
I'm including the parameters I used to control the simulation
#MD.TypeOfRun           CG               MD.Steps                     2000      
      MD.MaxDispl               0.001 Bohr      MD.MaxForceTol         0.01 
eV/Ang      MD.VariableCell         T                MD.MaxStressTol        
0.02 GPa         MD.TargetPressure      0.0 GPa          
# WriteCoorStep           TWriteForces             TWriteMDHistory          
TWriteCoorInitial        T
# DM.UseSaveDM            TMD.UseSaveXV            TMD.UseSaveCG            T
Thank you for your help
-- 
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/)

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

[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
# 
# Copyright (C) 1996-2016	The SIESTA group
#  This file is distributed under the terms of the
#  GNU General Public License: see COPYING in the top directory
#  or http://www.gnu.org/copyleft/gpl.txt.
# See Docs/Contributors.txt for a list of contributors.
#
#---

.SUFFIXES: .f .F .o .c .a .f90 .F90

SIESTA_ARCH = x86_64-unknown-linux-gnu--Intel

CC = mpicc
FPP = $(FC) -E -P -x c
FC = mpiifort
FC_SERIAL = ifort
MPI_INTERFACE = libmpi_f90.a
MPI_INCLUDE = .
FPPFLAGS += -DMPI

FFLAGS = -O2 -fPIC -fp-speculation=strict -fp-model strict -I${TACC_NETCDF_INC} #-I{EBROOTNETCDFMINFORTRAN}/include


AR = ar
RANLIB = ranlib

SYS = nag

SP_KIND = 4
DP_KIND = 8
KINDS = $(SP_KIND) $(DP_KIND)

LDFLAGS =

#COMP_LIBS = libsiestaLAPACK.a libsiestaBLAS.a

FPPFlAGS += -DFC_HAVE_ABORT -DFC_HAVE_FLUSH
#FPPFLAGS += $(DEFS_PREFIX) -DFC_HAVE_ABORT -DFC_HAVE_FLUSH
#
LIBS =

#BLAS_LIBS=-L${MKLROOT}/lib/intel64 -lmkl_blas95_lp64
#lAPACK_LIBS=-L${MKLROOT}/lib/intel64 -lmkl_lapack95_lp64
#SCALAPACK_LIBS= -L${MKLROOT}/lib/intel64 -lmkl_scalapack_ilp64 -lmkl_intel_ilp64 -lmkl_sequential -lmkl_core -lmkl_blacs_intelmpi_ilp64 -lpthread -lm -ldl
#
#qj MKL Link
BLAS_LIBS=-L${MKLROOT}/lib/intel64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core  -liomp5 -lpthread -lm -ldl
LAPACK_LIBS=-L${MKLROOT}/lib/intel64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core  -liomp5 -lpthread -lm -ldl
BLACS_LIBS=-lmkl_blacs_intelmpi_lp64
SCALAPACK_LIBS=-lmkl_scalapack_lp64
#
#
NETCDF_LIBS=-L${TACC_NETCDF_LIB} -lnetcdff -lnetcdf
HDF5_LIBS=-L${TACC_HDF5_LIB} -lhdf5_fortran -lhdf5 -lz
##Z_LIBS=-L${EBROOTZLIB}/lib -lz
###LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(SCALAPACK_LIBS) $(NETCDF_LIBS) $(HDF5_LIBS)
##
#FFTW_LIBS=-L${EBROOTFFTW}/lib -lfftw3 -lfftw3f # This line is in QJ's Davinci arch.make file

LIBS = $(SCALAPACK_LIBS) $(BLACS_LIBS) $(LAPACK_LIBS) $(BLAS_LIBS) $(NETCDF_LIBS) $(HDF5_LIBS)
##
CPPFLAGS=-I${TACC_NETCDF_INC}/include   #Added by Yuefei
##
COMP_LIBS += libncdf.a libfdict.a  #Added by Yuefei, ncdf
FPPFLAGS += -DCDF -DNCDF -DNCDF_4
FPPFLAGS += -DNCDF_PARALLEL

INCFLAGS += -I/home1/05762/tg850616/Compile/Compile_SIESTA/siesta-4.1-b4-Intel/Docs/build/flook/0.7.0/include
LDFLAGS += -L/home1/05762/tg850616/Compile/Compile_SIESTA/siesta-4.1-b4-Intel/Docs/build/flook/0.7.0/lib -Wl,-rpath=/home1/05762/tg850616/Compile/Compile_SIESTA/siesta-4.1-b4-Intel/Docs/build/flook/0.7.0/lib
LIBS += -L/opt/flook/lib -lflookall -ldl
COMP_LIBS += libfdict.a
FPPFLAGS += -DSIESTA__FLOOK
#

# Dependency rules -

FFLAGS_DEBUG = -g -O1 -fp-model source   # your appropriate flags here...

# The atom.f code is very vulnerable. Particularly the Intel compiler
# will make an erroneous compilation of atom.f with high 

[SIESTA-L] External potential in siesta calculations.

[agaur]

Hello All,

I am wondering if there is a way to add external potential at atomic 
sites or as grid file in siesta calculations.


In short, can the potential (Electrostatic and/or Total) calculated and 
saved in NetCDF format can be used in another siesta calculation 
(keeping the grid, unit-cell dimensions the same). Also, is it possible 
to add external potential distribution from other sources (such as 
COMSOL) in siesta calculations? The potential distribution is non-linear 
and non-uniform but static.


Any insights would be really helpful.

Regards.

Anshu
-- 
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] Two Quick transiesta questions

[El-Abed Haidar]

Good afternoon all,
I was wondering:

  *   Transiesta has issues with negative coordinates or lattice vectors or not 
while doing Transiesta calculations?
  *   I was trying to look up in the siesta mail for the proper procedure to 
use Transiesta. I could not find it but wondering in terms of getting the right 
fdf format and proper procedure if anyone could go list out the steps?

Thank you very much! Looking forward to all responses!

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!TA5MMDMG-pihjtiQUOcaDnDp0SzZ-Zv9r1iKQDLTBS-X8LN20EdPamG6O-JSItzowCFyrkx0YBAghfK4pDsvxRS1$
 
Find out more about NCI: 
YouTube  / 
Facebook / 
Twitter / 
LinkedIn
[NCI Australia logo black PNG transparent]  [MHFAider Accredited Digital Badge]


-- 
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] Core-hole pseudopotential

[Rubén Soria]

Dear SIESTA user's,


I would like to create a pseudopotential with a core-hole to compute the
core level shift and the binding energy of my system. I was reading the
atom code but there is no way (or I don't know how) to specify a core hole.
Also, I found and read two papers ans in one of them there is a footnote 1
"This pseudopotential is constructed reducing the occupation of the core
level configuration by one."
I would like to know how could be it done.


DOI: 10.1140/epjb/e2012-30334-5
DOI;10.1016/j.susc.2013.03.017


Thanks in advance


Rubén

-- 
Aunque mi madre no sabía nada de ciencia, también ejerció sobre mí una gran
influencia.
Yo, un universo de átomos, un átomo en el universo.

-- 
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] Question Regarding Relaxation Calculations in Molecular Junctions

[zahra Sartipi]

Dear Siesta users,

I'm currently working on relaxation calculations for a molecular junction (
Please see figures 8, 9 and 11 of the article  "
https://urldefense.com/v3/__https://journals.aps.org/prb/abstract/10.1103/PhysRevB.65.165401__;!!D9dNQwwGXtA!RFzNsWVuURE6G4-aGPFeW3zMgHQ3Z4TxT8NGrC3ykKZ--sjsFh9sW3AoLlw8v4Zgpm0D4ZLsx6he-K4CsA$
 .")


For relaxation calculations of a molecular junction, which includes a
scattering region and electrodes, is it possible to keep the atomic
positions of the electrode region fixed, only allowing for changes in the
atomic positions of the scattering region?

Best regards,
Zahra Sartipi

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

Re: [SIESTA-L] How to increase the number of significant figures of energy values in .out file

[agaur]

In addition, is it possible to increase significant digits of energy in 
.band file? Currently, it is limited to 4 decimal places only.


Regards,

Anshu

On 27-04-2023 14:37, Fanmiao Kong wrote:


Dear Siesta users,

Does anyone know how to increase the number of significant figures of 
the energy values in output file? Currently it has only 6 digits after 
decimal point. I am calculating the singlet-triplet gap of a molecule. 
The gap is very small and I want to increase the precision of the total 
energy, with at least 10 digits after decimal place.


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
-- 
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] How to increase the number of significant figures of energy values in .out file

[Fanmiao Kong]

Dear Siesta users,

Does anyone know how to increase the number of significant figures of the 
energy values in output file? Currently it has only 6 digits after decimal 
point. I am calculating the singlet-triplet gap of a molecule. The gap is very 
small and I want to increase the precision of the total energy, with at least 
10 digits after decimal place.

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


-- 
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] [***Posible SPAM***] SUBSCRIBE SIESTA-L

[zahra Sartipi]

-- 
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] Constraints in positive or negative z-direction

[Ramon Sampaio Ferreira]

Dear Daniel,

I aim to try to induce some sp3 bonds between the layers, forcing them by
hydrogenating (or by other chemical groups) a couple of carbon atoms (the
non-constrained atoms) and strain. In fact, I'm trying to obtain the 2D
diamond structure and then trying to use the same methodology in other
structures (doped ones, for example).

I understood your comments and now believe I can perform these calculations
with your advice, I am immensely grateful.


Em sáb., 8 de abr. de 2023 às 17:00, Daniel Bennett 
escreveu:

> Hi Ramon,
>
> I'm not sure if this is such a good idea, at least in your example. If I
> understand correctly, you freeze the first graphene layer (in the z=0 plane
> say), then the second graphene layer is at some z which is larger than the
> optimal one which minimizes the van der Waals energy. Then you move the
> second layer in the negative z direction, closer to the first, until it
> reaches the minimum distance. But in relaxations, the coordinates
> oscillating about the minimum until they converge below a given tolerance.
> As soon as the second layer passes to the other side of that minimum, the
> energy will explode, because it can only move closer to the first layer.
> The same thing will happen if you constrain the atoms to move in the other
> direction and begin with the second layer too close to the first: the
> second layer will move to the other side of the cell in the z-direction,
> and you will have the same problem on the other side of the first graphene
> layer. It might work if you get lucky and the system happens to get very
> close to the minimum without going beyond it, but I think this would be
> very unlikely to happen
>
> Are you trying to do this for graphene, or something more complicated?
> Because with bilayer graphene if you freeze the first layer, the xy
> components of the second, and force the z components of the second to be
> equal, only one parameter needs to be optimized, and siesta can do this
> very efficiently with its native geometry constraints.
>
> Daniel Bennett
>
>
> --
> *From:* siesta-l-requ...@uam.es  on behalf of
> Ramon Sampaio Ferreira 
> *Sent:* 07 April 2023 11:13
> *To:* siesta-l@uam.es 
> *Subject:* [SIESTA-L] Constraints in positive or negative z-direction
>
>
> Hi there,
>
> I know that SIESTA allows some restrictions on atomic displacements.
> However, I didn’t find in the manual a way to allow atomic displacement
> only in the negative or positive z-direction during the relaxation process
> for specific atoms. For example: During the relaxation process of a
> graphene bilayer, I would like to freeze the atoms on one sheet (I know how
> to do that) and allow specific atoms on the other sheet to move only in the
> negative z-direction.
>
> Is it possible to enforce this kind of restriction? My idea is that it is
> possible to do this by modifying the construct.f routine, am I right in
> thinking this way? There are other ways to do that?
>
> Thank you so much for your help.
>
> --
>
> *Ramon Sampaio Ferreira*
> Doutorando em Física
> Programa de Pós-Graduação em Física - Universidade Federal do Ceará
> Campus do Pici - Bloco 928
>
> --
> 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!TJ4BQ9j0GGUqe7PUKu5fA9-bjaslnczB01iSHZu0ZZ2NU-wdu2oEm-ALq0XLt4YQ4g9diYHMJcuA-diKjg$
>  )
>


-- 

*Ramon Sampaio Ferreira*
Doutorando em Física
Programa de Pós-Graduação em Física - Universidade Federal do Ceará
Campus do Pici - Bloco 928

-- 
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] Constraints in positive or negative z-direction

[Daniel Bennett]

Hi Ramon,

I'm not sure if this is such a good idea, at least in your example. If I 
understand correctly, you freeze the first graphene layer (in the z=0 plane 
say), then the second graphene layer is at some z which is larger than the 
optimal one which minimizes the van der Waals energy. Then you move the second 
layer in the negative z direction, closer to the first, until it reaches the 
minimum distance. But in relaxations, the coordinates oscillating about the 
minimum until they converge below a given tolerance. As soon as the second 
layer passes to the other side of that minimum, the energy will explode, 
because it can only move closer to the first layer. The same thing will happen 
if you constrain the atoms to move in the other direction and begin with the 
second layer too close to the first: the second layer will move to the other 
side of the cell in the z-direction, and you will have the same problem on the 
other side of the first graphene layer. It might work if you get lucky and the 
system happens to get very close to the minimum without going beyond it, but I 
think this would be very unlikely to happen

Are you trying to do this for graphene, or something more complicated? Because 
with bilayer graphene if you freeze the first layer, the xy components of the 
second, and force the z components of the second to be equal, only one 
parameter needs to be optimized, and siesta can do this very efficiently with 
its native geometry constraints.

Daniel Bennett



From: siesta-l-requ...@uam.es  on behalf of Ramon 
Sampaio Ferreira 
Sent: 07 April 2023 11:13
To: siesta-l@uam.es 
Subject: [SIESTA-L] Constraints in positive or negative z-direction


Hi there,

I know that SIESTA allows some restrictions on atomic displacements. However, I 
didn’t find in the manual a way to allow atomic displacement only in the 
negative or positive z-direction during the relaxation process for specific 
atoms. For example: During the relaxation process of a graphene bilayer, I 
would like to freeze the atoms on one sheet (I know how to do that) and allow 
specific atoms on the other sheet to move only in the negative z-direction.

Is it possible to enforce this kind of restriction? My idea is that it is 
possible to do this by modifying the construct.f routine, am I right in 
thinking this way? There are other ways to do that?

Thank you so much for your help.

--
[https://urldefense.com/v3/__https://www.quixada.ufc.br/wp-content/Arquivos_Site/Brasao*20Horizontal*20UFC*20Policromatico.png__;JSUl!!D9dNQwwGXtA!VENvDzcOvOWpfn_Zkw13PW7PctnZQGcYDIP5n82ctxipjXtSbMoTCw3dOFzc-lLMkRLIV22m1o7hZPrx$
 ]
Ramon Sampaio Ferreira
Doutorando em Física
Programa de Pós-Graduação em Física - Universidade Federal do Ceará
Campus do Pici - Bloco 928

-- 
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] Constraints in positive or negative z-direction

[Ramon Sampaio Ferreira]

Hi there,

I know that SIESTA allows some restrictions on atomic displacements.
However, I didn’t find in the manual a way to allow atomic displacement
only in the negative or positive z-direction during the relaxation process
for specific atoms. For example: During the relaxation process of a
graphene bilayer, I would like to freeze the atoms on one sheet (I know how
to do that) and allow specific atoms on the other sheet to move only in the
negative z-direction.

Is it possible to enforce this kind of restriction? My idea is that it is
possible to do this by modifying the construct.f routine, am I right in
thinking this way? There are other ways to do that?

Thank you so much for your help.

-- 

*Ramon Sampaio Ferreira*
Doutorando em Física
Programa de Pós-Graduação em Física - Universidade Federal do Ceará
Campus do Pici - Bloco 928

-- 
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] about the Transiesta calculation problem

[Bo Xiao]

Dear users

I have compile the siesta-4.1.5 sucessfully.
However, when i run the test job of ts_graphene, the calculation stoped at the 
beginning of Transiesta.
The corresponding files are attached.

Thanks for your help.


graphene.fdf
Description: graphene.fdf


scatt.pbs
Description: scatt.pbs


pure.e184326
Description: pure.e184326


output
Description: output

-- 
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] about the 'You are initializing the electrode EDM'

[Bo Xiao]

Dear Siesta users

I am calculating the I/V curve for one system, while some warning messages were 
shown in the output file
"You are initializing the electrode EDM. This may result in erroneous forces on 
electrode atoms. Do not use forces from electrodes"
I have read the manual, but can not find any information related to this error.
So, i am wondering how to avoid this error, or whether this warning could be 
ignored?

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/)

Re: [SIESTA-L] What is ADOS?

[yh46]

Hello Srest,
I think ADOS measures how much the DOS of a certain electrode is  
spilled onto a certain set of orbitals. So it is related to the DOS of  
the electrode, and how strong the orbitals are coupleed to the  
electrode. If the scattering region is not connected in the same way  
to the two electrodes, it is should have different ADOS.
The book 'Electronic transport in mesoscopic systems' from Supriyo  
Datta should have a full explanation about it.

Best,
Yuefei

Quoting msz228074 :


Hi Siesta users,

I am trying to calculate transport across two system. Now, if ADOS  
is spectral DOS of electrode and if I am using same electrode in  
both the cases (with diff scattering region) why I am getting  
different average ADOS? I don't think I clearly understand what ADOS  
actually is.


Any help would be useful.

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



--
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 (http://www.max-centre.eu/)

[SIESTA-L] What is ADOS?

[msz228074]

Hi Siesta users,

I am trying to calculate transport across two system. Now, if ADOS is 
spectral DOS of electrode and if I am using same electrode in both the 
cases (with diff scattering region) why I am getting different average 
ADOS? I don't think I clearly understand what ADOS actually is.


Any help would be useful.

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 (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] About Work Function Calculation on Au

[yh46]

Hello SIESTA users,
I found that this is due to choice of PAO.EnergyShift, the work  
function value is very sensitive to the selection of this parameter.  
With PAO.EnergyShift = 0.02 Ry I get 3.5 eV. With PAO.EnergyShift =  
0.001 Ry,  I get 5.1eV.


I know that the role of this parameter is changing the localization of  
the basis functions. Is there an a priori way to determine this  
parameter, beside comparing the results with other sources  
(experiments, other codes etc.)?


Thank you very much!

Best,
Yuefei


Quoting yh46 :


Hello Dear Prof. Garcia,
Thank you very much!

Actually I have tried 30 layers. The work function is very close  
(within 0.2eV, 30 layer even smaller).


I plotted the potential along z direction using  
ElectrostaticPotential.grid.nc. The potential profile is flat in the  
vacuum. The value of the potential is basically the vacuum level in  
the output file, which I subtract the Fermi level in the output file  
to get work function.


Is there any other possible cause that could lead to this strange  
result of work function? Thank you!


Best,
Yuefei


Quoting Alberto Garcia :


Hi,

Your 'slab' is just three layers thick... that is not nearly enough  
to have a good representation of

a "bulk" region in the center and a "surface" region.

After you fix that, you probably need to process the .VH file and  
obtain a potential profile along

z to check that you reach a flat region in the vacuum.

Alberto

- El 15 de Marzo de 2023, a las 11:41, yh46  escribió:

| Hello Dear SIESTA Users,
| I am trying to do a work function calculation of Au 111 surface. The
| work function I get if 3.5 eV, which is quite different from
| experimental results ~ 5.26eV, or Quantum Espresso Result(Physical
| Review B, 2009, 80(23): 235407) ~ 5.15eV, or VASP result from my
| own~4.8eV. I understand that they are different codes, however the
| results are too different. I am wondering if there is anything wrong
| with my input file or the pseudo potential file that I use? I have
| attached the input files. 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!SR7RKg5wYyo4KC7PNB4i_YnJUjJdXsj-mVehHFyh_ZVKs3VnEZJW6r_lWnes9l149P-x9YbDmN_sXQ$

| )



--
Yuefei Huang
Graduate Student
Department of Material Science and NanoEngineering
Rice University
email: yuefei.hu...@rice.edu
phone: +1-832-499-9169



--
Yuefei Huang
Graduate Student
Department of Material Science and NanoEngineering
Rice University
email: yuefei.hu...@rice.edu
phone: +1-832-499-9169
TACC:  Starting up job 11076108 
TACC:  Starting parallel tasks... 
Siesta Version  : v4.1-b4
Architecture: x86_64-unknown-linux-gnu--Intel
Compiler version: ifort (IFORT) 18.0.2 20180210
Compiler flags  : mpiifort -O2 -fPIC -fp-speculation=strict -fp-model strict 
-I/opt/apps/intel118/impi18_0/parallel-netcdf/4.6.2/x86_64/include
PP flags: -DMPI -DCDF -DNCDF -DNCDF_4 -DNCDF_PARALLEL
Libraries   : libncdf.a libfdict.a   -lmkl_scalapack_lp64 
-lmkl_blacs_intelmpi_lp64 
-L/opt//intel/compilers_and_libraries_2018.2.199/linux/mkl/lib/intel64 
-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core  -liomp5 -lpthread -lm -ldl 
-L/opt/intel/compilers_and_libraries_2018.2.199/linux/mkl/lib/intel64 
-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core  -liomp5 -lpthread -lm -ldl 
-L/opt/apps/intel18/impi18_0/parallel-netcdf/4.6.2/x86_64/lib -lnetcdff 
-lnetcdf -L/opt/apps/intel18/impi18_0/phdf5/1.10.4/x86_64/lib -lhdf5_fortran 
-lhdf5 -lz
PARALLEL version
NetCDF support
NetCDF-4 support
NetCDF-4 MPI-IO support

* Running on 90 nodes in parallel
>> Start of run:  22-MAR-2023   4:10:03

   ***   
   *  WELCOME TO SIESTA  *   
   ***   

reinit: Reading from SIESTA.fdf

reinit: ---
reinit: System Name: Au
reinit: ---
reinit: System Label: SIESTA
reinit: ---

initatom: Reading input for the pseudopotentials and atomic orbitals --
Species number:   1 Atomic number:   79 Label: Au
 
Ground state valence configuration:   6s01  5d10
Reading pseudopotential information in formatted form from Au.psf

Valence configuration for pseudopotential generation:
6s( 1.00) rc: 2.63
6p( 0.00) rc: 2.77
5d(10.00) rc: 2.63
5f( 0.00) rc: 2.63
For Au, standard SIESTA heuristics set lmxkb to 3
 (one more than the basis l, including polarization orbitals).
Use PS.lmax or PS.KBprojectors blocks to override.

[SIESTA-L] about the 'Electrode connectivity is not perfect'

[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


output
Description: output


scatt.fdf
Description: scatt.fdf

-- 
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] STM Utility Inquiry

[Nadia Salami]

Hi,
I want to plot the LDOS of my system including a 2D material by using stm
utility within the siesta-3.2 package. So I tried some of the examples
included in the corresponding doc in the Util/stm/ol-stm/Examples.
According to the user's guide of STM.1.0.1, at first WFSX was converted to
WFS using compiled code of wfsx2wfs. After that the stm code was runned by
command of ./stm 
-- 
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 Work Function Calculation on Au

[Alberto Garcia]

Hi, 

Your 'slab' is just three layers thick... that is not nearly enough to have a 
good representation of 
a "bulk" region in the center and a "surface" region. 

After you fix that, you probably need to process the .VH file and obtain a 
potential profile along 
z to check that you reach a flat region in the vacuum. 

Alberto 

- El 15 de Marzo de 2023, a las 11:41, yh46  escribió: 

| Hello Dear SIESTA Users,
| I am trying to do a work function calculation of Au 111 surface. The
| work function I get if 3.5 eV, which is quite different from
| experimental results ~ 5.26eV, or Quantum Espresso Result(Physical
| Review B, 2009, 80(23): 235407) ~ 5.15eV, or VASP result from my
| own~4.8eV. I understand that they are different codes, however the
| results are too different. I am wondering if there is anything wrong
| with my input file or the pseudo potential file that I use? I have
| attached the input files. 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!SR7RKg5wYyo4KC7PNB4i_YnJUjJdXsj-mVehHFyh_ZVKs3VnEZJW6r_lWnes9l149P-x9YbDmN_sXQ$
| )

-- 
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

[Daniel Bennett]

Thanks Nick! Good to hear this is a known problem and not something on my end. 
For the record, I tried D, expert and MRRR solvers, and they all had this 
problem.

At the moment, intel 2021 is the only version for which the compilers, MPI and 
MKL all worked for siesta on my cluster, so I am stuck with it for now. We will 
have a big upgrade including intel 23 in the coming months. I will also build 
siesta with the ELPA solver going forward to be safe (or finally move to 
compiling with ESL). I'm working on recompiling my current version ELPA, but 
having some problems compiling ELPA. For now my not so elegant solution was to 
lower the kpoints and energy cutoff and increase cores to reduce memory-related 
crashes, and resbumit if they crash. It's working ok for now until I get the 
long term solutions working

Danny

From: siesta-l-requ...@uam.es  on behalf of Nick 
Papior 
Sent: 27 February 2023 03:07
To: siesta-l@uam.es 
Subject: Re: [SIESTA-L] Memory problems with SOC

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!UGLOSLEhGEY9xiUzENi1YMH4paRXN8Bztvik-VhAh_gu_vPS4z4F8c3B_nr5dFRJmnfpAJDmZMqZUsgU$
 
<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 
mailto:db...@cantab.ac.uk>>:
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!UGLOSLEhGEY9xiUzENi1YMH4paRXN8Bztvik-VhAh_gu_vPS4z4F8c3B_nr5dFRJmnfpAJDmZL6SNciY$
 
<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] 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/)

[SIESTA-L] Memory problems with SOC

[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 (http://www.max-centre.eu/)

[SIESTA-L] Does siesta consider periodicity in scattering region?

[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 (http://www.max-centre.eu/)

[SIESTA-L] [***Posible SPAM***] about the master version of siesta

[Bo Xiao]

Dear user

The mater version of siesta support the psml potental and contain all the 
features of V4.1+, while it is a developed version.
I am wondering whether the results obtained from this mater version is all 
right, and publish paper.

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-L] [***Posible SPAM***] about the method to obtain the pseudo potentials

[Bo Xiao]

Dear users,

As i know, there are several methods to obtain the pseudo potentials, while i 
am wondering whcih one is recommanded or safe.

  1.   I konw the best method is by using the ATOM package, while its input 
file and the subsquent test procedure is sometimes difficult to deal with.
  2.  I can download the pseudo potential from  
PseudoDojo with .psml format. Then, by using the psml2psf coverter,
with the command line: psml2psf -o Hf.psf Hf.psml, the Hf.psf was obtained. 
When using Hf.psf, i still need to include the electron state in the PAO.basis 
part in the .fdf input file.
Is it possible to fullfill the PAO.basis part automatically? is this method 
safe?
In this website 
https://urldefense.com/v3/__https://www.simuneatomistics.com/siesta-pro/siesta-pseudos-and-basis-database/__;!!D9dNQwwGXtA!QLKbXiqFrfXQs1wLG_i4QTrGWgPTC8rqyYYDrWSXBsqsJxwzcrQe2OYDgn1EyCayVNKDaAROBZOkeqcmMaQ$
 , it provied the pseudo potentials of limited elements together with the 
corrponding PAO.basis part.

   3. Obtain the pseudo potential with .psf directly from here  
https://departments.icmab.es/leem/SIESTA_MATERIAL/Databases/Pseudopotentials/periodictable-gga-abinit.html,
 the PAO.basis part is included.
Is there any method to obtain the pseudo potentials?

Thanks!

-- 
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

[Andrei Postnikov]

Isn't this information explicitly included in .ion files - 
after a general header, one basis function after the other? 
You just need to cut whichever you want and feed it to a plotting program... 
Best regards, 
A.P. 

... 

# PAOs:__ 

0 2 1 0 2.00 #orbital l, n, z, is_polarized, population 

500 0.132468670984E-01 6.61018668210 # npts, delta, cutoff 

0.000 0.287172515330 

0.132468670984E-01 0.287187021634 

0.264937341968E-01 0.287232752566 

0.397406012952E-01 0.287308980728 

0.529874683936E-01 0.287415720365 

... 

- Le 15 Fév 23, à 15:34, Emilio Artacho  a écrit : 

> Check the WriteIonPlotFiles option

> E

>> On 14 Feb 2023, at 06:17, Francisco Garcia < [ 
>> mailto:garcia.ff@gmail.com |
>> garcia.ff@gmail.com ] > wrote:
>> 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!S0apBc_vxFM3XsCbZ2x_Ek6V_jNWS_G7uxbf6fayBqjsXL1bU6GTY35UzarXF3pSaMhFMFRLKKd94oJ0dFV9$
>> | 
>> https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!W61yKVCs4FflUUO_VbPHAuO0S3HZ8Xzc17Dr0DE6UJW862iIwupaYKBiGgBCBcoIWd0sdJ20S4blr36ZkIE3e-aI_Z3qKyHZtQ$
>>   ] )

> --
> Emilio Artacho

> Theory Group, Nanogune, 20018 San Sebastian, Spain, and
> Theory of Condensed Matter, Department of Physics,
> Cavendish Laboratory, University of Cambridge, Cambridge CB3 0HE, 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!W61yKVCs4FflUUO_VbPHAuO0S3HZ8Xzc17Dr0DE6UJW862iIwupaYKBiGgBCBcoIWd0sdJ20S4blr36ZkIE3e-aI_Z3qKyHZtQ$
>  )

-- 
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

[Emilio Artacho]

Check the WriteIonPlotFiles option

E


On 14 Feb 2023, at 06:17, Francisco Garcia 
mailto:garcia.ff@gmail.com>> wrote:

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!S0apBc_vxFM3XsCbZ2x_Ek6V_jNWS_G7uxbf6fayBqjsXL1bU6GTY35UzarXF3pSaMhFMFRLKKd94oJ0dFV9$
 )

--
Emilio Artacho

Theory Group, Nanogune, 20018 San Sebastian, Spain, and
Theory of Condensed Matter, Department of Physics,
Cavendish Laboratory, University of Cambridge, Cambridge CB3 0HE, UK




-- 
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] Relaxation constraints, using rigid on separate groups of atoms

[Nick Papior]

The input you have means:

1) all forces along x and y are made 0
2) atoms 1 - 10 are not moved *at all*
3) atoms 11 - 20 will be moved as though they are 1 atom. Since there is
only z forces (due to 1), then this block of atoms will move along z, and
the average z force determines the movement.
4, 5) same as 3, but for those groups independently.

So the 3 rigid groups are moved separately, using their own group's average
forces.

If you want to fix the z coordinate, you

Hope this clarifies the use?


Den man. 13. feb. 2023 kl. 22.03 skrev Daniel Bennett :

> Hi all,
>
> I was wondering what happens if I used the "rigid" option several times in
> the geometry constraints block. Let's say I want to relax a stack of
> monolayers, but keeping the z coordinates of the atoms in individual layer
> equal. For example, if there are 10 atoms in each layer, the constraint
> block would look something like this:
>
> %block Geometry.Constraints
>  atom all 1.0 0.0 0.0   # Fix in-plane coordinates
>  atom all 0.0 1.0 0.0
>  atom [1 -- 10]# Freeze layer 1
>  rigid [11 -- 20]   # Relax layer 2, same z coord
>  rigid [21 -- 30]   # Relax layer 3
>  rigid [31 -- 40]   # Relax layer 4
> %endblock Geometry.Constraints
>
> My question is: Does each use group of rigid fix that group of atoms
> independently, or are all of the atoms specified in all three uses of rigid
> grouped together?
>
> 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!V2SplgVeU3EMpyPEXkzb83MnZ5ECyzauXoApNHuPtmIgNtz8k8cKXBivYIKJsm9CUU8xeqofCB_RcSldpQ$
>  )
>


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

[Francisco Garcia]

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 (http://www.max-centre.eu/)

[SIESTA-L] Relaxation constraints, using rigid on separate groups of atoms

[Daniel Bennett]

Hi all,

I was wondering what happens if I used the "rigid" option several times in the 
geometry constraints block. Let's say I want to relax a stack of monolayers, 
but keeping the z coordinates of the atoms in individual layer equal. For 
example, if there are 10 atoms in each layer, the constraint block would look 
something like this:

%block Geometry.Constraints
 atom all 1.0 0.0 0.0   # Fix in-plane coordinates
 atom all 0.0 1.0 0.0
 atom [1 -- 10]# Freeze layer 1
 rigid [11 -- 20]   # Relax layer 2, same z coord
 rigid [21 -- 30]   # Relax layer 3
 rigid [31 -- 40]   # Relax layer 4
%endblock Geometry.Constraints

My question is: Does each use group of rigid fix that group of atoms 
independently, or are all of the atoms specified in all three uses of rigid 
grouped together?

Thanks,

Daniel Bennett


-- 
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] Gaussian basis vs numerical basis

[Francisco Garcia]

Dear users,

I would like to know why calculations with a Gaussian basis are in general
more expensive than a numerical basis like the type used in SIESTA.

Both Gaussian and numerical basis sets are atom-centered so one would
expect their performance not to be too far apart.

Is the SIESTA basis set faster because the radial part of the basis is
stored on a log grid? Or is it because the confining potential shortens the
radial extent of the basis set, thereby making it more compact?

Any inputs from the experts would be appreciated.

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/)

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

[Alberto Garcia]

Hi, 

This is something that we are planning to implement. 
For now, if file space is a problem, you could use symbolic links from a 
central location to each execution directory. 

Best regards, 
Alberto 

- El 3 de Feb de 2023, a las 19:33, Daniel Bennett  
escribió: 

| 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!RkZdOSfo_MsQg4qvNBNkO_hKMLIOgXOgHejCMx12JNdSBwMcEJ5r8R4jZiIBUeCA4m2Clw4QwoF4MdvrqA$
| )

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

[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 (http://www.max-centre.eu/)

Re: [SIESTA-L] Restarting calculations with different spin orientations

[Andres Tellez Mora]

Thank you, Nick.

I had used sisl previously and didn't know it could do that. I was able to
converge the other spin configurations without issues.

Best,
Andres.

On Wed, Feb 1, 2023 at 4:11 PM Nick Papior  wrote:

> 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!SxJyOfo0c7E4r3CqXVdJ00u8p47cOpuD6_uLXukTlMd5FgcFugEdGNvPG4iDhYudDT06N4Vfyqf86NGymlI$
>  
> 
>
> 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!SxJyOfo0c7E4r3CqXVdJ00u8p47cOpuD6_uLXukTlMd5FgcFugEdGNvPG4iDhYudDT06N4Vfyqf8YJI5B10$
>>  
>> 
>> )
>>
>
>
> --
> 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!SxJyOfo0c7E4r3CqXVdJ00u8p47cOpuD6_uLXukTlMd5FgcFugEdGNvPG4iDhYudDT06N4Vfyqf8YJI5B10$
>  )
>

-- 
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] I forgot my sign in password

[Mpayami]

Dear SIESTA Administrator,

Hi.
Kindly, I have forgotten my SIGN_IN password to access the online materials in 
the documentation tab of 
https://urldefense.com/v3/__https://siesta-project.org/SIESTA_MATERIAL/Docs/Tutorials/soc-2018-icn2/index.html__;!!D9dNQwwGXtA!SQeBb9dV3eNdAuDww8HP7raYNkzBeAWMNpNPcIo_SqqKcCOCgbtSM0PibWSI1xCk2-lUM7jrp6sFxJw$
 

I would be grateful if you please help me manage it.

Best regards,


Mahmoud Payami
NSTRI, AEOI
Tehran, Iran
Email: mpay...@aeoi.org.ir
Phone: +98(0)2182066504
- Original Message -




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

[Andrei Postnikov]

Dear Andres Tellez, 
my DMtune tool was written having similar tasks in mind; 
please feel free to download it from 
[ 
https://urldefense.com/v3/__https://www.home.uni-osnabrueck.de/apostnik/download.html__;!!D9dNQwwGXtA!UOZi7W_dTZOE_UPIXqgD4MdGacy1Fx8Kvs3HymrL_qKWalh8UtdNSwuKc4JOVzfzoPLVLIAZ5uHSbQoT-gAurVYvIzKoJQhPng$
  | 
https://urldefense.com/v3/__https://www.home.uni-osnabrueck.de/apostnik/download.html__;!!D9dNQwwGXtA!UOZi7W_dTZOE_UPIXqgD4MdGacy1Fx8Kvs3HymrL_qKWalh8UtdNSwuKc4JOVzfzoPLVLIAZ5uHSbQoT-gAurVYvIzKoJQhPng$
  ] 
and test whether it still works and applies to your case. 
There is no special documentation, but minimal explanations are included 
at the beginning of the source file dmtune.f. 
In case of problems it should not be difficult to modify, or pass me a word 
(with an example), I'll try to update. 

Best regards 

Andrei Postnikov 

- Le 31 Jan 23, à 18:14, Andres Tellez Mora  a écrit : 

> 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!UOZi7W_dTZOE_UPIXqgD4MdGacy1Fx8Kvs3HymrL_qKWalh8UtdNSwuKc4JOVzfzoPLVLIAZ5uHSbQoT-gAurVYvIzK9M_8LNA$
>  )

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

[Andres Tellez Mora]

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

[Daniel Bennett]

You can check the list of vdW functionals in the siesta manual:

https://departments.icmab.es/leem/SIESTA_MATERIAL/Docs/Manuals/siesta-4.1-b4.pdf

pages 48-49

Daniel Bennett

From: siesta-l-requ...@uam.es  on behalf of Mahbubeh 
Amiri 
Sent: 25 January 2023 05:43
To: siesta-l@uam.es 
Subject: [SIESTA-L] DFT-D3 in Siesta package

You don't often get email from amirimahbu...@gmail.com. Learn why this is 
important<https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!D9dNQwwGXtA!VCbVwN3fSRYeRnXV3ZeO27XteJsIv0EldZaRImrYPkU_o85q1XhF_kCy-9LM0zOhBh1JK3Jl0_KBlutl$
 >

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 (http://www.max-centre.eu/)

[SIESTA-L] DFT-D3 in Siesta package

[Mahbubeh Amiri]

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 (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/)

[SIESTA-L] Siesta-master Pseudopotential issues

[Francisco Garcia]

Dear Users/Developers

I noticed that siesta-master (the latest version) has a problem reading
some pseudopotentials whereas siesta-v 4.1.5 has no such issue.

For example: version 4.1.5 can read Ga psf with 3d10 4s2 4p1 or 4s2 4p1 4f0
as the reference state. However, the latest siesta-master fails to read the
3d10 4s2 4p1 psf but reads 4s2 4p1 4f0 successfully. The error message in
siesta-master is: Total charge in occupied basis states different from
valence charge.

Is there any particular reason why one version of SIESTA reads both psfs
and the other can't?

Thanks!

PS: I was forced to resort to siesta-master because I get the following
error is siesta v 4.1.5 (the error occurs for a few systems; setting the
optimization flag to -O0 and recompiling doesn't alleviate the problem is v
4.1.5):

Image  PCRoutineLineSource
libpthread-2.31.s  14C32F8A88C0  Unknown   Unknown  Unknown
siesta 00BD6729  gpfa2f329  fft1d.F
siesta 00BD5F63  gpfa  194  fft1d.F
siesta 004560F6  fft   193  fft.F
siesta 00570A11  poison103  poison.F
siesta 004623C1  dhscf_init406  dhscf.F
siesta 0075E338  setup_h0  141
 setup_H0.F
siesta 006077FF  siesta_forces 219
 siesta_forces.F
siesta 00BAF618  siesta 74  siesta.F
siesta 0041C9BD  Unknown   Unknown  Unknown
libc-2.31.so   14C32A3712BD  __libc_start_main Unknown  Unknown
siesta 0041C8EA  Unknown   Unknown  Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred

-- 
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] Question about educational opportunities

[ionut ghitiu]

Dear SIESTA users,
I was wondering if you are aware of any summer schools/workshops etc. that take 
place this year regarding DFT and related methods. 
Thanks in advance,Ioan-Mihai Ghitiu
-- 
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] Error in compiling Siesta master branch

[Fanmiao Kong]

Dear Siesta Users,

I am trying to compile Siesta master branch on my computer following the 
instructions here 
https://urldefense.com/v3/__https://gitlab.com/siesta-project/siesta/-/wikis/New-building-scheme__;!!D9dNQwwGXtA!S4aIbgjYzgs5Bh_TrUBevfr_ytrTeu0xcezoGl9KUqu-Mqww-JtoU--lcpCFd2PrG4H3v3sNUYD6fbB4RpQsICFpfVYd5w$
 . But I got this error:

make[1]: *** No rule to make target 'libmpi_f90.a', needed by 'siesta'.  Stop.

I think I have install mpi packages correctly in my computer, as I have 
compiled the 4.1 version before. I couldn't find the file 'libmpi_f90.a' in 
either /lib, /usr/lib, or /usr/local/lib. I have no idea how to solve this 
error. Can anyone help me out of this problem?

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


-- 
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] Need help with Phonon Dispersion Band Lines in Vibra

[Andrei Postnikov]

Dear Francisco, 
so your AFM structure is of CuAu type. This is fine but of course 
this is not the only AFM structure possible (and I don't know whether it is 
realistic at all, but this of course depends on your objectives). 
Now, if you want the q-path to be the same in your two settings, 
you should consider that the second one is rotated by 45 degrees. 
That is, if you choose the Gamma->X direction || [010] in the first setting 
it must be || [110] in the second setting, with the lattice vectors you use. 
Otherwise define the lattice vectors as [1/2 -1/2 0], [1/2 1/2 0], [0 0 1] 
with the same lattice parameter as in the first setting 
and enjoy the same coordinates of q points (cartesian, in terms of pi/a) 
in both settings. 

Best regards 

Andrei 

- Le 31 Déc 22, à 0:24, garcia ff 000  a écrit : 

> Dear Prof. Postnikov,

> Many thanks and appreciation for your response. I believe I found a solution 
> to
> my problem but I want to run it by you.

> First, an FCC cell with 2 unique atoms is equivalent to a tetragonal cell 
> (this
> is the smallest unit cell to model antiferromagnetism).

> Using the website [ 
> https://urldefense.com/v3/__https://www.materialscloud.org/work/tools/seekpath__;!!D9dNQwwGXtA!VCzh9W4S1t5nhfeK_65w_ZsZpJauei8vdCoYcoysbxbXQ6kbxNBuSTzR-LciHx145nkwK_JGfqplTyD_aZeQ8icIeWJtZ4jCPg$
>   |
> https://urldefense.com/v3/__https://www.materialscloud.org/work/tools/seekpath__;!!D9dNQwwGXtA!VCzh9W4S1t5nhfeK_65w_ZsZpJauei8vdCoYcoysbxbXQ6kbxNBuSTzR-LciHx145nkwK_JGfqplTyD_aZeQ8icIeWJtZ4jCPg$
>   ] , the high symmetry points
> in the Brillouin zone are as follows (each set of points is scaled by the
> corresponding pi/a):

> Standard FCC primitive cell: Gamma (0,0,0), X(0,2,0), K(1.5,1.5,0), W(1,2,0),
> L(1,1,1)

> 2-atom tetragonal cell: Gamma(0,0,0), X(0,1,0), M(1,1,0), R(0,1,0.707107),
> A(1,1,0.707107), Z(0,0,0.707107).

> With this information, I believe the two Vibra inputs below, one for the
> primitive FCC cell and the other for 2-atom tetragonal cell, are formally
> equivalent (the last two k-points in each case, i.e. L and M, is what I'm a 
> bit
> unsure about).

> Thank you very much for your kindness & happy holidays.

> (A) Primitive FCC cell:

> NumberOfAtoms 1

> #Lattice parameters
> LatticeConstant 3.47 Ang
> %block LatticeVectors
> 0.50 0.50 0.00
> 0.50 0.00 0.50
> 0.00 0.50 0.50
> %endblock LatticeVectors

> #Atomic positions
> AtomicCoordinatesFormat Fractional
> %block AtomicCoordinatesAndAtomicSpecies
> 0.00 0.00 0.00 1 54.938
> %endblock AtomicCoordinatesAndAtomicSpecies

> #High symmetry Brillouin zones points scaled by pi/a: Gamma (0,0,0), X(0,2,0),
> K(1.5,1.5,0), W(1,2,0), L(1,1,1)

> BandLinesScale pi/a
> %block BandLines
> 1 0.000 0.000 0.000 \Gamma
> 30 0.000 2.000 0.000 X
> 30 2.000 2.000 2.000 \Gamma
> 30 1.000 1.000 1.000 L
> %endblock BandLines

> (B) 2-atom tetragonal cell to model antiferromagnetism (this is double the
> volume of the FCC primitive cell)

> NumberOfAtoms 2

> #Lattice parameters
> LatticeConstant 2.453660531 Ang #[this is the FCC lattice constant divided by
> sqrt(2)]
> %block LatticeVectors
> 1.00 0.00 0.00
> 0.00 1.00 0.00
> 0.00 0.00 1.414213562
> %endblock LatticeVectors

> #Atomic positions
> AtomicCoordinatesFormat Fractional
> %block AtomicCoordinatesAndAtomicSpecies
> 0.00 0.00 0.00 1 54.938
> 0.50 0.50 0.50 1 54.938
> %endblock AtomicCoordinatesAndAtomicSpecies

> #High symmetry Brillouin zones points scaled by pi/a: Gamma(0,0,0), X(0,1,0),
> M(1,1,0), R(0,1,0.707107), A(1,1,0.707107), Z(0,0,0.707107)

> BandLinesScale pi/a
> %block BandLines
> 1 0.000 0.000 0.000 \Gamma
> 30 0.000 1.000 0.000 X
> 30 1.000 1.000 1.000 \Gamma
> 30 2.000 2.000 2.000 M
> %endblock BandLines

> On Thu, Dec 29, 2022 at 3:34 PM Andrei Postnikov < [
> mailto:andrei.postni...@univ-lorraine.fr | andrei.postni...@univ-lorraine.fr ]
> > wrote:

>> Dear Francisco,
>> it is difficult to give a useful advice on the basis of very limited 
>> information
>> you provide,
>> but my impression is that your problems are not obviously related with Vibra.
>> Some questions:
>> 1. What (magnetic) structure are you modelling? How comes you have four atoms
>> per AFM unit cell?
>> Can there be two?
>> 2. Is electronic structure (and band dispersions) correct, prior to any 
>> phonons?
>> 3. What means "incorrect phonon dispersion"? Do you have problems with
>> crystallography /
>> choosing the q-path, or is your calculation basically wrong?
>> 4. With 4 atoms as you use it so far, the Gamma phonon calculation would 
>> yield
>> 9 modes, which would map genuine zone-center and zone-boundary modes.
>> Do they come out reasonably?

>> To your problem:
>> "B asically I want to alter the band lines in input 2 so that they are
>> equivalent to the band lines in input 1" -
>> you have
>> BandLinesScale pi/a
>> in both inputs, the same lattice parameter, and the same 

Re: [SIESTA-L] Need help with Phonon Dispersion Band Lines in Vibra

[Francisco Garcia]

Dear Prof. Postnikov,

Many thanks and appreciation for your response. I believe I found a
solution to my problem but I want to run it by you.

First, an FCC cell with 2 unique atoms is equivalent to a tetragonal cell
(this is the smallest unit cell to model antiferromagnetism).

Using the website 
https://urldefense.com/v3/__https://www.materialscloud.org/work/tools/seekpath__;!!D9dNQwwGXtA!WbTOEoZkczNXgxFdjZz1Ho66DZKcaHdWandSB0IytM7jNKQONZgfMHtxCird0d0mH_PsbycR0mostpvReHj7Iw$
 , the
high symmetry points in the Brillouin zone are as follows (each set of
points is scaled by the corresponding pi/a):

Standard FCC primitive cell: Gamma (0,0,0), X(0,2,0), K(1.5,1.5,0),
W(1,2,0), L(1,1,1)

2-atom tetragonal cell: Gamma(0,0,0), X(0,1,0), M(1,1,0), R(0,1,0.707107),
A(1,1,0.707107), Z(0,0,0.707107).

With this information, I believe the two Vibra inputs below, one for the
primitive FCC cell and the other for 2-atom tetragonal cell, are formally
equivalent (the last two k-points in each case, i.e. L and M, is what I'm a
bit unsure about).


Thank you very much for your kindness & happy holidays.



(A) Primitive FCC cell:

NumberOfAtoms   1

#Lattice parameters
LatticeConstant   3.47 Ang
%block LatticeVectors
0.50 0.50 0.00
0.50 0.00 0.50
0.00 0.50 0.50
%endblock LatticeVectors

#Atomic positions
AtomicCoordinatesFormat  Fractional
%block AtomicCoordinatesAndAtomicSpecies
0.00 0.00 0.00  1  54.938
%endblock AtomicCoordinatesAndAtomicSpecies

#High symmetry Brillouin zones points scaled by pi/a: Gamma (0,0,0),
X(0,2,0), K(1.5,1.5,0), W(1,2,0), L(1,1,1)

BandLinesScale   pi/a
%block BandLines
 1  0.000  0.000  0.000   \Gamma
30 0.000  2.000  0.000   X
30  2.000  2.000  2.000  \Gamma
30  1.000  1.000  1.000   L
%endblock BandLines



(B) 2-atom tetragonal cell to model antiferromagnetism (this is double the
volume of the FCC primitive cell)

NumberOfAtoms   2

#Lattice parameters
LatticeConstant  2.453660531 Ang #[this is the FCC lattice constant divided
by sqrt(2)]
%block LatticeVectors
1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.414213562
%endblock LatticeVectors

#Atomic positions
AtomicCoordinatesFormat  Fractional
%block AtomicCoordinatesAndAtomicSpecies
0.00 0.00 0.00  1  54.938
0.50 0.50 0.50  1  54.938
%endblock AtomicCoordinatesAndAtomicSpecies

#High symmetry Brillouin zones points scaled by pi/a: Gamma(0,0,0),
X(0,1,0), M(1,1,0), R(0,1,0.707107), A(1,1,0.707107), Z(0,0,0.707107)

BandLinesScale   pi/a
%block BandLines
 1   0.000  0.000  0.000   \Gamma
30  0.000  1.000  0.000   X
30  1.000  1.000  1.000  \Gamma
30  2.000  2.000  2.000   M
%endblock BandLines



On Thu, Dec 29, 2022 at 3:34 PM Andrei Postnikov <
andrei.postni...@univ-lorraine.fr> wrote:

> Dear Francisco,
> it is difficult to give a useful advice on the basis of very limited
> information you provide,
> but my impression is that your problems are not obviously related with
> Vibra.
> Some questions:
> 1. What (magnetic) structure are you modelling? How comes you have four
> atoms per AFM unit cell?
> Can there be two?
> 2. Is electronic structure (and band dispersions) correct, prior to any
> phonons?
> 3. What means "incorrect phonon dispersion"? Do you have problems with
> crystallography /
> choosing the q-path, or is your calculation basically wrong?
> 4. With 4 atoms as you use it so far, the Gamma phonon calculation would
> yield
> 9 modes, which would map genuine zone-center and zone-boundary modes.
> Do they come out reasonably?
>
> To your problem:
> "Basically I want to alter the band lines in input 2 so that they are
> equivalent to the band lines in input 1" -
> you have
> BandLinesScale   pi/a
> in both inputs, the same lattice parameter, and the same definition of
> path.
> So if everything is correctly read, you must get the same Cartesian q-path
> in both cases.
> Either this is not so and there is something wrong with the input,
> or the paths are identical but your problem is elsewhere.
>
> Best regards
>
> Andrei
>
>
>
>
>
>
>
>
> - Le 29 Déc 22, à 0:40, garcia ff 000  a
> écrit :
>
> Dear Users,
>
> I have appended 2 Vibra inputs below for computing the phonon dispersion
> for FCC Mn.
>
> Input 1 works fine as it gives the expected band shapes for the dispersion
> (but the frequencies are off). The main issue with input 1 is that it is
> not suitable for antiferromagnetic calculations since there is only one Mn
> atom in the primitive cell.
>
> This led me to consider input 2, which has 4 atoms in the unit cell and
> can be used for antiferromagnetic calculations. The issue with input 2 is
> that the bandlines yield an incorrect phonon dispersion. This is what I
> need your help on. Basically I want to alter the band lines in input 2 so
> that they are equivalent to the band lines in input 1.
>
> Any assistance with this, especially from the Vibra authors, would be
> 

Re: [SIESTA-L] Need help with Phonon Dispersion Band Lines in Vibra

[Francisco Garcia]

Dear Prof. Postnikov,

Special thanks again for your kind and prompt response.

(i) The q-paths in input 2 must be rotated by 45 degrees to maintain
consistency with the paths in input 1. I would like to kindly know the axis
about which the rotation should be performed.

(ii) Regarding your suggestion of using the lattice vectors [1/2 -1/2 0],
[1/2 1/2 0], [0 0 1], I can't quite figure out why the q-paths will be the
same as the q-paths for input 1. The primitive FCC lattice vectors in input
1 are [1/2 1/2 0], [1/2 0 1/2], and [0 1/2 1/2] (with an angle of 60
degrees between each pair of lattice vectors). The angle between the
lattice vectors you proposed is 90 degrees for each pair. I'm having a
difficulty grasping how this new set of lattice vectors yields the same
q-paths as input 1. Any further explanation would be highly appreciated.

Thank you very much Professor.

On Fri, Dec 30, 2022 at 5:12 PM Andrei Postnikov <
andrei.postni...@univ-lorraine.fr> wrote:

> Dear Francisco,
> so your AFM structure is of CuAu type. This is fine but of course
> this is not the only AFM structure possible (and I don't know whether it is
> realistic at all, but this of course depends on your objectives).
> Now, if you want the q-path to be the same in your two settings,
> you should consider that the second one is rotated by 45 degrees.
> That is, if you choose the Gamma->X direction ||  [010] in the first
> setting
> it must be || [110] in the second setting, with the lattice vectors you
> use.
> Otherwise define the lattice vectors as [1/2 -1/2 0], [1/2 1/2 0], [0 0 1]
> with the same lattice parameter as in the first setting
> and enjoy the same coordinates of q points (cartesian, in terms of pi/a)
> in both settings.
>
> Best regards
>
> Andrei
>
>
> - Le 31 Déc 22, à 0:24, garcia ff 000  a
> écrit :
>
> Dear Prof. Postnikov,
>
> Many thanks and appreciation for your response. I believe I found a
> solution to my problem but I want to run it by you.
>
> First, an FCC cell with 2 unique atoms is equivalent to a tetragonal cell
> (this is the smallest unit cell to model antiferromagnetism).
>
> Using the website 
> https://urldefense.com/v3/__https://www.materialscloud.org/work/tools/seekpath__;!!D9dNQwwGXtA!RtHnhiKf-1Tr0ZJZ17JGCt-WslBldkrwcANZ1KZuejXMskHtY6-_llZSytEsPLSiAktiz7DhWg1EBpjE-NmrWg$
>  , the
> high symmetry points in the Brillouin zone are as follows (each set of
> points is scaled by the corresponding pi/a):
>
> Standard FCC primitive cell: Gamma (0,0,0), X(0,2,0), K(1.5,1.5,0),
> W(1,2,0), L(1,1,1)
>
> 2-atom tetragonal cell: Gamma(0,0,0), X(0,1,0), M(1,1,0), R(0,1,0.707107),
> A(1,1,0.707107), Z(0,0,0.707107).
>
> With this information, I believe the two Vibra inputs below, one for the
> primitive FCC cell and the other for 2-atom tetragonal cell, are formally
> equivalent (the last two k-points in each case, i.e. L and M, is what I'm a
> bit unsure about).
>
>
> Thank you very much for your kindness & happy holidays.
>
>
>
> (A) Primitive FCC cell:
>
> NumberOfAtoms   1
>
> #Lattice parameters
> LatticeConstant   3.47 Ang
> %block LatticeVectors
> 0.50 0.50 0.00
> 0.50 0.00 0.50
> 0.00 0.50 0.50
> %endblock LatticeVectors
>
> #Atomic positions
> AtomicCoordinatesFormat  Fractional
> %block AtomicCoordinatesAndAtomicSpecies
> 0.00 0.00 0.00  1  54.938
> %endblock AtomicCoordinatesAndAtomicSpecies
>
> #High symmetry Brillouin zones points scaled by pi/a: Gamma (0,0,0),
> X(0,2,0), K(1.5,1.5,0), W(1,2,0), L(1,1,1)
>
> BandLinesScale   pi/a
> %block BandLines
>  1  0.000  0.000  0.000   \Gamma
> 30 0.000  2.000  0.000   X
> 30  2.000  2.000  2.000  \Gamma
> 30  1.000  1.000  1.000   L
> %endblock BandLines
>
>
>
> (B) 2-atom tetragonal cell to model antiferromagnetism (this is double the
> volume of the FCC primitive cell)
>
> NumberOfAtoms   2
>
> #Lattice parameters
> LatticeConstant  2.453660531 Ang #[this is the FCC lattice constant
> divided by sqrt(2)]
> %block LatticeVectors
> 1.00 0.00 0.00
> 0.00 1.00 0.00
> 0.00 0.00 1.414213562
> %endblock LatticeVectors
>
> #Atomic positions
> AtomicCoordinatesFormat  Fractional
> %block AtomicCoordinatesAndAtomicSpecies
> 0.00 0.00 0.00  1  54.938
> 0.50 0.50 0.50  1  54.938
> %endblock AtomicCoordinatesAndAtomicSpecies
>
> #High symmetry Brillouin zones points scaled by pi/a: Gamma(0,0,0),
> X(0,1,0), M(1,1,0), R(0,1,0.707107), A(1,1,0.707107), Z(0,0,0.707107)
>
> BandLinesScale   pi/a
> %block BandLines
>  1   0.000  0.000  0.000   \Gamma
> 30  0.000  1.000  0.000   X
> 30  1.000  1.000  1.000  \Gamma
> 30  2.000  2.000  2.000   M
> %endblock BandLines
>
>
>
> On Thu, Dec 29, 2022 at 3:34 PM Andrei Postnikov <
> andrei.postni...@univ-lorraine.fr> wrote:
>
>> Dear Francisco,
>> it is difficult to give a useful advice on the basis of very limited
>> information you provide,
>> but my impression is that your