Re: [SIESTA-L] About SIESTA and wannier90 interface.

[Jigneshkumar Barot]

Dear Javier,

Thank you. I hope it will be implemented soon.

Regards,
Jigneshkumar

On Tue, 18 Jun, 2024, 1:30 am Junquera Quintana, Francisco Javier, <
javier.junqu...@unican.es> wrote:

>
>  Dear Jigneshkumar:
>
>  The interface between SIESTA and WANNIER90 for spinors has not been
> implemented yet.
>
>  Best regards,
>
>Javier
>
>
> [image: logoweb] [image: logocitimac]
> 
>
> *Javier Junquera*
> Catedrático de Universidad
> Departamento de Ciencias de la Tierra y Física de la Materia Condensada
> Facultad de Ciencias​
> Avda. de los Castros, s/n. 39005 Santander
> *UNIVERSIDAD DE CANTABRIA*
>
> [image: web]  [image: facebook]
> 
>  [image: twitter]
> 
>
> Tel. + 34 942 20 15 16
> Email: javier.junqu...@unican.es
>
> [image: imprimirresponsable] *Antes de imprimir este mensaje, asegúrate
> de que es necesario. Proteger el medio ambiente está en tus manos.*
>
> El 16 jun 2024, a las 14:22, Jigneshkumar Barot <
> barotjignesh2...@gmail.com> escribió:
>
> Hello everyone,
>
> Can anybody tell me how to run SIESTA with *.nnkp file generated with
> wannier90 keeping 'spinors=true' ? I want to run SIESTA and WANNIER90 with
> SOC.
> When spinors=false *.nnkp is generated with "begin projections" and siesta
> reads it fine. But when spinors=true *.nnkp is generated with "begin spinor
> projections" and siesta gives error, the projection block is missing.
> Please enlighten me.
>
> Regards.
>
>
> --
> 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!T0ETADvOmqNucwE6RmvKHcgNlbRiFXQr6RTW6RFynvOkvrgGbZWEB2zgSUidF021eDkcud3tLgHjwMm7KeLCq2tbQefKGY8bww$
> )
>
>
>
> --
> 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!R0jKyl_Yl7fKHuCSkRb-zYQwV-2IjTVzRUKuM3uyfaTAKhu7aJdsU_t6B8uCuvj_m_b-BaCaCb-FVt1iBYLYsWNfRw$
>  )
>

-- 
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 SIESTA and wannier90 interface.

[Junquera Quintana, Francisco Javier]

 Dear Jigneshkumar:

 The interface between SIESTA and WANNIER90 for spinors has not been 
implemented yet.

 Best regards,

   Javier


[logoweb]  [logocitimac]  

Javier Junquera
Catedrático de Universidad
Departamento de Ciencias de la Tierra y Física de la Materia Condensada
Facultad de Ciencias​
Avda. de los Castros, s/n. 39005 Santander
UNIVERSIDAD DE CANTABRIA
[web] [facebook] 
  [twitter]  

Tel. + 34 942 20 15 16
Email: javier.junqu...@unican.es
[imprimirresponsable] Antes de imprimir este mensaje, asegúrate de que es 
necesario. Proteger el medio ambiente está en tus manos.

El 16 jun 2024, a las 14:22, Jigneshkumar Barot  
escribió:

Hello everyone,

Can anybody tell me how to run SIESTA with *.nnkp file generated with wannier90 
keeping 'spinors=true' ? I want to run SIESTA and WANNIER90 with SOC.
When spinors=false *.nnkp is generated with "begin projections" and siesta 
reads it fine. But when spinors=true *.nnkp is generated with "begin spinor 
projections" and siesta gives error, the projection block is missing. Please 
enlighten me.

Regards.


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


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

Re: [SIESTA-L] << Siesta 5.0 + LibXC >>

[Nick Papior]

Hi,

Could you share more information, like the full output of the cmake
invocation, it is hard (if not impossible) to work out what went wrong in
this case.

Den ons. 29. maj 2024 kl. 22.00 skrev I. Camps :

> Hello,
>
> I downloaded SIESTA version 5.0 from Gitlab (
> https://urldefense.com/v3/__https://gitlab.com/siesta-project/siesta/-/releases/5.0.0__;!!D9dNQwwGXtA!X3CjzQFENOHlj3YjbHy0VwALfhDvC5YJta_5wauxQY8eniNvx6e9zmiLRFolXQn2XQOc3IxEWUtK_5yUEQ$
>  )
> 
> and latest LibXC library version 6.2.2 
> (https://urldefense.com/v3/__https://libxc.gitlab.io/download/__;!!D9dNQwwGXtA!X3CjzQFENOHlj3YjbHy0VwALfhDvC5YJta_5wauxQY8eniNvx6e9zmiLRFolXQn2XQOc3IxEWUv4b-NehA$
>  
> 
> ).
>
> After compiling LibXC, I installed it at */software/libxc*.
> Then I used the following to compile SIESTA:
>
> *cmake -S. -B_build -DSIESTA_TOOLCHAIN=gnu
> -DCMAKE_INSTALL_PREFIX=/software/siesta -DSIESTA_WITH_LIBXC=ON
> -DSIESTA_WITH_NETCDF_PARALLEL=ON -DSIESTA_EXECUTABLE_SUFFIX=.x
> -DSIESTA_WITH_OPENMP=ON -DSIESTA_WITH_NCDF=ON
> -DCMAKE_PREFIX_PATH=/software/libxc -DOpenMP_Fortran_FLAGS=-fopenmp
>  -DSIESTA_TESTS_MPI_MAX_NUMPROCS=19 -DSIESTA_WITH_LIBXC=ON
> -DCMAKE_PREFIX_PATH=/software/libxc*
>
> Which return the compilation error:
> *CMake Error at CMakeLists.txt:347 (message):*
> *  Libxc could not be found by CMake*
>
> Without the information about LibXC, SIESTA compiles without any issue.
>
> PS: I also tried to point *CMAKE_PREFIX_PATH *to LibXC source folder,
> unsuccessfully.
>
> Any help is welcome!
>
>
> []'s,
> Camps
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!X3CjzQFENOHlj3YjbHy0VwALfhDvC5YJta_5wauxQY8eniNvx6e9zmiLRFolXQn2XQOc3IxEWUvGq8nSQQ$
>  )
>


-- 
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] Issues with building and compiling new siesta

[Boubacar Traore]

Thanks Alberto;  the "Deferred-length character" error vanishes with a
modern gcc.

On Fri, 7 Jun 2024 at 22:00, Alberto Garcia  wrote:

> You compiler (gnu 4.8.5) is *very* old. Please upgrade to a modern version.
>
> Best regards,
>
> Alberto
>
>
> - El 6 de Junio de 2024, a las 19:09, Boubacar Traore <
> bt.bouba...@gmail.com> escribió:
>
> I finally sorted out the issue of scalapack linking by adding its path to
> LIBRARY_PATH instead of LD_LIBRARY_PATH (more info here:
> https://urldefense.com/v3/__https://stackoverflow.com/questions/47105835/ld-library-path-is-ignored-by-gcc__;!!D9dNQwwGXtA!V3AkKMLCSGZOKkh_zfS8r1kcYcyK6WFVYg9o6fg3LQbmBE9vrhj8bkJqVK30r8O-MI2SQbO6_pxVcf_zSf4$
>  
> 
> ).
>
> I used this for cmake build stage:
> $ cmake -S. -B_build
> -DCMAKE_INSTALL_PREFIX=/home/boubacart/SIESTA/siesta/bin
> -DSIESTA_WITH_MPI=ON -DSIESTA_WITH_ELPA=ON
> -DSCALAPACK_LIBRARY_DIR=/usr/lib64/openmpi/lib
> -DSCALAPACK_LIBRARY="-lscalapack"
>
> The config steps then succeeds.
>
> However, I encounter other issues during the compilation stage and I am
> not sure what is the problem and from the start it issues errors regarding
> some deferred-length character :
> ===
> [  0%] Building Fortran object
> _deps/libfdf-build/CMakeFiles/libfdf-lib.dir/src/prec.F90.o
> [  0%] Building Fortran object
> _deps/mctc-lib-build/CMakeFiles/mctc-lib-lib.dir/src/mctc/env/accuracy.f90.o
> [  0%] Building Fortran object
> _deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/wxml/m_wxml_array_str.f90.o
> [  0%] Building Fortran object
> _deps/libfdf-build/CMakeFiles/libfdf-lib.dir/src/utils.F90.o
> [  0%] Building Fortran object
> _deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/alloc.F90.o
> [  0%] Building Fortran object
> _deps/mctc-lib-build/CMakeFiles/mctc-lib-lib.dir/src/mctc/env/error.f90.o
>
> /home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/mctc-lib-src/src/mctc/env/error.f90:46.46:
>
>   character(len=:), allocatable :: message
>   1
> Error: Deferred-length character component 'message' at (1) is not yet
> supported
>
> /home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/mctc-lib-src/src/mctc/env/error.f90:46.46:
>
>   character(len=:), allocatable :: message
>   1
> Error: Deferred-length character component 'message' at (1) is not yet
> supported
> gmake[2]: ***
> [_deps/mctc-lib-build/CMakeFiles/mctc-lib-lib.dir/src/mctc/env/error.f90.o]
> Error 1
> gmake[1]: *** [_deps/mctc-lib-build/CMakeFiles/mctc-lib-lib.dir/all] Error
> 2
> gmake[1]: *** Waiting for unfinished jobs
> [  0%] Building Fortran object
> _deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/precision.F90.o
> [  0%] Building Fortran object
> _deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/wxml/m_wxml_error.f90.o
> [  0%] Building Fortran object
> _deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/sys.F90.o
> [  0%] Building Fortran object
> _deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/wxml/m_wxml_escape.f90.o
>
> ..
> ..
> ..
> [  2%] Building Fortran object
> _deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/dom/m_dom_parse.f90.o
> [  2%] Building Fortran object
> _deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/debugxc.F90.o
> [  3%] Building Fortran object
> _deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/xpath/xmlf90_xpath.f90.o
> [  3%] Building Fortran object
> _deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/vv_vdwxc.F90.o
> [  3%] Building Fortran object
> _deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/dom/xmlf90_dom.f90.o
> [  3%] Linking Fortran static library libxmlf90.a
> [  3%] Built target xmlf90-lib
> [  3%] Building Fortran object
> _deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/fft3d.F90.o
>
> /home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:234.25:
>
>   call c_f_pointer(c_loc(aDat(:,:,:,1)),aux1,[aMesh(1)*aMesh(2)*aMesh(3)])
>  1
> Warning: Array section in 'c_loc' call at (1)
>
> /home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:235.25:
>
>   call c_f_pointer(c_loc(aDat(:,:,:,2)),aux2,[aMesh(1)*aMesh(2)*aMesh(3)])
>  1
> Warning: Array section in 'c_loc' call at (1)
>
> /home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:249.28:
>
>  call c_f_pointer(c_loc(aDat(:,:,i3,1)),aux1,[aMesh(1)*aMesh(2)])
> 1
> Warning: Array section in 'c_loc' call at (1)
>
> /home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:250.28:
>
>  call c_f_pointer(c_loc(aDat(:,:,i3,2)),aux2,[aMesh(1)*aMesh(2)])
> 1
> Warning: Array section in 'c_loc' call at (1)
>
> 

Re: [SIESTA-L] Issues with building and compiling new siesta

[Alberto Garcia]

You compiler (gnu 4.8.5) is *very* old. Please upgrade to a modern version. 

Best regards, 

Alberto 

- El 6 de Junio de 2024, a las 19:09, Boubacar Traore 
 escribió: 

| I finally sorted out the issue of scalapack linking by adding its path to
| LIBRARY_PATH instead of LD_LIBRARY_PATH (more info here: [
| 
https://urldefense.com/v3/__https://stackoverflow.com/questions/47105835/ld-library-path-is-ignored-by-gcc__;!!D9dNQwwGXtA!UKXFsN93oU7fdjctS5itiA2CMH4YTUW-VUxSJl8f5ejE_wN2ffrRXxBautffKqwBfEnjMj-Kg2AAYGfMdi0$
| |
| 
https://urldefense.com/v3/__https://stackoverflow.com/questions/47105835/ld-library-path-is-ignored-by-gcc__;!!D9dNQwwGXtA!WikrDz3RbFwqReRTUxLQfCcPc8VFr9BlO-JUJkIQug1Z9u1DQHc_ER-m8pNnzqj6DLgZxZVP-L5VhTVb$
 
| ] ).

| I used this for cmake build stage:
| $ cmake -S. -B_build -DCMAKE_INSTALL_PREFIX=/home/boubacart/SIESTA/siesta/bin
| -DSIESTA_WITH_MPI=ON -DSIESTA_WITH_ELPA=ON
| -DSCALAPACK_LIBRARY_DIR=/usr/lib64/openmpi/lib
| -DSCALAPACK_LIBRARY="-lscalapack"

| The config steps then succeeds.

| However, I encounter other issues during the compilation stage and I am not 
sure
| what is the problem and from the start it issues errors regarding some
| deferred-length character :
| ===
| [ 0%] Building Fortran object
| _deps/libfdf-build/CMakeFiles/libfdf-lib.dir/src/prec.F90.o
| [ 0%] Building Fortran object
| _deps/mctc-lib-build/CMakeFiles/mctc-lib-lib.dir/src/mctc/env/accuracy.f90.o
| [ 0%] Building Fortran object
| _deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/wxml/m_wxml_array_str.f90.o
| [ 0%] Building Fortran object
| _deps/libfdf-build/CMakeFiles/libfdf-lib.dir/src/utils.F90.o
| [ 0%] Building Fortran object
| _deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/alloc.F90.o
| [ 0%] Building Fortran object
| _deps/mctc-lib-build/CMakeFiles/mctc-lib-lib.dir/src/mctc/env/error.f90.o
| 
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/mctc-lib-src/src/mctc/env/error.f90:46.46:

| character(len=:), allocatable :: message
| 1
| Error: Deferred-length character component 'message' at (1) is not yet 
supported
| 
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/mctc-lib-src/src/mctc/env/error.f90:46.46:

| character(len=:), allocatable :: message
| 1
| Error: Deferred-length character component 'message' at (1) is not yet 
supported
| gmake[2]: ***
| [_deps/mctc-lib-build/CMakeFiles/mctc-lib-lib.dir/src/mctc/env/error.f90.o]
| Error 1
| gmake[1]: *** [_deps/mctc-lib-build/CMakeFiles/mctc-lib-lib.dir/all] Error 2
| gmake[1]: *** Waiting for unfinished jobs
| [ 0%] Building Fortran object
| _deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/precision.F90.o
| [ 0%] Building Fortran object
| _deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/wxml/m_wxml_error.f90.o
| [ 0%] Building Fortran object
| _deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/sys.F90.o
| [ 0%] Building Fortran object
| _deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/wxml/m_wxml_escape.f90.o

| ..
| ..
| ..
| [ 2%] Building Fortran object
| _deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/dom/m_dom_parse.f90.o
| [ 2%] Building Fortran object
| _deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/debugxc.F90.o
| [ 3%] Building Fortran object
| _deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/xpath/xmlf90_xpath.f90.o
| [ 3%] Building Fortran object
| _deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/vv_vdwxc.F90.o
| [ 3%] Building Fortran object
| _deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/dom/xmlf90_dom.f90.o
| [ 3%] Linking Fortran static library libxmlf90.a
| [ 3%] Built target xmlf90-lib
| [ 3%] Building Fortran object
| _deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/fft3d.F90.o
| 
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:234.25:

| call c_f_pointer(c_loc(aDat(:,:,:,1)),aux1,[aMesh(1)*aMesh(2)*aMesh(3)])
| 1
| Warning: Array section in 'c_loc' call at (1)
| 
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:235.25:

| call c_f_pointer(c_loc(aDat(:,:,:,2)),aux2,[aMesh(1)*aMesh(2)*aMesh(3)])
| 1
| Warning: Array section in 'c_loc' call at (1)
| 
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:249.28:

| call c_f_pointer(c_loc(aDat(:,:,i3,1)),aux1,[aMesh(1)*aMesh(2)])
| 1
| Warning: Array section in 'c_loc' call at (1)
| 
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:250.28:

| call c_f_pointer(c_loc(aDat(:,:,i3,2)),aux2,[aMesh(1)*aMesh(2)])
| 1
| Warning: Array section in 'c_loc' call at (1)
| 
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:263.25:

| call c_f_pointer(c_loc(aDat(:,:,:,1)),aux1,[aMesh(1)*aMesh(2)*aMesh(3)])
| 1
| Warning: Array section in 'c_loc' call at (1)
| 
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:264.25:

| call c_f_pointer(c_loc(aDat(:,:,:,2)),aux2,[aMesh(1)*aMesh(2)*aMesh(3)])
| 1
| Warning: Array section in 'c_loc' call at (1)
| [ 3%] Building Fortran object
| 

Re: [SIESTA-L] Issues with building and compiling new siesta

[Boubacar Traore]

Hi Camps,
Thanks for the reply.

I have already gone through that link but those known issues do not seem to
be related to the compilation errors that I encounter.
In particular, there is "Error: Deferred-length character component
'message' at (1) is not yet supported " error message.
I am not sure what could be the origin of this error...

Thanks

On Thu, 6 Jun 2024 at 22:00, I. Camps  wrote:

> Hi Boubacar,
>
> Take a look at this link, it may help:
> https://urldefense.com/v3/__https://docs.siesta-project.org/projects/siesta/en/stable/installation/build-issues.html__;!!D9dNQwwGXtA!U5L33f-z6CqoaqT9KtG7JesqsRR_k4Z_np6habI59Zlw7Vf-hcbdOSctAnM9rF2usShS3BuyptEtRdZuzrE$
>  
> 
> .
>
>
> []'s,
> Camps
>
>
> On Wed, Jun 5, 2024 at 5:00 PM Boubacar Traore 
> wrote:
>
>> Hi,
>>
>> I am trying to compile siesta with cmake but I encounter issues with
>> scalapack linking. I notice that the compilation process has changed
>> compared to what I was used to.
>>
>> Here is my cmake build command:
>>
>> $ cmake -S. -B_build
>> -DCMAKE_INSTALL_PREFIX=/home/boubacart/SIESTA/siesta/bin
>> -DSIESTA_WITH_MPI=ON -DSIESTA_WITH_ELPA=ON -DSIESTA_WITH_LIBXC=ON
>> -DSCALAPACK_LIBRARY="-lscalapack-openmpi-devel"
>>
>> It fails at with a linking error as shown below:
>> ===
>> -- The Fortran compiler identification is GNU 4.8.5
>> -- The C compiler identification is GNU 4.8.5
>> -- Detecting Fortran compiler ABI info
>> -- Detecting Fortran compiler ABI info - done
>> -- Check for working Fortran compiler: /bin/f95 - skipped
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Check for working C compiler: /bin/cc - skipped
>> -- Detecting C compile features
>> -- Detecting C compile features - done
>> -- Check use of deprecated variables
>> --   All Siesta variables/options are prefixed with SIESTA_, e.g.
>> SIESTA_WITH_MPI
>> -- Check use of deprecated variables - success
>> -- Using GNU compiler
>> -- Using toolchain: Config/cmake/toolchains/gnu.cmake
>> --
>> No build type selected. SIESTA will default to 'Release'.
>> To override pass -DCMAKE_BUILD_TYPE= in order to configure SIESTA.
>> Available options are:
>>   * -DCMAKE_BUILD_TYPE=Release - For an optimized build with no
>> assertions or debug info.
>>   * -DCMAKE_BUILD_TYPE=Debug - For an unoptimized build with assertions
>> and debug info.
>>   * -DCMAKE_BUILD_TYPE=Check - For an unoptimized build with assertions
>> and debug info + code checks.
>>   * -DCMAKE_BUILD_TYPE=RelWithDebInfo - For an optimized build with no
>> assertions but with debug info.
>>   * -DCMAKE_BUILD_TYPE=MinSizeRel - For a build optimized for size
>> instead of speed.
>>
>> -- Flags for C-compiler (build type: Release):  -O3 -march=native
>> -- Flags for Fortran-compiler (build type: Release):  -O3 -march=native
>> -- Found PkgConfig: /bin/pkg-config (found version "0.27.1")
>> -- Checking Siesta version
>> --   SIESTA_VERSION: 5.1-MaX-28-gf3224d62e (err=3)
>> --
>>   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://urldefense.com/v3/__https://gitlab.com/siesta-project/siesta/-/releases__;!!D9dNQwwGXtA!U5L33f-z6CqoaqT9KtG7JesqsRR_k4Z_np6habI59Zlw7Vf-hcbdOSctAnM9rF2usShS3BuyptEt127aG_4$
>>  
>> 
>>
>>
>> -- Checking Siesta version - found development version
>> -- Parsing BLAS options
>> --   Locating BLAS library
>> --   Looking for Fortran sgemm
>> --   Looking for Fortran sgemm - not found
>> --   Performing Test CMAKE_HAVE_LIBC_PTHREAD
>> --   Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
>> --   Looking for pthread_create in pthreads
>> --   Looking for pthread_create in pthreads - not found
>> --   Looking for pthread_create in pthread
>> --   Looking for pthread_create in pthread - found
>> --   Found Threads: TRUE
>> --   Looking for Fortran sgemm
>> --   Looking for Fortran sgemm - found
>> --   Found BLAS: /usr/lib64/libblas.so
>> --   Found CustomBlas: /usr/lib64/libblas.so
>> --   Locating BLAS library - found
>> --   BLAS library: /usr/lib64/libblas.so
>> --   BLAS link flags:
>> -- Parsing LAPACK options
>> --   Locating LAPACK library
>> --   Looking for Fortran cheev
>> --   Looking for Fortran cheev - not found
>> --   Looking for Fortran cheev
>> --   Looking for Fortran cheev - found
>> --   Found LAPACK: /usr/lib64/liblapack.so;/usr/lib64/libblas.so
>> --   Found CustomLapack: 

Re: [SIESTA-L] Issues with building and compiling new siesta

[I. Camps]

Hi Boubacar,

Take a look at this link, it may help:
https://urldefense.com/v3/__https://docs.siesta-project.org/projects/siesta/en/stable/installation/build-issues.html__;!!D9dNQwwGXtA!W7_FwTUE6tqp6WrQ8D3wsJLjE9muIaDjVOCP95FNi--GCwPavq6Ac4fosYmMJSd8pCIVgsxT9gQk$
 
.


[]'s,
Camps


On Wed, Jun 5, 2024 at 5:00 PM Boubacar Traore 
wrote:

> Hi,
>
> I am trying to compile siesta with cmake but I encounter issues with
> scalapack linking. I notice that the compilation process has changed
> compared to what I was used to.
>
> Here is my cmake build command:
>
> $ cmake -S. -B_build
> -DCMAKE_INSTALL_PREFIX=/home/boubacart/SIESTA/siesta/bin
> -DSIESTA_WITH_MPI=ON -DSIESTA_WITH_ELPA=ON -DSIESTA_WITH_LIBXC=ON
> -DSCALAPACK_LIBRARY="-lscalapack-openmpi-devel"
>
> It fails at with a linking error as shown below:
> ===
> -- The Fortran compiler identification is GNU 4.8.5
> -- The C compiler identification is GNU 4.8.5
> -- Detecting Fortran compiler ABI info
> -- Detecting Fortran compiler ABI info - done
> -- Check for working Fortran compiler: /bin/f95 - skipped
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check use of deprecated variables
> --   All Siesta variables/options are prefixed with SIESTA_, e.g.
> SIESTA_WITH_MPI
> -- Check use of deprecated variables - success
> -- Using GNU compiler
> -- Using toolchain: Config/cmake/toolchains/gnu.cmake
> --
> No build type selected. SIESTA will default to 'Release'.
> To override pass -DCMAKE_BUILD_TYPE= in order to configure SIESTA.
> Available options are:
>   * -DCMAKE_BUILD_TYPE=Release - For an optimized build with no assertions
> or debug info.
>   * -DCMAKE_BUILD_TYPE=Debug - For an unoptimized build with assertions
> and debug info.
>   * -DCMAKE_BUILD_TYPE=Check - For an unoptimized build with assertions
> and debug info + code checks.
>   * -DCMAKE_BUILD_TYPE=RelWithDebInfo - For an optimized build with no
> assertions but with debug info.
>   * -DCMAKE_BUILD_TYPE=MinSizeRel - For a build optimized for size instead
> of speed.
>
> -- Flags for C-compiler (build type: Release):  -O3 -march=native
> -- Flags for Fortran-compiler (build type: Release):  -O3 -march=native
> -- Found PkgConfig: /bin/pkg-config (found version "0.27.1")
> -- Checking Siesta version
> --   SIESTA_VERSION: 5.1-MaX-28-gf3224d62e (err=3)
> --
>   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://urldefense.com/v3/__https://gitlab.com/siesta-project/siesta/-/releases__;!!D9dNQwwGXtA!W7_FwTUE6tqp6WrQ8D3wsJLjE9muIaDjVOCP95FNi--GCwPavq6Ac4fosYmMJSd8pCIVgkvC_xmO$
>  
> 
>
>
> -- Checking Siesta version - found development version
> -- Parsing BLAS options
> --   Locating BLAS library
> --   Looking for Fortran sgemm
> --   Looking for Fortran sgemm - not found
> --   Performing Test CMAKE_HAVE_LIBC_PTHREAD
> --   Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
> --   Looking for pthread_create in pthreads
> --   Looking for pthread_create in pthreads - not found
> --   Looking for pthread_create in pthread
> --   Looking for pthread_create in pthread - found
> --   Found Threads: TRUE
> --   Looking for Fortran sgemm
> --   Looking for Fortran sgemm - found
> --   Found BLAS: /usr/lib64/libblas.so
> --   Found CustomBlas: /usr/lib64/libblas.so
> --   Locating BLAS library - found
> --   BLAS library: /usr/lib64/libblas.so
> --   BLAS link flags:
> -- Parsing LAPACK options
> --   Locating LAPACK library
> --   Looking for Fortran cheev
> --   Looking for Fortran cheev - not found
> --   Looking for Fortran cheev
> --   Looking for Fortran cheev - found
> --   Found LAPACK: /usr/lib64/liblapack.so;/usr/lib64/libblas.so
> --   Found CustomLapack: /usr/lib64/liblapack.so;/usr/lib64/libblas.so
> --   Locating LAPACK library - found
> --   LAPACK library: /usr/lib64/liblapack.so;/usr/lib64/libblas.so
> --   LAPACK link flags:
> -- Found MPI_C: /usr/lib64/openmpi/lib/libmpi.so (found version "3.0")
> -- Found MPI_Fortran: /usr/lib64/openmpi/lib/libmpi_usempi.so (found
> version "3.0")
> -- Found MPI: TRUE (found version "3.0") found components: Fortran C
> -- Parsing ScaLAPACK options
> --   Locating ScaLAPACK library
> --   Using user-defined variables
> --   Found CustomScalapack: -lscalapack-openmpi-devel
> --   Locating ScaLAPACK library - found
> --   ScaLAPACK library: -lscalapack-openmpi-devel
> --   ScaLAPACK link flags:
> -- Checking that BLAS library works...
> --   

Re: [SIESTA-L] Issues with building and compiling new siesta

[Boubacar Traore]

More specifically it stops at scalapack stage when :
"--   Performing Test scalapack_has_blacs_gridinit - Failed"

The config routine finds scalapack but it fails in
"SiestaCheckLinalg.cmake" routine.
All the dependencies were installed according to the doc. So, I am not sure
if I still missed something or if it is a bug ?

Thanks,
Boubacar

On Wed, 5 Jun 2024 at 21:54, Boubacar Traore  wrote:

> Hi,
>
> I am trying to compile siesta with cmake but I encounter issues with
> scalapack linking. I notice that the compilation process has changed
> compared to what I was used to.
>
> Here is my cmake build command:
>
> $ cmake -S. -B_build
> -DCMAKE_INSTALL_PREFIX=/home/boubacart/SIESTA/siesta/bin
> -DSIESTA_WITH_MPI=ON -DSIESTA_WITH_ELPA=ON -DSIESTA_WITH_LIBXC=ON
> -DSCALAPACK_LIBRARY="-lscalapack-openmpi-devel"
>
> It fails at with a linking error as shown below:
> ===
> -- The Fortran compiler identification is GNU 4.8.5
> -- The C compiler identification is GNU 4.8.5
> -- Detecting Fortran compiler ABI info
> -- Detecting Fortran compiler ABI info - done
> -- Check for working Fortran compiler: /bin/f95 - skipped
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check use of deprecated variables
> --   All Siesta variables/options are prefixed with SIESTA_, e.g.
> SIESTA_WITH_MPI
> -- Check use of deprecated variables - success
> -- Using GNU compiler
> -- Using toolchain: Config/cmake/toolchains/gnu.cmake
> --
> No build type selected. SIESTA will default to 'Release'.
> To override pass -DCMAKE_BUILD_TYPE= in order to configure SIESTA.
> Available options are:
>   * -DCMAKE_BUILD_TYPE=Release - For an optimized build with no assertions
> or debug info.
>   * -DCMAKE_BUILD_TYPE=Debug - For an unoptimized build with assertions
> and debug info.
>   * -DCMAKE_BUILD_TYPE=Check - For an unoptimized build with assertions
> and debug info + code checks.
>   * -DCMAKE_BUILD_TYPE=RelWithDebInfo - For an optimized build with no
> assertions but with debug info.
>   * -DCMAKE_BUILD_TYPE=MinSizeRel - For a build optimized for size instead
> of speed.
>
> -- Flags for C-compiler (build type: Release):  -O3 -march=native
> -- Flags for Fortran-compiler (build type: Release):  -O3 -march=native
> -- Found PkgConfig: /bin/pkg-config (found version "0.27.1")
> -- Checking Siesta version
> --   SIESTA_VERSION: 5.1-MaX-28-gf3224d62e (err=3)
> --
>   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://urldefense.com/v3/__https://gitlab.com/siesta-project/siesta/-/releases__;!!D9dNQwwGXtA!UYGP2tP5MBKEuEDYVd_AAXzvz0C3xJG_Brop7boUp6SK-HsSIaTpqmCq0R944FkAiIbjxG7ZlENeBCPQnN4$
>  
>
>
> -- Checking Siesta version - found development version
> -- Parsing BLAS options
> --   Locating BLAS library
> --   Looking for Fortran sgemm
> --   Looking for Fortran sgemm - not found
> --   Performing Test CMAKE_HAVE_LIBC_PTHREAD
> --   Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
> --   Looking for pthread_create in pthreads
> --   Looking for pthread_create in pthreads - not found
> --   Looking for pthread_create in pthread
> --   Looking for pthread_create in pthread - found
> --   Found Threads: TRUE
> --   Looking for Fortran sgemm
> --   Looking for Fortran sgemm - found
> --   Found BLAS: /usr/lib64/libblas.so
> --   Found CustomBlas: /usr/lib64/libblas.so
> --   Locating BLAS library - found
> --   BLAS library: /usr/lib64/libblas.so
> --   BLAS link flags:
> -- Parsing LAPACK options
> --   Locating LAPACK library
> --   Looking for Fortran cheev
> --   Looking for Fortran cheev - not found
> --   Looking for Fortran cheev
> --   Looking for Fortran cheev - found
> --   Found LAPACK: /usr/lib64/liblapack.so;/usr/lib64/libblas.so
> --   Found CustomLapack: /usr/lib64/liblapack.so;/usr/lib64/libblas.so
> --   Locating LAPACK library - found
> --   LAPACK library: /usr/lib64/liblapack.so;/usr/lib64/libblas.so
> --   LAPACK link flags:
> -- Found MPI_C: /usr/lib64/openmpi/lib/libmpi.so (found version "3.0")
> -- Found MPI_Fortran: /usr/lib64/openmpi/lib/libmpi_usempi.so (found
> version "3.0")
> -- Found MPI: TRUE (found version "3.0") found components: Fortran C
> -- Parsing ScaLAPACK options
> --   Locating ScaLAPACK library
> --   Using user-defined variables
> --   Found CustomScalapack: -lscalapack-openmpi-devel
> --   Locating ScaLAPACK library - found
> --   ScaLAPACK library: -lscalapack-openmpi-devel
> --   ScaLAPACK link flags:
> -- Checking that BLAS library works...
> --   Performing Test blas_has_sgemm
> --   Performing Test blas_has_sgemm - Success
> --   Performing Test 

Re: [SIESTA-L] Issues with building and compiling new siesta

[Boubacar Traore]

I finally sorted out the issue of scalapack linking by adding its path to
LIBRARY_PATH instead of LD_LIBRARY_PATH (more info here:
https://urldefense.com/v3/__https://stackoverflow.com/questions/47105835/ld-library-path-is-ignored-by-gcc__;!!D9dNQwwGXtA!UKXFsN93oU7fdjctS5itiA2CMH4YTUW-VUxSJl8f5ejE_wN2ffrRXxBautffKqwBfEnjMj-Kg2AAYGfMdi0$
 
).

I used this for cmake build stage:
$ cmake -S. -B_build
-DCMAKE_INSTALL_PREFIX=/home/boubacart/SIESTA/siesta/bin
-DSIESTA_WITH_MPI=ON -DSIESTA_WITH_ELPA=ON
-DSCALAPACK_LIBRARY_DIR=/usr/lib64/openmpi/lib
-DSCALAPACK_LIBRARY="-lscalapack"

The config steps then succeeds.

However, I encounter other issues during the compilation stage and I am not
sure what is the problem and from the start it issues errors regarding some
deferred-length character :
===
[  0%] Building Fortran object
_deps/libfdf-build/CMakeFiles/libfdf-lib.dir/src/prec.F90.o
[  0%] Building Fortran object
_deps/mctc-lib-build/CMakeFiles/mctc-lib-lib.dir/src/mctc/env/accuracy.f90.o
[  0%] Building Fortran object
_deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/wxml/m_wxml_array_str.f90.o
[  0%] Building Fortran object
_deps/libfdf-build/CMakeFiles/libfdf-lib.dir/src/utils.F90.o
[  0%] Building Fortran object
_deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/alloc.F90.o
[  0%] Building Fortran object
_deps/mctc-lib-build/CMakeFiles/mctc-lib-lib.dir/src/mctc/env/error.f90.o
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/mctc-lib-src/src/mctc/env/error.f90:46.46:

  character(len=:), allocatable :: message
  1
Error: Deferred-length character component 'message' at (1) is not yet
supported
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/mctc-lib-src/src/mctc/env/error.f90:46.46:

  character(len=:), allocatable :: message
  1
Error: Deferred-length character component 'message' at (1) is not yet
supported
gmake[2]: ***
[_deps/mctc-lib-build/CMakeFiles/mctc-lib-lib.dir/src/mctc/env/error.f90.o]
Error 1
gmake[1]: *** [_deps/mctc-lib-build/CMakeFiles/mctc-lib-lib.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs
[  0%] Building Fortran object
_deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/precision.F90.o
[  0%] Building Fortran object
_deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/wxml/m_wxml_error.f90.o
[  0%] Building Fortran object
_deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/sys.F90.o
[  0%] Building Fortran object
_deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/wxml/m_wxml_escape.f90.o

..
..
..
[  2%] Building Fortran object
_deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/dom/m_dom_parse.f90.o
[  2%] Building Fortran object
_deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/debugxc.F90.o
[  3%] Building Fortran object
_deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/xpath/xmlf90_xpath.f90.o
[  3%] Building Fortran object
_deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/vv_vdwxc.F90.o
[  3%] Building Fortran object
_deps/xmlf90-build/CMakeFiles/xmlf90-lib.dir/src/dom/xmlf90_dom.f90.o
[  3%] Linking Fortran static library libxmlf90.a
[  3%] Built target xmlf90-lib
[  3%] Building Fortran object
_deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/fft3d.F90.o
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:234.25:

  call c_f_pointer(c_loc(aDat(:,:,:,1)),aux1,[aMesh(1)*aMesh(2)*aMesh(3)])
 1
Warning: Array section in 'c_loc' call at (1)
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:235.25:

  call c_f_pointer(c_loc(aDat(:,:,:,2)),aux2,[aMesh(1)*aMesh(2)*aMesh(3)])
 1
Warning: Array section in 'c_loc' call at (1)
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:249.28:

 call c_f_pointer(c_loc(aDat(:,:,i3,1)),aux1,[aMesh(1)*aMesh(2)])
1
Warning: Array section in 'c_loc' call at (1)
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:250.28:

 call c_f_pointer(c_loc(aDat(:,:,i3,2)),aux2,[aMesh(1)*aMesh(2)])
1
Warning: Array section in 'c_loc' call at (1)
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:263.25:

  call c_f_pointer(c_loc(aDat(:,:,:,1)),aux1,[aMesh(1)*aMesh(2)*aMesh(3)])
 1
Warning: Array section in 'c_loc' call at (1)
/home/boubacart/SIESTA/siesta-5.0.0/_build/_deps/libgridxc-src/src/fft3d.F90:264.25:

  call c_f_pointer(c_loc(aDat(:,:,:,2)),aux2,[aMesh(1)*aMesh(2)*aMesh(3)])
 1
Warning: Array section in 'c_loc' call at (1)
[  3%] Building Fortran object
_deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/vdwxc.F90.o
[  4%] Building Fortran object
_deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/fftr.F90.o
[  4%] Building Fortran object
_deps/libgridxc-build/CMakeFiles/libgridxc-lib.dir/src/xcmod.F90.o
[  4%] Building Fortran 

Re: [SIESTA-L] Tbtrans not printing Volatge and current output

[El-Abed Haidar]

Hi There
Did you have to use 4.1.5 ?
The reason i am saying this is because 4.1.3 had its own bugs
El abed
Sent from my iPhone

On 25 May 2024, at 6:01 AM, RUPESH TIWARI  wrote:


Dear  users and developers,
   I am performing a transport calculation using the transiesta 4.1-b3  
version. The calculation converges and terminates normally. However, during the 
I-V calculations in Tbrans, the output does not print the voltage/current 
values. Also the UP/DOWN avtrans files are not getting generated.
  I have attached here the Tbtrans input and output files. 
Please let me know if I'm making some mistakes in the input or if there is some 
problem in the installation.

Regards
Rupesh Kumar Tiwari
C/o: Prof. Gopalan Rajaraman
Senior Research Fellow (CSIR)
Department of Chemistry
IIT Bombay
Mumbai- 400076



--
SIESTA is supported by the Spanish Research Agency (AEI) and by the European 
H2020 MaX Centre of Excellence 
(https://urldefense.com/v3/__https://url.au.m.mimecastprotect.com/s/i7z0Cq71mwfLR6VLgIZfMtF?domain=max-centre.eu__;!!D9dNQwwGXtA!Rl9yyMgi_WyHPc0H3t3954zYtf-JJhmd8tZoCBgO1SqbOtaWwLt1TijLXG2zXUJxvDdC6qTvr6R95QkWkAwK7gWC$
 )

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

Re: [SIESTA-L] siesta with miniconda3

[Nick Papior]

Hi,

Which version of siesta did you install with conda?

Could you try and upgrade the siesta installation. The latest version
should have this enabled.

Den tors. 16. maj 2024 kl. 22.00 skrev Aleksandra Oranskaia <
aleksandra.oransk...@kaust.edu.sa>:

> Dear users and developers,
>
> I am a beginner user of Siesta and installed it via conda (as described
> here
> https://urldefense.com/v3/__https://docs.siesta-project.org/projects/siesta/en/latest/installation/conda.html__;!!D9dNQwwGXtA!Rfqlu6lbZ09CF33nERDLu2sDGB7yDZjhqMkO747azwfrA95ojVbQhuf200SAkJLBSe9ogODx1S2AeHwOcA$
>  
> 
> ).
>
> After going through the basic tutorials/tests I tried NEB examples with
> lua functionality but this type of run is not recognized by Siesta (i.e.
> conda installation is done without the flos library, if I understand
> correctly).
> Could you please connect me with a person(s) who could help with making
> conda installation possible with flos?
>
> PS I tried to compile Siesta (following
> https://urldefense.com/v3/__https://github.com/siesta-project/flos__;!!D9dNQwwGXtA!Rfqlu6lbZ09CF33nERDLu2sDGB7yDZjhqMkO747azwfrA95ojVbQhuf200SAkJLBSe9ogODx1S0Spi90Fg$
>  
> )
> but it did not work for me.
>
> Sorry for bothering. Thank you and hope to hear from anybody.
>
> Best wishes,
> Alex, PhD in chemical sciences
> 'I.. a universe of atoms, an atom in the universe' (Richard P. Feynman)
> https://urldefense.com/v3/__https://cpms.kaust.edu.sa/__;!!D9dNQwwGXtA!Rfqlu6lbZ09CF33nERDLu2sDGB7yDZjhqMkO747azwfrA95ojVbQhuf200SAkJLBSe9ogODx1S3OJ2HO3g$
>  
> 
>
> --
> 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!Rfqlu6lbZ09CF33nERDLu2sDGB7yDZjhqMkO747azwfrA95ojVbQhuf200SAkJLBSe9ogODx1S2b6qq9Rw$
>  )
>


-- 
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] Hole pockets in Bi

[Daniel Bennett]

Hi Roland,

I would highly recommend using psml pseudos: 
https://urldefense.com/v3/__http://www.pseudo-dojo.org/__;!!D9dNQwwGXtA!RrBjENfaENy8ZMudSEjcZAXbM2fn5MOyEJ82THnRwER5QrSWiV4QR4EMegYaKl394GIDwNSAlunD3CJh$
  . I have used the Bi pseudos from here (different system) and got good 
agreement with plane wave codes. You'll need to compile a version of siesta 
that can use psml pseudos, instructions 
here.
 It will take a bit of work, but extremely worth it.

You can also use abinit with the psml pseudos (instructions Javier's slides), 
so you can compare the two codes and see if there is an issue with the siesta 
basis.

Before doing any serious tests, you can simply reduce the EnergyShift (try 
something small like 20 meV), and try larger basis sets: DZDP, TZP TZDP, etc. I 
think some are listed in the manual, but you can find a full list in 
siesta/Src/basis_specs.f, around line 1408

Best,

Daniel Bennett


From: siesta-l-requ...@uam.es  on behalf of Roland 
Coratger 
Sent: 25 April 2024 04:43
To: siesta-l@uam.es 
Subject: [SIESTA-L] Hole pockets in Bi


Dear all,

I am currently engaged in investigating the electronic structure of Bismuth 
using Siesta4.1 b4. In the attached file, you will find my results concerning 
the band structure and electron pockets located at the L points of the 
Brillouin Zone (BZ). However, I've encountered an anomaly: hole pockets are not 
aligning with the trigonal axis (T point of BZ), but instead, they are slightly 
displaced along the H direction while the rest of the electronic structure is 
consistent with previous calculations of several authors. This displacement 
persists regardless of the basis set used (be it DZP or a more sophisticated 
one, as detailed in my fdf file).

While I'm open to the possibility of error, I think that a bad pseudo (my entry 
file for the Atom program is also in the attached file) or a poor basis set 
would result in very unsuitable electronic structures, not only at the T 
points. I'm reaching out to seek your insights. Perhaps one of you might have 
suggestions on what adjustments I could make to enhance the accuracy of my 
results and correctly obtain the structure at the T points.

Thank you sincerely for your attention and any assistance you can provide.

Regards,

Roland






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

Re: [SIESTA-L] Regarding SCF convergence issue during optimization

[Daniel Bennett]

I just wanted to add to this that usually the best place to start with 
convergence problems are the SCF parameters (assuming you already followed the 
advice by Andrei, checking geometry, electronic structure, kpoints etc.). Check 
the manual for more details, but usually playing around with the following can 
help:

SCF.Mix Hamiltonian
SCF.Mixer.Weight 0.25
SCF.Mixer.History 7 # Number of previous SCF steps to estimate 
input (default: 2)

SCF.DM.Converge true# Converge SCF step wrt density matrix 
(default: 1e-4)
SCF.H.Converge true # Converge wrt Hamiltonian matrix elements 
(default: 1e-3 eV)

SCF.DM.Tolerance 0.0001
SCF.H.Tolerance  0.0001 eV

I just posted an example which works well for the calculations I'm doing, but 
you'll need to tune these. Try to converge these with a smaller system if 
possible, i.e. if your system is a supercell, converge these with the primitive 
cell. It can be quite tedious, you'll have to run siesta, track the SCF loop 
(e.g. "tail -f *.out" and watch it for a while), then update the parameters and 
see if that makes it better or worse. But it is very worth it, it will save you 
lots of computational effort, and you'll only have to do it once (unless you 
change to a very different material).

If you can get the SCF to converge well for a smaller system, then you'll need 
to take some additional care to set up the larger system. First, you can check 
that it is parallelized efficiently. The PARALLEL_DIST file will give you 
information about that, it is good to have similar number of orbitals on each 
core. If you are not sure, you can do "grep orbitals *.out" to see how many 
orbitals you have, then use a number of cores that divides this. Don't use too 
many cores, 10-20 orbitals per core is efficient (somebody mentioned this at 
the last siesta workshop, if not true can somebody weigh in).

Once you have all that sorted, you can try changing the eigensolver for larger 
systems. I did a large calculation recently (152 atoms, 2048 cores, full 
geometry+cell relaxation), and had a lot of success using

Diag.Algorithm MRRR
NumberOfEigenStates -20 # this will include first 20 conduction bands

without OrderN. But before worrying about this, it's important to make sure 
that the SCF converges very well for smaller and simpler systems

Regards,

Daniel Bennett

From: siesta-l-requ...@uam.es  on behalf of Andrei 
Postnikov 
Sent: 23 April 2024 07:09
To: Siesta-l 
Cc: deb.jyotirmo...@gmail.com 
Subject: Re: [SIESTA-L] Regarding SCF convergence issue during optimization

Hi,
you provide too few information. Of course just increasing the number of 
iterations won't bring you further
if there is no convergence. General advises might be as follows:

- Check that you are using diagonalisation and NOT order-N scheme before you 
fix the things and
"know what you are doing". With 235 atoms the chances are, you are in order-N 
regime by default,
and things go astray.

- Check your system visually (using visualisation tools from your working XV 
file)
whether its shape is as expected; a huge number of problems result from an 
error in defining the structure.

- Check whether your electronic structure makes sense (the main bands are more 
or less where they are expected)
at very first iterations, before the calculations start to markedly diverge. Do 
not just look at the convergence, but at other things
in the output file. Make sure that the attribution of valence states in the 
pseudopotential and in the basis matches.
Some inconsistencies may cry aloud in the output file, but you need to pay 
attention...

- Reduce the mixing parameter. Reduce it drastically if needed (0.001 is not 
uncommon in some cases).
Start converging with large broadening (electronic temperature), say 600 K, and 
then reduce it gradually as you enter
into a convergence regime.

The actual behaviour may depend on whether your system is isolated or periodic, 
insulator or metal.
If your case is periodic and metallic, you may need many k-points as well (in 
the directions of periodicity, of course).

Good luck

Andrei Postnikov

- Le 19 Avr 24, à 4:16, Jyotirmoy Deb  a écrit :
Dear Sir/Madam,
I want to optimize a heterostructure consisting of 235 atoms. But I am facing 
an error every time  "SCF did not converge in the maximum number of steps". I 
have gradually increased the "MaxSCFIterations" however, I have not been able 
to solve this issue. Please help me in this regard.

Thanking you
with regards
Jyotirmoy


Dr. Jyotirmoy Deb
C/O Dr. G. Narahari Sastry & Dr. Lakshi Saikia
DST-SERB National Post-Doctoral Fellow
Advanced Computation and Data Sciences Division (ACDSD)
CSIR-North East Institute of Science & Technology, Jorhat-785006, Assam, India.
Ph. No: +917002140643/+919435589869
Email: deb.jyotirmo...@gmail.com<mailto:deb.jyotirmo...@gmail.com>
Webpage: 
https://url

Re: [SIESTA-L] Regarding SCF convergence issue during optimization

[Andrei Postnikov]

Hi, 
you provide too few information. Of course just increasing the number of 
iterations won't bring you further 
if there is no convergence. General advises might be as follows: 

- Check that you are using diagonalisation and NOT order-N scheme before you 
fix the things and 
"know what you are doing". With 235 atoms the chances are, you are in order-N 
regime by default, 
and things go astray. 

- Check your system visually (using visualisation tools from your working XV 
file) 
whether its shape is as expected; a huge number of problems result from an 
error in defining the structure. 

- Check whether your electronic structure makes sense (the main bands are more 
or less where they are expected) 
at very first iterations, before the calculations start to markedly diverge. Do 
not just look at the convergence, but at other things 
in the output file. Make sure that the attribution of valence states in the 
pseudopotential and in the basis matches. 
Some inconsistencies may cry aloud in the output file, but you need to pay 
attention... 

- Reduce the mixing parameter. Reduce it drastically if needed (0.001 is not 
uncommon in some cases). 
Start converging with large broadening (electronic temperature), say 600 K, and 
then reduce it gradually as you enter 
into a convergence regime. 

The actual behaviour may depend on whether your system is isolated or periodic, 
insulator or metal. 
If your case is periodic and metallic, you may need many k-points as well (in 
the directions of periodicity, of course). 

Good luck 

Andrei Postnikov 

- Le 19 Avr 24, à 4:16, Jyotirmoy Deb  a écrit : 

> Dear Sir/Madam,
> I want to optimize a heterostructure consisting of 235 atoms. But I am facing 
> an
> error every time "SCF did not converge in the maximum number of steps". I have
> gradually increased the "MaxSCFIterations" however, I have not been able to
> solve this issue. Please help me in this regard.

> Thanking you
> with regards
> Jyotirmoy

> Dr. Jyotirmoy Deb
> C/O Dr. G. Narahari Sastry & Dr. Lakshi Saikia
> DST-SERB National Post-Doctoral Fellow
> Advanced Computation and Data Sciences Division (ACDSD)
> CSIR-North East Institute of Science & Technology, Jorhat-785006, Assam, 
> India.
> Ph. No: +917002140643/ +919435589869
> Email: [ mailto:deb.jyotirmo...@gmail.com | deb.jyotirmo...@gmail.com ]
> Webpage: [
> https://urldefense.com/v3/__https://sites.google.com/view/jyotirmoydftphy__;!!D9dNQwwGXtA!QXMXS7L8cCba3hBh8KgcbwyC9C-E5X98KJTAXUguv0CMpKRil5P5cMWK5ziJhwU4-c14ht8eejcbtj_czqW_iUBo$
> | 
> https://urldefense.com/v3/__https://sites.google.com/view/jyotirmoydftphy__;!!D9dNQwwGXtA!TlNGLjwuIHLvaLUEXMAzZneDEOzZtFJFMRfYAnBQADgcqVNh1tJuG4DMBR8sWhbOVnrRtR-96vIssOhkbvkqvQKGf5LpgmFIQA$
>   ]

> --
> 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!TlNGLjwuIHLvaLUEXMAzZneDEOzZtFJFMRfYAnBQADgcqVNh1tJuG4DMBR8sWhbOVnrRtR-96vIssOhkbvkqvQKGf5IASVdD0A$
>  )

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

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

[Nick Papior]

Hi Camps,

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

Thanks!

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

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


-- 
Kind regards Nick

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

Re: [SIESTA-L] learning

[Sunetra Das]

STOP

On Tue, 26 Dec, 2023, 2:30 am M Mohammadi, 
wrote:

> how can i learn siesta from the biggening?
>
> --
> 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!TtP64JYx8M2cReaZheQmoWqos8mKglFNplOnM79Os0NWA6TYEtBU0QO6ewNMLRNfqyTzO32zxojIru5n4WnLoqY$
>  )
>

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

Re: [SIESTA-L] Grimm parameters

[Nick Papior]

Hi,

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

Thanks.

/ Nick

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

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


-- 
Kind regards Nick

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

Re: [SIESTA-L] converge problem in long voltage range

[ELDER AUGUSTO VIANA MOTA]

Hello Yelda, I hope you are doing well!

Try to decrease the bias step. For instance, if you are trying to get
convergence in -1.6 V using the "*.TSDE" and "*.TSHS" files of -1.5 V, do
the calculation for -1.55 V using the -1.50 V files, and then use the -1.55
V files to get the -1.60 V convergence.

I hope that helps!

Em qui., 7 de dez. de 2023 às 18:00, Yelda Kadıoglu <
yeldaakadio...@gmail.com> escreveu:

> Hello Dr. Nick Papior
> I'm disturbing you because I'm having trouble with the crucial part of my
> work.
> I added my IV data for two different sizes of the same structure. The
> voltages I scanned and those that did not converge are shown in dat files.
> Even though I choose the DM.MixingWeight parameter quite small (0.01), I
> have a convergence problem over a long voltage range. Especially i need
> between (-1.6)-(-2.0) V.
> Is there another solution than DM.MixingWeight and increasing V? As far as
> i know I can't change the part where you code the chemical potential and
> the integrals underneath it.
>
> Thanks in advance for your help
> Yelda
>
> --
> 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!Sk946bt1iAMGJMu7hyjfmaDIyekwaSRWmWGSe6eu4pxDj5q0koUigdVYn1DpwJykvwM2uCnBzINiMuyZ2ZDUqWc$
>  )
>


-- 
Prof. Dr. Elder A. V. Mota
Licenciatura em Física,  UFPA - Belém / 2017
Bacharelado em Física, UFPA - Belém / 2018
Mestrado em Física, UFPA - Belém / 2019
Doutorado em Física, UFPA - Belém / 2023
Professor Substituto, UFPA - Campus Abaetetuba / Atual
https://urldefense.com/v3/__http://lattes.cnpq.br/9918962099819860__;!!D9dNQwwGXtA!Sk946bt1iAMGJMu7hyjfmaDIyekwaSRWmWGSe6eu4pxDj5q0koUigdVYn1DpwJykvwM2uCnBzINiMuyZW_IcMKY$
 

-- 
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] converge problem in long voltage range

[El-Abed Haidar]

Good evening Yelda
I have been facing similar issues and at this stage Nick would tell you its a 
trial and error situation since at lower voltages your calculations worked.
So you might want to try instead of 2.1 V try 2.13V
Or changing mixing weight again could work
Hope that helps
El abed
Sent from my iPhone

On 8 Dec 2023, at 8:00 am, Yelda Kadıoglu  wrote:


Hello Dr. Nick Papior
I'm disturbing you because I'm having trouble with the crucial part of my work.
I added my IV data for two different sizes of the same structure. The voltages 
I scanned and those that did not converge are shown in dat files. Even though I 
choose the DM.MixingWeight parameter quite small (0.01), I have a convergence 
problem over a long voltage range. Especially i need between (-1.6)-(-2.0) V.
Is there another solution than DM.MixingWeight and increasing V? As far as i 
know I can't change the part where you code the chemical potential and the 
integrals underneath it.

Thanks in advance for your help
Yelda
<25A_iv.dat>


--
SIESTA is supported by the Spanish Research Agency (AEI) and by the European 
H2020 MaX Centre of Excellence 
(https://urldefense.com/v3/__https://protect-au.mimecast.com/s/1EqwCOMKzVTNXWjPnFEN3Ud?domain=max-centre.eu__;!!D9dNQwwGXtA!VEipfei-EAw3qAkXRn4NDhp2_dG1_hNrxjku49_g_rEqGTDUnTpnE8DuUK4blIKuEGgtZUsSwLkjkerG2i4cOWPy$
 )

-- 
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] Passing constraint harmonic energy through constr.f

[Alberto Garcia]

Hi Francisco, 

You could define new "species" for the atoms you are interested in, and then 
put in the MM.Potentials block the right information for those species. 

A simple example. Say that you want to constrain harmonically one of the H 
atoms and the O atom in a water molecule. Then: 

SystemName Harmonically-constrained Water molecule 

SystemLabel hc- h2o 

NumberOfAtoms 3 

NumberOfSpecies 3 

%block ChemicalSpeciesLabel 

1 8 O 

2 1 H 

3 1 H_blue 

%endblock ChemicalSpeciesLabel 

AtomicCoordinatesFormat Ang 

%block AtomicCoordinatesAndAtomicSpecies 

0.000 0.000 0.000 1 

0.757 0.586 0.000 2 

-0.757 0.586 0.000 3 

%endblock AtomicCoordinatesAndAtomicSpecies 

%block MM.Potentials 

1 3 harm 4.0 0.8 

%endblock MM.Potentials 

(The potential parameters are made up. You should use appropriate ones). 

The pseudopotential file for H_blue can be a symbolic link to the hydrogen one, 
e.g. H.psf. 

I hope this helps. 

Alberto 

- El 16 de Noviembre de 2023, a las 04:17, Francisco Garcia 
 escribió: 

| Dear Prof. Garcia

| Many thanks for your response.

| I looked up the MM.Potentials block but I couldn't figure out how to apply the
| harmonic potential to selected atoms.

| Any assistance would be appreciated.

| Thanks!

| Francisco

| On Mon, Nov 13, 2023 at 1:51 AM Alberto Garcia < [ mailto:alber...@icmab.es |
| alber...@icmab.es ] > wrote:

|| Hi Francisco,

|| You could indeed modify the constr.f file to include what you need, but first
|| check the section of the manual entitled "Auxiliary Force Field". In there 
you
|| can find a discussion of the MM.Potentials block, in which you can define the
|| parameters of, among others, a harmonic potential.

|| Best regards,

|| Alberto

|| - El 11 de Noviembre de 2023, a las 09:13, Francisco Garcia < [
|| mailto:garcia.ff@gmail.com | garcia.ff@gmail.com ] > escribió:

||| Dear Users,

||| The constraint subroutine takes the form: subroutine constr( cell, na, isa,
||| amass, xa, stress, fa, ntcon ). It doesn't contain information about energy.

||| Now I am using a harmonic potential with a stiff spring to constrain a pair 
of
||| atoms separated by a distance of r0. I should be able to pass the constraint
||| harmonic energy V=1/2 * k * (rij - r0)^2 to the subroutine to be added to 
the
||| total energy i.e., E + 1/2 * k * (rij - r0)^2 will be the total energy.

||| Which routines should I modify to allow the total energy to account for the
||| constraint energy?

||| --
||| 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!V_yhBOHCFFxdY5WMcg2Vv8Ymb5CUuYr4dpyQyrnB8zQRuVGasPatUDFCuulHsnFCbVfyyrstpp82eApPAg3lvMc$
||| |
||| 
https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!V_yhBOHCFFxdY5WMcg2Vv8Ymb5CUuYr4dpyQyrnB8zQRuVGasPatUDFCuulHsnFCbVfyyrstpp82eApPAg3lvMc$
||| ] )
-- 
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] Passing constraint harmonic energy through constr.f

[Francisco Garcia]

Dear Prof. Garcia

Many thanks for your response.

I looked up the MM.Potentials block but I couldn't figure out how to apply
the harmonic potential to selected atoms.

Any assistance would be appreciated.

Thanks!

Francisco

On Mon, Nov 13, 2023 at 1:51 AM Alberto Garcia  wrote:

> Hi Francisco,
>
> You could indeed modify the constr.f file to include what you need, but
> first check the section of the manual entitled "Auxiliary Force Field". In
> there you can find a discussion of the MM.Potentials block, in which you
> can define the parameters of, among others, a harmonic potential.
>
>   Best regards,
>
>Alberto
>
>
> - El 11 de Noviembre de 2023, a las 09:13, Francisco Garcia <
> garcia.ff@gmail.com> escribió:
>
> Dear Users,
>
> The constraint subroutine takes the form: subroutine constr( cell, na,
> isa, amass, xa, stress, fa, ntcon ). It doesn't contain information about
> energy.
>
> Now I am using a harmonic potential with a stiff spring to constrain a
> pair of atoms separated by a distance of r0. I should be able to pass the
> constraint harmonic energy V=1/2 * k * (rij - r0)^2 to the subroutine to be
> added to the total energy i.e., E + 1/2 * k * (rij - r0)^2 will be the
> total energy.
>
> Which routines should I modify to allow the total energy to account for
> the constraint energy?
>
>
>
>
> --
> 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!V_yhBOHCFFxdY5WMcg2Vv8Ymb5CUuYr4dpyQyrnB8zQRuVGasPatUDFCuulHsnFCbVfyyrstpp82eApPAg3lvMc$
> )
>
>
>

-- 
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] Passing constraint harmonic energy through constr.f

[Alberto Garcia]

Hi Francisco, 

You could indeed modify the constr.f file to include what you need, but first 
check the section of the manual entitled "Auxiliary Force Field". In there you 
can find a discussion of the MM.Potentials block, in which you can define the 
parameters of, among others, a harmonic potential. 

Best regards, 

Alberto 


- El 11 de Noviembre de 2023, a las 09:13, Francisco Garcia 
 escribió: 



Dear Users, 

The constraint subroutine takes the form: subroutine constr( cell, na, isa, 
amass, xa, stress, fa, ntcon ). It doesn't contain information about energy. 

Now I am using a harmonic potential with a stiff spring to constrain a pair of 
atoms separated by a distance of r0. I should be able to pass the constraint 
harmonic energy V=1/2 * k * (rij - r0)^2 to the subroutine to be added to the 
total energy i.e., E + 1/2 * k * (rij - r0)^2 will be the total energy. 

Which routines should I modify to allow the total energy to account for the 
constraint energy? 




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




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

Re: [SIESTA-L] Siesta fatbands / building utilities in 5.0

[Nick Papior]

Hi Daniel,

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

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

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


-- 
Kind regards Nick

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

Re: [SIESTA-L] Siesta fatbands / building utilities in 5.0

[Daniel Bennett]

Thanks Alberto. I didn't know that cmake builds the utilities by default, very 
convenient! I was looking in siesta/Util instead of siesta/build/Util

I ran the fat program from siesta 5.0, and I am getting the message:

unknown HSX file version [0, 1]

but I ran the calculations with the same version of siesta. I tried getting the 
*.HSX file with both COOP.Write true and Save-HS true in separate calculations 
and got the same error. Is there another way to get the *.HSX file?



From: siesta-l-requ...@uam.es  on behalf of Alberto 
Garcia 
Sent: 24 October 2023 03:20
To: siesta-l@uam.es 
Subject: Re: [SIESTA-L] Siesta fatbands / building utilities in 5.0

Hi Daniel,

In Siesta 5.0 the CMake system builds all the utilities by default. If you 
install the package after building they will all be in the 
/path/to/installation/bin
directory, together with the siesta executable itself.  If you do not install, 
they will be in _build/Util/, where _build stands for the CMake build 
directory and  for the appropriate subdirectory in the Util hierarchy.

The build_all.sh script is a fossil we forgot to remove…

If you used an old version of ‘fat’, the format of the HSX file might have 
changed. Please use the latest version.

  Alberto





On 20 Oct 2023, at 21:56, Daniel Bennett 
mailto:db...@cantab.ac.uk>> wrote:

Hi all,

I'm trying to run a simple calculation of the fat bands, using the latest 
siesta version 5.0. I compiled with cmake and noticed that the build_all.sh 
script still uses the arch.make file, does anybody know how to build the 
utilities with 5.0 if using cmake to build siesta?

Anyway, I'm using an older version of siesta util/COOP/fat. Attached is a 
simple example of graphene, I'm trying to get the fatbands for the p_z 
orbitals. I run

ln -s Graphene.bands.WFSX Graphene.WFSX
/path/to/util/COOP/fat fatbands

And the output is

Reading wf file: Graphene.WFSX
 Minimum/Maximum number of wfs per k-point:26   26
Min_eigval, max_eigval on WFS file: -23.7976191.4211
Min_eigval, max_eigval in band set : -23.7976191.4211
Band set used: (min, max):   1  26
 Graphene.HSX nnao, no_s, nspin, nh:   1   0   0
   0
nnao, no_s...

It seems to stop short of writing the EIGFAT files.

Can anyone advise? I tried following both 
this<https://personales.unican.es/junqueraj/JavierJunquera_files/Metodos/Structuralproperties/Fatbands-SrTiO3/Exercise-Fatbands-SrTiO3.pdf>
 (old) and 
this<https://urldefense.com/v3/__https://docs.siesta-project.org/projects/siesta/en/school-2021/tutorials/advanced-analysis/fatbands/index.html__;!!D9dNQwwGXtA!TYstP5a46p6MCs73BudAIltCxnBcKjKEkEXTOmNfVFATwQ94a2mXAZNCCbVw5Jj-Cc_cCWGH0XrdG8IF$>
 (newer), but always get the same thing. Also any advice on building the 
utilities with siesta 5.0 appreciated too

Thanks,

Daniel Bennett

--
SIESTA is supported by the Spanish Research Agency (AEI) and by the European 
H2020 MaX Centre of Excellence 
(https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!QI4qwP-wiDpydqflVwrSkysOntWyR5FS9_AHJq0WaTFZGIQGK6v79-PoUS7xjbU6AHVjNu4GqF977sUH4g$
 )


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

Re: [SIESTA-L] Siesta fatbands / building utilities in 5.0

[Alberto Garcia]

Hi Daniel,

In Siesta 5.0 the CMake system builds all the utilities by default. If you 
install the package after building they will all be in the 
/path/to/installation/bin
directory, together with the siesta executable itself.  If you do not install, 
they will be in _build/Util/, where _build stands for the CMake build 
directory and  for the appropriate subdirectory in the Util hierarchy.

The build_all.sh script is a fossil we forgot to remove…

If you used an old version of ‘fat’, the format of the HSX file might have 
changed. Please use the latest version.

  Alberto


  


> On 20 Oct 2023, at 21:56, Daniel Bennett  wrote:
> 
> Hi all,
> 
> I'm trying to run a simple calculation of the fat bands, using the latest 
> siesta version 5.0. I compiled with cmake and noticed that the build_all.sh 
> script still uses the arch.make file, does anybody know how to build the 
> utilities with 5.0 if using cmake to build siesta?
> 
> Anyway, I'm using an older version of siesta util/COOP/fat. Attached is a 
> simple example of graphene, I'm trying to get the fatbands for the p_z 
> orbitals. I run
> 
> ln -s Graphene.bands.WFSX Graphene.WFSX
> /path/to/util/COOP/fat fatbands
> 
> And the output is
> 
> Reading wf file: Graphene.WFSX
>  Minimum/Maximum number of wfs per k-point:26   26
> Min_eigval, max_eigval on WFS file: -23.7976191.4211
> Min_eigval, max_eigval in band set : -23.7976191.4211
> Band set used: (min, max):   1  26
>  Graphene.HSX nnao, no_s, nspin, nh:   1   0   0  
>  0
> nnao, no_s...
> 
> It seems to stop short of writing the EIGFAT files.
> 
> Can anyone advise? I tried following both this 
> 
>  (old) and this 
> 
>  (newer), but always get the same thing. Also any advice on building the 
> utilities with siesta 5.0 appreciated too
> 
> Thanks,
> 
> Daniel Bennett
> 
> -- 
> SIESTA is supported by the Spanish Research Agency (AEI) and by the European 
> H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!QI4qwP-wiDpydqflVwrSkysOntWyR5FS9_AHJq0WaTFZGIQGK6v79-PoUS7xjbU6AHVjNu4GqF977sUH4g$
>  
> 
>  )


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

Re: [SIESTA-L] [EXTERNAL] Re: 3 Terminal STM device.

[Mohammed Ghadiyali]

Hello Prof. Nick,

Found my mistake. The calculations are running now.

Regards,
Ghadiyali Mohammed Kader
Post Doctoral Fellow
King Abdullah University of Science and Technology
On 29 Sep 2023 at 11:00 PM +0300, Nick Papior , wrote:
> No transfer matrix generally happens when you do electrode runs without 
> k-points, or if you are using a vacuum region along the semi-infinite 
> direction (which is clearly wrong).
>
> Try and figure out these two conditions for your input files.
>
> > Den tors. 28. sep. 2023 kl. 22.00 skrev Mohammed Ghadiyali 
> > :
> > > Hello,
> > >
> > > I’m trying to reproduce the calculations form paper “Control of the local 
> > > magnetic states in graphene with voltage and gating”, it has three 
> > > terminal STM device I’m getting following error:
> > >
> > > Electrode el-1 has no transfer matrix.
> > > The self-energy cannot be calculated with a zero transfer matrix!
> > > Elec: transfer matrix has 0 elements. The self-energy cannot be 
> > > calculated. Please check your electrode electronic structure.
> > >
> > > Form the pervious forum post it could be due to two reasons:
> > >
> > > 1. Missing periodic boundary condition
> > > 2. Incorrect semi-inf-direction
> > >
> > > I’ve checked both and it’s still giving me the error.
> > > I’ve used the "-fdf TS.Analyze” for getting the pivoting scheme, it runs 
> > > and prints that the electrodes are perfect.
> > >
> > > I’ve attached the inputs of the electrodes and scattering region, as well 
> > > as the output of the scattering region with the error.
> > >
> > > PS. As I'm testing, I’m not using the magnetic moment to save cost and 
> > > time.
> > >
> > > Regards,
> > > Ghadiyali Mohammed Kader
> > > Post Doctoral Fellow
> > > King Abdullah University of Science and Technology
> > >
> > > This message and its contents, including attachments are intended solely 
> > > for the original recipient. If you are not the intended recipient or have 
> > > received this message in error, please notify me immediately and delete 
> > > this message from your computer system. Any unauthorized use or 
> > > distribution is prohibited. Please consider the environment before 
> > > printing this email.
> > > --
> > > SIESTA is supported by the Spanish Research Agency (AEI) and by the 
> > > European H2020 MaX Centre of Excellence 
> > > (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!Rb1H_U-M_ExkFArXb177QxcyY60NWZ_Bhl63A5YEtJ2I2y1yS57X0GhlqfSnkVNmlysCW0Xj93gRnPfOqfTsOOrlv6bftw$
> > >  )
>
>
> --
> Kind regards Nick
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the European 
> H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!Nmw4Hv0!2euwLIsQtv1daoWRYUpfjCMDmGQw5tP1NkAGig6hor4VOBCPkXs9C16QGzOev4cBIa0-mopP3PFCVxUDwAEf6LonMYtCJhY$
>  )

-- 

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] Error in compiling siesta-master (28 Sep. 2023)

[Alberto Garcia]

Hi, 

Please note that the master branch has received a lot of new commits in the 
past week. You might have downloaded a version with a temporary glitch. 

I suggest you now re-run the build step in the same directory with the option 
'-j 1' instead of '-j 44', so that the compilation's last message refers 
to the actual error. Then you can get more information about what might be 
happening. 

Once you do, and if you cannot figure out the cause and you are not missing any 
patches from master, please get back to me privately with the output of the 
configuration and building steps. 

Thank you for your feedback. 

Alberto 

- El 28 de Septiembre de 2023, a las 21:33, Reza Behjatmanesh-Ardakani 
 escribió: 

| Hi
| I used following command for compiling siesta-master:
| 
| cmake -S. -B_build -DCMAKE_INSTALL_PREFIX=/home/reza/siesta_master
| -DWITH_DFTD3=OFF
| -DWITH_LIBXC=OFF -DWITH_FLOOK=OFF
| 
-DSIESTA_TOOLCHAIN=/home/reza/siesta-master/Config/cmake/toolchains/intel.cmake
| -DWITH_MPI=ON
| 
-DSCALAPACK_LIBRARY="-L/opt/intel_2020/compilers_and_libraries_2020.4.304/linux/mkl/lib/intel64
| -lmkl_scalapack_lp64
| -lmkl_blacs_intelmpi_lp64 -ldl -lm"

| cmake --build _build -j 44
| 

| however, I get following error:

| .=
| .
| .
| .

| [ 27%] Building Fortran object
| Src/easy-fdict/CMakeFiles/siesta-libfdict.dir/dictionary.f90.o
| [ 27%] Linking Fortran static library libsiesta-libfdict.a
| [ 27%] Built target siesta-libfdict
| gmake: *** [Makefile:146: all] Error 2

| 

| Any idea?

| Thanks
| Reza

| --
| SIESTA is supported by the Spanish Research Agency (AEI) and by the European
| H2020 MaX Centre of Excellence
| 
(https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!VMFehL9Lz3LHN1QckE3o_y3EnDk8MzIkzui8piHltB6SXNwe6fBPdFY2xUZMb9yY8rI5X1Hj0Iluth21njg$
| )

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

Re: [SIESTA-L] 3 Terminal STM device.

[Nick Papior]

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

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

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

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


-- 
Kind regards Nick

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

Re: [SIESTA-L] Error in tselecs.sh

[Nick Papior]

Thanks for reporting.

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

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

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

> Hello,
>
> I’m trying to use the utility tselecs.sh, howerve it is giving following
> error “Unknown option”, even if I use the given example
>
> ./tselecs.sh -2 -el3 name=Top,mu=Left,inf-dir=+a2,end-pos=-1
>
> Regards,
> Ghadiyali Mohammed Kader
> Post Doctoral Fellow
> King Abdullah University of Science and Technology
>
> --
> This message and its contents, including attachments are intended solely
> for the original recipient. If you are not the intended recipient or have
> received this message in error, please notify me immediately and delete
> this message from your computer system. Any unauthorized use or
> distribution is prohibited. Please consider the environment before printing
> this email.
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 
> (https://urldefense.com/v3/__http://www.max-centre.eu/__;!!D9dNQwwGXtA!R7LzVg_Ad7zuUrs0lizbVzH71PZlK4YS6F2IkTSpOdkDvRQc3YtI_nLUFWd-Ksc4DpIFwNp2xccj8RjXSQ$
>  )
>


-- 
Kind regards Nick

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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 

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

[Andrei Postnikov]

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 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 greatly
> appreciated.

> Thank you very much for your kind assistance and God Bless!

> Francisco

> #INPUT 1 (1 atom in the FCC primitive cell; 125 atoms in Supercell)
> SystemName fccMn_1
> SystemLabel fccMn_1
> NumberOfAtoms 1
> 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

> AtomicCoordinatesFormat Fractional
> %block AtomicCoordinatesAndAtomicSpecies
> 0.00 0.00 0.00 1 54.938
> %endblock AtomicCoordinatesAndAtomicSpecies

> SuperCell_1 2
> SuperCell_2 2
> SuperCell_3 2

> AtomicDispl 0.04 Bohr

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

> Eigenvectors True

> #INPUT 2 (4 atoms in the FCC conventional cell; 108 atoms in Supercell)
> SystemName fccMn_4
> SystemLabel fccMn_4
> NumberOfAtoms 4
> LatticeConstant 3.47 Ang
> %block LatticeVectors
> 1.00 0.00 0.00
> 0.00 1.00 0.00
> 0.00 0.00 1.00
> %endblock LatticeVectors

> AtomicCoordinatesFormat Fractional
> %block AtomicCoordinatesAndAtomicSpecies
> 0.00 0.00 0.00 1 54.938
> 0.50 0.50 0.00 1 54.938
> 0.50 0.00 0.50 1 54.938
> 0.00 0.50 0.50 1 54.938
> %endblock AtomicCoordinatesAndAtomicSpecies

> SuperCell_1 1
> SuperCell_2 1
> SuperCell_3 1

> AtomicDispl 0.04 Bohr

> BandLinesScale pi/a
> # The band lines below are incorrect.
> %block BandLines
> 1 0.000 0.000 0.000 \Gamma
> 30 2.000 0.000 0.000 X
> 30 2.000 2.000 2.000 \Gamma
> 30 1.000 1.000 1.000 L
> %endblock BandLines

> Eigenvectors True

> --
> 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!T-wl-ZvX-LX5xZC7QdfhJRIJ8Pmxo5HofWGt13XzKiGWhx9VgP3MXmjkoKcw2oYTy4STEEQIyWW5lU0aV4mzNGNhq7rtk7d9KA$
>  )

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

Re: [SIESTA-L] Current or transmission direction

[Nick Papior]

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

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

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

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


-- 
Kind regards Nick

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

Re:[SIESTA-L]

[I. Camps]

I think the problem is that you are using a semicolon instead of a point
for decimal separation.


[]'s,

Camps


On Mon, Nov 7, 2022 at 6:05 PM Amal Yassin  wrote:

> Dear siesta users
> can you help me? i did the run for fdf file, and i found this error..
>
>
> coor:   Atomic-coordinates input format  = Cartesian coordinates
> coor:  (in Angstroms)
> rcut: Wrong species  3. Have  1
> Stopping Program from Node:0
>
> Program aborted. Backtrace:
>
> siesta: Atomic coordinates (Bohr) and species
> siesta:  5.66918**   5.66918  31
> siesta:  5.66918**   5.66918  32
> siesta:  5.66918**   7.55891  33
> siesta:  5.66918**   7.55891  34
> siesta:  3.77945**   9.44863  25
> siesta:  3.77945**   9.44863  26
> siesta:  1.88973**   9.44863  17
> siesta:  1.88973**   9.44863  18
> siesta:  0.0**   7.55891  09
> siesta:  0.0**   7.55891  0   10
> siesta: -0.0**   5.66918  0   11
> siesta: -0.0**   5.66918  0   12
> siesta:  0.0**   3.77945  0   13
> siesta:  0.0**   3.77945  0   14
> siesta:  1.88973**   1.88973  1   15
> siesta:  1.88973**   1.88973  1   16
> siesta:  3.77945**   1.88973  2   17
> siesta:  3.77945**   1.88973  2   18
> siesta:  5.66918**   3.77945  3   19
> siesta:  5.66918**   3.77945  3   20
>
> siesta: Automatic unit cell vectors (Ang):
> siesta:5.8135000.000.00
> siesta:0.000.00
> siesta:0.000.00   10.213500
> rcut: Wrong species  3. Have  1
> Stopping Program from Node:0
> #0  0x7f1e771a8d21 in ???
> #1  0x7f1e771a97ad in ???
> #2  0x7f1e773fd38c in ???
> #3  0x562eeed87aca in ???
> #4  0x562eeeac6e83 in ???
> #5  0x562eeea4cd25 in ???
> #6  0x562eeea79d0b in ???
> #7  0x562eeea78277 in ???
> #8  0x562eee9bd74c in ???
> #9  0x7f1e76e24082 in __libc_start_main
> at ../csu/libc-start.c:308
> #10  0x562eee9bd81d in ???
> #11  0x in ???
>
> and this is the fdf file..
>
> # Created by GDIS version 0,90.0
> #
>
> SystemLabel  nano55
>
> NumberOfAtoms20
>
> NumberOfSpecies  1
> %block ChemicalSpeciesLabel
> 16  C
> %endblock ChemicalSpeciesLabel
>
> LatticeConstant 1.0 Ang
> %block LatticeVectors
>7,3128000,000,00
>   -3,6564006,33307057280,00
>0,000,004,280600
> %endblock LatticeVectors
>
> AtomicCoordinatesFormat NotScaledCartesianAng
> %block AtomicCoordinatesAndAtomicSpecies
>  3,811431360 3,166535286 1,4211592001
>  3,811431360 3,166535286 0,01
>  3,432628320 4,331820272 3,5614592001
>  3,432628320 4,331820272 2,140301
>  2,441012640 5,052523703 1,4211592001
>  2,441012640 5,052523703 0,01
>  1,215387360 5,052523703 3,5614592001
>  1,215387360 5,052523703 2,140301
>  0,224502960 4,331820272 1,4211592001
>  0,224502960 4,331820272 0,01
> -0,155031360 3,166535286 3,5614592001
> -0,155031360 3,166535286 2,140301
>  0,223771680 2,001250301 1,4211592001
>  0,223771680 2,001250301 0,01
>  1,215387360 1,280546870 3,5614592001
>  1,215387360 1,280546870 2,140301
>  2,441012640 1,280546870 1,4211592001
>  2,441012640 1,280546870 0,01
>  3,431897040 2,001250301 3,5614592001
>  3,431897040 2,001250301 2,140301
> %endblock AtomicCoordinatesAndAtomicSpecies
>
>
>
> PAO.BasisTypesplit
> PAO.BasisSizeDZP
>
> SolutionMethod diagon
>
>
> Harris_functionalfalse
> XC.functionalLDA
> XC.AuthorsPZ
> SpinPolarizedfalse
> MeshCutoff100,00 Ry
> kgrid_cutoff0,00 Bohr
> ElectronicTemperature300,00 K
> MaxSCFIterations50
> DM.NumberPulay0
> DM.MixingWeight0,25
> MD.TypeOfRunCG
> MD.VariableCellfalse
> MD.MaxCGDispl0,20 Bohr
> MD.PreconditionVariableCell5,00 Ang
> MD.MaxStressTol1,00 GPa
>
> %block MD.TargetStress
> -1,00 -1,00 -1,00 0,00 0,00 0,00
> %endblock MD.TargetStress
>
> MD.MaxForceTol0,04 eV/Ang
> MD.InitialTimeStep1
> MD.FinalTimeStep1
> MD.LengthTimeStep1 fs
> MD.InitialTemperature0,00 K
> MD.Quenchfalse
> MD.TargetTemperature0,00 K
> MD.NoseMass100,00 Ry*fs**2
> MD.ParrinelloRahmanMass100,00 Ry*fs**2
> MD.AnnealOptionTemperatureandPressure
> MD.TauRelax

Re:[SIESTA-L]

[Alberto Garcia]

Hi, 

For some reason, you are using commas (",") instead of dots (".") as decimal 
separators. In fortran, 
a comma in an input line separates items. This confuses the program. You should 
check your 'locale' settings. 

Alberto 

- El 7 de Noviembre de 2022, a las 17:18, Amal Yassin 
 escribió: 

| Dear siesta users
| can you help me? i did the run for fdf file, and i found this error..

| coor: Atomic-coordinates input format = Cartesian coordinates
| coor: (in Angstroms)
| rcut: Wrong species 3. Have 1
| Stopping Program from Node: 0

| Program aborted. Backtrace:

| siesta: Atomic coordinates (Bohr) and species
| siesta: 5.66918** 5.66918 3 1
| siesta: 5.66918** 5.66918 3 2
| siesta: 5.66918** 7.55891 3 3
| siesta: 5.66918** 7.55891 3 4
| siesta: 3.77945** 9.44863 2 5
| siesta: 3.77945** 9.44863 2 6
| siesta: 1.88973** 9.44863 1 7
| siesta: 1.88973** 9.44863 1 8
| siesta: 0.0** 7.55891 0 9
| siesta: 0.0** 7.55891 0 10
| siesta: -0.0** 5.66918 0 11
| siesta: -0.0** 5.66918 0 12
| siesta: 0.0** 3.77945 0 13
| siesta: 0.0** 3.77945 0 14
| siesta: 1.88973** 1.88973 1 15
| siesta: 1.88973** 1.88973 1 16
| siesta: 3.77945** 1.88973 2 17
| siesta: 3.77945** 1.88973 2 18
| siesta: 5.66918** 3.77945 3 19
| siesta: 5.66918** 3.77945 3 20

| siesta: Automatic unit cell vectors (Ang):
| siesta: 5.813500 0.00 0.00
| siesta: 0.00 0.00
| siesta: 0.00 0.00 10.213500
| rcut: Wrong species 3. Have 1
| Stopping Program from Node: 0
| #0 0x7f1e771a8d21 in ???
| #1 0x7f1e771a97ad in ???
| #2 0x7f1e773fd38c in ???
| #3 0x562eeed87aca in ???
| #4 0x562eeeac6e83 in ???
| #5 0x562eeea4cd25 in ???
| #6 0x562eeea79d0b in ???
| #7 0x562eeea78277 in ???
| #8 0x562eee9bd74c in ???
| #9 0x7f1e76e24082 in __libc_start_main
| at ../csu/libc-start.c:308
| #10 0x562eee9bd81d in ???
| #11 0x in ???

| and this is the fdf file..

| # Created by GDIS version 0,90.0
| #

| SystemLabel nano55

| NumberOfAtoms 20

| NumberOfSpecies 1
| %block ChemicalSpeciesLabel
| 1 6 C
| %endblock ChemicalSpeciesLabel

| LatticeConstant 1.0 Ang
| %block LatticeVectors
| 7,312800 0,00 0,00
| -3,656400 6,3330705728 0,00
| 0,00 0,00 4,280600
| %endblock LatticeVectors

| AtomicCoordinatesFormat NotScaledCartesianAng
| %block AtomicCoordinatesAndAtomicSpecies
| 3,811431360 3,166535286 1,421159200 1
| 3,811431360 3,166535286 0,0 1
| 3,432628320 4,331820272 3,561459200 1
| 3,432628320 4,331820272 2,14030 1
| 2,441012640 5,052523703 1,421159200 1
| 2,441012640 5,052523703 0,0 1
| 1,215387360 5,052523703 3,561459200 1
| 1,215387360 5,052523703 2,14030 1
| 0,224502960 4,331820272 1,421159200 1
| 0,224502960 4,331820272 0,0 1
| -0,155031360 3,166535286 3,561459200 1
| -0,155031360 3,166535286 2,14030 1
| 0,223771680 2,001250301 1,421159200 1
| 0,223771680 2,001250301 0,0 1
| 1,215387360 1,280546870 3,561459200 1
| 1,215387360 1,280546870 2,14030 1
| 2,441012640 1,280546870 1,421159200 1
| 2,441012640 1,280546870 0,0 1
| 3,431897040 2,001250301 3,561459200 1
| 3,431897040 2,001250301 2,14030 1
| %endblock AtomicCoordinatesAndAtomicSpecies

| PAO.BasisType split
| PAO.BasisSize DZP

| SolutionMethod diagon

| Harris_functional false
| XC.functional LDA
| XC.Authors PZ
| SpinPolarized false
| MeshCutoff 100,00 Ry
| kgrid_cutoff 0,00 Bohr
| ElectronicTemperature 300,00 K
| MaxSCFIterations 50
| DM.NumberPulay 0
| DM.MixingWeight 0,25
| MD.TypeOfRun CG
| MD.VariableCell false
| MD.MaxCGDispl 0,20 Bohr
| MD.PreconditionVariableCell 5,00 Ang
| MD.MaxStressTol 1,00 GPa

| %block MD.TargetStress
| -1,00 -1,00 -1,00 0,00 0,00 0,00
| %endblock MD.TargetStress

| MD.MaxForceTol 0,04 eV/Ang
| MD.InitialTimeStep 1
| MD.FinalTimeStep 1
| MD.LengthTimeStep 1 fs
| MD.InitialTemperature 0,00 K
| MD.Quench false
| MD.TargetTemperature 0,00 K
| MD.NoseMass 100,00 Ry*fs**2
| MD.ParrinelloRahmanMass 100,00 Ry*fs**2
| MD.AnnealOption TemperatureandPressure
| MD.TauRelax 100,00 fs
| MD.BulkModulus 100,00 Ry/Bohr**3
| MD.TargetPressure 0,00 GPa
| MD.FCDispl 0,04 Bohr
| MD.FCfirst 1
| MD.FClast 0

| UseSaveData false
| WriteCoorInital true
| WriteCoorStep false
| WriteForces false
| WriteKpoints false
| WriteEigenvalues false
| WriteKbands false
| WriteBands false
| WriteWaveFunctions false
| WriteMullikenPop 0
| WriteDM true
| WriteCoorXmol false
| WriteCoorCerius false
| WriteMDXmol false
| WriteMDhistory true

| --
| SIESTA is supported by the Spanish Research Agency (AEI) and by the European
| H2020 MaX Centre of Excellence
| 

Re: [SIESTA-L] (Wrong block specification)

[Alberto Garcia]

Hi, 

You should remove the comment character from: 

#%endblock LatticeVectors 

Alberto 

- El 21 de Septiembre de 2022, a las 12:23, Amal Yassin 
 escribió: 

| Dear Siesta Users
| I make run to carbone nanotube armchair, but i find an error, can anyone helle
| me to solve this error? ( I added also fdf file here)

| FDF module: fdf_bline: block_fdf structure not initialized

| File: fdf.F90
| Line: 2803
| ** ** *
| STOP Stopping Program

| FDF file:
| SystemLabel arm

| NumberOfAtoms 12
| NumberOfSpecies 1

| %block ChemicalSpeciesLabel
| 1 6 C
| %endblock ChemicalSpeciesLabel

| LatticeConstant 1.0 Ang
| %block LatticeVectors
| 25.000 0.0 0.0
| 0.000 2.50108130 0.0
| 0. 25.0 0.0
| #%endblock LatticeVectors

| #%block LatticeParameters
| # 7,476200 7,476200 2,464300 90,00 90,00 120,00
| #%endblock LatticeParameters

| AtomicCoordinatesFormat Ang
| %block AtomicCoordinatesAndAtomicSpec ies
| 0,77620 0,5 0,0 1
| 0,81380 0,70610 0,0 1
| 0,77620 0,77620 0,5 1
| 0,60770 0,81380 0,5 1
| 0,5 0,77620 0,0 1
| 0,29390 0,60770 0,0 1
| 0,22380 0,5 0,5 1
| 0,18620 0,29390 0,5 1
| 0,22380 0,22380 0,0 1
| 0,39230 0,18620 0,0 1
| 0,5 0,22380 0,5 1
| 0,70610 0,39230 0,5 1
| %endblock AtomicCoordinatesAndAtomicSpec ies

| PAO.BasisType split
| PAO.BasisSize DZP
| PAO.EnergyShift 50 meV

| SolutionMethod diagon
| PAO.SplitNorm 0,15

| XC.functional LDA
| XC.Authors PZ
| SpinPolarized false
| MeshCutoff 300,00 Ry

| %block kgrid_Monkhorst_Pack
| 10 0 0 0.0
| 0 1 0 0.0
| 0 0 10 0.0
| %endblock kgrid_Monkhorst_Pack

| MD.MaxForceTol 0,005 eV/Ang
| MD.InitialTimeStep 1
| MD.FinalTimeStep 1
| MD.LengthTimeStep 1 fs
| MD.NumCGsteps 0
| MD.TypeOfRun CG
| DM.MixingWeight 0.02
| WriteCoorXmol true
| WriteMDXmol true
| WriteMullikenPop 1
| DM.NumberPulay 5
| ElectronicTemperature 300,00 K
| MaxSCFIterations 500
| DM.Tolerance 1.d-5
| SolutionMethod diagon
| TS.WriteHS true

| DM.UseSaveDM true
| UseSaveData true
| MD.UseSaveXV true
| MD.UseSaveCG true

| %block BandLines
| 1 0.0 0.0 0.0 \Gamma
| 50 0.0 0.0 0.5 X
| 100 0.0 0.0 0.0 \Gamma
| %endblock BandLines

| %block ProjectedDensityOfStates
| -30.00 20.00 0.2 1000 eV
| %endblock ProjectedDensityOfStates

| %block PAO.basis
| C 3 .35201
| n=2 0 2 E 50.37145 5.22551
| 5.43077 3.08484
| 1.0 1.0
| n=2 1 2 E 13.53326 6.81234
| 6.83094 3.01366
| 1.0 1.0
| n=2 2 1 E 110.78225 .01065
| 5.04748
| 1.0
| %endblock PAO.basis

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

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

Re: [SIESTA-L] (problems with polarization orbital when using Mg.psml)

[Rajesh_Dutta]

Dear Alberto,

Many thanks for the guidance. I was looking for that section (%block
PAO.PolarizationScheme) in the manual v. 4.1-b4 but couldn't find any.

However, I entered as you wrote and it worked, but it goes only for one CG
steps and ends.

Then I tried with "PAO.oldstylepolorbs to be false and it also worked but with
all given CG steps (for example in my case it was 20).  Here is the difference
in the result output file:

1st CASE:  Using %block PAO.PolarizationScheme
 Mg non-perturbative
%endblock PAO.PolarizationScheme >   it only make non-perturbative
polarization for Mg but not for O as obviously.

2nd CASE: , using PAO.OldStylePolOrbs F -> it makes perturbative
polarization orbitals for both Mg and O.

In both case Cut-off radius for the neutral-atom potential was   8.935841

For the 2nd case I found this line "cgvc: WARNING: CG file not found" before
starting the next CG move.
For the 1st case it was "iocg: Reading CG continuation file"  and there was
another line "cgvc: No target stress found, assuming hydrostatic
MD.TargetPressure." before writing the band energy which was absent for 2nd
case.

Why the 1st case ends after one CG move? BTW, there was difference in LUMO
band structure and also Fermi energy about 0.02 eV. So, use of
"PAO.OldStylePolOrbs   F" would be ok?

Best regards,
Rajesh

P.S:  I had another question to all of you. For example MgO where we have
Mg(2+) and (o2-) state. Should I generate pseudopotential with these oxidation
state (Mg- 1s2 2s2 2p6 and O - 1s2 2s2 2p6) or should I generate as neutral
atom (Mg- 1s2 2s2 2p6 3s2 and O - 1s2 2s2 2p4)? It has to be neutral atom for
PP generation always?





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

Re: [SIESTA-L] (problems with polarization orbital when using Mg.psml)

[Alberto Garcia]

Dear Rajesh, 

I quote from (the source of) the Siesta manual: 

\item The default perturbative scheme for polarization orbitals 
can fail in very specific cases. When the polarization orbital 
has to have a node due to the presence of a lower-lying orbital 
with the same $l$, the program can (if enabled by the 
\fdf{PAO!Polarization!NonPerturbative.Fallback} option) automatically switch to 
using a non-perturbative scheme. In other cases, include the 
\textit{Chemical\_label} in the following block to request a 
non-perturbative scheme: 

\begin{fdfexample} 
%block PAO.PolarizationScheme 
Mg non-perturbative 
%endblock PAO.PolarizationScheme 
\end{fdfexample} 

Please see the relevant section for a fuller explanation. 

- El 7 de Septiembre de 2022, a las 15:50, Rajesh Dutta 
 escribió: 

| Dear Fanmiao,

| Many thanks for the information, I exactly needed thatinfo.
| BTW, I was playing with different PP format (.psf and .psml) to have a test on
| result. Mg.psml downloaded from pseudo dojo through some following error:
| 
**
| POLgen: Perturbative polarization orbital with L= 1

| POLgen: Polarization orbital for state 3s
| POLARIZATION: Iteration to find the polarization
| orbital has failed !
| sys::die: Program terminated
| Stopping Program from Node: 0
| Please try with a Rc no bigger than 2.1037069778585620 Bohr
| sys::die: Program terminated
| Stopping Program from Node: 0
| 
**

| I guess I can not modify the downloaded psml file with smaller Rc as suggested
| by the program.

| Is there any way to modify or any input that I can give inside the Siesta to
| fix this error?

| Thanks and best regards,
| Rajesh

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

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

RE: [SIESTA-L] [***Posible SPAM***] RE: number of k-points in denchar

[Fanmiao Kong]

Dear Rajesh,

Sorry I have no idea about this error. I would also like to know if someone 
else can provide a solution.

Best,
Fanmiao

Fanmiao Kong
Department of Materials, Trinity College, University of Oxford
Tel: +44 (0)7529931806 / +86 13162054601
16 Parks Road, OX1 3PH, Oxford, UK

-Original Message-
From: Rajesh_Dutta  
Sent: 2022年9月7日 14:50
To: Fanmiao Kong ; siesta-l@uam.es
Subject: Re: [SIESTA-L] [***Posible SPAM***] RE: number of k-points in denchar

Dear Fanmiao,

Many thanks for the information, I exactly needed thatinfo.
BTW, I was playing with different PP format (.psf and .psml) to have a test on 
result. Mg.psml downloaded from pseudo dojo through some following error:
**
 POLgen: Perturbative polarization orbital with L=  1

POLgen: Polarization orbital for state 3s
 POLARIZATION: Iteration to find the polarization  orbital has failed !
sys::die: Program terminated
Stopping Program from Node:0
 Please try with a Rc no bigger than2.1037069778585620   Bohr
sys::die: Program terminated
Stopping Program from Node:0
**

I guess I can not modify the downloaded psml file with smaller Rc as suggested 
by the program.

Is there any way to modify or any input that I can give inside the Siesta to 
fix this error?

Thanks and best regards,
Rajesh


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

Re: [SIESTA-L] [***Posible SPAM***] RE: number of k-points in denchar

[Rajesh_Dutta]

Dear Fanmiao,

Many thanks for the information, I exactly needed thatinfo.
BTW, I was playing with different PP format (.psf and .psml) to have a test on
result. Mg.psml downloaded from pseudo dojo through some following error:
**
 POLgen: Perturbative polarization orbital with L=  1

POLgen: Polarization orbital for state 3s
 POLARIZATION: Iteration to find the polarization
 orbital has failed !
sys::die: Program terminated
Stopping Program from Node:0
 Please try with a Rc no bigger than2.1037069778585620   Bohr
sys::die: Program terminated
Stopping Program from Node:0
**

I guess I can not modify the downloaded psml file with smaller Rc as suggested
by the program.

Is there any way to modify or any input that I can give inside the Siesta to
fix this error?

Thanks and best regards,
Rajesh


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

[Andrei Postnikov]

Dear Amal Yassin: 
Your unit cell vectors are all zeros; 
your atom belongs to specie Nr zero (must be 1), 
and there seems to be a problem with its coordinate. 
All this is evident from your output file if you read it beyond the first line. 
The absence of XV file is just a warning; it's no problem 
if the structure is correctly defined in the input file. 

Good luck, 

Andrei Postnikov 

- Le 18 Aoû 22, à 22:18, Amal Yassin  a écrit : 

> Hello
> When i run the simulation of Carbone , i existe this error .
> Any Idea about this error , and how can resolve it ?!
> Please Help..

> Best regard

> siesta: WARNING: XV file not found

> siesta: Atomic coordinates (Bohr) and species
> siesta: 0.0** 3.77945 0 1

> siesta: Automatic unit cell vectors (Ang):
> siesta: 0.00 0.00 0.00
> siesta: 0.00 0.00 0.00
> siesta: 0.00 0.00 0.00
> rcut: Wrong species 0. Have 1
> Stopping Program from Node: 0
> #0 0x7f0bf0cdbd21 in ???
> #1 0x7f0bf0cdc7ad in ???
> #2 0x7f0bf0f3038c in ???
> #3 0x55c259359aca in ???
> #4 0x55c259098e83 in ???
> #5 0x55c25901ed25 in ???
> #6 0x55c25904bd0b in ???
> #7 0x55c25904a277 in ???
> #8 0x55c258f8f74c in ???
> #9 0x7f0bf0957082 in __libc_start_main
> at ../csu/libc-start.c:308
> #10 0x55c258f8f81d in ???
> #11 0x in ???

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

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

Re: [SIESTA-L] Installing Siesta GPU acclerated version

[Narendranath Ghosh]

Dear All,
Thank you very much for introducing me to a wonderful forum.
I am new in Siesta.
Please let me know how I calculate free energy change of a reaction, I am
interested in calculating free energy profile for CO2 reduction steps.
Thanks in advance.

Regards,
Dr. N N Ghsoh
University of Gour Banga
India-73211
‪Dr. NARENDRA NATH GHOSH‬ - ‪Google Scholar‬




On Fri, Jul 1, 2022 at 1:31 AM Mohammed Ghadiyali <
mohammed.ghadiy...@kaust.edu.sa> wrote:

> Hello,
>
> Thanks for the information, I’ll try to install it as per the instructions
> provided.
>
> Regards,
> Ghadiyali Mohammed Kader
> Post Doctoral Fellow
> King Abdullah University of Science and Technology
> On 29 Jun 2022, 11:06 PM +0300, Alberto Garcia , wrote:
>
> Hello,
>
> We are writing a section on GPUs in the documentation, but until it is
> ready you can use the ideas below:
>
>
> There are two ways to take advantage of GPUs (enabled only for the solver
> stage, which typically takes up the most time):
>
> -- Using the ELPA library and its native interface in Siesta (this method
> is available for Siesta versions 4.1.5 and up)
>
> -- Using the ELSI library (for Siesta "MaX" versions
> (see the Guide to Siesta Versions in
> https://urldefense.com/v3/__https://gitlab.com/siesta-project/siesta/-/wikis/Guide-to-Siesta-versions__;!!Nmw4Hv0!zoGYljExKqs1b-VkrSmFhJ6futBuvXnhXa2RrwwV6TwhqqPzKFcb7n5hg1lr7CF5rT0insiOyeJscp-ZjrM4f0RLn3Di2A$
> )
>
> In both cases the special installation instructions involve only enabling
> GPU support in either ELPA or ELSI, and using the proper options in Siesta.
>
> For the first method the fdf options to enable GPUs are (example):
>
> diag-algorithm elpa-2
> diag-elpa-usegpu T
> diag-blocksize 16
> # Optional
> number-of-eigenstates 17320
> use-tree-timer T
>
>
> For the second (ELSI) method:
>
> solution-method elsi
> elsi-solver elpa
> elsi-elpa-gpu 1
> elsi-elpa-flavor 2
>
> # Optional
> number-of-eigenstates 17320
> use-tree-timer T
> elsi-output-level 3
>
> The installation of ELPA and ELSI with GPU support is system-specific, but
> you can get inspiration from the following examples:
>
> * ELPA (on Marconi-100 at CINECA, with IBM P9 chips and nVidia A100 GPUs,
> using the gcc compiler):
>
> Script to configure:
>
> #!/bin/sh
>
> # (Need to define properly the symbols used below)
> # Note that the P9 does not use the typical Intel kernels
>
> FC=mpifort CC=mpicc CXX=mpic++ \
> CFLAGS="-O3 -mcpu=native -std=c++11" \
> FCFLAGS="-O3 -mcpu=native -ffree-line-length-none"
> LDFLAGS="${SCALAPACK_LIBS} ${LAPACK_LIBS}" \
> ../configure \
> --with-cuda-path=${CUDA_HOME} \
> --with-cuda-sdk-path=${CUDA_HOME} \
> --enable-nvidia-gpu --with-NVIDIA-GPU-compute-capability=sm_70 \
> --enable-NVIDIA-gpu-memory-debug --enable-nvtx \
> --disable-sse-assembly --disable-sse --disable-avx --disable-avx2
> --disable-avx512 \
> --enable-c-tests=no --prefix=$PRJ/bin/gcc/elpa/2021.05.002.jul22
>
>
> (Adapt the options to your system)
>
> * ELSI
>
> SET(CMAKE_INSTALL_PREFIX "$ENV{BASE_DIR}/elsi/2.6.2" CACHE STRING
> "Installation dir")
>
> SET(CMAKE_Fortran_COMPILER "mpif90" CACHE STRING "MPI Fortran compiler")
> SET(CMAKE_C_COMPILER "mpicc" CACHE STRING "MPI C compiler")
> SET(CMAKE_CXX_COMPILER "mpicxx" CACHE STRING "MPI C++ compiler")
>
> SET(CMAKE_Fortran_FLAGS "-O2 -g -fbacktrace -fdump-core" CACHE STRING
> "Fortran flags")
> SET(CMAKE_C_FLAGS "-O2 -g -std=c99" CACHE STRING "C flags")
> SET(CMAKE_CXX_FLAGS "-O2 -g -std=c++11" CACHE STRING "C++ flags")
> SET(CMAKE_CUDA_FLAGS "-O3 -arch=sm_70 -std=c++11" CACHE STRING "CUDA
> flags")
> # Workaround: specify -std=c++11 in CMAKE_CUDA_FLAGS to avoid __ieee128
> gcc/cuda bug
>
> SET(USE_GPU_CUDA ON CACHE BOOL "Use CUDA-based GPU acceleration in ELPA")
> SET(ENABLE_PEXSI ON CACHE BOOL "Enable PEXSI")
> SET(ENABLE_TESTS ON CACHE BOOL "Enable tests")
> #SET(ADD_UNDERSCORE OFF CACHE BOOL "Do not suffix C functions with an
> underscore")
>
> SET(LIB_PATHS
> "/cineca/prod/opt/libraries/lapack/3.9.0/gnu--8.4.0/lib;/cineca/prod/opt/libraries/scalapack/2.1.0/spectrum_mpi--10.3.1--binary/lib;/cineca/prod/opt/compilers/cuda/11.0/none/lib64;/cineca/prod/opt/libraries/essl/6.2.1/binary/lib64"
> CACHE STRING "External library paths")
>
> SET(LIBS "scalapack;lapack;essl;cublas;cudart" CACHE STRING "External
> libraries")
> You should modify appropriately the location and version numbers of your
> libraries.
>
> Finally, a note about the importance of the proper execution incantation,
> for "pinning" the MPI ranks to the appropriate GPU:
>
> (There are probably better and more streamlined ways to do this)
>
> For this example I use the 32 cores (2x16) in Marconi for MPI tasks, no
> OpenMP, and do not take advantage of the 4x hyperthreading.
>
> The slurm script I typically use is: (gcc_env et al are my own Lmod
> modules)
>
> =
> #!/bin/bash
> #SBATCH 

Re: [SIESTA-L] Question about Gate in SIESTA

[肖威]

Dear Nick Papior,
Thank you very much for your reply. Please take a moment to see if I 
misunderstood your response. As shown in the comments section below (red font) :
1. Please confirm whether the comments in red font below are correct. This will 
help me a lot.
%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
(comment) : In the above example, (1.0 1.0 1.0) is the starting point of the 
normal vector and (1.0 0.5 0.2) is the end point of the normal vector. Since it 
is an infinite plane, the length of the normal vector can be arbitrary.
%block Geometry.Hartree
square 1. eV # The lifting potential on the geometry
delta
1.0 1.0 1.0 Ang # The starting point of the square
2.0 0.5 0.2 Ang # The first spanning vector
0.0 2.5 0.2 Ang # The second spanning vector
%endblock Geometry.Hartree
(comment) : In the above example, (1.0 1.0 1.0) is the starting point of the 
first and second spanning vectors, and (2.0 0.5 0.2) (0.0 2.5 0.2) is the end 
point of the first and second spanning vectors, respectively. The first and 
second spanning vectors form a parallelogram. The lengths of the first and 
second spanning vectors determine the area of the parallelogram, which is the 
size of the square.
%block Geometry.Hartree
box 1. eV # The lifting potential on the geometry
delta
1.0 1.0 1.0 Ang # Origo of the box
2.0 0.5 0.2 Ang # The first spanning vector
0.0 2.5 0.2 Ang # The second spanning vector
0.0 0.5 3.2 Ang # The third spanning vector
%endblock Geometry.Hartree
(comment) : In the example above (1.0 1.0 1.0) is the starting point of the 
first, second, and third spanning vectors. (2.0 0.5 0.2) (0.0 2.5 0.2) (0.0 0.5 
3.2) are the end points of the first, second and third spanning vectors 
respectively. The three spanning vectors form a parallelepiped. The lengths of 
the three spanning vectors determine the volume of the parallelepiped, which is 
the volume of the box.
2. As for your reply "The most simple thing is (if you don't have periodicity 
along the field generated by the gate) to add a slab dipole correction, and add 
vacuum corresponding to 1.5 times the distance between your structure and the 
gate. ", I do not understand how long the vacuum layer between the structure 
and the gate is appropriate.
I am looking forward to your reply again.
Thank you very much!
Wei




| |
肖威
|
|
xiaowei951...@163.com
|
On 7/25/2022 04:00，Nick Papior wrote：
Hi, 


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


Dear SIESTA developers and users,

I recently read Papior et al. 's article on Phys. Chem. Chem. Phys. entitled 
"Manipulating the voltage drop in graphene nanojunctions using a gate potential 
(DOI: 10.1039/C5CP04613K)". I am very interested in the method of adding gate 
voltage to a system in this article and try to learn how to use it. However, I 
have encountered some difficulties in the process, and I'm really looking 
forward to some help. 

1. When I use the square (Bounded plane) option in Gate, I need to set the 
starting point of the square and two spanning vectors. As shown below (copied 
from the SIESTA 4.1-b4 manual).

%block Geometry.Hartree

square 1. eV  # The lifting potential on the geometry

gauss 1. 2. Ang  # the std. and the cut-off length

1.0  1.0  1.0  Ang  # The starting point of the square

2.0  0.5  0.2  Ang  # The first spanning vector

0.0  2.5  0.2  Ang  # The second spanning vector

%endblock Geometry.Hartree

But we all know that two points define a vector, so do the coordinates that 
define the spanning vector in the example above represent the end point of the 
vector? If so, what is the starting point of this spanning vector? Is the 
spanning vector starting at the origin (0  0  0) or at the starting point of 
the square (1.0  1.0  1.0) defined in the example above?

I have the same question about plane (Infinite plane, a vector) and Box (three 
vectors) in Gate.



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






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



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


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

I'm really looking forward to some help.

Thank you very much!

Wei



| |
肖威
|
|
xiaowei951...@163.com
|

--
SIESTA is supported by the Spanish Research Agency (AEI) and by the European 

Re: [SIESTA-L] Question about Gate in SIESTA

[Nick Papior]

Hi,

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

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

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


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

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

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

> I'm really looking forward to some help.
>
> Thank you very much!
>
> Wei
>
> 肖威
> xiaowei951...@163.com
>
> 
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

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

Re: [SIESTA-L] TBtrans and broadening matrix

[Aleksandar Tomovic]

Hi,

thank you very much for provided material!

Kind regards,

Aleksandar Tomovic


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

Re: [SIESTA-L] TBtrans and broadening matrix

[Nick Papior]

Hi,

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

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

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

Hope this helps.

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

> Dear all,
>
> I'm interested in finding the coupling of my device with the L/R
> electrode.
> In the paper "Improvements on non-equilibrium and transport Green
> function techniques: The next-generation transiesta" there is a sentence
> that says that tbtrans saves all scalar quantities ⟨Mj|Γ L|Mj′ ⟩.
> However, after reviewing TBtrans manual chapter related to projected
> transmission and sisl documentation on tbtprojncSileTBtrans, I was still
> unable to retrieve that information. I would appreciate any hints that
> you could provide.
>
> Kind regards,
>
> Aleksandar Tomovic
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>


-- 
Kind regards Nick

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

Re: [SIESTA-L] Installing Siesta GPU acclerated version

[Mohammed Ghadiyali]

Hello,

Thanks for the information, I’ll try to install it as per the instructions 
provided.

Regards,
Ghadiyali Mohammed Kader
Post Doctoral Fellow
King Abdullah University of Science and Technology
On 29 Jun 2022, 11:06 PM +0300, Alberto Garcia , wrote:
> Hello,
>
> We are writing a section on GPUs in the documentation, but until it is ready 
> you can use the ideas below:
>
>
> There are two ways to take advantage of GPUs (enabled only for the solver 
> stage, which typically takes up the most time):
>
> -- Using the ELPA library and its native interface in Siesta (this method is 
> available for Siesta versions 4.1.5 and up)
>
> -- Using the ELSI library (for Siesta "MaX" versions
> (see the Guide to Siesta Versions in 
> https://urldefense.com/v3/__https://gitlab.com/siesta-project/siesta/-/wikis/Guide-to-Siesta-versions__;!!Nmw4Hv0!zoGYljExKqs1b-VkrSmFhJ6futBuvXnhXa2RrwwV6TwhqqPzKFcb7n5hg1lr7CF5rT0insiOyeJscp-ZjrM4f0RLn3Di2A$
>  )
>
> In both cases the special installation instructions involve only enabling GPU 
> support in either ELPA or ELSI, and using the proper options in Siesta.
>
> For the first method the fdf options to enable GPUs are (example):
>
> diag-algorithm elpa-2
> diag-elpa-usegpu T
> diag-blocksize 16
> # Optional
> number-of-eigenstates 17320
> use-tree-timer T
>
>
> For the second (ELSI) method:
>
> solution-method elsi
> elsi-solver elpa
> elsi-elpa-gpu 1
> elsi-elpa-flavor 2
>
> # Optional
> number-of-eigenstates 17320
> use-tree-timer T
> elsi-output-level 3
>
> The installation of ELPA and ELSI with GPU support is system-specific, but 
> you can get inspiration from the following examples:
>
> * ELPA (on Marconi-100 at CINECA, with IBM P9 chips and nVidia A100 GPUs, 
> using the gcc compiler):
>
> Script to configure:
>
> #!/bin/sh
>
> # (Need to define properly the symbols used below)
> # Note that the P9 does not use the typical Intel kernels
>
> FC=mpifort CC=mpicc CXX=mpic++ \
> CFLAGS="-O3 -mcpu=native -std=c++11" \
> FCFLAGS="-O3 -mcpu=native -ffree-line-length-none" LDFLAGS="${SCALAPACK_LIBS} 
> ${LAPACK_LIBS}" \
> ../configure \
> --with-cuda-path=${CUDA_HOME} \
> --with-cuda-sdk-path=${CUDA_HOME} \
> --enable-nvidia-gpu --with-NVIDIA-GPU-compute-capability=sm_70 \
> --enable-NVIDIA-gpu-memory-debug --enable-nvtx \
> --disable-sse-assembly --disable-sse --disable-avx --disable-avx2 
> --disable-avx512 \
> --enable-c-tests=no --prefix=$PRJ/bin/gcc/elpa/2021.05.002.jul22
>
>
> (Adapt the options to your system)
>
> * ELSI
>
> SET(CMAKE_INSTALL_PREFIX "$ENV{BASE_DIR}/elsi/2.6.2" CACHE STRING 
> "Installation dir")
>
> SET(CMAKE_Fortran_COMPILER "mpif90" CACHE STRING "MPI Fortran compiler")
> SET(CMAKE_C_COMPILER "mpicc" CACHE STRING "MPI C compiler")
> SET(CMAKE_CXX_COMPILER "mpicxx" CACHE STRING "MPI C++ compiler")
>
> SET(CMAKE_Fortran_FLAGS "-O2 -g -fbacktrace -fdump-core" CACHE STRING 
> "Fortran flags")
> SET(CMAKE_C_FLAGS "-O2 -g -std=c99" CACHE STRING "C flags")
> SET(CMAKE_CXX_FLAGS "-O2 -g -std=c++11" CACHE STRING "C++ flags")
> SET(CMAKE_CUDA_FLAGS "-O3 -arch=sm_70 -std=c++11" CACHE STRING "CUDA flags")
> # Workaround: specify -std=c++11 in CMAKE_CUDA_FLAGS to avoid __ieee128 
> gcc/cuda bug
>
> SET(USE_GPU_CUDA ON CACHE BOOL "Use CUDA-based GPU acceleration in ELPA")
> SET(ENABLE_PEXSI ON CACHE BOOL "Enable PEXSI")
> SET(ENABLE_TESTS ON CACHE BOOL "Enable tests")
> #SET(ADD_UNDERSCORE OFF CACHE BOOL "Do not suffix C functions with an 
> underscore")
>
> SET(LIB_PATHS 
> "/cineca/prod/opt/libraries/lapack/3.9.0/gnu--8.4.0/lib;/cineca/prod/opt/libraries/scalapack/2.1.0/spectrum_mpi--10.3.1--binary/lib;/cineca/prod/opt/compilers/cuda/11.0/none/lib64;/cineca/prod/opt/libraries/essl/6.2.1/binary/lib64"
>  CACHE STRING "External library paths")
>
> SET(LIBS "scalapack;lapack;essl;cublas;cudart" CACHE STRING "External 
> libraries")
> You should modify appropriately the location and version numbers of your 
> libraries.
>
> Finally, a note about the importance of the proper execution incantation, for 
> "pinning" the MPI ranks to the appropriate GPU:
>
> (There are probably better and more streamlined ways to do this)
>
> For this example I use the 32 cores (2x16) in Marconi for MPI tasks, no 
> OpenMP, and do not take advantage of the 4x hyperthreading.
>
> The slurm script I typically use is: (gcc_env et al are my own Lmod modules)
> =
> #!/bin/bash
> #SBATCH --job-name=test-covid
> #SBATCH --account=Pra19_MaX_1
> #SBATCH --partition=m100_usr_prod
> #SBATCH --output=mpi_%j.out
> #SBATCH --error=mpi_%j.err
> #SBATCH --nodes=8
> #SBATCH --ntasks-per-node=32
> #SBATCH --ntasks-per-socket=16
> #SBATCH --cpus-per-task=4
> #SBATCH --gres=gpu:4
> #SBATCH --time=00:19:00
>
> #
> ml purge
> ml gcc_env
> ml siesta-max/1.0-14
> #
> date
> which siesta
> echo "---"
> #
> export OMP_NUM_THREADS=1
> #
> mpirun --map-by socket:PE=1 --rank-by core --report-bindings \
> -np ${SLURM_NTASKS} 

Re: [SIESTA-L] Question on VCA approach

[Alberto Garcia]

Hi Roberto,

The first reference is the closest in spirit, except that we incorporate the 
mix as the pseudopotential of a new "alchemical" species
instead of keeping separate "pure" ghost atoms and using a weight factor for 
each.

The second reference imposes extra conditions on the pseudopotential of the 
alchemical species.

  Best regards,

  Alberto


- El 28 de Junio de 2022, a las 14:09, RCP pasia...@cnea.gov.ar escribió:

| Dear developers,
| 
| I'd like to know if there is a specific reference for the method
| of mixing pseudopotentials implemented in the VCA mixps utility.
| Are general refs. such as these two below suitable?
|  L. Bellaiche & D. Vanderbilt, Phys. Rev. B 61(12), 7877 (2000)
|  N.J. Ramer & A.M. Rappe, J. Phys. Chem. Solids 61, 315 (2000)
| 
| Thanks a lot,
| 
| Roberto P
| 
| 
| --
| SIESTA is supported by the Spanish Research Agency (AEI) and by the European
| H2020 MaX Centre of Excellence (http://www.max-centre.eu/)

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

Re: [SIESTA-L] Installing Siesta GPU acclerated version

[Alberto Garcia]

Hello,

We are writing a section on GPUs in the documentation, but until it is ready 
you can use the ideas below:


There are two ways to take advantage of GPUs (enabled only for the solver 
stage, which typically takes up the most time):

-- Using the ELPA library and its native interface in Siesta (this method is 
available for Siesta versions 4.1.5 and up)

-- Using the ELSI library (for Siesta "MaX" versions 
 (see the Guide to Siesta Versions in 
https://gitlab.com/siesta-project/siesta/-/wikis/Guide-to-Siesta-versions)

In both cases the special installation instructions involve only enabling GPU 
support in either ELPA or ELSI, and using the proper options in Siesta.

For the first method the fdf options to enable GPUs are (example):

diag-algorithm elpa-2
diag-elpa-usegpu T
diag-blocksize 16
# Optional
number-of-eigenstates 17320
use-tree-timer T


For the second (ELSI) method: 

solution-method elsi
elsi-solver elpa
elsi-elpa-gpu 1
elsi-elpa-flavor 2

# Optional 
number-of-eigenstates 17320
use-tree-timer T
elsi-output-level 3

The installation of ELPA and ELSI with GPU support is system-specific, but you 
can get inspiration from the following examples:

* ELPA (on Marconi-100 at CINECA, with IBM P9 chips and nVidia A100 GPUs, using 
the gcc compiler):

Script to configure:

#!/bin/sh

# (Need to define properly the symbols used below)   
# Note that the P9 does not use the typical Intel kernels

FC=mpifort CC=mpicc CXX=mpic++ \
CFLAGS="-O3 -mcpu=native -std=c++11" \
FCFLAGS="-O3 -mcpu=native -ffree-line-length-none" 
LDFLAGS="${SCALAPACK_LIBS} ${LAPACK_LIBS}" \
../configure \
--with-cuda-path=${CUDA_HOME} \
--with-cuda-sdk-path=${CUDA_HOME} \
--enable-nvidia-gpu --with-NVIDIA-GPU-compute-capability=sm_70 \
--enable-NVIDIA-gpu-memory-debug  --enable-nvtx  \
--disable-sse-assembly --disable-sse --disable-avx --disable-avx2 
--disable-avx512 \
--enable-c-tests=no --prefix=$PRJ/bin/gcc/elpa/2021.05.002.jul22


(Adapt the options to your system)

* ELSI

SET(CMAKE_INSTALL_PREFIX "$ENV{BASE_DIR}/elsi/2.6.2" CACHE STRING "Installation 
dir")

SET(CMAKE_Fortran_COMPILER "mpif90" CACHE STRING "MPI Fortran compiler")
SET(CMAKE_C_COMPILER "mpicc" CACHE STRING "MPI C compiler")
SET(CMAKE_CXX_COMPILER "mpicxx" CACHE STRING "MPI C++ compiler")

SET(CMAKE_Fortran_FLAGS "-O2 -g -fbacktrace -fdump-core" CACHE STRING "Fortran 
flags")
SET(CMAKE_C_FLAGS "-O2 -g -std=c99" CACHE STRING "C flags")
SET(CMAKE_CXX_FLAGS "-O2 -g -std=c++11" CACHE STRING "C++ flags")
SET(CMAKE_CUDA_FLAGS "-O3 -arch=sm_70 -std=c++11" CACHE STRING "CUDA flags")
# Workaround: specify -std=c++11 in CMAKE_CUDA_FLAGS to avoid __ieee128 
gcc/cuda bug

SET(USE_GPU_CUDA ON CACHE BOOL "Use CUDA-based GPU acceleration in ELPA")
SET(ENABLE_PEXSI ON CACHE BOOL "Enable PEXSI")
SET(ENABLE_TESTS ON CACHE BOOL "Enable tests")
#SET(ADD_UNDERSCORE OFF CACHE BOOL "Do not suffix C functions with an 
underscore")

SET(LIB_PATHS 
"/cineca/prod/opt/libraries/lapack/3.9.0/gnu--8.4.0/lib;/cineca/prod/opt/libraries/scalapack/2.1.0/spectrum_mpi--10.3.1--binary/lib;/cineca/prod/opt/compilers/cuda/11.0/none/lib64;/cineca/prod/opt/libraries/essl/6.2.1/binary/lib64"
 CACHE STRING "External library paths")

SET(LIBS "scalapack;lapack;essl;cublas;cudart" CACHE STRING "External 
libraries")
You should modify appropriately the location and version numbers of your 
libraries.

Finally, a note about the importance of the proper execution incantation, for 
"pinning" the MPI ranks to the appropriate GPU:

(There are probably better and more streamlined ways to do this)

For this example I use the 32 cores (2x16) in Marconi for MPI tasks, no OpenMP, 
and do not take advantage of the 4x hyperthreading.

The slurm script I typically use is:  (gcc_env et al are my own Lmod modules)
=
#!/bin/bash
#SBATCH --job-name=test-covid
#SBATCH --account=Pra19_MaX_1
#SBATCH --partition=m100_usr_prod
#SBATCH --output=mpi_%j.out
#SBATCH --error=mpi_%j.err
#SBATCH --nodes=8
#SBATCH --ntasks-per-node=32
#SBATCH --ntasks-per-socket=16
#SBATCH --cpus-per-task=4
#SBATCH --gres=gpu:4
#SBATCH --time=00:19:00

#
ml purge
ml gcc_env
ml siesta-max/1.0-14
#
date
which siesta
echo "---"
#
export OMP_NUM_THREADS=1
#
mpirun --map-by socket:PE=1 --rank-by core --report-bindings \
   -np ${SLURM_NTASKS} ./gpu_bind.sh \
   siesta covid.fdf
=

The crucial part is the gpu_bind.sh script, which contains code to make sure 
that each socket
talks to the right GPUs (1st socket, GPU0/GPU1), 2nd socket, GPU2/GPU3), and 
within each socket, the first 8 tasks
use GPU0/2 and the second group of 8 tasks use GPU1/3. For this, the tasks have 
to be ordered. (This is specific to Marconi). I found that using
the
  
   --map-by socket:PE=1 --rank-by-core

incantation I could achieve that ordering. 

The