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

[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!Rkn1x3TU0j53Ix6xXXF7kYhYKQlJKWYK6uHzjjHvggVdN1_pL0Z0UcoPpBBKjS7nQVNPM2lq6XI0$
 ) and latest LibXC
library version 6.2.2 
(https://urldefense.com/v3/__https://libxc.gitlab.io/download/__;!!D9dNQwwGXtA!Rkn1x3TU0j53Ix6xXXF7kYhYKQlJKWYK6uHzjjHvggVdN1_pL0Z0UcoPpBBKjS7nQVNPM3BcCan2$
 ).

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

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

[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!VOGt5kWpn38naMamN5vxacrTLjXzrNYdt0gtGFQ0EGeJmjEtgFT3DtAW0bO9FZkpuDXl_S0UzN5v$
 
   )
   - AiiDA 
(https://urldefense.com/v3/__https://www.aiida.net/index.html__;!!D9dNQwwGXtA!VOGt5kWpn38naMamN5vxacrTLjXzrNYdt0gtGFQ0EGeJmjEtgFT3DtAW0bO9FZkpuDXl_YxLsIYn$
 )
   - SISL 
(https://urldefense.com/v3/__https://zerothi.github.io/sisl/__;!!D9dNQwwGXtA!VOGt5kWpn38naMamN5vxacrTLjXzrNYdt0gtGFQ0EGeJmjEtgFT3DtAW0bO9FZkpuDXl_VWm39bn$
 )


[]'s,
Camps

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

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]

[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] << two set of charge calculations >>

[I. Camps]

I completely agree with Tamas and Emilio BUT my question *is not* related
to which charge calculation scheme is "better".

My question is that in my calculations, two different sets of data of the
same type of charges are appearing in the output file, instead only one for
each. I have two outputs for Hirshfeld and two outputs for Voronoi charges.

[]'s,

Camps


On Mon, Jun 20, 2022 at 5:02 PM Emilio Artacho 
wrote:

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

Re: [SIESTA-L] << two set of charge calculations >>

[I. Camps]

> cite: Please see "h2o.bib" for an exhaustive BiBTeX file.
> [...]
>
> in which one gets two blocks, one for Voronoi and another one for
> Hirshfeld populations.
>
>   Alberto
>
>
> - El 14 de Junio de 2022, a las 22:18, I. Camps ica...@gmail.com
> escribió:
>
> | Hello,
> |
> | I set my input to calculate and export the charges using Voronoi, Bader
> and
> | Hirshfeld approaches.
> |
> | My output has at the end two sets, one after the energy
> decomposition/final
> | energy/etc. section, and then after some info about Bader/Vacuum
> level/LDOS
> | info.
> |
> | Both sets return different charges.
> |
> | My questions are:
> | - Why two sets of charges?
> | - Which one is the "good" one?
> |
> | []'s,
> |
> | Camps
> |
> |
> | --
> | SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European
> | H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

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

[SIESTA-L] << two set of charge calculations >>

[I. Camps]

Hello,

I set my input to calculate and export the charges using Voronoi, Bader and
Hirshfeld approaches.

My output has at the end two sets, one after the energy decomposition/final
energy/etc. section, and then after some info about Bader/Vacuum level/LDOS
info.

Both sets return different charges.

My questions are:
- Why two sets of charges?
- Which one is the "good" one?

[]'s,

Camps

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

[SIESTA-L] << One fdf, several serial calculations >>

[I. Camps]

Hello SIESTers,,

I just read somewhere (but don't remember where) that you can use one FDF
input for running sequential calculations.

Is it possible or is my memory playing me a trick?

[]'s,

Camps

PS: by sequential calculations I mean something like this:

- first run only a geometry optimization.
- then use the output from the geometry optimization and run some
calculations.

Or
- run a geometry optimization using PBE
- use the output optimized geometry an run another geometry optimization
using vdW

-- 
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] Tools for extracting band gap?

[I. Camps]

Maybe this can help (SISL documentation):
https://zerothi.github.io/sisl/visualization/viz_module/showcase/BandsPlot.html?highlight=band

[]'s,

Camps


On Tue, Jan 25, 2022 at 6:04 PM El-abed Haidar 
wrote:

> Good afternoon all,
>
> I was wondering how do you usually extract the band gap when using sisl? I
> could not find it ☹
>
>
>
>
>
> Cheers,
>
> EL-Abed
>
>
>
> El-Abed Haidar | Doctor of Philosophy (Science)
> Condensed Matter Theory (CMT) Group| School of Physics
> THE UNIVERSITY OF SYDNEY | NSW | 2006
>
>
>
> *From: *I. Camps 
> *Sent: *Tuesday, 25 January 2022 8:06 AM
> *To: *siesta-l@uam.es
> *Subject: *Re: [SIESTA-L] Tools for extracting band gap?
>
>
>
> Hello Danny,
>
>
>
> You can double-check (triple check?) using tools like:
>
> - SISL: https://github.com/zerothi/sisl
> <https://protect-au.mimecast.com/s/HJ7NCP7LAXfKgn3wWUzpJVO?domain=github.com>
> and
>
> - GUI4dft: https://github.com/sozykinsa/GUI4dft
> <https://protect-au.mimecast.com/s/OB4ECQnMBZfkVLoQOfPKYtw?domain=github.com>
>
>
>
> I used the three for a little bit. Both SISL and GUI4dft can manage spin
> polarized system but SIESTA-Shell-Tools don't (at least I didn't find how).
>
>
>
> []'s,
>
> Camps
>
>
>
>
>
> On Fri, Jan 14, 2022 at 6:02 PM Daniel Bennett  wrote:
>
> Dear siesta users,
>
>
>
> Does anybody know of any existing tools for extracting the band gap from
> the *.bands file? I tried using the calc_gap utility from
> https://github.com/caiovincius/SIESTA-Shell-Tools
> <https://protect-au.mimecast.com/s/RpGXCROND2uvYX56EiPY_bA?domain=github.com>
> , but it is giving me a nonzero gap in systems which I can clearly see are
> metallic by plotting the band structure.
>
>
>
> Thanks,
>
>
>
> Danny Bennett
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/
> <https://protect-au.mimecast.com/s/LhzzCVARKgCxB8gJ3TJBLkl?domain=max-centre.eu/>
> )
>
>
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

-- 
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] Tools for extracting band gap?

[I. Camps]

Hello Danny,

You can double-check (triple check?) using tools like:
- SISL: https://github.com/zerothi/sisl and
- GUI4dft: https://github.com/sozykinsa/GUI4dft

I used the three for a little bit. Both SISL and GUI4dft can manage spin
polarized system but SIESTA-Shell-Tools don't (at least I didn't find how).

[]'s,

Camps


On Fri, Jan 14, 2022 at 6:02 PM Daniel Bennett  wrote:

> Dear siesta users,
>
> Does anybody know of any existing tools for extracting the band gap from
> the *.bands file? I tried using the calc_gap utility from
> https://github.com/caiovincius/SIESTA-Shell-Tools , but it is giving me a
> nonzero gap in systems which I can clearly see are metallic by plotting the
> band structure.
>
> Thanks,
>
> Danny Bennett
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

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

[SIESTA-L] << Hot to plot NetCDF data files produced with SIESTA? >>

[I. Camps]

Hello SIESTers,,

I was wondering how I can plot the NetCDF data produced with SIESTA.

I have the following files:
- BaderCharge.grid.nc
- Chlocal.grid.nc
- DeltaRho.grid.nc
- ElectrostaticPotential.grid.nc
- Rho.grid.nc
- RhoXC.grid.nc
- TotalCharge.grid.nc
- TotalPotential.grid.nc

Regards,
I already tried with two suggestions from here
, but both
recommendations failed.

Camps

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

[SIESTA-L] << Output wavefunctions: all vs selected >>

[I. Camps]

Hello SIESTERs,

I want to plot the wavefunctions related to HOMO/LUMO. Also, I want to do
COOP analysis.

>From the SIESTA manual, I can setup to write the wavefunctions associated
to a set of bands or selecting them by energy:


*"The user can optionally request that the wavefunctions corresponding to
the computed bands bewritten to file. They are written to the
SystemLabel.bands.WFSX file."*

and





*"The user can optionally request that specific wavefunctions are written
to file. These wavefunctionsare re-computed after the geometry loop (if
any) finishes, using the last (presumably converged)density matrix produced
during the last self-consistent field loop (after a final mixing). They
arewritten to the SystemLabel.selected.WFSX file.*


*Note that the complete set of wavefunctions obtained during the last
iteration of the SCF loop willbe written to SystemLabel.fullBZ.WFSX if the
COOP.Write option is in effect."*

I am using the following keywords:
WFS.Write.For.Bands T
COOP.Write  T
WriteEigenvaluesT
WriteKbands T
WriteBands  T
WriteWaveFunctions  T

The results are two files a SystemLabel.fullBZ.WFSX with ~800MB and a
SystemLabel.bands.WFSX with 14GB.

Some doubts:
1-) If you let the number of bands and energy intervals to default, these
two files should not be the same?
2-) Which one should I use to plot the wavefunctions corresponding to
eigenvalues around the Fermi energy?

Thanks in advance.

PS: This question was also posted in
https://mattermodeling.stackexchange.com/ forum.

[]'s,

Camps

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

Re: [SIESTA-L] << SCF convergence issues >>

[I. Camps]

Thank you Tamas.

I will go through your recommendations carefully.

[]'s,

Camps


On Wed, Aug 25, 2021 at 5:00 PM Tamas Karpati  wrote:

> Dear I. Camps,
>
> Sorry for the late answer, just read your message now.
>
>
> I guess the "SpinPolatized T" line is not sufficient in itself.
> Try several values for Spin.Total as well (the optimal value might be
> sensitive to your actual structures) and check in the outputs the
> (seemingly automatically set) value of Spin.Fix too.
> Set Spin.Fix in the FDF if necessary.
>
> NOTE-1: I may use another version of SIESTA (4.1.5), as I specify
> "Spin polarized" rather than SpinPolarized T".  I hope you can find
> Spin.Total or its equivalent in your SW version, too.
>
> NOTE-2: I'm new to SIESTA, thus I do not know whether the minimum
> energy spin multiplicity is found by SIESTA automatically, or not.
> If yes, just make sure it does so (settings). If not, scan them
> .
>
> SCF is sensitive to the reliability of the applied multiplicity,
> while default mixer params work in most cases (or weight=0.1, history=8).
> On the other hand, DFT is a single configuration theory and you can
> introduce a little static correlation like improvement by using nonzero
> ElectronicTemperature (eg. 300 K or more). Too much of it, I believe,
> is not reliable. Try as low as enough for the SCF to converge
> in ALL of your simulations (affects Etot thus heat of reactions, as well).
> I think it is OK up to 1500 K or so.
>
>
> In addition, consider the appropriate spin multiplicities to be applied
> for the pure Ni structures in accordance with the other structures of
> your project,
> as eg. heats of reactions and other derived data should be reliable, too.
> I typically start by the pure metals and use their minimum energy
> multiplicities
> also for the derived structures -afterwards. Do not forget to recalculate
> spin for multiplied slabs (if any), as multiplicity is sort of extensive.
>
> I hope this helps,
>   t
>
> On Sun, Aug 15, 2021 at 10:00 PM El-abed Haidar
>  wrote:
> >
> > No problem! Still though you would like to do a convergence test for
> Mesh cut off because you might get surprised that you do not need that much
> energy even when including the metals.
> >
> > Really eager to see the update of this work.
> >
> > Good luck!
> >
> > EL-abed
> >
> >
> >
> > El-abed Haidar | Doctor of Philosophy (Science)
> > Condensed Matter Theory (CMT) Group| School of Physics
> > THE UNIVERSITY OF SYDNEY | NSW | 2006
> >
> >
> >
> > From: I. Camps
> > Sent: Sunday, 15 August 2021 6:04 AM
> > To: siesta-l@uam.es
> > Subject: Re: [SIESTA-L] << SCF convergence issues >>
> >
> >
> >
> > Thanks @Nick and @El-abed for your contribution.
> >
> >
> >
> > I tested with the following combinations:
> >
> >
> >
> > DM.MixingWeight: 0.25, 0.05, 0.02 and 0.01
> >
> > SCF.Mixer.History: 1, 3, 6 and 9
> >
> > SCF.Mixer.Variant: original and GR
> >
> > SCF.Mixer.Kick: 3, 10 and 50
> >
> >
> >
> > The high value of the mesh cut off is due to this calculation being part
> of a bigger study including two other metals (Cd and Pb) interacting with
> boron-nitride nanotubes. This value was obtained after convergence study.
> >
> >
> >
> > The only thing that makes the system converge is changing DZP by SZP.
> >
> >
> >
> > []'s,
> >
> > Camps
> >
> >
> >
> >
> >
> > On Fri, Aug 13, 2021 at 5:00 PM Nick Papior 
> wrote:
> >
> > What did you play with for mixing weights and kick etc?
> >
> >
> >
> > A mixing weight of 0.25 is pretty high, if not excessively high in this
> case. :)
> >
> >
> >
> > Did you try, say 0.02, or something like that?
> >
> >
> >
> > Also, kicks are *only* necessary when you have problems with stalls in
> convergence. If you stall after 50 SCF, you should have a kick at that
> point, but definitely not at every 3rd SCF, that may worsen your
> convergence.
> >
> >
> >
> > Den tor. 12. aug. 2021 kl. 22.02 skrev I. Camps :
> >
> > Hello SIESTers,
> >
> >
> >
> > I am trying to optimize some 4 atom Ni clusters. There are 4 types: one
> linear, one zigzag, one 2D and one 3D.
> >
> >
> >
> > Using the setup below, I don't get the calculations to converge even
> after 1000 SCF steps (which is huge!).
> >
> >
> >
> > I already play with DM.Mixi

Re: [SIESTA-L] << SCF convergence issues >>

[I. Camps]

Thanks @Nick and @El-abed for your contribution.

I tested with the following combinations:

DM.MixingWeight: 0.25, 0.05, 0.02 and 0.01
SCF.Mixer.History: 1, 3, 6 and 9
SCF.Mixer.Variant: original and GR
SCF.Mixer.Kick: 3, 10 and 50

The high value of the mesh cut off is due to this calculation being part of
a bigger study including two other metals (Cd and Pb) interacting with
boron-nitride nanotubes. This value was obtained after convergence study.

The only thing that makes the system converge is changing DZP by SZP.

[]'s,

Camps


On Fri, Aug 13, 2021 at 5:00 PM Nick Papior  wrote:

> What did you play with for mixing weights and kick etc?
>
> A mixing weight of 0.25 is pretty high, if not excessively high in this
> case. :)
>
> Did you try, say 0.02, or something like that?
>
> Also, kicks are *only* necessary when you have problems with stalls in
> convergence. If you stall after 50 SCF, you should have a kick at that
> point, but definitely not at every 3rd SCF, that may worsen your
> convergence.
>
> Den tor. 12. aug. 2021 kl. 22.02 skrev I. Camps :
>
>> Hello SIESTers,
>>
>> I am trying to optimize some 4 atom Ni clusters. There are 4 types: one
>> linear, one zigzag, one 2D and one 3D.
>>
>> Using the setup below, I don't get the calculations to converge even
>> after 1000 SCF steps (which is huge!).
>>
>> I already play with DM.MixingWeight, SCF.Mixer.History,
>> SCF.Mixer.Variant, SCF.Mixer.Kick, and nothing works.
>>
>> The tolerance is not even high, it is only 1E-3.
>>
>> The input is below.
>>
>> Any ideas, suggestions?
>>
>> Regards,
>>
>> Camps
>>
>> ###
>> SystemName  NiM4-1Dlinear
>> SystemLabel NiM4-1Dlinear
>>
>> LatticeConstant 12.787740 Ang
>> %block LatticeVectors
>>  1.394587   0.00 0.00
>>  0.00   1.394587 0.00
>>  0.00   0.00 1.00
>> %endblock LatticeVectors
>>
>> NumberOfSpecies1
>> NumberOfAtoms  4
>>
>> %block ChemicalSpeciesLabel
>>   1  28  Ni
>> %endblock ChemicalSpeciesLabel
>>
>> AtomicCoordinatesFormat Ang
>>
>> %block AtomicCoordinatesAndAtomicSpecies
>>   8.9168000  8.7888600  9.6866000 1
>>   8.9168000  8.7888600  7.5067061 1
>>   8.9168000  8.7888600  3.1011000 1
>>   8.9168000  8.7888600  5.2809939 1
>> %endblock AtomicCoordinatesAndAtomicSpecies
>>
>>  -- SELF-CONSISTENT FIELD --
>> PAO.BasisSize DZP
>> MD.TypeOfRun  CG
>> MD.NumCGsteps 1000
>> MinSCFIterations  3
>> MaxSCFIterations  1000
>> SpinPolarized T
>> MeshCutoff500 Ry
>> DM.MixingWeight   0.25
>> SCF.Mixer.History  6   # replace DM.NumberPulay
>> #SCF.Mixer.Variant  GR
>> SCF.Mixer.Kick 3
>> DM.Tolerance  0.001
>> XC.functional GGA
>> XC.authorsPBE
>> SolutionMethod diagon
>>
>> --
>> SIESTA is supported by the Spanish Research Agency (AEI) and by the
>> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>>
>
>
> --
> Kind regards Nick
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

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

[SIESTA-L] << SCF convergence issues >>

[I. Camps]

Hello SIESTers,

I am trying to optimize some 4 atom Ni clusters. There are 4 types: one
linear, one zigzag, one 2D and one 3D.

Using the setup below, I don't get the calculations to converge even after
1000 SCF steps (which is huge!).

I already play with DM.MixingWeight, SCF.Mixer.History, SCF.Mixer.Variant,
SCF.Mixer.Kick, and nothing works.

The tolerance is not even high, it is only 1E-3.

The input is below.

Any ideas, suggestions?

Regards,

Camps

###
SystemName  NiM4-1Dlinear
SystemLabel NiM4-1Dlinear

LatticeConstant 12.787740 Ang
%block LatticeVectors
 1.394587   0.00 0.00
 0.00   1.394587 0.00
 0.00   0.00 1.00
%endblock LatticeVectors

NumberOfSpecies1
NumberOfAtoms  4

%block ChemicalSpeciesLabel
  1  28  Ni
%endblock ChemicalSpeciesLabel

AtomicCoordinatesFormat Ang

%block AtomicCoordinatesAndAtomicSpecies
  8.9168000  8.7888600  9.6866000 1
  8.9168000  8.7888600  7.5067061 1
  8.9168000  8.7888600  3.1011000 1
  8.9168000  8.7888600  5.2809939 1
%endblock AtomicCoordinatesAndAtomicSpecies

 -- SELF-CONSISTENT FIELD --
PAO.BasisSize DZP
MD.TypeOfRun  CG
MD.NumCGsteps 1000
MinSCFIterations  3
MaxSCFIterations  1000
SpinPolarized T
MeshCutoff500 Ry
DM.MixingWeight   0.25
SCF.Mixer.History  6   # replace DM.NumberPulay
#SCF.Mixer.Variant  GR
SCF.Mixer.Kick 3
DM.Tolerance  0.001
XC.functional GGA
XC.authorsPBE
SolutionMethod diagon

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

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

[I. Camps]

Hi Nick,

Here are two links with all the inputs for DENCHAR:
Link 1: https://lamodel.unifal-mg.edu.br/downloads/Camps_DencharInput.tar.gz
Link 2:
https://drive.google.com/file/d/1GyjLmpOEZ553-A7R8r9oXqwlzx9NcQGb/view?usp=sharing

Also, I compiled DENCHAR with *-debug all -g* options (I am using Intel
suite), but no new message appear.

Thank you for your disponibility.

[]'s,

Camps


On Wed, Apr 14, 2021 at 5:01 PM Nick Papior  wrote:

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

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

[I. Camps]

Hello Nick,

My input file is below. I duplicate the grid size.

Also, I save the output from DENCHAR to a file and keep monitoring the CPU
and memory usage.

In the output there is no indication of error and the memory usage keep
above 4GB with a 49% use (my note have 8GB).

### INPUT
SystemLabel BN-Ni-p4-dCRITIC2
NumberOfSpecies3
%block ChemicalSpeciesLabel
  1   5  B
  2   7  N
  3  28  Ni
%endblock ChemicalSpeciesLabel
Denchar.TypeOfRun  3D
Denchar.PlotCharge T
Denchar.CoorUnits   Ang   # Format for coordinate of the points
   # Bohr
   # Ang
Denchar.DensityUnits   Ele/Ang**3 # Units of Charge Density
   # Ele/bohr**3
   # Ele/Ang**3
   # Ele/UnitCell
Denchar.NumberPointsX  480
Denchar.NumberPointsY  480
Denchar.NumberPointsZ  360

Denchar.MinX  0  Ang
Denchar.MaxX  17.833623 Ang
Denchar.MinY  0 Ang
Denchar.MaxY  17.833623  Ang
Denchar.MinZ  0  Ang
Denchar.MaxZ  12.171076 Ang
###

### OUTPUT
...
...
 115 23.089612.3513 2.6562
   116 23.041412.373710.7105
   117 23.060412.365518.7637
   118 24.088814.5243 1.3261
   119 24.059614.5373 9.3802
   120 24.062314.539317.4349
   121 14.8510 5.857515.3723

   Generating Charge Density values on the grid now
   Please, wait
###


Regards,

Camps


On Wed, Apr 7, 2021 at 5:17 PM Nick Papior  wrote:

> Hi,
>
> Hmm.. That depends on the options you use. It could be that you run out of
> memory?
> Perhaps some more information about what was before this would be useful?
> I.e. what does denchar print before writing "Killed"?
>
> Den tor. 1. apr. 2021 kl. 22.02 skrev I. Camps :
>
>> Thank you very much Nick!
>>
>> I am using the second option...
>>
>> The original mesh is 240x240x180. I tried to double it, but DENCHAR just
>> stopped with a simple text: "Killed", without any information about.
>>
>> Do you have a recommendation about the best form to select the grid?
>>
>> []'s,
>>
>> Camps
>>
>>
>> On Mon, Mar 29, 2021 at 5:02 PM Nick Papior  wrote:
>>
>>> Hi,
>>>
>>> You can use sisl to interpolate and write out the a cube file.
>>>
>>> For instance,
>>>
>>> sgrid siesta.RHO --interp 300 400 400 --out rho.cube
>>>
>>> will interpolate the RHO grid to a size of 300, 400, 400, x, y, z
>>> directions. Please refer to sgrid --help for more information. For instance
>>> the interpolation method may be quite important in your case.
>>>
>>> Alternatively you can use denchar to replot the density matrix files
>>> using a denser grid. This is of course more precise since it isn't
>>> interpolation but using the same DM to recreate the full grid on a
>>> different mesh.
>>>
>>> Good luck!
>>>
>>> Den søn. 28. mar. 2021 kl. 23.01 skrev I. Camps :
>>>
>>>> Dear SIESTers,
>>>>
>>>> I am doing a critical point study using the package CRITIC2, but for
>>>> SIESTA, it only accepts the RHO density in cube format, so its results are
>>>> dependent on the quality of the used grid.
>>>>
>>>> Is it possible to increase the mesh for the grid where RHO is
>>>> calculated?
>>>>
>>>> []'s,
>>>>
>>>> Camps
>>>>
>>>> --
>>>> SIESTA is supported by the Spanish Research Agency (AEI) and by the
>>>> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>>>>
>>>
>>>
>>> --
>>> Kind regards Nick
>>>
>>> --
>>> SIESTA is supported by the Spanish Research Agency (AEI) and by the
>>> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>>>
>>
>> --
>> SIESTA is supported by the Spanish Research Agency (AEI) and by the
>> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>>
>
>
> --
> Kind regards Nick
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

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

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

[I. Camps]

Thank you very much Nick!

I am using the second option...

The original mesh is 240x240x180. I tried to double it, but DENCHAR just
stopped with a simple text: "Killed", without any information about.

Do you have a recommendation about the best form to select the grid?

[]'s,

Camps


On Mon, Mar 29, 2021 at 5:02 PM Nick Papior  wrote:

> Hi,
>
> You can use sisl to interpolate and write out the a cube file.
>
> For instance,
>
> sgrid siesta.RHO --interp 300 400 400 --out rho.cube
>
> will interpolate the RHO grid to a size of 300, 400, 400, x, y, z
> directions. Please refer to sgrid --help for more information. For instance
> the interpolation method may be quite important in your case.
>
> Alternatively you can use denchar to replot the density matrix files using
> a denser grid. This is of course more precise since it isn't interpolation
> but using the same DM to recreate the full grid on a different mesh.
>
> Good luck!
>
> Den søn. 28. mar. 2021 kl. 23.01 skrev I. Camps :
>
>> Dear SIESTers,
>>
>> I am doing a critical point study using the package CRITIC2, but for
>> SIESTA, it only accepts the RHO density in cube format, so its results are
>> dependent on the quality of the used grid.
>>
>> Is it possible to increase the mesh for the grid where RHO is calculated?
>>
>> []'s,
>>
>> Camps
>>
>> --
>> SIESTA is supported by the Spanish Research Agency (AEI) and by the
>> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>>
>
>
> --
> Kind regards Nick
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

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

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

[I. Camps]

Dear SIESTers,

I am doing a critical point study using the package CRITIC2, but for
SIESTA, it only accepts the RHO density in cube format, so its results are
dependent on the quality of the used grid.

Is it possible to increase the mesh for the grid where RHO is calculated?

[]'s,

Camps

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

[SIESTA-L] << GUI for SIESTA >>

[I. Camps]

Dear SIESTers,

I will like to share with you this information about a recent paper
describing a Graphical User Interface ready to use with our beloved SIESTA:


GUI4dft-A SIESTA oriented GUI
Computer Physics Communications 262 (2021) 1078
DOI: [image: image.png]
https://doi.org/10.1016/j.cpc.2021.1078430

Abstract.
The Graphical User Interface for Density Functional Theory (GUI4dft) is a
new software for users ofSIESTA. It is a free cross-platform software with
a graphical user interface. GUI4dft allows the user towork with standard
SIESTA files and prepare manuscript-quality figures of the atomic structure
andproperties such as three-dimensional charge density distributions, DOS,
PDOS, and band structure. GUI4dft is written in Python language and falls
under an MIT license.
Program summary
Program title: GUI4dft.
CPC Library link to program files: [image: image.png]
https://doi.org/10.17632/htrvwm7k2h.1

Developer’s repository link: [image: image.png]
https://github.com/sozykinsa/GUI4dft

Licensing provision: MIT.
Programming language: Python 3.
External routines/libraries: PyQt5, OpenGL, Scipy, Numpy, Scikit-ima

[]'s,

Camps

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

Re: [SIESTA-L] [CCC-UAM #1102] Resolved: Re: << Compiling Utils using build_all scrip >>

[I. Camps via RT]

Estimada MAria,
Hubo una respuesta mas no una solución.

[]'s,

Camps


On Thu, Feb 18, 2021 at 6:00 PM María Martínez Garrido via RT <
administrador@uam.es (mailto:administrador@uam.es)> wrote:

  Según nuestros registros, su petición ha sido resuelta. Si tiene alguna
  pregunta o duda, por favor, responda a este mensaje.

  Saludos.

  -

  Subject: Resolved: Re: [SIESTA-L] << Compiling Utils using build_all scrip
  >>
  Content-Type: text/html

  According to our records, your request has been resolved. If you have
  any further questions or concerns, please respond to this message.


  --
  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] << Compiling Utils using build_all scrip >>

[I. Camps]

Hi Nick,

Thank you for your email.

1. We can't see your arch.make, so there may be problems related to that.
>
The used arch.make file is attached here.
I successfully compiled SIESTA, both v4.1.5 and PSML version, without any
errors with it


> 2. You shouldn't do any manual copies, so I bet your copy of the xmlparser
> folder causes problems. Could you please try from a clean pdosxml folder,
> it should only contain these files:
> total 196K
> -rw-r--r-- 1 nicpa nicpa  28K Oct  9  2019 f2kcli-manual.txt
> -rw-r--r-- 1 nicpa nicpa 141K Oct  9  2019 h2o_dos.PDOS
> -rw-r--r-- 1 nicpa nicpa 1.6K Feb  4 08:22 makefile
> -rw-r--r-- 1 nicpa nicpa 1.2K Nov 17 13:48 m_orbital_chooser.f90
> -rw-r--r-- 1 nicpa nicpa 5.9K Feb  4 08:22 m_pdos.f90
> -rw-r--r-- 1 nicpa nicpa 1.3K Feb  4 08:22 pdosxml.f90
> -rw-r--r-- 1 nicpa nicpa 1.7K Oct  9  2019 README
>
This was Ok.

3. Utilities depend on the Obj directory. So if you hadn't done
> ../Src/obj_setup.sh in the Obj directory this may be the root cause of the
> problem.
>
This did the trick! But there following packages:












 All failed directories: *** (Some programs have to be compiled after
compiling Siesta)   ./WFS   ./SiestaSubroutine/ProtoNEB/Src
 ./SiestaSubroutine/SimpleTest/Src   ./ON   ./Grid   ./Gen-basis
 ./STM/simple-stm   ./DensityMatrix   ./MPI_test   ./Helpers:*

Had the same complaint finding NETCDF. For example, this is the output of
running *make* inside the WFS folder:
























*fort  -L/software/SIESTA-Libs/zlib-1.2.8/lib
-Wl,-rpath=/software/SIESTA-Libs/zlib-1.2.8/lib
-L/software/SIESTA-Libs/hdf5-1.8.12/lib
-Wl,-rpath=/software/SIESTA-Libs/hdf5-1.8.12/lib
-L/software/SIESTA-Libs/netcdf-4.4.1/lib
-Wl,-rpath=/software/SIESTA-Libs/netcdf-4.4.1/lib
-L/software/SIESTA-Libs/netcdf-fortran-4.4.4/lib
-Wl,-rpath=/software/SIESTA-Libs/netcdf-fortran-4.4.4/lib -static-intel
-L/software/intel/compilers_and_libraries_2020.4.304/linux/mkl/lib/intel64
-o wfsnc2wfsx wfsnc2wfsx.o ld: wfsnc2wfsx.o: in function
`MAIN__':wfsnc2wfsx.F90:(.text+0x66): undefined reference to
`netcdf_mp_nf90_open_'ld: wfsnc2wfsx.F90:(.text+0x97): undefined reference
to `netcdf_mp_nf90_inq_dimid_'ld: wfsnc2wfsx.F90:(.text+0xc4): undefined
reference to `netcdf_mp_nf90_inquire_dimension_'ld:
wfsnc2wfsx.F90:(.text+0xfe): undefined reference to
`netcdf_mp_nf90_inq_dimid_'ld: wfsnc2wfsx.F90:(.text+0x128): undefined
reference to `netcdf_mp_nf90_inquire_dimension_'ld:
wfsnc2wfsx.F90:(.text+0x155): undefined reference to
`netcdf_mp_nf90_inq_dimid_'ld: wfsnc2wfsx.F90:(.text+0x182): undefined
reference to `netcdf_mp_nf90_inquire_dimension_'ld:
wfsnc2wfsx.F90:(.text+0x1af): undefined reference to
`netcdf_mp_nf90_inq_dimid_'ld: wfsnc2wfsx.F90:(.text+0x1dc): undefined
reference to `netcdf_mp_nf90_inquire_dimension_'ld:
wfsnc2wfsx.F90:(.text+0x209): undefined reference to
`netcdf_mp_nf90_inq_dimid_'ld: wfsnc2wfsx.F90:(.text+0x236): undefined
reference to `netcdf_mp_nf90_inquire_dimension_'ld:
wfsnc2wfsx.F90:(.text+0x263): undefined reference to
`netcdf_mp_nf90_inq_varid_'ld: wfsnc2wfsx.F90:(.text+0x28d): undefined
reference to `netcdf_mp_nf90_inq_varid_'ld: wfsnc2wfsx.F90:(.text+0x1856):
undefined reference to `netcdf_mp_nf90_get_var_1d_fourbytereal_'ld:
wfsnc2wfsx.F90:(.text+0x19ec): undefined reference to
`netcdf_mp_nf90_get_var_1d_fourbytereal_'ld: wfsnc2wfsx.F90:(.text+0x1b3a):
undefined reference to `netcdf_mp_nf90_get_var_1d_fourbytereal_'ld:
wfsnc2wfsx.F90:(.text+0x1bf3): undefined reference to
`netcdf_mp_nf90_get_var_1d_fourbytereal_'ld: wfsnc2wfsx.F90:(.text+0x1d71):
undefined reference to `netcdf_mp_nf90_close_'ld:
wfsnc2wfsx.F90:(.text+0x1dcf): undefined reference to
`netcdf_mp_nf90_strerror_'ld: wfsnc2wfsx.o: in function
`wfsnc2wfsx_IP_check_':wfsnc2wfsx.F90:(.text+0x1f65): undefined reference
to `netcdf_mp_nf90_strerror_'make: *** [makefile:58: wfsnc2wfsx] Error 1*

Regards,

Camps


arch.make
Description: Binary data

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

[SIESTA-L] << Compiling Utils using build_all scrip >>

[I. Camps]

Hello SIESTers,

I am trying to compile all the utilities from the Util folder (from SIESTA
PSML distro).

When start compiling *pdosxml*, I got the following messages:




*/bin/sh: 1: cd: can't cd to
../..//home/icamps/Downloads/SIESTA/siesta-psml/Obj/xmlparsermake[4710]:
Entering directory
'/home/icamps/Downloads/SIESTA/siesta-psml/Util/pdosxml'Making sure that
the xmlparser library is compiled...(cd
../..//home/icamps/Downloads/SIESTA/siesta-psml/Obj/xmlparser ; make
"VPATH=../../Src/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser/xmlparser*

This is endless, keep filing the terminal and also making my computer to
extremely slowdown.

I compiled SIESTA and copy the *xmlparser *folder (which has the library
file *libxmlparser.a*) inside* Obj,* so, the folder is there.

Also, I excecuted the script *clean_all.sh*.

Any help/idea will be appreciated.

[]'s,

Camps

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

Re: [SIESTA-L] SIESTA (GitLab version) installation failure

[I. Camps]

Hello Toma,

Could you share your arch.make file?

Thanks in advance.

[]'s,

Camps


On Fri, Jan 8, 2021 at 6:02 PM Tamas Karpati  wrote:

> Dear Nick, dear Alberto,
>
> I want to thank you for your valuable help.
> I could build SIESTA/GitLab successfully following your hints.
>
> I'm happy to go on exploring the realm of SIESTA :)
>
> Best regards,
>   toma
>
>
> On Fri, Dec 18, 2020 at 8:57 AM Tamas Karpati  wrote:
> >
> > Dear Nick, Alberto,
> >
> > Thanks for the hints and directions. I can now go further :)
> >
> > Best regards,
> >   toma
> >
> > On Thu, Dec 17, 2020 at 10:21 PM Nick Papior 
> wrote:
> > >
> > > Like I said.
> > >
> > > COMP_LIBS should only contain specific library names. No paths.
> > >
> > > Also, you still have redundancies... ;)
> > >
> > > Delete this line:
> > > COMP_LIBS = -L/prghome/Siesta1/Obj
> > >
> > > Lastly, please always post the exact error everytime you post
> something new. It makes it much easier for us to see (regardless of whether
> you see the "same" error).
> > >
> > > Den ons. 16. dec. 2020 kl. 22.04 skrev Tamas Karpati <
> tkarp...@gmail.com>:
> > >>
> > >> Hi,
> > >>
> > >> Sorry for bothering you with such a messy file last time.
> > >> I noticed and removed the redundancies (and still have the same
> result).
> > >> Also made it easier to read, I hope. Can you please take a look at it?
> > >> I'm afraid that there is an issue with the ordering of flags for each
> pkg
> > >> (MPI, ELPA etc) or something is missing.
> > >>
> > >> Best regards,
> > >>   toma
> > >>
> > >> On Sun, Dec 13, 2020 at 12:59 PM Tamas Karpati 
> wrote:
> > >> >
> > >> > Dear Prof. Papior,
> > >> >
> > >> > Thank you for your quick response. Please find arch.make attached.
> > >> >
> > >> > For your information: this file was auto-generated by my home-made
> > >> > pkg. manager which added all flags for all the dependencies. The
> code
> > >> > is based on my understanding of Obj/DOCUMENTED-TEMPLATE.make.
> > >> >
> > >> > I appreciate your aid very much, thank you.
> > >> >
> > >> > With regards,
> > >> >   toma
> > >> >
> > >> > On Sat, Dec 12, 2020 at 10:01 PM Nick Papior 
> wrote:
> > >> > >
> > >> > > Please attach your arch.make file
> > >> > >
> > >> > > On Fri, 11 Dec 2020, 22:03 Tamas Karpati, 
> wrote:
> > >> > >>
> > >> > >> Dear fellow developers,
> > >> > >>
> > >> > >>
> > >> > >> Please help my first attempt to build SIESTA as I'm stuck after
> > >> > >> several attempts. No similar symptoms I could find in the
> archives.
> > >> > >>
> > >> > >> Shortly: make stops without both executables and error messages.
> > >> > >>
> > >> > >>
> > >> > >> Details: after having
> > >> > >>   * OpenMPI-4.0.5, OpenBLAS-0.3.10, ScaLAPACK-2.1.0,
> > >> > >> Elpa-2020.005.001, Metis-5.1.0 and MUMPS-5.3.5 built,
> > >> > >>   * downloaded from GitLab the Dec. 11, 2020 master version of
> SIESTA,
> > >> > >>   * applied the install scripts in Doc for both NetCDF and FLOOK,
> > >> > >>   * created the arch.make and finally invoked
> > >> > >>   * make (either without arguments or adding the "-j N" option).
> > >> > >>
> > >> > >> Without a better guess I followed siesta-4.1-b4.pdf/Section 2.
> > >> > >>
> > >> > >>
> > >> > >> Two observations:
> > >> > >>
> > >> > >>   1, there neither executables (ie. siesta)
> > >> > >>  nor error messages appear
> > >> > >>
> > >> > >>   2, when I run make several times:
> > >> > >>  - first time libwxml.a and libmpi_f90.a appear,
> > >> > >>  - second time libfdf.a and MatrixSwitch.a appear,
> > >> > >>  - third time libSiestaXC.a materialized but
> > >> > >>  - starting from the fourth invokation of make I got
> > >> > >>
> > >> > >>"No rule to make target '-L/home/atom/Siesta/Obj',
> > >> > >>needed by 'posix_calls.o'.  Stop."
> > >> > >>
> > >> > >>(iteration converged, this method gives me no more fruit)
> > >> > >>
> > >> > >> Looking in Obj/Makefile did not help either. Still shut a few
> with
> > >> > >> "make lib", "make siesta" even "make dep" but to no avail.
> > >> > >> Apparently I need to learn.
> > >> > >>
> > >> > >>
> > >> > >> I kindly ask your help (instructions or written method on the
> Web).
> > >> > >> Thank you in advance.
> > >> > >>
> > >> > >> Best regards,
> > >> > >>   toma
> > >> > >>
> > >> > >> --
> > >> > >> SIESTA is supported by the Spanish Research Agency (AEI) and by
> the European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
> > >> > >
> > >> > >
> > >> > > --
> > >> > > SIESTA is supported by the Spanish Research Agency (AEI) and by
> the European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
> > >>
> > >> --
> > >> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
> > >
> > >
> > >
> > > --
> > > Kind regards Nick
> > >
> > > --
> > > SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence 

[SIESTA-L] << Materials Modeling Stack Exchange >>

[I. Camps]

Dear SIESTers,

I would like to invite you to visit the Materials Modeling Stack Exchange
forum (in public beta).

The site is dedicated for those interested in building a community
dedicated to answering research level questions about molecular and
materials modeling.

https://materials.stackexchange.com/



[]'s,

Camps

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

Re: [SIESTA-L] [SIESTA] Performing geometrical optimization

[I. Camps]

Hello Yuvam,

Normally, there is no need to use scripts for geometry optimization. There
are keywords in order to set up the type of optimization you want. For
example, the keyword *MD.VariableCell* if set to *.true.* (together with
the keyword *MD.NumCGsteps* with a value different than cero), indicates
the full system optimization (lattice and atoms), whereas if set to
*.false.* (the default) will optimize only the atom positions.

About your second question, SIESTA is faster and much more efficient than
QE. Just to give you an idea: a colleague of me was running a geometry
optimization for an AuAg alloy in his workstation with 20 cores and 64GB
RAM and didn't get convergence in weeks. I successfully run the same
simulation on my desktop (8 cores & 16GB RAM) in 4 hours :)

An example of input file (with lattice optimization is bellow.

Regards,

Camps











































































































































































































*#SystemLabel
 all_variableNumberOfAtoms136NumberOfSpecies  4%block
ChemicalSpeciesLabel  1 1 H  2 6 C  3 7 N  4 8 O%endblock
ChemicalSpeciesLabelLatticeConstant 1.0 Ang%block LatticeParameters
10.581000  7.928000  16.553000  90.00  107.727000  90.00%endblock
LatticeParametersAtomicCoordinatesFormat NotScaledCartesianAng%block
AtomicCoordinatesAndAtomicSpecies1.910766631.06761342   15.24602191
  4   1  O0.889973800.892725898.85534731   3   2  N
0.611496120.68841552   11.25381561   2   3  C   -0.37800408
 0.876394994.79519096   2   4  C0.177164280.47923136
 9.86087998   2   5  C2.134528011.75492777   12.87753202   2
6  C1.671134221.58737973   11.55716550   2   7  C
 -0.814005500.989914153.36835751   2   8  C   -0.89278897
 1.271347677.17038679   2   9  C1.299448740.36580952
 6.51695994   2  10  C1.528039901.00682960   13.92714439   2
   11  C0.439359960.13522161   13.64432263   2  12  C
0.902578640.378105225.17019135   2  13  C0.41120560
 0.815648067.54080575   2  14  C   -0.02161433   -0.00907599
12.32406669   2  15  C   -1.264459231.313747985.81631769   2
   16  C2.909084072.04185648   15.63433950   2  17  C
0.189171490.570695322.29067770   2  18  C   -1.95869884
 1.391771633.06824363   4  19  O   -2.243424761.71912263
 5.49997151   1  20  H2.312778660.007627066.78322120   1
   21  H2.115678892.17257368   10.72891688   1  22  H
 -0.89145647   -0.66705989   12.12300421   1  23  H2.94658582
 2.47568148   13.07752853   1  24  H1.618815910.01816457
 4.40973296   1  25  H   -1.592180021.631588487.94893656   1
   26  H3.079901221.88410055   16.72353891   1  27  H
3.866259631.88340124   15.08053077   1  28  H   -0.04006592
-0.40428223   14.48326591   1  29  H   -0.184812350.86448272
 1.28710652   1  30  H1.200912611.005904562.46215283   1
   31  H0.29169576   -0.541369042.32642118   1  32  H
2.553981673.08091944   15.9882   1  33  H   -0.77656939
-0.089055029.70436399   1  34  H4.513928564.05305723
 9.70436769   1  35  H7.844470600.88309155   15.44450702   1
   36  H5.582285294.505375122.32641439   1  37  H
6.491439302.958127962.46213203   1  38  H5.10570204
 3.099542071.28714656   1  39  H5.250406724.36830302
14.48326455   1  40  H9.156762142.08061061   15.08054382   1
   41  H8.370416312.07994527   16.72359277   1  42  H
3.698323242.332411417.94893113   1  43  H6.90932527
 3.945857524.40976662   1  44  H8.237106321.48834724
13.07752621   1  45  H4.399018074.63106387   12.12301206   1
   46  H7.406166271.79143952   10.72891311   1  47  H
7.603278403.956374196.78325047   1  48  H3.04709892
 2.244902925.49989556   1  49  H3.331762772.57227271
 3.06821609   4  50  O5.479688583.393328362.29069132   2
   51  C8.199591771.92215422   15.63438028   2  52  C
4.026061392.650268315.81630560   2  53  C5.26887021
 3.97308171   12.32406939   2  54  C5.701713333.14836187
 7.54083576   2  55  C6.193096703.585904975.17021374   2
   56  C5.729849073.82877904   13.64433415   2  57  C
6.818538572.95718157   13.92713751   2  58  C6.58995380
 3.598180166.51699519   2  59  C4.397717172.69265969
 7.17038194   2  60  C4.476557622.974123413.36836044   2
   61  C6.961626412.37663337   11.55716297   2  62  C
7.425030942.20908483   12.87753026   2   

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

[I. Camps]

The output of "make dep" at the util folder was:

*make: *** No rule to make target 'dep'.  Stop.*

Inside the COOP folder was:





*sfmakedepend --depend=obj --modext=o \
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.f
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.f90
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.F
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.F90 \ *.f
*.f90 *.F *.F90/bin/sh: sfmakedepend: command not foundmake: ***
[Makefile:53: dep] Error 127*

I didn't have *sfmakedepend  *on my system. So, Googling, I download a
version from here <https://marine.rutgers.edu/po/tools/perl/sfmakedepend>
that looks to work after minor modifications. The output now is (attached):


































































*sfmakedepend -o obj -m o \
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.f
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.f90
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.F
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/*.F90 \ *.f
*.f90 *.F *.F90Can't find file: class_Data1D.T90Can't find file:
class_Data1D.T90Can't find file: class_Data1D.T90Can't find file:
class_Data1D.T90Can't find file: class_Data1D.T90Can't find file:
class_Data1D.T90Can't find file: class_Data2D.T90Can't find file:
class_Data2D.T90Can't find file: class_Data2D.T90Can't find file:
class_Data2D.T90Can't find file: class_Data2D.T90Can't find file:
class_Data2D.T90Can't find file: basic_type.incCan't find file:
Fstack.T90Can't find file: Fstack.T90Can't find file: Fstack.T90Can't find
file: Fstack.T90Can't find file: Fstack.T90Can't find file: Fstack.T90Can't
find file: Fstack.T90Can't find file: basic_type.incCan't find file:
basic_type.incCan't find file: Pair.T90Can't find file: Pair.T90Can't find
file: Pair.T90Can't find file: Pair.T90Can't find file: Pair.T90Can't find
file: basic_type.incCan't find file: class_SpData1D.T90Can't find file:
class_SpData1D.T90Can't find file: class_SpData1D.T90Can't find file:
class_SpData1D.T90Can't find file: class_SpData1D.T90Can't find file:
class_SpData1D.T90Can't find file: class_SpData2D.T90Can't find file:
class_SpData2D.T90Can't find file: class_SpData2D.T90Can't find file:
class_SpData2D.T90Can't find file: class_SpData2D.T90Can't find file:
class_SpData2D.T90Can't find file: class_TriMat.T90Can't find file:
class_TriMat.T90Can't find file: class_TriMat.T90Can't find file:
class_TriMat.T90Can't find file: class_TriMat.T90Can't find file:
class_TriMat.T90Can't find file: f_interface.f90Can't find file:
zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
zmumps_struc.hCan't find file: zmumps_struc.hCan't find file:
zmumps_struc.h*
I didn't mention before, because I though this can be irrelevant, but my
system CPU is not Intel, it is AMD (Six-Core AMD Opteron(tm) Processor
8431).



[]'s,

Camps


On Fri, May 15, 2020 at 5:04 PM Nick Papior  wrote:

> Hmm, this looks weird.
>
> Could you do a "make dep" in the utility folder, and do
> make clean
> make
> ?
>
> Den tor. 14. maj 2020 kl. 22.04 skrev I. Camps :
>
>> Thanks Nick.
>>
>> The output from make parallel.o was:
>>
>>
>> *ifort  -c -O2 -ipo -xHost -ip -prec-div -prec-sqrt -opt-prefetch
>> -mkl=parallel
>>  
>> -I/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/include
>> -I/software/SIESTA_LIBS/netcdf/4.4.1/include -DMPI -UMPI
>>  /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/parallel.Ffpp:
>> warning: cannot remove MPI - not a predefined macro*
>>
>> and the output from make was:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *ifort  -c -O2 -ipo -xHost -ip -prec-div -prec-sqrt -opt-prefetch
>> -mkl=parallel
>>  
>> -I/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/include
>> -I/software/SIESTA_LIBS/netcdf/4.4.1/include -DMPI -UMPI
>>  /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/precision.Ffpp:
>> warning: cannot remove MPI - not a predefined macroifort  -c -O2
>> -ipo -xHost -ip -prec-div -prec-sqrt -opt-prefetch -mkl=parallel
>>  
>> -I/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/include
>> -I/software/SIESTA_LIBS/netcdf/4.4.1/include -DMP

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

[I. Camps]

Thanks Nick.

The output from make parallel.o was:


*ifort  -c -O2 -ipo -xHost -ip -prec-div -prec-sqrt -opt-prefetch
-mkl=parallel
 -I/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/include
-I/software/SIESTA_LIBS/netcdf/4.4.1/include -DMPI -UMPI
 /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/parallel.Ffpp:
warning: cannot remove MPI - not a predefined macro*

and the output from make was:



























*ifort  -c -O2 -ipo -xHost -ip -prec-div -prec-sqrt -opt-prefetch
-mkl=parallel
 -I/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/include
-I/software/SIESTA_LIBS/netcdf/4.4.1/include -DMPI -UMPI
 /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/precision.Ffpp:
warning: cannot remove MPI - not a predefined macroifort  -c -O2
-ipo -xHost -ip -prec-div -prec-sqrt -opt-prefetch -mkl=parallel
 -I/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/include
-I/software/SIESTA_LIBS/netcdf/4.4.1/include -DMPI -UMPI
 /home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90fpp:
warning: cannot remove MPI - not a predefined
macro/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(212):
error #7002: Error in opening the compiled module file.  Check INCLUDE
paths.   [SYS]  use sys,   only: die   ! Termination
routine--^/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(213):
error #7002: Error in opening the compiled module file.  Check INCLUDE
paths.   [M_IO]  use m_io,  only: io_assign ! Get and reserve an
available IO
unit--^/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(212):
error #6580: Name in only-list does not exist.   [DIE]  use sys,
only: die   ! Termination
routine---^/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(213):
error #6580: Name in only-list does not exist.   [IO_ASSIGN]  use m_io,
 only: io_assign ! Get and reserve an available IO
unit---^/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(374):
error #6406: Conflicting attributes or multiple declaration of name.
[IO_ASSIGN]call
io_assign(REPORT_UNIT)-^/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(381):
error #6406: Conflicting attributes or multiple declaration of name.
[IO_ASSIGN]call
io_assign(REPORT_UNIT)-^/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(2343):
error #6406: Conflicting attributes or multiple declaration of name.
[DIE]  call die('alloc_err: allocate error')---^compilation aborted for
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90 (code
1)make: *** [../../Obj/arch.make:128: alloc.o] Error 1*


[]'s,

Camps


On Wed, May 13, 2020 at 5:02 PM Nick Papior  wrote:

> Could you try and do (in Util/COOP):
>
> make clean
> make parallel.o
> make
>
> and give me the output if it fails?
>
> Den fre. 8. maj 2020 kl. 22.10 skrev I. Camps :
>
>> Hello SIESTers,
>>
>> I successfully compiled SIESTA with the attached arch.make (link
>> <https://drive.google.com/open?id=128E5AgyuakybDlr2q31TBNICabxvvdO5>).
>>
>> Now, when trying to compile some utilities (COOP, for example), I am
>> getting several errors. The output is attached (link
>> <https://drive.google.com/open?id=1HvuaqcFPALHoNplu_k3wufrx9eNLhMJp>).
>>
>> I will appreciate any help you can provide.
>>
>> Thanks in advance.
>>
>> []'s,
>>
>> Camps
>>
>> --
>> SIESTA is supported by the Spanish Research Agency (AEI) and by the
>> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>>
>
>
> --
> Kind regards Nick
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

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

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

[I. Camps]

Hello SIESTers,

I successfully compiled SIESTA with the attached arch.make (link
).

Now, when trying to compile some utilities (COOP, for example), I am
getting several errors. The output is attached (link
).

I will appreciate any help you can provide.

Thanks in advance.

[]'s,

Camps
ifort  -c -O2 -ipo -xHost -ip -prec-div -prec-sqrt -opt-prefetch 
-mkl=parallel  
-I/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/include 
-I/software/SIESTA_LIBS/netcdf/4.4.1/include -DMPI -UMPI  
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/precision.F
fpp: warning: cannot remove MPI - not a predefined macro
ifort  -c -O2 -ipo -xHost -ip -prec-div -prec-sqrt -opt-prefetch 
-mkl=parallel  
-I/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64/include 
-I/software/SIESTA_LIBS/netcdf/4.4.1/include -DMPI -UMPI  
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90
fpp: warning: cannot remove MPI - not a predefined macro
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(208): 
error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   
[PARALLEL]
  use parallel,  only: Node  ! My processor node index
--^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(212): 
error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   
[SYS]
  use sys,   only: die   ! Termination routine
--^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(213): 
error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   
[M_IO]
  use m_io,  only: io_assign ! Get and reserve an available IO unit
--^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(208): 
error #6580: Name in only-list does not exist.   [NODE]
  use parallel,  only: Node  ! My processor node index
---^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(209): 
error #6580: Name in only-list does not exist.   [NODES]
  use parallel,  only: Nodes ! Number of parallel processors
---^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(210): 
error #6580: Name in only-list does not exist.   [IONODE]
  use parallel,  only: ionode! Am I the I/O processor?
---^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(211): 
error #6580: Name in only-list does not exist.   [PARALLEL_INIT]
  use parallel,  only: parallel_init  ! Initialize parallel variables
---^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(212): 
error #6580: Name in only-list does not exist.   [DIE]
  use sys,   only: die   ! Termination routine
---^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(213): 
error #6580: Name in only-list does not exist.   [IO_ASSIGN]
  use m_io,  only: io_assign ! Get and reserve an available IO unit
---^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(359): 
error #6404: This name does not have a type, and must have an explicit type.   
[NODE]
if (node == 0) then
^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(374): 
error #6406: Conflicting attributes or multiple declaration of name.   
[IO_ASSIGN]
call io_assign(REPORT_UNIT)
-^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(381): 
error #6406: Conflicting attributes or multiple declaration of name.   
[IO_ASSIGN]
call io_assign(REPORT_UNIT)
-^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(2134): 
error #6404: This name does not have a type, and must have an explicit type.   
[NODES]
if (Nodes>1) write(6,'(9x,a,i6)') 'Node:', Node
^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(2206): 
error #6406: Conflicting attributes or multiple declaration of name.   
[PARALLEL_INIT]
call parallel_init()
-^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(2327): 
error #6404: This name does not have a type, and must have an explicit type.   
[IONODE]
  if (ionode) print*, 'alloc_err: allocate status error', ierr
--^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(2327): 
error #6341: A logical data type is required in this context.   [IONODE]
  if (ionode) print*, 'alloc_err: allocate status error', ierr
--^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(2329): 
error #6341: A logical data type is required in this context.   [IONODE]
if (ionode) print*, 'alloc_err: array ', name, &
^
/home/icamps/temp/SIESTA/siesta-4.1-b4/Util/COOP/../../Src/alloc.F90(2332): 
error #6341: A logical data type is 

[SIESTA-L] << new PSML format >>

[I. Camps]

Hello SIESTers,

Which is the real advantage of using SIESTA with the PSML format?
I mean, I know that the general purpose is to have pseudopotentials in a
common format that can be shared/used by different first principle codes.

Regards,

Camps

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

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

[I. Camps]

Please, take a look in section *6.4.4 Input of structural information from
external* files of SIESTA manual (v4.1-b4).


[]'s,

Camps


On Thu, Jan 16, 2020 at 6:00 PM D. Bennett  wrote:

> Dear siesta users,
>
> I have a very quick technical question: is it possible to use a .fdf
> file and specify the lattice and atomic coordinates only from a .XV
> file? When I run with MD.UseSaveXV true and without LatticeVectors and
> AtomicCoordinatesAndAtomicSpecies blocks, siesta complains that I
> haven't specified atomic coordinates. I guess it reads them from the
> .fdf file first and then overwrites from the .XV file?
>
> Thanks,
>
> Danny Bennett
>
> --
> SIESTA is supported by the Spanish Research Agency (AEI) and by the
> European H2020 MaX Centre of Excellence (http://www.max-centre.eu/)
>

-- 
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 model (dispersion correction)

[I. Camps]

Hi,

You can generate several pseudo potentials (from several authors) with the
dispersion correction implement.

[]'s

Camps

Em dom, 22 de set de 2019 17:00, Azadeh Ayatollahie <
azadeh.ayatolla...@gmail.com> escreveu:

> Dear siesta users
>
> Is there DFT-D3 model of Grimme (Grimme et al, J. Chem. Phys. 132, 154104
> (2010)) in siesta package?
>
> Best,
>
> Azadeh
>
>

-- 
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] Input generation regarding

[I. Camps]

Hi Rahul,

If you have xyz, the first column is the atom symbol, so, using a
spreadsheet program, you can interchange it and add it to the far right (or
you can use Notepad++ that is able to copy/cut/paste columns).

Also, the last column in SIESTA input is the number of the atom as in the
species block, not the atom symbol.

[]'s

Camps

Em sáb, 7 de set de 2019 17:01, RAHUL SURESH 
escreveu:

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

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

[I. Camps]

Thank you Nick for your help.

[]'s

Camps

Em qua, 4 de set de 2019 17:00, Nick Papior  escreveu:

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

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

[I. Camps]

Hello SIESTers,

I am trying to analyze the charge transfer when a metal is absorbed on a
surface. In order to do that, I calculated the charges using different
schemes implemented in SIESTA  (Mulliken, Hirshfeld, Voronoi and Bader).

At the end of the output (bellow), I got two values for the Hirshfeld and
Voronoi.

My question is: why did I got two values instead of one?

# Output for Pb

















*Hirshfeld Net Atomic Populations:Atom #Qatom  Species 1   -0.000
 PbVoronoi Net Atomic Populations:Atom #Qatom  Species 1   -0.000
 PbBader Analysis core-charge setup. Radii (standard, H):  1.000
0.600dhscf: Vacuum level (max, mean) =0.0033770.003376 eVHirshfeld
Net Atomic Populations:Atom #Qatom  Species 16.000  PbVoronoi
Net Atomic Populations:Atom #Qatom  Species 16.000  Pb*
# Output for Pb

[]'s,

Camps

Re: [SIESTA-L] Relaxation of borophene nanoribbon

[I. Camps]

I had a similar problem with convergence for other system using boron. The
solution I found was to disable the Pulay mixing, maybe this work for you
too.


[]'s,

Camps


On Wed, Aug 14, 2019 at 5:01 PM Najmeh Honari 
wrote:

>
>
> Dear Siesta Users
>  I am trying to relax 8-pmmn borophene nanoribbon using siesta, but each I 
> could not.
> Here is my fdf files for reference.
>  Please help me with this.
>  Thank You
> .
> SystemName  YBNR
> SystemLabel 9YBNR
>
> ##
> #Basis#
> ##
> PAO.BasisSize   DZP   # Default value
> ##
>
> ##
> #Bandstructure k points#  # Uncomment the following only 
> when you want the bandstructure.
> ##
> #BandLinesScale   ReciprocalLatticeVectors
> #%block BandLines 
> #10.  0.  0.  # K
> #500  0.  0.  0.  # Gamma
> #500  0.5000  0.5000  0.  # M
> #500  0.  0.  0.  # K 
> #%endblock BandLines
>
> ##
> #Sampling k points#
> ##
> %blockkgrid_Monkhorst_Pack  # For DOS calculations use 
> X3. More info on DOS calculation can be found at PDOS analysis section.
>  1000.0
>  0100.0
>  00   100.0
> %endblock kgrid_Monkhorst_pack
>
> 
> #DFT, Grid, SCF#
> 
> SolutionMethod  diagon
> XC.Functional   GGA
> XC.authors  PBE
> SpinPolarized   F   # Default value
> NonCollinearSpinF # Default value
> FixSpin F   # Default value
> TotalSpin   0.0   # Default value
> SingleExcitationF   # Default value
> 
> MeshCutoff  300.0 Ry# Change it according 
> to your case.
> 
> MaxSCFIterations500
> DM.MixingWeight 0.1
> DM.NumberPulay  6
> DM.NumberKick   0
> DM.KickMixingWeight 0.10
> DM.MixSCF1  F   # Default value
> DM.Tolerance0.0001  # Default value
> DM.InitSpinAF   F # Default value (For 
> SpinPolarized=T)
>
> 
> EggboxScale 1 eV# Default value
> 
>
> #
> #Eigenvalue problems#
> #
>
> MD.TypeOfRunCG  # Default value
> MD.VariableCell T   # Default value 
> (First set it to F, then you may want to set it to T!)
> MD.NumCGsteps   300
> MD.MaxCGDispl   0.2 Bohr# Default value
> MD.PreconditionVariableCell 5.0 Ang
> MD.MaxForceTol  0.01 eV/Ang # Default value
>
> 
> #Output options#
> 
> #WriteCoorStep  T   # Writes coordinates 
> to standard output.
> WriteMDhistory  T   # Writes .MD and .MDE 
> files for making animations.
> #WriteForcesT   # Writes forces to 
> standard output.
> WriteDM T   # Writes density 
> matrix to .DM file.
> WriteEigenvaluesF   # Writes the 
> eigenvalues for the sampling k points to .EIG file.
> WriteMDXmol T   # Creates a .ANI file 
> for making animations directly with XMOL.
> WriteCoorXmol T   # Writes a .xyz file 
> readable by XMOL.
> WriteCoorCerius   T   # Writes a .xtl 
> file readable by CERIUS.
>
> 
> WriteDencharT # Writes the .PLD and 
> .DIM files to be used with DENCHAR tool.
> 
>
>
> 
> UseSaveData T
> DM.UseSaveDMT # Use the .DM file from a coarser kpoint 
> calculation to obtain PDOS for a denser kgrid in a second step.
> ON.UseSaveLWF   T
> MD.UseSaveXVT
> MD.UseSaveCGT
> %include POSITIONS.fdf
>
>

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

[I. Camps]

I will recalculate everything again :)

The polarization of my system is not total as shown.

[]'s,

Camps


On Sat, Aug 10, 2019 at 5:01 PM Nick Papior  wrote:

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

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

[I. Camps]

Thanks Nick.

Unfortunately, the only xml output that I have is related to the ion files
:(.

Should I have to re-calculate?

[]'s,

Camps


On Thu, Aug 8, 2019 at 5:00 PM Nick Papior  wrote:

> If you also store the xml output you can get the spin polarization
> information there, key=siesta:stot and key=siesta:svec (only for
> non-colinear).
>
> Den tir. 6. aug. 2019 kl. 22.00 skrev I. Camps :
>
>> Dear SIESTers,
>>
>> In previous versions of SIESTA (aka 3.1), when running a spin polarized
>> calculation, I got in the output the following information:
>>
>> *siesta: Total spin polarization (Qup-Qdown) =0.435246 *
>>
>> Now, running in SIESTA v4.1-b4, I just got:
>>
>> *spin moment: S , {S} =2.0   0.0   0.0   2.0*
>>
>> Is there any other file from were I can got the spin polarization
>> information?
>>
>> Regards,
>>
>> Camps
>>
>
>
> --
> Kind regards Nick
>

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

[I. Camps]

Dear SIESTers,

In previous versions of SIESTA (aka 3.1), when running a spin polarized
calculation, I got in the output the following information:

*siesta: Total spin polarization (Qup-Qdown) =0.435246 *

Now, running in SIESTA v4.1-b4, I just got:

*spin moment: S , {S} =2.0   0.0   0.0   2.0*

Is there any other file from were I can got the spin polarization
information?

Regards,

Camps

Re: [SIESTA-L] pseudopotential

[I. Camps]

Hello,

Did you compile the ATOM program?
(https://departments.icmab.es/leem/siesta/Pseudopotentials/index.html)


[]'s,

Camps


On Wed, Jul 10, 2019 at 5:05 PM batoul  wrote:

> Dear all
>
> I'm trying to generate the pseudopotential but i have this problem .how
> can i fix it
>
>
>
> ../../Utils/pg.sh Si.tm2.inp
> ../../Utils/pg.sh: 45: ../../Utils/pg.sh:
> /home/SIESTA-4.0.2/siesta-4.0.2/Pseudo/atom-4.2.7-100/Tutorial/Utils/../../atm:
>
> not found
> cp: cannot stat 'VPSOUT': No such file or directory
> cp: cannot stat 'VPSFMT': No such file or directory
>
>
> thank you
>
>

Re: [SIESTA-L] Siesta error, regarding

[I. Camps]

Hello Rahul,

The error you are having is because SIESTA is not finding the corresponding
pseudopotentials files.

This consist in two steps:
- You need to insert in your input the information about the
pseudopotentials you want to use.
- You need to put the corresponding files (psf extension) together with
your input file.

As you want to use GGA-PBE, you have to insert something like:

XC.functional GGA
XC.authorsPBE

To obtain the pseudo files, you have different approach. As you are a
beginner, I recommend to download from the site below:
https://departments.icmab.es/leem/siesta/Databases/Pseudopotentials/periodictable-intro.html

Or you can generate your own pseudos using the ATOM program (link
)
or visiting this site: https://www.nnin.org/search/node/pseudopotential

For your question regarding to use PAW, I am afraid SIESTA can not help you
because PAW is not implemented on it (so SIESTA is one of the faster DFT
codes :-)). PAW is implemented in software like Quantum Expresso and ABINIT
(both are free).

[]'s,

Camps


On Wed, Jun 5, 2019 at 5:01 PM RAHUL SURESH  wrote:

> Hi
>
> I got your second comment. Is there any visualizer which could generate
> the coordiantes in the format for siesta code?
>
> About your first comment, I havent mentioned C.hsc anywhere in my fdf file.
>
>
> I have one more querry, I want ot run this simulation with GGA-PBE functional
> and PAW method for core valence interaction. How do I mention that in my
> fdf  file?
>
> Thank you
>
> On Wed, Jun 5, 2019 at 1:30 AM sullah  wrote:
>
>> Just change C.hsc to C in the .fdf file. Also, the block "%block
>> AtomicCoordinatesAndAtomicSpecies" be like
>>
>> x.xxx y. z. 1, where 1 represents N atoms, 2 Catoms, and 3 H
>> atoms as per your input.
>>
>> Best,
>>
>> Em 03.06.2019 07:40, RAHUL SURESH escreveu:
>>
>>
>> Dear Users
>>
>> First time accessing a siesta code. I have managed to make a fdf file for
>> my structure. I end up with error regarding pseudo potential. I have
>> attached my fdf as well as the log file. In fact i saw similar error based
>> threads but I wasn't able to recognise and understand the solution
>> mentioned. The pseudopotential files are taken from the tutorials
>> available.
>>
>> Thank you for your timely help
>>
>> --
>> *Regards,*
>>
>> *Rahul *
>>
>> *Phd *
>>
>>
>>
>
> --
> *Regards,*
> *Rahul *
>

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

[I. Camps]

Hello,

After successfully compiled siesta-4.1-b4, I moved to
*siesta-4.1-b4/Util/TS/TBtrans* in order to compile TBtrans.

Just calling *make*, result in the following errors:



































*local_sys.F(48): error #7002: Error in opening the compiled module file.
Check INCLUDE paths.   [PARALLEL]  use parallel, only :
Node--^local_sys.F(68): error #6406: Conflicting attributes or
multiple declaration of name.   [NODE]  write(6,'(a,i4)') 'Stopping
Program from Node: ',
Node^local_sys.F(69):
error #6406: Conflicting attributes or multiple declaration of name.
[NODE]  write(0,'(a,i4)') 'Stopping Program from Node: ',
Node^local_sys.F(71):
error #6406: Conflicting attributes or multiple declaration of name.
[NODE]  if (Node .eq. 0) then--^local_sys.F(48): error #6580:
Name in only-list does not exist or is not accessible.   [NODE]  use
parallel, only : Node---^local_sys.F(91): error
#7002: Error in opening the compiled module file.  Check INCLUDE paths.
[PARALLEL]  use parallel, only : Node--^local_sys.F(101): error
#6406: Conflicting attributes or multiple declaration of name.
[NODE]  if (Node .eq. 0) then--^local_sys.F(91): error #6580:
Name in only-list does not exist or is not accessible.   [NODE]  use
parallel, only : Node---^local_sys.F(122): error
#7002: Error in opening the compiled module file.  Check INCLUDE paths.
[PARALLEL]  use parallel, only : Node--^local_sys.F(133): error
#6406: Conflicting attributes or multiple declaration of name.
[NODE]  if (Node.eq.0) then--^local_sys.F(122): error #6580:
Name in only-list does not exist or is not accessible.   [NODE]  use
parallel, only : Node---^compilation aborted for
local_sys.F (code 1)../../../Obj/arch.make:118: recipe for target
'local_sys.o' failed*
*make: *** [local_sys.o] Error 1*

Is there a need to modify the *Makefile* or the *arch.make* used to compile
SIESTA?

[]'s,

Camps

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

[I. Camps]

Dear Nick,

After cleaned up the arch.make, I successfully (semi)compiled
siesta-4.1-b4. I wrote (semi) because I got several errors with MUMPS that
I "solved" removing from arch.make.

Thank you very much.

Camps

On Mon, Apr 22, 2019 at 5:01 PM Nick Papior  wrote:

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

Re: [SIESTA-L] Atom binary

[I. Camps]

Hi,

I think you have to got to:
https://departments.icmab.es/leem/siesta/Pseudopotentials/atom_licence.html

In order to get atom.

[]'s,

Camps


On Tue, Apr 23, 2019 at 5:03 PM Максим Арсентьев 
wrote:

> Dear siesta users and developers,
>
>
> Does anybody have binary file for the latest version of atom program.
>
> Bests, Maxim Arsentev,
> ISC RAS
>

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

[I. Camps]

Dear Nick,

I compiled siesta-4.1-b4 with -O1 and used unbuffer as recommended.

It is running with 7 processor since yesterday (almost 24h now) but I can
not see any information in the output file (I imaging that the file will be
updated at the end).

Hopping everything goes well.

[]'s,

Camps


On Tue, Apr 16, 2019 at 5:01 PM Nick Papior  wrote:

> Could you:
>
> 0) Send the FORCE_STRESS file?
> 1) Use siesta-4.1 b4 (you are using b3)
> 2) Add MinSCFIterations 3 to the options
> 3) I would probably try and relax the system a bit first in a
> non-polarized calculation (but this is unrelated to the failure)
>
> Also, you are compiling with Intel -O3 which I typically won't advice.
> Intel compilers are extremely aggressive which may lead to small numerical
> problems. I would stick with -O2 and compile atom.F with -O1.
>
> It seems the output was truncated since the failing call is *after* the
> atoms has been moved. I.e. try this:
> $> unbuffer mpirun -np ... siesta RUN.fdf > RUN.out
> or equivalent, then send the output again.
>
> Den man. 15. apr. 2019 kl. 22.02 skrev I. Camps :
>
>> Hi Nick,
>>
>> Here it is.
>>
>> []'s,
>>
>> Camps
>>
>>
>> On Sun, Apr 14, 2019 at 5:02 PM Nick Papior  wrote:
>>
>>> Could you please do a tar.gz or zip file? rar is horrible ;)
>>>
>>> Den lør. 13. apr. 2019 kl. 22.01 skrev I. Camps :
>>>
>>>> Hello Nick,
>>>>
>>>> Here are the files.
>>>>
>>>> []'s,
>>>>
>>>> Camps
>>>>
>>>>
>>>> On Fri, Apr 12, 2019 at 5:02 PM Nick Papior 
>>>> wrote:
>>>>
>>>>> Could you attach the output, fdf and psf files?
>>>>>
>>>>> Den tor. 11. apr. 2019 kl. 22.01 skrev I. Camps :
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> My system is a nanotube with 123 atoms (B, N, Ni). I am running a
>>>>>> geometry optimization and the calculations are stopped (after 10 CG 
>>>>>> steps)
>>>>>> with the following message:
>>>>>>
>>>>>> "*Sparse pattern is oversubscribed with nodes, please reduce number
>>>>>> of nodes*"
>>>>>>
>>>>>> The calculation are running using 7 and 3 cores (in the same node).
>>>>>> In both cases, the error message is the same.
>>>>>>
>>>>>> System: OpenSUSE 64bits, Intel and siesta-4.1--736
>>>>>>
>>>>>>
>>>>>> I appreciate any help.
>>>>>>
>>>>>> []'s,
>>>>>>
>>>>>> Camps
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Kind regards Nick
>>>>>
>>>>
>>>
>>> --
>>> Kind regards Nick
>>>
>>
>
> --
> Kind regards Nick
>

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

[I. Camps]

Hello,

I am trying to compile siesta in a new box with the following configuration:
OS: Debian 9.8 64bits
Compilers: Intel(R) Fortran Intel(R) 64 Compiler for applications running
on Intel(R) 64, Version 19.0.3.199 Build 20190206
MPI: Intel(R) MPI Library for Linux* OS, Version 2019 Update 3 Build
20190214

I am getting the following error message:




*netcdf_ncdf.f90(59): error #7002: Error in opening the compiled module
file.  Check INCLUDE paths.   [NETCDF]  use
netcdf--^netcdf_ncdf.f90(95): error #8237: The character length in a
component declaration shall either be a colon, be an initialization
expression, or be a specification expression.   [GRP]...*









*netcdf_ncdf.f90(663): error #6404: This name does not have a type, and
must have an explicit type.   [NF90_INQUIRE_DIMENSION]  call
ncdf_err(nf90_inquire_dimension(this%id,i,name=key))^netcdf_ncdf.f90(2964):
catastrophic error: Too many errors, exitingcompilation aborted for
netcdf_ncdf.f90 (code
1)/home/icamps/temp/SIESTA/siesta-4.1-b4/Src/ncdf/smeka/Makefile.compiler:141:
recipe for target 'netcdf_ncdf.o' failedmake[1]: *** [netcdf_ncdf.o] Error
1make[1]: Leaving directory
'/home/icamps/temp/SIESTA/siesta-4.1-b4/tmp-orange/ncdf/obj'Makefile:317:
recipe for target 'libncdf.a' failedmake: *** [libncdf.a] Error 2*

This is driving me crazy as I used the same steps to compile siesta in
other linux boxes (only changing the Intel compilers and MPI versions)

The output from NetCDF and NetCDF-Fortran are:

NetCDF:
This netCDF 4.4.1 has been built with the following features:
  --cc-> mpiicc
  --cflags->  -I/software/LIBS/netcdf-4.4.1/include -fPIC
-I/software/LIBS/hdf5-1.8.12/include -I/include
-I/software/LIBS/pnetcdf-1.11.0/include
  --libs  ->
  --has-c++   -> no
  --cxx   ->
  --has-c++4  -> no
  --cxx4  ->
  --fc->
  --fflags->
  --flibs ->
  --has-f90   -> no
  --has-f03   -> no
  --has-dap   -> yes
  --has-nc2   -> yes
  --has-nc4   -> yes
  --has-hdf5  -> yes
  --has-hdf4  -> no
  --has-logging-> no
  --has-pnetcdf-> yes
  --has-szlib ->
  --prefix-> /software/LIBS/netcdf-4.4.1
  --includedir-> /software/LIBS/netcdf-4.4.1/include
  --version   -> netCDF 4.4.1

NetCDF-Fortran:
This netCDF-Fortran 4.4.4 has been built with the following features:
  --cc-> mpiicc
  --cflags->  -I/software/LIBS/netcdf-fortran-4.4.4/include -fPIC
-DgFortran -I/software/LIBS/hdf5-1.8.12/include -I/include
-I/software/LIBS/netcdf-4.4.1/include
  --fc-> mpiifort
  --fflags-> -I/software/LIBS/netcdf-fortran-4.4.4/include
  --flibs -> -L/software/LIBS/netcdf-fortran-4.4.4/lib -lnetcdff
-lnetcdf -L/lib -Wl,-rpath=/lib -L/software/LIBS/hdf5-1.8.12/lib
-Wl,-rpath=/software/LIBS/hdf5-1.8.12/lib -L/software/LIBS/netcdf-4.4.1/lib
-Wl,-rpath=/software/LIBS/netcdf-4.4.1/lib -lnetcdf -lhdf5hl_fortran
-lhdf5_fortran -lhdf5_hl -lhdf5 -lz
  --has-f90   -> no
  --has-f03   -> yes
  --has-nc2   -> yes
  --has-nc4   -> yes
  --prefix-> /software/LIBS/netcdf-fortran-4.4.4
  --includedir-> /software/LIBS/netcdf-fortran-4.4.4/include
  --version   -> netCDF-Fortran 4.4.4

My arch.make file:












*SIESTA_ARCH=intel-mpi##FC=mpiifortFC_SERIAL=ifortCC=mpiiccCXX=mpicxxRANLIB=ranlibMKLPATH=/opt/intel/mkl/lib/intel64FFLAGS=-O1
-ipo -xHost -ip -prec-div -prec-sqrt -qopt-prefetch -mkl=parallel
-I${MKLROOT}/includeFFLAGS_CHECKS=-g -O0 -debug full -traceback
-CFFLAGS_DEBUG= -gDUMMY_FOX=--enable-dummy*
















































*INCFLAGS += -I/software/LIBS/netcdf-4.4.1/includeLDFLAGS +=
-L/software/LIBS/zlib-1.2.8/lib
-Wl,-rpath=/software/LIBS/zlib-1.2.8/libLDFLAGS +=
-L/software/LIBS/hdf5-1.8.12/lib
-Wl,-rpath=/software/LIBS/hdf5-1.8.12/libLDFLAGS +=
-L/software/LIBS/netcdf-4.4.1/lib
-Wl,-rpath=/software/LIBS/netcdf-4.4.1/libLIBS += -lnetcdff -lnetcdf
-lhdf5_hl -lhdf5 -lzCOMP_LIBS += libncdf.a libfdict.aFPPFLAGS += -DCDF
-DNCDF -DNCDF_4LDFLAGS += -static-intel
-L$(MKLPATH)#MPI_INTERFACE=libmpi_f90.aMPI_INCLUDE=/opt/intel/impi/2019.3.199/intel64/include
# Note . for no-opMPI_LIBS= -L/opt/intel/impi/2019.3.199/intel64/lib
-lmpi_90FPPFLAGS_MPI=-DMPIMETIS_LIB=/software/LIBS/parmetis-4.0.3/lib/libparmetis.aFPPFLAGS
+= -DSIESTA__METIS# MUMPSLIBS += -L/software/LIBS/MUMPS-5.0.2/lib -lzmumps
-lmumps_commonFPPFLAGS += -DSIESTA__MUMPSMKLROOT=${MKLPATH}SUGGESTED_LIBS=
${MKLROOT}/libmkl_blas95_lp64.a ${MKLROOT}/libmkl_lapack95_lp64.a
\${MKLROOT}/libmkl_scalapack_lp64.a \
-Wl,--start-group \ ${MKLROOT}/libmkl_intel_lp64.a
\ ${MKLROOT}/libmkl_sequential.a \
${MKLROOT}/libmkl_core.a \
${MKLROOT}/libmkl_blacs_intelmpi_lp64.a \-Wl,--end-group
\-lm -ldlLIBS=$(SUGGESTED_LIBS) $(NETCDF_LIBS) $(COMP_LIBS)
$(METIS_LIB)#SYS=nagFPPFLAGS= $(FPPFLAGS_CDF) $(FPPFLAGS_MPI)INCFLAGS
+=$(NETCDF_INCFLAGS)#FFLAGS += $(INCFLAGS)#FFLAGS_DEBUG = -g -O1   # your
appropriate flags here...# The atom.f code 

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

[I. Camps]

Hello,

My system is a nanotube with 123 atoms (B, N, Ni). I am running a geometry
optimization and the calculations are stopped (after 10 CG steps) with the
following message:

"*Sparse pattern is oversubscribed with nodes, please reduce number of
nodes*"

The calculation are running using 7 and 3 cores (in the same node). In both
cases, the error message is the same.

System: OpenSUSE 64bits, Intel and siesta-4.1--736


I appreciate any help.

[]'s,

Camps

Re: [SIESTA-L] kpoints inside Gamma-M-K-Gamma

[I. Camps]

The data looks like representing the path K -> Gamma -> M -> K:
(b1/3 b2/3 0) -> (0 0 0 ) -> (b1/2 0 0) -> (b1/3 b2/3 0

[]'s,

Camps


On Thu, Mar 28, 2019 at 6:03 PM ziba torkashvand 
wrote:

> Thank you very much. your explanation is exactly what I mean. Now my
> question: from M to K is the value of kx must be constant and again for
> ky repeat the above procedure or something else. If yes, I can not see this
> trend in the attached data after G to M path because the value of kx is
> increasing.
>
> Cheers,
> Ziba Torkashvand
>
> [image: Mailtrack]
> <https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
>  Sender
> notified by
> Mailtrack
> <https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;>
>  03/28/19,
> 12:34:57 PM
>
> On Thu, Mar 28, 2019 at 1:52 AM I. Camps  wrote:
>
>> Dear Ziba,
>>
>> I think I get what are you asking for.
>>
>> Following the reference (10.1016/j.commatsci.2010.05.010
>> <http://dx.doi.org/10.1016/j.commatsci.2010.05.010>) we have for the
>> hexagonal lattice (table 13):
>> Gamma point: 0 0 0
>> M point: b1/2 0 0
>> (b1, b2, b3 are the lattice parameters).
>>
>> In order to build the path between Gamma and M, you need to specify a
>> number of points N and calculated the steps.
>>
>> Let put N=5 and b1=10:
>> You need to calculated the numerical points between kx_initial = 0 (from
>> GAMMA)  and kx_final = b1/2 (from M). In this example between 0 and 5:
>> kx_i = i * (kx_final - kx_initial) / N
>> kx_i = i * (b1/2 - 0) / N
>> kx_i = i * (b1/2) / N
>> kx_i = i * 1
>> (i=0 to N)
>>
>> Giving:
>> 0 0 0 (Gamma)
>> 1 0 0
>> 2 0 0
>> 3 0 0
>> 4 0 0
>> 5 0 0 (M)
>>
>> []'s,
>>
>> Camps
>>
>>
>> On Tue, Mar 26, 2019 at 6:14 PM  wrote:
>>
>>>
>>> Sym points are governed by the lattice vectors. Please read kittel' book
>>> on solid state physics chapters 1 and 2
>>>
>>>
>>> > Thank you for your response. I see but in this references, the high
>>> > symmetry points are provided just in term of lattice vectors now, my
>>> > question is how kx, ky, and kz are vary along this pathes? I have
>>> found a
>>> > file with some data (below) but I can't find my understood relation
>>> > (mensioned in my previous email) between these data for Hexagonal
>>> lattice.
>>> >
>>> > 0.500 0.2887000 0
>>> >
>>> > 0.4930556 0.28469027778 0
>>> >
>>> > 0.486 0.2806806 0
>>> >
>>> > 0.4791667 0.2766708 0
>>> >
>>> > 0.472 0.2726611 0
>>> >
>>> > 0.4652778 0.26865138889 0
>>> >
>>> > 0.458 0.2646417 0
>>> >
>>> > 0.4513889 0.2606319 0
>>> >
>>> > 0.444 0.2566222 0
>>> >
>>> > 0.4375000 0.2526125 0
>>> >
>>> > 0.4305556 0.2486028 0
>>> >
>>> > 0.4236111 0.24459305556 0
>>> >
>>> > 0.417 0.2405833 0
>>> >
>>> > 0.4097222 0.2365736 0
>>> >
>>> > 0.4027778 0.2325639 0
>>> >
>>> > 0.3958333 0.22855416667 0
>>> >
>>> > 0.389 0.2245444 0
>>> >
>>> > 0.3819444 0.2205347 0
>>> >
>>> > 0.375 0.2165250 0
>>> >
>>> > 0.3680556 0.21251527778 0
>>> >
>>> > 0.361 0.2085056 0
>>> >
>>> > 0.3541667 0.2044958 0
>>> >
>>> > 0.347 0.2004861 0
>>> >
>>> > 0.3402778 0.19647638889 0
>>> >
>>> > 0.333 0.1924667 0
>>

Re: [SIESTA-L] kpoints inside Gamma-M-K-Gamma

[I. Camps]

Please, take look in the main reference paper at the link below, it has all
the high symmetry points to build your path.

Link: https://en.m.wikipedia.org/wiki/Brillouin_zone

[]'s

Camps

Em sáb, 23 de mar de 2019 18:03, ziba torkashvand 
escreveu:

> Dear all SIESTA users,
> I'm trying to find kpoint coordinates (kx,ky,kz) inside the
> Gamma-M-K-Gamma path for my structure. I have found kpoints coordinates in
> siesta output file. I think the kpoints coordinates  in a hexagonal
> structure must have a trend as below
> in Gamma-M path kx must be increasing and ky is zero
> in M-K path kx is constant equal to the last point in Gamma-M path and ky
> is increasing
> in K-Gamma both kx and ky are decreasing.
> however, my band structure is the same as reported in papers kx and ky in
> output file don't have the same trend as above. I want to know if I'm in
> wrong or my input fule has problem.
>
> Cheers,
> Ziba Torkashvand
>
> [image: Mailtrack]
> 
>  Sender
> notified by
> Mailtrack
> 
>  03/23/19,
> 8:16:02 PM
>

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

[I. Camps]

Thanks Nick and Sushilfor the suggestions.

[]'s,

Camps


On Tue, Feb 5, 2019 at 7:05 PM Nick Papior  wrote:

> These messages are written to std-out and std-err.
>
> Simply do:
>
> siesta ... 2>/dev/null &
>
> If you want to suppress those messages from stderr while running in the
> background.
>
> Den man. 4. feb. 2019 kl. 22.04 skrev I. Camps :
>
>> Hi SIESTers,
>>
>> I would like to know how to avoid the output from SIESTA that is directed
>> to the terminal window.
>>
>> After sending a calculation to run in background, I am getting message
>> like these:
>>
>> Gamma-point calculation with multiply-connected orbital pairs
>> Folding of H and S implicitly performed
>>
>> I am using siesta_4.1-b4. In previous versions and with the same system I
>> did not get such messages.
>>
>> Regards,
>>
>> Camps
>>
>
>
> --
> Kind regards Nick
>

Re: [SIESTA-L] Calculating the charge density

[I. Camps]

Dear Vardha,

Take a look at the SIESTA manual. Section 6.17, page. 88 (SIESTA 4.1-b3
manual) shows you how to implement different calculation charge schemes
like Mulliken, Voronoi and Hirshfeld.

[]'s,

Camps


On Thu, Dec 6, 2018 at 7:00 PM Suvardhan Jonnalagadda <
j.su.vard...@gmail.com> wrote:

> Dear All,
>
> I am new to Siesta, and I want to calculate the charge density of a
> periodic framework. From this charge density, I want to calculate the
> partial charges of the atoms in the framework. Can someone share a sample
> input file, and explain how to start with.
>
> Thanks and best regards,
> Vardhan,
> Research Scholar,
> India
>

Re: [SIESTA-L] [***Posible SPAM***]<< convergence problems BN+Ni >>

[I. Camps]

Salvador,

The system is 7.83Angs in diameter and 12.78Angs in length. I already
worked with carbon nanotubes with similar sizes and with the same
combinations of metals without any problems.

[]'s,

Camps


On Fri, Nov 30, 2018 at 7:08 PM Salvador Barraza-Lopez 
wrote:

>  This will be a not too specific comment and I have not looked into your
> atomic system, but if your system dimensions are too dissimilar; i.e., if
> the tube is too long, then you have a cycle of charge moving into and out
> of your Ni atom, this process gets larger the longer an asymmetric
> dimension is. I have seen this in multiple systems that have one direction
> that is, say, orders of magnitude larger than the other two. This could be
> aggravated if the forces are too large, this is, if the structural
> optimization is not very strict.
>
>
> So I would look at forces first, and maybe approach the Ni atom slowly
> into the tube *by hand*, using the DM from the previous *ionic* step to get
> you going.
>
>
>  Hopefully, these comments are useful.
>
>
> -Salvador
> ------
> *From:* siesta-l-requ...@uam.es  on behalf of I.
> Camps 
> *Sent:* Thursday, November 29, 2018 11:23:50 AM
> *To:* siesta-l@uam.es
> *Subject:* Re: [SIESTA-L] [***Posible SPAM***]<< convergence problems
> BN+Ni >>
>
> Dear Leonardo,
>
> Thank you for your advise.
>
> Unfortunately, your suggestions did not work :(
>
> []'s,
>
> Camps
>
>
> On Wed, Nov 28, 2018 at 7:04 PM Leonardo Fonseca 
> wrote:
>
> You could try a smaller mixing parameter. Currently you are using
> DM.MixingWeight 0.01. You could try 0.005 or even 0.001. If it works then
> you can increase it back to see at which value convergence is lost.
>
> Em ter, 27 de nov de 2018 às 19:02, I. Camps  escreveu:
>
> Hello SIESTers,
>
> I am starting doing calculations with boron nitride nanotube interacting
> with nickel.
>
> My problem is that SCF calculations are not converging for even 1500 steps!
>
> I am using several mesh cutoff energies (between 150 and 650 Ry) but the
> problem persists.
>
> The input, pseudopotentials and output files are attached to this email
> (and can be download from the link
> https://drive.google.com/open?id=1s3Z-kQWcNptvGMX3pM7dbTR2FpVZLX74
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-3Fid-3D1s3Z-2DkQWcNptvGMX3pM7dbTR2FpVZLX74=DwMFaQ=7ypwAowFJ8v-mw8AB-SdSueVQgSDL4HiiSaLK01W8HA=d_wByFh562xnF38KR6av_HxjWbFMw90KK5BKq2dwiQc=8vdXSd45w4M0hHp4CImKWXV-yNpYNLjf6GzeVD2y6A8=yp0Mc62NicI6eDUsFqLpn_757uWL9lVgtOFM-f4-pUU=>
> ).
>
> Any help, ideas are welcome.
>
> Regards,
>
> Camps
>
>

Re: [SIESTA-L] << error compiling in Intel processors >>

[I. Camps]

Thank you very much Nick. It worked!

[]'s,

Camps


On Thu, Nov 29, 2018 at 7:00 PM Nick Papior  wrote:

> Try these flags instead:
>
> FFLAGS = -m64 -fPIC -O2 -xHost -prec-div -prec-sqrt -fp-model source
>
> Sadly intel compilers are relatively buggy, and especially so for high
> optimization (-O3).
>
> Den ons. 28. nov. 2018 kl. 22.02 skrev I. Camps :
>
>> Hello,
>>
>> I successfully compiled siesta-4.1-b4 in an AMD box with OpenSUSE+Intel
>> (compiler+MPI).
>>
>> Now, when compiling in an Intel box (same software), I got the error:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *010101_13492fortcom: Severe: **Internal compiler error: internal abort**
>> Please report this error along with the circumstances in which it occurred
>> in a Software Problem Report.  Note: File and line given may not be
>> explicit cause of this error.ipo-4: error #11005: multi-object compilation
>> 3 returned error status 3ifort: error #10014: problem during multi-file
>> optimization compilation (code 3)Makefile:493: recipe for target 'siesta'
>> failedmake: *** [siesta] Error 3*
>> My arch.make file is:
>> # This file is part of the SIESTA package.
>> #
>> # Copyright (c) Fundacion General Universidad Autonoma de Madrid:
>> # E.Artacho, J.Gale, A.Garcia, J.Junquera, P.Ordejon, D.Sanchez-Portal
>> # and J.M.Soler, 1996- .
>> #
>> #
>> # 
>> #
>> # Execution:
>> #
>> #   mpirun -np NPROCS siesta 
>> #
>> SIESTA_ARCH=intel-mpi
>> #
>> #
>> FC=mpiifort
>> FC_SERIAL=ifort
>> CC=mpiicc
>> CXX=mpicxx
>> RANLIB=ranlib
>>
>> MKLPATH=/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64
>> #
>> #  You can play with other optimization options
>> #  I am not sure whether the compiler attempts to multithread the code
>> #
>> #CPP = $(FC) -P -E
>> #FFLAGS= -w  -O2 -mp
>> FFLAGS=-O3 -ipo -xHost -ip -prec-div -prec-sqrt -opt-prefetch
>> -mkl=parallel  -I${MKLROOT}/include
>> FFLAGS_CHECKS=-g -O0 -debug full -traceback -C
>> FFLAGS_DEBUG= -g
>> #COMP_LIBS += libncdf.a libfdict.a
>> #RANLIB=echo
>> #
>> # You might want to turn off FoX for Intel11
>> #
>> DUMMY_FOX=--enable-dummy
>> #
>> #
>>
>> INCFLAGS += -I/software/SIESTA_LIBS/netcdf/4.4.1/include
>> LDFLAGS += -L/software/SIESTA_LIBS/zlib/1.2.8/lib
>> -Wl,-rpath=/software/SIESTA_LIBS/zlib/1.2.8/lib
>> LDFLAGS += -L/software/SIESTA_LIBS/hdf5/1.8.16/lib64
>> -Wl,-rpath=/software/SIESTA_LIBS/hdf5/1.8.16/lib64
>> LDFLAGS += -L/software/SIESTA_LIBS/netcdf/4.4.1/lib64
>> -Wl,-rpath=/software/SIESTA_LIBS/netcdf/4.4.1/lib64
>> LIBS += -lnetcdff -lnetcdf -lhdf5_hl -lhdf5 -lz
>> COMP_LIBS += libncdf.a libfdict.a
>> FPPFLAGS += -DCDF -DNCDF -DNCDF_4
>> LDFLAGS += -static-intel -L$(MKLPATH)
>>
>> #
>> MPI_INTERFACE=libmpi_f90.a
>> MPI_INCLUDE=/software/intel/MPI/compilers_and_libraries_2017.1.132/linux/mpi/intel64/include
>> # Note . for no-op
>> MPI_LIBS=
>> -L/software/intel/MPI/compilers_and_libraries_2017.1.132/linux/mpi/intel64/lib
>> -lmpi_90
>> FPPFLAGS_MPI=-DMPI
>>
>> METIS_LIB=/software/SIESTA_LIBS/parmetis-4.0.3/lib/libparmetis.a
>> FPPFLAGS += -DSIESTA__METIS
>>
>> # MUMPS
>> LIBS += -L/software/SIESTA_LIBS/MUMPS-5.0.2/lib -lzmumps -lmumps_common
>> FPPFLAGS += -DSIESTA__MUMPS
>> #
>> # From the "Intel advisor"
>> #
>> #MKLPATH=/mnt/SoftIns/intel/composer_xe_2015.1.133/mkl/lib/intel64
>> #SUGGESTED_LIBS=$(MKLPATH)/libmkl_scalapack_ilp64.a \
>> #   -Wl,--start-group \
>> #  $(MKLPATH)/libmkl_blacs_intelmpi_ilp64.a \
>> #  $(MKLPATH)/libmkl_sequential.a \
>> #  $(MKLPATH)/libmkl_intel_ilp64.a \
>> #  $(MKLPATH)/libmkl_core.a \
>> #  $(MKLPATH)/libmkl_intel_thread.a \
>> #  $(MKLPATH)/libmkl_blacs_intelmpi_ilp64.a \
>> #   -Wl,--end-group \
>> #   -lpthread
>> #
>> MKLROOT=${MKLPATH}
>> SUGGESTED_LIBS= ${MKLROOT}/libmkl_blas95_lp64.a
>> ${MKLROOT}/libmkl_lapack95_lp64.a \
>> ${MKLROOT}/libmkl_scalapack_lp64.a \
>> -Wl,--start-group \
>>  ${MKLROOT}/libmkl_intel_lp64.a \
>>  ${MKLROOT}/libmkl_sequential.a \
>>  ${MKLROOT}/libmkl_core.a \
>>  ${MKLROOT}/libmkl_blacs_intelmpi_lp64.a \
>>

Re: [SIESTA-L] [***Posible SPAM***]<< convergence problems BN+Ni >>

[I. Camps]

Dear Leonardo,

Thank you for your advise.

Unfortunately, your suggestions did not work :(

[]'s,

Camps


On Wed, Nov 28, 2018 at 7:04 PM Leonardo Fonseca 
wrote:

> You could try a smaller mixing parameter. Currently you are using
> DM.MixingWeight 0.01. You could try 0.005 or even 0.001. If it works then
> you can increase it back to see at which value convergence is lost.
>
> Em ter, 27 de nov de 2018 às 19:02, I. Camps  escreveu:
>
>> Hello SIESTers,
>>
>> I am starting doing calculations with boron nitride nanotube interacting
>> with nickel.
>>
>> My problem is that SCF calculations are not converging for even 1500
>> steps!
>>
>> I am using several mesh cutoff energies (between 150 and 650 Ry) but the
>> problem persists.
>>
>> The input, pseudopotentials and output files are attached to this email
>> (and can be download from the link
>> https://drive.google.com/open?id=1s3Z-kQWcNptvGMX3pM7dbTR2FpVZLX74).
>>
>> Any help, ideas are welcome.
>>
>> Regards,
>>
>> Camps
>>
>>

[SIESTA-L] << error compiling in Intel processors >>

[I. Camps]

Hello,

I successfully compiled siesta-4.1-b4 in an AMD box with OpenSUSE+Intel
(compiler+MPI).

Now, when compiling in an Intel box (same software), I got the error:










*010101_13492fortcom: Severe: **Internal compiler error: internal abort**
Please report this error along with the circumstances in which it occurred
in a Software Problem Report.  Note: File and line given may not be
explicit cause of this error.ipo-4: error #11005: multi-object compilation
3 returned error status 3ifort: error #10014: problem during multi-file
optimization compilation (code 3)Makefile:493: recipe for target 'siesta'
failedmake: *** [siesta] Error 3*
My arch.make file is:
# This file is part of the SIESTA package.
#
# Copyright (c) Fundacion General Universidad Autonoma de Madrid:
# E.Artacho, J.Gale, A.Garcia, J.Junquera, P.Ordejon, D.Sanchez-Portal
# and J.M.Soler, 1996- .
#
#
# 
#
# Execution:
#
#   mpirun -np NPROCS siesta 
#
SIESTA_ARCH=intel-mpi
#
#
FC=mpiifort
FC_SERIAL=ifort
CC=mpiicc
CXX=mpicxx
RANLIB=ranlib
MKLPATH=/software/intel/compiladores/composer_xe_2015.1.133/mkl/lib/intel64
#
#  You can play with other optimization options
#  I am not sure whether the compiler attempts to multithread the code
#
#CPP = $(FC) -P -E
#FFLAGS= -w  -O2 -mp
FFLAGS=-O3 -ipo -xHost -ip -prec-div -prec-sqrt -opt-prefetch
-mkl=parallel  -I${MKLROOT}/include
FFLAGS_CHECKS=-g -O0 -debug full -traceback -C
FFLAGS_DEBUG= -g
#COMP_LIBS += libncdf.a libfdict.a
#RANLIB=echo
#
# You might want to turn off FoX for Intel11
#
DUMMY_FOX=--enable-dummy
#
#

INCFLAGS += -I/software/SIESTA_LIBS/netcdf/4.4.1/include
LDFLAGS += -L/software/SIESTA_LIBS/zlib/1.2.8/lib
-Wl,-rpath=/software/SIESTA_LIBS/zlib/1.2.8/lib
LDFLAGS += -L/software/SIESTA_LIBS/hdf5/1.8.16/lib64
-Wl,-rpath=/software/SIESTA_LIBS/hdf5/1.8.16/lib64
LDFLAGS += -L/software/SIESTA_LIBS/netcdf/4.4.1/lib64
-Wl,-rpath=/software/SIESTA_LIBS/netcdf/4.4.1/lib64
LIBS += -lnetcdff -lnetcdf -lhdf5_hl -lhdf5 -lz
COMP_LIBS += libncdf.a libfdict.a
FPPFLAGS += -DCDF -DNCDF -DNCDF_4
LDFLAGS += -static-intel -L$(MKLPATH)

#
MPI_INTERFACE=libmpi_f90.a
MPI_INCLUDE=/software/intel/MPI/compilers_and_libraries_2017.1.132/linux/mpi/intel64/include
# Note . for no-op
MPI_LIBS=
-L/software/intel/MPI/compilers_and_libraries_2017.1.132/linux/mpi/intel64/lib
-lmpi_90
FPPFLAGS_MPI=-DMPI

METIS_LIB=/software/SIESTA_LIBS/parmetis-4.0.3/lib/libparmetis.a
FPPFLAGS += -DSIESTA__METIS

# MUMPS
LIBS += -L/software/SIESTA_LIBS/MUMPS-5.0.2/lib -lzmumps -lmumps_common
FPPFLAGS += -DSIESTA__MUMPS
#
# From the "Intel advisor"
#
#MKLPATH=/mnt/SoftIns/intel/composer_xe_2015.1.133/mkl/lib/intel64
#SUGGESTED_LIBS=$(MKLPATH)/libmkl_scalapack_ilp64.a \
#   -Wl,--start-group \
#  $(MKLPATH)/libmkl_blacs_intelmpi_ilp64.a \
#  $(MKLPATH)/libmkl_sequential.a \
#  $(MKLPATH)/libmkl_intel_ilp64.a \
#  $(MKLPATH)/libmkl_core.a \
#  $(MKLPATH)/libmkl_intel_thread.a \
#  $(MKLPATH)/libmkl_blacs_intelmpi_ilp64.a \
#   -Wl,--end-group \
#   -lpthread
#
MKLROOT=${MKLPATH}
SUGGESTED_LIBS= ${MKLROOT}/libmkl_blas95_lp64.a
${MKLROOT}/libmkl_lapack95_lp64.a \
${MKLROOT}/libmkl_scalapack_lp64.a \
-Wl,--start-group \
 ${MKLROOT}/libmkl_intel_lp64.a \
 ${MKLROOT}/libmkl_sequential.a \
 ${MKLROOT}/libmkl_core.a \
 ${MKLROOT}/libmkl_blacs_intelmpi_lp64.a \
-Wl,--end-group \
-lm -ldl

LIBS=$(SUGGESTED_LIBS) $(NETCDF_LIBS) $(COMP_LIBS) $(METIS_LIB)
#
SYS=nag
FPPFLAGS= $(FPPFLAGS_CDF) $(FPPFLAGS_MPI)
INCFLAGS +=$(NETCDF_INCFLAGS)
#FFLAGS += $(INCFLAGS)
#
FFLAGS_DEBUG = -g -O1   # your appropriate flags here...

# The atom.f code is very vulnerable. Particularly the Intel compiler
# will make an erroneous compilation of atom.f with high optimization
# levels.
atom.o: atom.F
$(FC) -c $(FFLAGS_DEBUG) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_fixed_F) $<

.c.o:
$(CC) -c $(CFLAGS) $(INCFLAGS) $(CPPFLAGS) $<
.F.o:
$(FC) -c $(FFLAGS) $(INCFLAGS)  $(FPPFLAGS) $<
.f.o:
$(FC) -c $(FFLAGS) $(INCFLAGS)   $<
.F90.o:
$(FC) -c $(FFLAGS) $(INCFLAGS)  $(FPPFLAGS) $<
.f90.o:
$(FC) -c $(FFLAGS) $(INCFLAGS)  $(FPPFLAGS) $<

[]'s,

Camps

Re: [SIESTA-L] online tool for the generation of DFT05 .ion files

[I. Camps]

That's so a great news!

Congratulations.

Just one question: it will work with any Siesta version?

Regards,

Camps

Em qua, 19 de set de 2018 17:09, Leonardo Fonseca 
escreveu:

> Dear Siesta users,
>
> It is our pleasure to inform the creation of a new online tool for
> generating modified .ion files for DFT05 calculations based on the original
> paper of Guimaraes et al. (PRB 78, 125116 (2008)). DFT05 is an efficient
> and accurate technique for the correction of band gaps of semiconductors
> and insulators, ideal for calculations of large systems where other
> techniques are numerically impractical. The new tool includes not only the
> original LDA-1/2 and GGA-1/2, but also shLDA-1/2, shGGA-1/2 and shLDA-x-y
> (Xue et al., CMS 153, 493 (2018)):
>
> http://www.eedevice.com/dft-half
>
> To use it the user provides the original .ion file and the desired range
> of cutoff radii, and obtains in return a set of modified .ion files, one
> for each cutoff radius. The modified .ion files can be used in simple bulk
> calculations to quickly identify the optimal cutoff radius, i.e., the one
> that maximizes the band gap, which is then transferred to the system of
> interest. The online tool can assist both Siesta and Vasp users.
>
> We will be happy to to answer any questions that may arise.
>
> Best regards,
>
> Kan-Hao Xue
> Huazhong University of Science and Technology, China
> x...@hust.edu.cn
>
> Leonardo R. C. Fonseca
> Universidade Federal de Minas Gerais, Brazil
> fonsecal...@gmail.com
>

Re: [SIESTA-L] << SIESTA wavefunction -> Multiwfn >>

[I. Camps]

Hi Peter,

Yeah, unfortunately, Multiwfn needs the wavefunctions in Gassian form.

Here is the comment of Multiwfn developer:

*Dear Camps,*

*Unfortunately, this cannot be easily realized. AFAIK, Siesta employs
numerical basis set, however, to carry out wavefunction analysis in
Multiwfn, the wavefunction must be represented by Gaussian type functions
(GTFs).*

*Best regards,*

*Tian*

[]'s,

Camps


On Tue, Aug 21, 2018 at 5:01 PM Peter Koval  wrote:

> http://sobereva.com/multiwfn/
>
> It seems there are only Gaussian orbitals in the data files? No?
> On Wed, Aug 15, 2018 at 10:05 PM I. Camps  wrote:
> >
> > Hello SIESTers,
> >
> > I was wondering if there is any tool that can convert the wavefunction
> file obtained from SIESTA to a format recognized by Multiwfn software (
> http://sobereva.com/multiwfn/).
> >
> > Multiwfn is a free extremely powerful program for realizing electronic
> wavefunction analysis.
> >
> > []'s,
> >
> > Camps
>

[SIESTA-L] << SIESTA wavefunction -> Multiwfn >>

[I. Camps]

Hello SIESTers,

I was wondering if there is any tool that can convert the wavefunction file
obtained from SIESTA to a format recognized by Multiwfn software (
http://sobereva.com/multiwfn/).

Multiwfn is a free extremely powerful program for realizing electronic
wavefunction analysis.

[]'s,

Camps

Re: [SIESTA-L] Optical properties

[I. Camps]

Sorry, but what an antenna software has to do with SIESTA?

[]'s,

Camps


On Mon, Jun 18, 2018 at 5:01 PM Nadia Salami  wrote:

> سلام
>
> خوشبختانه مشکل حل شد.
>
>
> با احترام
> سلامی
>
> On Sat, Jun 16, 2018 at 9:36 PM, Nadia Salami 
> wrote:
>
>> Dear Siesta users
>>
>> I want to calculate the optical properties of some molecules.
>>
>>
>>
>> In order to compile input.f code at Optical folder, the following command
>> is written in the terminal:
>> "gfortran optical.f -o optical"
>>
>>
>>
>> But it sounds that installing yagiuda requires using the following
>> command:
>> "sudo apt-get install yagiuda"
>>
>> After its installation, the input.f code is installed. But the following
>> error occurs, when the command "input < Systemlabel.EPSIMG" is typed:
>>
>>
>> “Yagi-Uda antenna analysis programs, version 1.19
>> Written by Dr. David Kirkby Ph.D. (G8WRB, email:david.kir...@onetel.net)
>>
>> This program asks for length, diameter and position of antenna elements
>> then
>> writes them to a file you specify. Data is written in m (metres)
>>
>> Numerical Recipes run-time error...
>> The minimum frequency has been set higher than the centre frequency
>> ...now exiting to system...
>> Enter any notes on this design (up to 400 characters): Enter a filename
>> to write data to Enter the centre frequency in MHz Enter the minimum
>> frequency in MHz Enter the maximum frequency in MHz Enter the frequency
>> steps in MHz “
>>
>>
>>
>>
>> However, solving this problem had been asked previously, but I don't find
>> an answer.
>>
>>
>>
>> Your help is highly appreciated to get rid of the problem.
>>
>> Thanks in advance,
>>
>> Kind regards
>>
>> Nadia Salami
>>
>>
>

[SIESTA-L] << plugin for Notepad++ >>

[I. Camps]

Hello,

Does anyone knows if there is a SIESTA code plugin for Notepad++?

[]'s,

Camps

Re: [SIESTA-L] Spin polarised band structure

[I. Camps]

Dear Sunetra,

SIESTA do not plot anything, it "only" calculates.

To plot, you should use gnuplot, xmgrace, Origin, etc.

Em seg, 30 de abr de 2018 17:00, Sunetra Das 
escreveu:

> Dear fellow SIESTA users,
>
> I would like to know if SIESTA can plot spin-polarized band structure of a
> given system? In which of the latest version of the software can I find the
> feature to draw spin-polarized band structure? Any help is highly
> appreciated.
>
> Thanks in advance.
>
> Regards,
> Sunetra Das
>
-- 

[]`s

Camps

Re: [SIESTA-L] Bands at lower energies

[I. Camps]

You can't change/fix were the Fermi level is. The Fermi level is the
electron chemical potential, so it depends on the number of electrons in
the system.

What some people does is to "normalize" it to zero, but this doesn't change
its  relative position to the bands.

They only thing that occurs now is doing a polarized calculation (as it
treat the electrons with different spins, different).

Em qui, 1 de fev de 2018 19:07, Sunetra Das 
escreveu:

> Dear all Siesta users,
>
> I am trying to calculate and reproduce the band structure for a certain 2D
> system. The band structure of the system has already been calculated using
> a different software and published. Even though the band structure remains
> the same when calculated using Siesta, the bands are forming at lower
> energy values with respect to the Fermi level.
> How to correct this mismatch and get the bands at their correct energies?
> In my calculation the Fermi level lies near the conduction band whereas in
> the already published data the Fermi level lies very close to the valence
> band. Is there any way to correct for this discrepancy?
> The calculations have been performaned in GGA-PBE exchange correlation
> functional as was done in published data.
> Any suggestion is humbly appreciated.
>
> Thankfully,
> Sunetra Das.
>


-- 

[]`s

Camps

Re: [SIESTA-L] DFT-1/2 vs DFT-U

[I. Camps]

I think that one good answer could be that, at least with LDA-1/2, the
semiconductors bandgap prediction are very good. They are in accordance
with experimental values (without any "extra" parametrization as in LDA-U).

Em sex, 26 de jan de 2018 19:01, Julian Niño 
escreveu:

> why?
>
> 2018-01-25 3:40 GMT-03:00 berna uyanık :
>
>> Hi, again. I used both DFT-1/2 and DFT-U methods to calculate ZnO band
>> gap. I think the first method is more succesful. Then, siesta should
>> include DFT-1/2 method. Best.
>>
>
>
>
> --
>
> -
>
> -
>
> -
>
> -
>
> -
>
> -
>


-- 

[]`s

Camps

Re: [SIESTA-L] Changing the crystal direction of Si

[I. Camps]

As a crystal is a 3D periodic system, it grows in all directions (and has
many crystallographic directions, all together), so, you can not change the
direction of a crystal.

What you can do is to change the cell used to model the crystal. You can
use the unit cell, the primitive cell, the Wigner–Seitz cell or even, a
supercell (depending on your needs).
To a very, very simple ideas take a look at:
https://en.wikipedia.org/wiki/Crystal_structure
https://en.wikipedia.org/wiki/Primitive_cell
https://en.wikipedia.org/wiki/Wigner%E2%80%93Seitz_cell

(Note: I do not advice to use Wikipedia as your only or final source of
information)

I suggest you read some Solid State Physics or Crystallographic books
before enter the (nano)word of solid state simulations.

[]'s,

Camps


On Wed, Jan 17, 2018 at 7:00 AM, Alaa Akkoush (Student)  wrote:

> I have build the Silicon which has diamond structure and calculate it's
> dispersion relation.
>
> I set the lattice vectors those of fcc and place two silicon atoms one at
> 0 and other at (0.25,0.25,0.25)
>
> as follows:
>
>
> %block LatticeVectors
> 0.0 0.5 0.5
> 0.5 0.0 0.5
> 0.5 0.5 0.0
> %endblock LatticeVectors
>
> %block AtomicCoordinatesAndAtomicSpecies
>  0.000.000.00   1   28.0855
>  0.250.25   0.251   28.0855
> %endblock AtomicCoordinatesAndAtomicSpecies
>
> I want to *CHANGE THE CRYSTAL DIRECTION TO <1 0 0>,* so i changed the
> lattice vector to
>
> %block LatticeVectors
> 1.0 0.0 0.0
> 0.0 1.0 0.0
> 0.0 0.0 1.0
> %endblock LatticeVectors
>
> But the system is unstable!!!
> Any help?
>
>
>
>

Re: [SIESTA-L] How to set ghost atoms in BSSE correction

[I. Camps]

Dear Bibhas,

You have to change not the individual atoms but the whole molecule/system.
In your case, you have to do a calculation with NO2 + BN(ghost sheet) and
NO2(ghost molecule) + BN.


[]'s,

Camps

On Wed, Jan 17, 2018 at 9:26 AM, Bibhas Manna  wrote:

> Dear Siesta users,
>
> I am very new to calculate BSSE correction in Siesta. I am following the
> steps as suggested by Abraham Hmiel
> 
> found in the siesta mail archive (https://www.mail-archive.com/
> siesta-l@uam.es/msg02916.html). However, I have a little doubt in setting
> the ghost atoms.
>
> Suppose, my system is nitrogen-dioxide molecule adsorbed on the
> Boron-Nitride (BN) sheet. First I have calculated energies of the three
> relaxed systems (NO2 with BN, only NO2 and only BN sheet)  separately. Now,
> for the energy calculation with  ghost atom in case of NO2, should I need
> to use ghost atoms for the nitrogen species or the oxygen species or the
> both?? Similarly for the calculation with ghost atom in case of BN sheet,
> should I use only ghost atom of the boron or the nitrogen or the both ??
>
>
> Any help in this regard will be highly appreciated.
>
> Thanking you.
> With regards,
> Bibhas
>

Re: [SIESTA-L] doping

[I. Camps]

Dear Masoudeh,

Be aware that doping is not the same of make atom substitution. We talk in
doping when the doping concentration is << that the system atom
concentrations. Using a 2x2x2 supercell will not give the decided
proportions in concentrations, so, you are simulating a ternary alloy
system TiOX.

Also, in working with alloys or doping, a big issue is to decide where to
"put/add" the third atom (in this case). There are techniques like
quase-random structure theory that can help with this.

Regarding your questions:

> 1. After doping should I find optimized lattice constant or optimized
> lattice constant of pure structure is acceptable?
>
If you know how your system behave (aka: is there experimental evidence of
crystal lattice parameter modifications) based on that, you select whether
or not make the lattice optimization. Normally, in doping, as the dopant
concentrations is low, there is no lattice modification. On the other hand,
working with alloys may not only change the lattice parameters but the
crystal symmetry as well.


> 2. after doping how can I measure the increasment or decreasment of the
> structure volume?
>
The structure volume can directly calculated from the crystal lattice
parameters. If you decided to not optimize the lattice then the volume will
not change. If you optimize the lattice, take the lattice parameters from
the output file (be sure the optimizations is completed) and calculate
manually the volume (I think that in the output, SIESTA write the crystal
volume).


> 2. I plot diagram of Pdos of pure tinoxide with 48 atoms, and I want to
> shift top of the valance band to zero. But the quantity of energy read from
> the filename.eig file (5.0578) is different from the value in the diagram
> of pdos( about 0.6). Why?
>
With the data you gave, I can not answer this question. What I do is take
the value of the Fermi level and then, using a graphical software
(OriginLab, Excel, Scigrapgh, GnuPlot, etc.) or a spreadsheet soft, shift
the data manually (maybe there is a tool or script in the SIESTA package).


> 2. For shifting the diagram of doped tinoxide, howmuch Should I shift it?
> As much as pure tinoxide read from the filename.eig or from the
> filename.eig of doped tinoxide?
>
It is your decision. It have to do with what you want to
show/study/discuss. Normally, I let the data as it, without making any
shift in the energy, but choose an energy scale of +/- 4eV around the Fermi
energy.

[]'s,

Camps

Re: [SIESTA-L] Mulliken charge calculation

[I. Camps]

Just look in the manual.

Em ter, 21 de nov de 2017 19:10, BISWAJIT BALL 
escreveu:

> Dear Siesta Users
>
>I want to calculate Mulliken charge in siesta. How can I proceed to
> do that and kindly help me by sending some input files.
>with best regards
>  Biswajit ball
>
>
>
> --

[]`s

Camps

Re: [SIESTA-L] << Intel vs AMD >>

[I. Camps]

I compiled SIESTA today with the same arch.make (all other setup identical)
but in the AMD box, and it run as expected, without any messages.

Em ter, 31 de out de 2017 19:03, Nick Papior <nickpap...@gmail.com>
escreveu:

> This message is not printed by Siesta, probably by MKL (?).
> If you have never seen it before it may mean you have upgraded MKL? At
> least, for sure, this is not related to siesta.
>
> 2017-10-30 20:53 GMT+01:00 I. Camps <ica...@gmail.com>:
>
>> Hello,
>>
>> I have a server that has AMD Opteron 8431 processor, the other ones are
>> Intel.
>>
>> As all of them have the same linux distro and the same packages/libraries
>> installed in the same places, usually, I compile SIESTA in one of them, and
>> copy to the others.
>>
>> For the first time, after compiled SIESTA in an Intel box, when running
>> in the AMD box, I got the error:
>>
>> *Please verify that both the operating system and the processor support
>> Intel(R) X87, CMOV, MMX, FXSAVE, SSE, SSE2, SSE3 and SSSE3 instructions.*
>>
>> Is this for the new versions of SIESTA (I am using siesta-4.1-b3)? The
>> arch.make is the same used previously without this issue.
>>
>>
>> []'s,
>>
>> Camps
>>
>
>
>
> --
> Kind regards Nick
>
-- 

[]`s

Camps

[SIESTA-L] << Intel vs AMD >>

[I. Camps]

Hello,

I have a server that has AMD Opteron 8431 processor, the other ones are
Intel.

As all of them have the same linux distro and the same packages/libraries
installed in the same places, usually, I compile SIESTA in one of them, and
copy to the others.

For the first time, after compiled SIESTA in an Intel box, when running in
the AMD box, I got the error:

*Please verify that both the operating system and the processor support
Intel(R) X87, CMOV, MMX, FXSAVE, SSE, SSE2, SSE3 and SSSE3 instructions.*

Is this for the new versions of SIESTA (I am using siesta-4.1-b3)? The
arch.make is the same used previously without this issue.


[]'s,

Camps

[SIESTA-L] << Big system with SIESTA >>

[I. Camps]

Hello,

I would like to know how to use SIESTA for system with (almost) a thousand
atoms. At this time, my system is molecular and have 850 atoms, but this
number will be increased.

When I ask "how to use", I mean, what flags should be set up in the input
file.

Note: My SIESTA is compiled with MPI.

[]'s,

Camps

Re: [SIESTA-L] Mulliken Charges on Water

[I. Camps]

Take a look at the following paper. They discus the effect of various
methods in the determinations of water atomic charges:

http://onlinelibrary.wiley.com/doi/10.1002/jcc.20157/full

F. Martin, H. Zipse, Charge distribution in the water molecule. A
comparison of methods,
J. Comput. Chem. 26 (2005) 97-105.
DOI: 10.1002/jcc.20157



[]'s,

Camps

On Mon, Oct 9, 2017 at 4:44 AM, Ulrich Biedermann 
wrote:

> Dear Dan,
> I have noticed similar problems.  Mulliken charges depend on the atomic
> basis set used.  In Siesta the cutoff radius (of H) seems to be the
> critical parameter.  I suggest that you check the dipol moment of an
> isolated water molecule (10 Angstrom box).  It should have the correct
> magnitude and sign for the basis set settings you use.
>
> Regards, Ulrich.
>
> * From: * Dan Gil 
> * To: * 
> * Sent: * 06.10.2017 16:13
> * Subject: * [SIESTA-L] Mulliken Charges on Water
>
> Hi,
>
> I am using Siesta 3.2 and ran into a strange problem.
>
> I simulate a water molecule and the Mulliken charges are wrong. It shows
> that the oxygen atom is positively charged and the two hydrogens are
> negatively charged. The Hirshfeld and Voronoi populations are fine. Did I
> run into a bug?
>
> *input.fdf*
> NumberOfAtoms   3
> NumberOfSpecies 4
>
> %block ChemicalSpeciesLabel
>  1  13 Al
>  2  14 Si
>  3   8 O
>  4   1 H
> %endblock ChemicalSpeciesLabel
>
> PAO.BasisType nodes
>
> %block PAO.BasisSizes
> Al DZP
> Si DZP
> O  DZP
> H  DZP
> %endblock PAO.BasisSizes
>
> XC.functional GGA
> XC.authorsPBE
>
> # SCF options
> MaxSCFIterations  200
> DM.MixingWeight   0.25 # New DM amount for next SCF cycle
> DM.Tolerance  1.d-6 # Tolerance in maximum difference
> SolutionMethoddiagon# OrderN or Diagon
> MeshCutoff  400 Ry
> DM.Require.Energy.Convergence.true.
> DM.Energy.Tolerance  1.d-6 eV
>
> MD.TypeOfRun  CG
> MD.NumCGsteps 100
> MD.InitialTemperature 300.0 K
> MD.TargetTemperature  300.0 K
>
> WriteHirshfeldPop .true.
> WriteVoronoiPop .true.
> WriteMullikenPop1
>
> LatticeConstant 1   Ang
>
> %block LatticeVectors
>  9.516000  0.00  0.00
> -4.758000  8.241100  0.00
>  0.00  0.00 48.2792733630
> %endblock LatticeVectors
>
> WarningMinimumAtiomicDistance 1.0 Ang
> AtomicCoordinatesFormat  NotScaledCartesianAng
> %block AtomicCoordinatesAndAtomicSpecies < Coord.fdf
>
> *Coord.fdf*
> 5.265981 -1.943725 -6.378528 3
> 4.222545 -1.943725 -6.378528 4
> 5.612381 -0.997652 -6.378528 4
>
> *Output (excerpts)*
> mulliken: Mulliken Atomic and Orbital Populations:
> Species: O
> Atom  Qatom  Qorb
>2s  2s  2py 2pz 2px 2py 2pz
>  2px
>2Pdxy   2Pdyz   2Pdz2   2Pdxz   2Pdx2-y2
>1  5.764   1.436  -0.027   1.363   1.793   1.235  -0.023  -0.003  -0.034
>   0.003   0.002   0.005   0.001   0.014
>
> Species: H
> Atom  Qatom  Qorb
>1s  1s  1Ppy1Ppz1Ppx
>2  1.118   0.845   0.036   0.063   0.104   0.070
>3  1.118   0.845   0.036   0.091   0.104   0.042
>
> Hirshfeld Net Atomic Populations:
> Atom #Qatom  Species
>  1   -0.234  O
>  20.117  H
>  30.117  H
>
> Voronoi Net Atomic Populations:
> Atom #Qatom  Species
>  1   -0.171  O
>  20.086  H
>  30.085  H
>
> Best Regards,
>
> Dan
>
>
>
>
> --
> -
> Max-Planck-Institut für Eisenforschung GmbH
> Max-Planck-Straße
> 
>  1
> 
> D-40237 Düsseldorf
>
> Handelsregister B 2533
> Amtsgericht Düsseldorf
>
> Geschäftsführung
> Prof. Dr. Gerhard Dehm
> Prof. Dr. Jörg Neugebauer
> Prof. Dr. Dierk Raabe
> Dr. Kai de Weldige
>
> Ust.-Id.-Nr.: DE 11 93 58 514
> Steuernummer: 105 5891 1000
>
>
> Please consider that invitations and e-mails of our institute are
> only valid if they end with …@mpie.de.
> If you are not sure of the validity please contact r...@mpie.de
>
> Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails
> aus unserem Haus nur mit der Endung …@mpie.de gültig sind.
> In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
> -
>

[SIESTA-L] << meaning Transiesta Example files >>

[I. Camps]

Hello.

I would like to know the physical meaning of each of the TRANSIESTA
examples in the Test/TranSiesta-TBTrans folder from SIESTA-4.1-b3 distro.

>From that folder we have:
- ts_au
- ts_au_100
- ts_au_100_0.25V
- ts_au_100_repetition
- ts_au_100_repetition_0.25V
- ts_au_repetition
- ts_graphene
- ts_term3
- ts_term4

Also, I want to point out that the manual (page 123) makes reference to
files didn't come with the distro.

[]'s,

Camps

[SIESTA-L] << full static SIESTA binary >>

[I. Camps]

Hello,

It could be possible to compile a fully static binary of SIESTA?

I have several calculations servers and now, I have to install in each of
them all the needed files (compiler, libraries, etc.). As was thinking in
the possibility to compile SIESTA only one time and distribute the
executable among the other servers.

[]'s,

Camps

Re: [SIESTA-L] visualize HOMO and LUMO

[I. Camps]

Hello,

I think that you should look about how to plot wave functions instead bands.

Take a look at this document from prof. Postnikov:
http://www.home.uni-osnabrueck.de/apostnik/Lectures/SIESTA-visual.pdf


[]'s,

Camps

On Mon, May 29, 2017 at 12:07 PM, Matías Soto C. 
wrote:

> One way to do it is that on your FDF file you need to specify the
> direction in which you want band energies to be calculated using the
> command BandLines.
>
> This will generate a file named filename.bands which contains the band
> energies.
> I use a utility called gnubands that converts this file into a more
> readable format that can be plotted using gnuplot or even excel. The
> utility is located in Util>Bands in your SIESTA directory.
>
> Best,
> -- Matias
>
> Matias Soto C, PhD
> Materials Science and NanoEngineering
> Rice University
>
> On Sun, May 28, 2017 at 5:16 AM, Najmeh Janati poor <
> janatipoor_naj...@yahoo.com> wrote:
>
>> Dear all,
>>
>> Does anyone know how to visualize HOMO and LUMO based solely on output
>> files from Siesta ?
>>  Regards
>> Najmeh
>>
>>
>>
>

Re: [SIESTA-L] Eig2DOS parameters

[I. Camps]

Dear Riya,

There aren´t default values for these parameters.

Take in mind that its YOU who is constructing the DOS (a continuum
function) from the eigenvalues (discrete values).

The idea here is (following your points):
- the program will add a gaussian or lorentzian function centered in each
eigenvalue. To draw a gaussian/lorentzian curve, you need two parameters:
the position where it will be centered (in this case is the eigenvalue) and
the width of it. You can play with this value: if you put a very small
value, then your gaussian/lorenztian will look like a line. If you put a
big value, each gaussian/lorentzian will superpose with its neighbor and
you will loose the contribution form neighbor eigenvalues (my suggestion is
that you put a value like 100meV, visualize the graph, if the graph looks
fine for you, or, if not, change the value, make the graph...). This value
should be reported in your final work.
- This is a number of energy values to make the total curve (from the sum
of gaussians/lorentizans). The greater this number is, better the quality
of the graph is. If this number is small, you can loose some features of
the DOS. As in the first point, play with different values: 200, 300, etc.
- in general, I select the energy window in such a way that the gap is
inside it. Actually, I made an energy windows always around the Fermi
level, something like Emin=EFermi-3eV and Emax=EFermi+3eV.

If you do not supply these values you can not produce the DOS.

You have another way to produce the DOS that is using the PDOS directive in
your FDF input. Then, using a tool like "fmpdos" from prof. Postnikov
(usually in \siesta-source\Util\Contrib\APostnikov\) you can generate,
instead the PDOS, the DOS.

Yes, all these values will affect the looks of the plot. But, as your
conclusion will be based in that look, it would be desired that the look is
good.


[]'s,

Camps

On Sat, May 20, 2017 at 3:17 AM, Riya Rogers 
wrote:

>
> Dear All
>
> What is the default values for the following parameters in Eig2DOS:
>
> - peak width (in eV) for broadening (gaussian or lorentzian).
> - number of points in the energy window
> - energy window: Emin and Emax (wrt E_F shifted to zero)
>
>
> And what if I dont supply these values in .EIG file?
>
> Is my calculation of DOS is wrong?
>
> or these values only affect the looks of plot.
>
>
> Thanks
>
>
> Regards
>
> Riya
>
>

Re: [SIESTA-L] << gaseous vs solid phase >>

[I. Camps]

Dear Ulrich,

Thank you very much for your comments. They are very useful and a good
guidance for further calculations.


[]'s,

Camps

On Mon, May 8, 2017 at 5:50 AM, Ulrich Biedermann <biederm...@mpie.de>
wrote:

> Hi,
>
> In order to avoid artefacts due to different basis sets and
> pseudopotentials (or all-electron calculation with Jaguar) I strongly
> recommend to do a "gas-phase" calculation with Siesta:  put one molecule in
> a large cubic supercell such that there is >> two times the larges cutoff
> of your basis set (see lines rc = in the basis set section of the output)
> space between peroidic immages.  For small molecules 20 Angstroms usually
> are sufficient.  However, you should check convergence (of the parameters
> of interest to within the accuracy you need) with respect to cell size by
> successively increasing the cell size.  A Gamma point calculation (1x1x1
> k-point mesh) is sufficient for isolated molecules.
>
> Then you can directly compare HOMO/LUMO energies with band gap and atomic
> charges and orbital occupations (e.g., Mullican) as implemented in Siesta.
>
> In case you are interested in the effect of basis sets and
> pseudopotentials and other differences between the programs you may also
> compare the Siesta-isolated molecule results with Jaguar.
> Keep in mind that - in particular small - basis sets may have a
> significant impact on the results.  Preferentially converged results
> (approximating an infinit basis set) should be compared to experimental
> results ("reality").
> Note that by default Jaguar uses quite drastic cut-offs for all kind of
> numerical approximations that may require adjustments for accurate
> results.  And offcourse you should also check the Siesta parameters for
> convergence, in particular MeshCutoff, DM.EnergyTolerance, MD.MaxForceTol,
> kgrid_cutoff and basis set related parameters.  For more details see the
> parameters used by Siesta in the output (and file out.fdf)  and the Siesta
> Manual and Tutorials.
>
> Furthermore, when comparing the total energy per molecule in isolated
> state and in the crystal you should check for BSSE (Basis Set Superposition
> Error) by calculating the Counterpoise correction (see Literature).  Also
> for molecular crystals, different DFTs may give quite different results.
> In particular the approximation for Van der Waals interactions will be
> important.
>
> I hope that this does not completely confuse you.  It certainly is
> advisable to go through the excellent Siesta Tutorials to get familiar with
> the program, how setup/run calculations and how to analyse results.
> I also strongly recommend to discuss your project with someone with
> experience in such calculations at your University.
>
> Good success with your Project,
> Ulrich.
>
> * From: * I. Camps <ica...@gmail.com>
> * To: * "siesta-l@uam.es" <siesta-l@uam.es>
> * Sent: * 05.05.2017 16:12
> * Subject: * [SIESTA-L] << gaseous vs solid phase >>
>
> Hello,
>
> I had made calculations for the gas phase of a compound and for the solid
> phase (organic crystal). For the gas phase I got the HOMO/LUMO, the Fukui
> indices and the NBO analysis (using the JAGUAR software). For the solid
> phase, I got the bands and the (partial)density of states (using SIESTA).
>
> Now, I want to correlate both results but I am not seen how. Do some one
> have an idea about this?
>
> Thanks in advance.
>
> []'s,
>
> Camps
>
>
>
> --
> -
> Max-Planck-Institut für Eisenforschung GmbH
> Max-Planck-Straße 1
> D-40237 Düsseldorf
>
> Handelsregister B 2533
> Amtsgericht Düsseldorf
>
> Geschäftsführung
> Prof. Dr. Gerhard Dehm
> Prof. Dr. Jörg Neugebauer
> Prof. Dr. Dierk Raabe
> Dr. Kai de Weldige
>
> Ust.-Id.-Nr.: DE 11 93 58 514
> Steuernummer: 105 5891 1000
>
>
> Please consider that invitations and e-mails of our institute are
> only valid if they end with …@mpie.de.
> If you are not sure of the validity please contact r...@mpie.de
>
> Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails
> aus unserem Haus nur mit der Endung …@mpie.de gültig sind.
> In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
> -
>

[SIESTA-L] << gaseous vs solid phase >>

[I. Camps]

Hello,

I had made calculations for the gas phase of a compound and for the solid
phase (organic crystal). For the gas phase I got the HOMO/LUMO, the Fukui
indices and the NBO analysis (using the JAGUAR software). For the solid
phase, I got the bands and the (partial)density of states (using SIESTA).

Now, I want to correlate both results but I am not seen how. Do some one
have an idea about this?

Thanks in advance.

[]'s,

Camps

Re: [SIESTA-L] Basis set superimposition error

[I. Camps]

I think that the answer to your question can be found in the original BSSE
paper.

On Sat, Apr 15, 2017, 17:02 Riya Rogers  wrote:

> Dear All
>
> I have a general query for those who are involved in calculation of
> adsorption energies.
>
> I have gone through many recent publications in very famous journals in
> which adsorption energies are calculated without considering Basis set
> superimposition error.
>
> Also, in most of the cases the Basis set superimposition error is ignored.
>
> Hence I would like to ask is it very necessary to calculate Basis set
> superimposition error or should one ignore it.
>
> Thanking you
>
> With Regards
> Riya
>
-- 

[]`s

Camps

Re: [SIESTA-L] << compiling siesta-4.1-b2 with Intel Compiler >>

[I. Camps]

Dear Nick,

I just finished to successful compile and run SIESTA-4.1-b2 (I just run
with the previous silicon example). Everything was fine.

One thing that is strange, to me, is that I just previously compile SIESTA
with the same Intel set (compiler, MKL, MPI) in a different Linux flavor
without any problem. My server was with OpenSUSE Tumbleweed (compile
without any issue) and now is with OpenSUSE Leap.

Thank you very much for your support.


[]'s,

Camps

On Thu, Apr 6, 2017 at 2:56 AM, Nick Papior <nickpap...@gmail.com> wrote:

> First, did you try my suggestion? It is not clear at all whether you did
> and you still have the problem?
>
> Secondly, those libraries are dependencies normal to the intel compiler.
> Intel isn't a completely separate compiler, it still relies on system
> libraries.
>
> Lastly, the pthread dependency is probably due to mkl=parallel (which you
> do not need, so try and remove it).
>
> 2017-04-05 21:53 GMT+02:00 I. Camps <ica...@gmail.com>:
>
>> Running the command "ldd siesta" and "ldd -v siesta" returns that all
>> libraries are on my system.
>>
>> Some dubs:
>> - why using libpthread from system instead from Intel?
>> - why using libgcc_s?
>>
>> It is not a memory problem (16GB) and a system size (1 atom).
>>
>> ldd siesta
>> linux-vdso.so.1 (0x7ffc57f9b000)
>> libm.so.6 => /lib64/libm.so.6 (0x2b38a65da000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x2b38a68d7000)
>> libmpifort.so.12 => /mnt/SoftIns/intel_MPI/compile
>> rs_and_libraries_2017.1.132/linux/mpi/intel64/lib/libmpifort.so.12
>> (0x2b38a6adc000)
>> libmpi.so.12 => /mnt/SoftIns/intel_MPI/compile
>> rs_and_libraries_2017.1.132/linux/mpi/intel64/lib/libmpi.so.12
>> (0x2b38a6e85000)
>> librt.so.1 => /lib64/librt.so.1 (0x2b38a7b9c000)
>> libpthread.so.0 => /lib64/libpthread.so.0 (0x2b38a7da5000)
>> libc.so.6 => /lib64/libc.so.6 (0x2b38a7fc2000)
>> /lib64/ld-linux-x86-64.so.2 (0x561c6c58)
>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x2b38a8365000)
>>
>> ldd -v siesta
>> linux-vdso.so.1 (0x7ffe01da7000)
>> libm.so.6 => /lib64/libm.so.6 (0x2ab261e3f000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x2ab26213c000)
>> libmpifort.so.12 => /mnt/SoftIns/intel_MPI/compile
>> rs_and_libraries_2017.1.132/linux/mpi/intel64/lib/libmpifort.so.12
>> (0x2ab262341000)
>> libmpi.so.12 => /mnt/SoftIns/intel_MPI/compile
>> rs_and_libraries_2017.1.132/linux/mpi/intel64/lib/libmpi.so.12
>> (0x2ab2626ea000)
>> librt.so.1 => /lib64/librt.so.1 (0x2ab263401000)
>> libpthread.so.0 => /lib64/libpthread.so.0 (0x2ab26360a000)
>> libc.so.6 => /lib64/libc.so.6 (0x2ab263827000)
>> /lib64/ld-linux-x86-64.so.2 (0x55f13aa31000)
>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x2ab263bca000)
>>
>> Version information:
>> ./siesta:
>> ld-linux-x86-64.so.2 (GLIBC_2.3) =>
>> /lib64/ld-linux-x86-64.so.2
>> libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2
>> libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0
>> libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6
>> libgcc_s.so.1 (GCC_3.0) => /lib64/libgcc_s.so.1
>> libgcc_s.so.1 (GCC_3.3) => /lib64/libgcc_s.so.1
>> libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
>> libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
>> libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
>> /lib64/libm.so.6:
>> libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
>> libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
>> /lib64/libdl.so.2:
>> ld-linux-x86-64.so.2 (GLIBC_PRIVATE) =>
>> /lib64/ld-linux-x86-64.so.2
>> libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
>> libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
>> /mnt/SoftIns/intel_MPI/compilers_and_libraries_2017.1.132/
>> linux/mpi/intel64/lib/libmpifort.so.12:
>> libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2
>> libgcc_s.so.1 (GCC_3.3) => /lib64/libgcc_s.so.1
>> libgcc_s.so.1 (GCC_3.0) => /lib64/libgcc_s.so.1
>> libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
>> libc.so.6 (GLIBC_2.3) =

Re: [SIESTA-L] << compiling siesta-4.1-b2 with Intel Compiler >>

[I. Camps]

   libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6
/lib64/libc.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.3) =>
/lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) =>
/lib64/ld-linux-x86-64.so.2
/lib64/libgcc_s.so.1:
libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6



[]'s,

Camps

On Tue, Apr 4, 2017 at 4:36 PM, I. Camps <ica...@gmail.com> wrote:

> Hello,
>
> I successfully compile SIESTa with the set Intel Fortran Compiler/Intel
> MPI/Intel MKL
> ifort: Intel(R) Fortran Intel(R) 64 Compiler XE for applications running
> on Intel(R) 64, Version 15.0.1.133 Build 20141023
> MPI: Intel(R) MPI Library for Linux* OS, Version 2017 Update 1 Build
> 20161016 (id: 16418)
> MKL: 11.2.1
>
> My arch.make file is attached.
>
> When running SIESTA with the silicon FDF (attached) I got the message:
>
> 
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image  PCRoutineLineSource
> siesta 01A94261  Unknown   Unknown  Unknown
> siesta 01A929B7  Unknown   Unknown  Unknown
> siesta 01A43464  Unknown   Unknown  Unknown
> siesta 01A43276  Unknown   Unknown  Unknown
> siesta 019F339F  Unknown   Unknown  Unknown
> siesta 019F993D  Unknown   Unknown  Unknown
> libpthread.so.02B9436D60B00  Unknown   Unknown  Unknown
> siesta 01F25615  Unknown   Unknown  Unknown
>
> Stack trace terminated abnormally.
> 
>
> This is driving me crazy...so, any help will be very appreciated.
>
> []'s,
>
> Camps
>

Re: [SIESTA-L] Siesta calcuations run with more number of processors

[I. Camps]

Dear Ankita,

If you run in more than one processor, it is not a serial run, it is a
parallel run.

You can run several SIESTA serial run at the same time.


[]'s,

Camps

On Tue, Mar 28, 2017 at 11:13 AM, Ankita Joshi 
wrote:

> Dear users,
>
> Does anyone know how to run SIESTA calculations with more than one
> processor in serial run ?
>
> Thanks,
> Ankita
>
>

Re: [SIESTA-L] how to install Netcdf4 for compilation of tbtrans in siesta 4.1b2

[I. Camps]

Hello Ankita,

Please, take a look in a previous topic in this list:

http://www.mail-archive.com/siesta-l@uam.es/msg09275.html


[]'s,

Camps

On Tue, Mar 21, 2017 at 6:00 AM, Ankita Joshi 
wrote:

> Dear SIESTA users,
>
> I want to compile tbtrans using netcdf4 in siesta 4.1b2. Can someone send
> me a link to install netcdf4 ?
>
> Thanks in advance,
>
> Ankita Joshi
>
>
>
>

Re: [SIESTA-L] Supercell

[I. Camps]

Hello,

I suggest you take a look in the list archives for a more complete answer.
The short answer is it depends. If you have 4 atoms and are interested in
25% doping, you only need to change one atom. But, as dopping is not that,
you have to selecte your dopping concentration, then, create your supercell
accordingly (to have enough atoms). Of course, you have to select were the
dopping atoms are in the structure.


On Fri, Feb 24, 2017, 18:02 berna uyanık  wrote:

> Hi. Should I add supercell definition for geometry optimization of one or
> two atom doped structure?
> Thanks for any helps.
>
-- 

[]`s

Camps

Re: [SIESTA-L] SIESTA 4.1-b2 with Intel MPI & MKL execution error

[I. Camps]

Hi Adiran,

The error message looks like a problem with your input file.

Did you run the test examples that come with SIESTA?


[]'s,

Camps

On Wed, Feb 22, 2017 at 2:55 PM, Adiran Garaizar 
wrote:

> Hello SIESTA users,
>
>
> I have been trying to run SIESTA 4.1-b2 compiled with ifort against both
> MKL and Intel MPI libraries. Whilst I am able to do this in BSC it is not
> possible in my local cluster, a 40 core machine running Ubuntu 14.06. It
> works fine if I run it in serial mode under MPI ‘mpirun -n 1’ and with
> regular gfortran + ScaLAPACK. However if I use more than 1 core I get this
> funny error:
>
>
>
> initatom: Reading input for the pseudopotentials and atomic orbitals
> --
>
> Block Chemical_species_label does not exist.
>
> Block Chemical_species_label does not exist.
>
> Stopping Program from Node:0
>
> Stopping Program from Node:0
>
> application called MPI_Abort(comm=0x8400, 1) - process 0
>
>
>
> With the same fdf with which I have done the rest of the tests. To
> construct my arch.make I’ve closely followed other mails asking similar
> questions and DIPC’s compiling guide with no luck. My arch.make is the
> following:
>
>
> SIESTA_ARCH=intel-mpi-mkl
>
> #
>
> .SUFFIXES: .f .F .o .a .f90 .F90
>
> #
>
> FC=mpiifort
>
> #
>
> FC_ASIS=$(FC)
>
> #
>
> RANLIB=ranlib
>
> #
>
> SYS=nag
>
> #
>
> MKL_ROOT=/opt/intel/mkl/
>
> #
>
> FFLAGS=-O2
>
> FPPFLAGS_MPI=-DMPI -DFC_HAVE_FLUSH -DFC_HAVE_ABORT
>
> FPPFLAGS= $(FPPFLAGS_MPI) $(FPPFLAGS_CDF)
>
> #
>
> MPI_INTERFACE=libmpi_f90.a
>
> MPI_INCLUDE=-I/opt/intel/compilers_and_libraries/linux/mpi/intel64/include
>
> #
>
> MKL_LIB=-L$(MKL_ROOT)/lib/intel64
>
> #
>
> BLAS_LIBS= -lmkl_blas95_lp64 -lmkl_intel_lp64  -lmkl_sequential -lmkl_core
>
> #
>
> LAPACK_LIBS=-lmkl_lapack95_lp64
>
> #
>
> BLACS_LIBS= -lmkl_blacs_intelmpi_lp64
>
> #
>
> SCALAPACK_LIBS=-lmkl_scalapack_lp64
>
> #
>
> EXTRA_LIBS= -lmkl_intel_lp64 -lmkl_core -lm -lpthread -lmkl_sequential
>
> #
>
> LIBS=$(MKL_LIB) $(SCALAPACK_LIBS) $(BLACS_LIBS) $(LAPACK_LIBS)
> $(BLAS_LIBS) $(EXTRA_LIBS)
>
> #
>
> .F.o:
>
> $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_fixed_F)  $<
>
> .F90.o:
>
> $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_free_F90) $<
>
> .f.o:
>
> $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_fixed_f)  $<
>
> .f90.o:
>
> $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_free_f90)  $<
>
>
>
> Thanks and regards,
>
>
> Adiran Garaizar
>

Re: [SIESTA-L] cut-off Radii & Atomic Coordinates

[I. Camps]

Hello Ajay,

1. Til my knowledge, the cut-off radii is not calculated with SIESTA. It is
an input parameter only used when you generate your own pseudopotentials.

2. In the case of the atomic coordinates, they also are not calculated. You
have to start from a given structure (given atomic coordinates) and do
calculations using it. You can optimize the atomic coordinates (obtain the
structure with lower energy).


[]'s,

Camps

On Thu, Feb 16, 2017 at 7:00 PM, Ajay_Khanna  wrote:

> Hello, Everyone, I'm a new user to SIESTA and trying to learn how to
> calculate
> band structure of semiconductors.
>
> In that, I need to know:-
> 1. how to calculate cut-off radii for generation of pseudopotentials for
> different atoms.
> 2. how to calculate the atomic coordinates for various systems.
>
> Many Many thanks in advance for helping me.
>
> Ajay Khanna
> Department of Chemistry
>

Re: [SIESTA-L] How to calculate single molecule energies

[I. Camps]

Dear Andrei,

Thank you very much for your email.

What I mean by convergence study is:
- I choose the accuracy for my energy calculations
- Do several calculations with different values of meshcutoff energies
- Plot the system energy (converged within the accuracy selected previously)
- Select the value of meshcutoff from were the system energy is stable

Is this ok?


[]'s,

Camps

On Mon, Dec 19, 2016 at 8:59 PM, Andrei Postnikov <
andrei.postni...@univ-lorraine.fr> wrote:

> A small comment to the latest remarks,
> sorry as it must be obvious:
> it hardly makes sense to run the convergence test on a calculation of just
> one molecule
> (or, in any standalone calculation) because you wont't have a clue
> what exactly, and to which accuracy, should be converged.
> Typically, you are after the energy difference between two (or more) cases:
> atoms vs molecule, free molecule + surface vs adsorbed molecule, etc.
> The  convergence to be checked
> is that of the meaningful energy difference, to the accuracy you need.
>
> Best regards
>
> Andrei Postnikov
>
> - I. Camps <ica...@gmail.com> a écrit :
> >
> Dear Riya,
>
> Its always good that, instead selecting those parameters (cutoff energy,
> cell parameters, numbers of k points, etc.) manually, you run convergence
> test. In this way, maybe you get smaller values for them and then less
> computational resources involved.
>
> []'s,
>
> Camps
>
>
> >
> On Sat, Dec 17, 2016 at 8:23 PM, Riya Rogers <rogers.riy...@gmail.com>
> wrote:
>
>> Dear Dr Camps
>>
>> >
>>
>> Thank u so much. I m taking very high cutoff greater than 340Ry. N put
>> the Molecule in middle of big lattice.
>>
>> > My bond lengths are lil away frm exam abt 1.2 to 1.4%.
>>
>> >
>>
>> Thanking you
>>
>> >
>>
>> Regards
>>
>> > Riya
>>
>> >
>>
>> On 18-Dec-2016 2:40 am, "I. Camps" <ica...@gmail.com> wrote:
>>
>>>
>>>
>>>> >
>>>>
>>>> Can anyone tell me how to calculate energy of one molecule of gas.
>>>>
>>>> >
>>>>
>>>> Should I take molecule inside lattice?
>>>>
>>>> > Or
>>>>
>>>> > Should I follow the following example1:
>>>>
>>>> >
>>>>
>>>> http://personales.unican.es/junqueraj/JavierJunquera_
>>>> files/Metodos/Basic/Basic-exercises.html
>>>>
>>>
>>> SIESTA is designed for periodic calculation, so, you have to put your
>>> molecule inside a fictional lattice. The lattice vectors should be big
>>> enough to not get interaction between two neighborhood molecules. Take a
>>> look in the second example. Also, you can check how SIESTA is treating your
>>> system (molecular, surface, slab, etc.) in the output file.
>>>
>>>
>>>> >
>>>>
>>>> Does k points n meshcutoff and basis set info req?
>>>>
>>> Yes.
>>>
>>>
>>> K vectors has meaning only for periodic system, so, in case of a
>>> molecule, only one is needed (the gamma point (0,0,0).
>>>
>>> For the meshcutoff, you should do the convergence study as usually.
>>>
>>> The basis set should be selected according the accuracy you want or need
>>> (as in any SIESTA calculation).
>>>
>>> Regards,
>>>
>>> --
>>>
>>> []`s
>>>
>>> >
>>>
>>> Camps
>>>
>>> >
>>>
>>> >
>>
>>
>> >
>>
>

Re: [SIESTA-L] How to calculate single molecule energies

[I. Camps]

Dear Riya,

Its always good that, instead selecting those parameters (cutoff energy,
cell parameters, numbers of k points, etc.) manually, you run convergence
test. In this way, maybe you get smaller values for them and then less
computational resources involved.

[]'s,

Camps




On Sat, Dec 17, 2016 at 8:23 PM, Riya Rogers <rogers.riy...@gmail.com>
wrote:

> Dear Dr Camps
>
> Thank u so much. I m taking very high cutoff greater than 340Ry. N put the
> Molecule in middle of big lattice.
> My bond lengths are lil away frm exam abt 1.2 to 1.4%.
>
> Thanking you
>
> Regards
> Riya
>
> On 18-Dec-2016 2:40 am, "I. Camps" <ica...@gmail.com> wrote:
>
>>
>> Can anyone tell me how to calculate energy of one molecule of gas.
>>>
>>> Should I take molecule inside lattice?
>>> Or
>>> Should I follow the following example1:
>>>
>>> http://personales.unican.es/junqueraj/JavierJunquera_files/M
>>> etodos/Basic/Basic-exercises.html
>>>
>>
>> SIESTA is designed for periodic calculation, so, you have to put your
>> molecule inside a fictional lattice. The lattice vectors should be big
>> enough to not get interaction between two neighborhood molecules. Take a
>> look in the second example. Also, you can check how SIESTA is treating your
>> system (molecular, surface, slab, etc.) in the output file.
>>
>>> Does k points n meshcutoff and basis set info req?
>>>
>> Yes.
>>
>> K vectors has meaning only for periodic system, so, in case of a
>> molecule, only one is needed (the gamma point (0,0,0).
>>
>> For the meshcutoff, you should do the convergence study as usually.
>>
>> The basis set should be selected according the accuracy you want or need
>> (as in any SIESTA calculation).
>>
>> Regards,
>>
>> --
>>
>> []`s
>>
>> Camps
>>
>

Re: [SIESTA-L] How to calculate single molecule energies

[I. Camps]

> Can anyone tell me how to calculate energy of one molecule of gas.
>
> Should I take molecule inside lattice?
> Or
> Should I follow the following example1:
>
>
> http://personales.unican.es/junqueraj/JavierJunquera_files/Metodos/Basic/Basic-exercises.html
>

SIESTA is designed for periodic calculation, so, you have to put your
molecule inside a fictional lattice. The lattice vectors should be big
enough to not get interaction between two neighborhood molecules. Take a
look in the second example. Also, you can check how SIESTA is treating your
system (molecular, surface, slab, etc.) in the output file.

> Does k points n meshcutoff and basis set info req?
>
Yes.

K vectors has meaning only for periodic system, so, in case of a molecule,
only one is needed (the gamma point (0,0,0).

For the meshcutoff, you should do the convergence study as usually.

The basis set should be selected according the accuracy you want or need
(as in any SIESTA calculation).

Regards,

-- 

[]`s

Camps

Re: [SIESTA-L] << error compiling Siesta 4.1 (b2) >>

[I. Camps]

Hello Nick,

Attached is the full output from Make.

Library versions:

hdf5: 1.8.12
netcdf: 4.4.1
netcdf-fortran: 4.4.4
pnetcdf: 1.7.0

Commands:
nc-config --all

his netCDF 4.4.1 has been built with the following features:

  --cc-> mpicc
  --cflags->  -I/software/lib/netcdf/include -fPIC
-I/software/lib/hdf5/include -I/software/lib/pnetcdf/include
  --libs  ->

  --has-c++   -> no
  --cxx   ->
  --has-c++4  -> no
  --cxx4  ->

  --fc->
  --fflags->
  --flibs ->
  --has-f90   -> no
  --has-f03   -> no

  --has-dap   -> yes
  --has-nc2   -> yes
  --has-nc4   -> yes
  --has-hdf5  -> yes
  --has-hdf4  -> no
  --has-logging-> no
  --has-pnetcdf-> yes
  --has-szlib ->

  --prefix-> /software/lib/netcdf
  --includedir-> /software/lib/netcdf/include
  --version   -> netCDF 4.4.1


nf-config --all

This netCDF-Fortran 4.4.4 has been built with the following features:

  --cc-> mpicc
  --cflags->  -I/software/lib/netcdf-fortran/include
-I/software/lib/netcdf/include -I/software/lib/pnetcdf/include
-I/software/lib/hdf5/include

  --fc-> mpiifort
  --fflags-> -I/software/lib/netcdf-fortran/include
  --flibs -> -L/software/lib/netcdf-fortran/lib -lnetcdff
-L/software/lib/netcdf/lib64 -L/software/lib/pnetcdf/lib
-L/software/lib/hdf5/lib64 -lnetcdf -lnetcdf -lhdf5_hl -lhdf5 -lz -lcurl
  --has-f90   -> no
  --has-f03   -> yes

  --has-nc2   -> yes
  --has-nc4   -> yes

  --prefix-> /software/lib/netcdf-fortran
  --includedir-> /software/lib/netcdf-fortran/include
  --version   -> netCDF-Fortran 4.4.4



[]'s,

Camps

On Thu, Dec 15, 2016 at 4:50 AM, Nick Papior <nickpap...@gmail.com> wrote:

> 1. I need the last lines of your compilation steps (not just the error
> message)
> 2. Give me the version numbers of your used netcdf, netcdf-fortran and
> hdf5 libraries
> 3. Please run and return the output of:
> nc-config --all
> nf-config --all
>
>
>
> 2016-12-14 14:56 GMT+01:00 I. Camps <ica...@gmail.com>:
>
>> Hi Nick,
>>
>> I recompile all libraries with the same Fortran compiler/MPI/MKL. The
>> error persist.
>>
>> Here is my arch.make.
>>
>> Thanks in advance.
>>
>>
>> []'s,
>>
>> Camps
>>
>> On Tue, Nov 29, 2016 at 6:33 PM, Nick Papior <nickpap...@gmail.com>
>> wrote:
>>
>>> It seems your netcdf module has been compiled with another compiler.
>>> Please ensure correct library and include paths.
>>>
>>> PS. Always include arch.make file if you have problems compiling,
>>> regardless of whether it works for previous versions.
>>>
>>>
>>> 2016-11-29 21:14 GMT+01:00 I. Camps <ica...@gmail.com>:
>>>
>>>> Hello,
>>>>
>>>> I am trying to compile the latest Siesta release (4.1-b2), but I am
>>>> facing errors bellow.
>>>>
>>>> Note: I believe isn't a problem with libraries/arch.make because 4.1-b1
>>>> compile nicely.
>>>>
>>>> I am using the Intel suite:
>>>> Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on
>>>> Intel(R) 64, Version 15.0.1.133 Build 20141023
>>>> Intel(R) MPI Library for Linux* OS, Version 2017 Build 20160721 (id:
>>>> 15987)
>>>> MKL: 11.2.1
>>>>
>>>>
>>>> Errors:
>>>>
>>>>
>>>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(133):
>>>> error #7012: The module file cannot be read.  Its format requires a more
>>>> recent F90 compiler.   [NETCDF]
>>>> use netcdf
>>>> ^
>>>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(136):
>>>> error #6683: A kind type parameter must be a compile-time constant.   [DP]
>>>>   real(dp), intent(in) :: cell(3,3)! Lattice vectors
>>>> ---^
>>>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(140):
>>>> error #6683: A kind type parameter must be a compile-time constant.
>>>> [GRID_P]
>>>>   real(grid_p), intent(in) :: gridfunc(npt_l,nspin)   !
>>>> Grid function
>>>> ---^
>>>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(150):
>>>> error #6683: A kind type parameter must be a compile-time constant.
>>>> [GRID_P]
>>>>   real(grid_p), dimension(:), pointer :: grid_buf  => null()
>>>> ---^
>&g

Re: [SIESTA-L] << error compiling Siesta 4.1 (b2) >>

[I. Camps]

Hi Nick,

I recompile all libraries with the same Fortran compiler/MPI/MKL. The error
persist.

Here is my arch.make.

Thanks in advance.


[]'s,

Camps

On Tue, Nov 29, 2016 at 6:33 PM, Nick Papior <nickpap...@gmail.com> wrote:

> It seems your netcdf module has been compiled with another compiler.
> Please ensure correct library and include paths.
>
> PS. Always include arch.make file if you have problems compiling,
> regardless of whether it works for previous versions.
>
>
> 2016-11-29 21:14 GMT+01:00 I. Camps <ica...@gmail.com>:
>
>> Hello,
>>
>> I am trying to compile the latest Siesta release (4.1-b2), but I am
>> facing errors bellow.
>>
>> Note: I believe isn't a problem with libraries/arch.make because 4.1-b1
>> compile nicely.
>>
>> I am using the Intel suite:
>> Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on
>> Intel(R) 64, Version 15.0.1.133 Build 20141023
>> Intel(R) MPI Library for Linux* OS, Version 2017 Build 20160721 (id:
>> 15987)
>> MKL: 11.2.1
>>
>>
>> Errors:
>>
>>
>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(133): error
>> #7012: The module file cannot be read.  Its format requires a more recent
>> F90 compiler.   [NETCDF]
>> use netcdf
>> ^
>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(136): error
>> #6683: A kind type parameter must be a compile-time constant.   [DP]
>>   real(dp), intent(in) :: cell(3,3)! Lattice vectors
>> ---^
>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(140): error
>> #6683: A kind type parameter must be a compile-time constant.   [GRID_P]
>>   real(grid_p), intent(in) :: gridfunc(npt_l,nspin)   ! Grid
>> function
>> ---^
>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(150): error
>> #6683: A kind type parameter must be a compile-time constant.   [GRID_P]
>>   real(grid_p), dimension(:), pointer :: grid_buf  => null()
>> ---^
>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(391): error
>> #7012: The module file cannot be read.  Its format requires a more recent
>> F90 compiler.   [NETCDF]
>> use netcdf, only: nf90_noerr, nf90_strerror
>> ^
>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(157): error
>> #6404: This name does not have a type, and must have an explicit type.
>> [NF90_SHARE]
>>iret = nf90_create(trim(name)//".grid.nc
>> ",NF90_SHARE+NF90_WRITE,ncid)
>> -^
>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(157): error
>> #6404: This name does not have a type, and must have an explicit type.
>> [NF90_WRITE]
>>iret = nf90_create(trim(name)//".grid.nc
>> ",NF90_SHARE+NF90_WRITE,ncid)
>> ^
>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(157): error
>> #6404: This name does not have a type, and must have an explicit type.
>> [NF90_CREATE]
>>iret = nf90_create(trim(name)//".grid.nc
>> ",NF90_SHARE+NF90_WRITE,ncid)
>> --^
>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(159): error
>> #6404: This name does not have a type, and must have an explicit type.
>> [NF90_DEF_DIM]
>>iret = nf90_def_dim(ncid,'xyz',3,xyz_id)
>> --^
>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(172): error
>> #6404: This name does not have a type, and must have an explicit type.
>> [NF90_FLOAT]
>>iret = nf90_def_var(ncid,'cell',nf90_
>> float,(/xyz_id,abc_id/),cell_id)
>> ---^
>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(172): error
>> #6404: This name does not have a type, and must have an explicit type.
>> [NF90_DEF_VAR]
>>iret = nf90_def_var(ncid,'cell',nf90_
>> float,(/xyz_id,abc_id/),cell_id)
>> --^
>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(174): error
>> #6404: This name does not have a type, and must have an explicit type.
>> [NF90_PUT_ATT]
>>iret = nf90_put_att(ncid,cell_id,'Description', &
>> --^
>> /home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(184): error
>> #6404: This name does not have a type, and must have an explicit type.
>> [NF90_ENDDEF]
>>iret = nf90_enddef(ncid)
>> --^
>> /home/icamps/Temp/SIESTA/

[SIESTA-L] << error compiling Siesta 4.1 (b2) >>

[I. Camps]

Hello,

I am trying to compile the latest Siesta release (4.1-b2), but I am facing
errors bellow.

Note: I believe isn't a problem with libraries/arch.make because 4.1-b1
compile nicely.

I am using the Intel suite:
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on
Intel(R) 64, Version 15.0.1.133 Build 20141023
Intel(R) MPI Library for Linux* OS, Version 2017 Build 20160721 (id: 15987)
MKL: 11.2.1


Errors:


/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(133): error
#7012: The module file cannot be read.  Its format requires a more recent
F90 compiler.   [NETCDF]
use netcdf
^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(136): error
#6683: A kind type parameter must be a compile-time constant.   [DP]
  real(dp), intent(in) :: cell(3,3)! Lattice vectors
---^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(140): error
#6683: A kind type parameter must be a compile-time constant.   [GRID_P]
  real(grid_p), intent(in) :: gridfunc(npt_l,nspin)   ! Grid
function
---^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(150): error
#6683: A kind type parameter must be a compile-time constant.   [GRID_P]
  real(grid_p), dimension(:), pointer :: grid_buf  => null()
---^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(391): error
#7012: The module file cannot be read.  Its format requires a more recent
F90 compiler.   [NETCDF]
use netcdf, only: nf90_noerr, nf90_strerror
^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(157): error
#6404: This name does not have a type, and must have an explicit type.
[NF90_SHARE]
   iret = nf90_create(trim(name)//".grid.nc",NF90_SHARE+NF90_WRITE,ncid)
-^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(157): error
#6404: This name does not have a type, and must have an explicit type.
[NF90_WRITE]
   iret = nf90_create(trim(name)//".grid.nc",NF90_SHARE+NF90_WRITE,ncid)
^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(157): error
#6404: This name does not have a type, and must have an explicit type.
[NF90_CREATE]
   iret = nf90_create(trim(name)//".grid.nc",NF90_SHARE+NF90_WRITE,ncid)
--^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(159): error
#6404: This name does not have a type, and must have an explicit type.
[NF90_DEF_DIM]
   iret = nf90_def_dim(ncid,'xyz',3,xyz_id)
--^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(172): error
#6404: This name does not have a type, and must have an explicit type.
[NF90_FLOAT]
   iret = nf90_def_var(ncid,'cell',nf90_float,(/xyz_id,abc_id/),cell_id)
---^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(172): error
#6404: This name does not have a type, and must have an explicit type.
[NF90_DEF_VAR]
   iret = nf90_def_var(ncid,'cell',nf90_float,(/xyz_id,abc_id/),cell_id)
--^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(174): error
#6404: This name does not have a type, and must have an explicit type.
[NF90_PUT_ATT]
   iret = nf90_put_att(ncid,cell_id,'Description', &
--^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(184): error
#6404: This name does not have a type, and must have an explicit type.
[NF90_ENDDEF]
   iret = nf90_enddef(ncid)
--^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(188): error
#6632: Keyword arguments are invalid without an explicit interface.
[START]
   iret = nf90_put_var(ncid, cell_id, cell, start = (/1, 1 /), &
^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(189): error
#6632: Keyword arguments are invalid without an explicit interface.
[COUNT]
count = (/3, 3/) )
^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(188): error
#6404: This name does not have a type, and must have an explicit type.
[NF90_PUT_VAR]
   iret = nf90_put_var(ncid, cell_id, cell, start = (/1, 1 /), &
--^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(230): error
#6632: Keyword arguments are invalid without an explicit interface.
[START]
start=(/ lb(1), lb(2),
lb(3), ispin/),  &
^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(231): error
#6632: Keyword arguments are invalid without an explicit interface.
[COUNT]
count=(/nel(1), nel(2),
nel(3), 1 /) ) )
^
/home/icamps/Temp/SIESTA/siesta-4.1-b2/Src/iogrid_netcdf.F90(260): error
#6404: This name does not have a type, and 

[SIESTA-L] << Calculating Infrared for organic crystal >>

[I. Camps]

Hello SIESTers,

I want to calculate the infrared spectrum using vibra package
(fcbuild+vibrator).

My system is an organic crystal with 136 atoms.

I am having the problems bellow:

1-) When using supercell=1 (SuperCell_1=1, SuperCell_2=1, SuperCell_3=1), I
got 3672 atoms and the SIESTA run stops with:

ordern: enum =  10368.
chkdim: ERROR: In iolwf, dimension nbasis =   34776. It must be exactly
1288
Stopping Program from Node:0
chkdim: ERROR: In iolwf, dimension nbasis =   34776. It must be exactly
1288
Stopping Program from Node:4




2-) When using fcbuild with no supercell (SuperCell_1=0, SuperCell_2=0,
SuperCell_3=0) I got in the output:

...
cgwf: iter =  103  grad = -257935.103783  Eb(Ry) =
-6375.731952
cgwf: iter =  104  grad =-1939049.279754  Eb(Ry) =
-6467.950266
cgwf: iter =  105  grad = **  Eb(Ry) =
-509285.740165

cgwf:  CG tolerance reached

denmat: qtot (before DM normalization) =   -7122.0789
ordern: qtot (after  DM normalization) = 384.
...
ordern: enum =384.
cgwf: iter =1  grad = **  Eb(Ry) =
**

cgwf: WARNING: E. increased; resetting CG
cgwf: iter =2  grad = -30.914791  Eb(Ry) =
**
...
iesta: iscf =6
Eharris(eV) = -15952.3269  E_KS(eV) = -15950.5079  dDmax =  1.9173


ordern: enum =384.
cgwf: iter =1  grad =  -Infinity  Eb(Ry) =
**
cgwf: iter =2  grad =NaN  Eb(Ry) =
NaN
cgwf: iter =3  grad =NaN  Eb(Ry) =
NaN
cgwf: iter =4  grad =NaN  Eb(Ry) =
NaN
...

[]'s,

Camps

[SIESTA-L] << polarized spin transport output >>

[I. Camps]

Hello,

I am following the examples from the tutorial "Siesta/TranSiesta Tutorial,
Tel Aviv, September 8-11, 2014" at SIESTA site (link
).

>From this tutorial, in example 09, there is an script that do all the
needed calculation and at the end, generate a file "IV.dat" with the
calculated current.

The calculations done in this tutorial are for the spin unpolarized case,
i.e. there is only one current.

I am doing spin polarized calculations, i.e., there are two current (one
for each spin polarization).

The output from TBTRANS for the two polarization are mixed in the same file.

My questions:
- Is possible to instruct TBTRANS to output all the files separately for
each spin?
OR
- How can I get both currents from the TBTRANS single output to
automatically create the IV.dat?

Attached is the script used in the tutorial. On it, they used the following
command to get the value of the current:

I=`grep Current $sys.tbt-out-V${V//./_} | awk '{print $5}'`
printf "%f\t%f\n" $V $I >> IV.dat


[]'s,

Camps
#!/bin/bash

. ./source.sh

dir=09-IV
sys=stackingfault

pushd $dir

# First calculate the electrode
pushd elec
echo "Calculating the electrode..."
$_ts < elec.fdf > elec.out
echo "Done..."
popd

# This will run all biases
setV() {
local V=$1 ; shift
# calculate number of points
local N=$(echo "define abs(i) {
if (i < 0) return (-i)
return (i)
};
abs($V) / 0.0125" | bc)
sed -i -e "s/TS.Voltage.*/TS.Voltage $V eV/gi" $sys.fdf
sed -i -e "s/TS.biasContour.NumPoints.*/TS.biasContour.NumPoints $N/gi" 
$sys.fdf
# In principle you need to correct the number of points for
# tbtrans (due to the bias-window integration).
# In this case we use a fixed integration seperation
# which means that you have the same precision for the integral
}

# First we run for the zero bias case (equilibrium)
rm -f $sys.[^f]*
echo "Calculating for 0V..."
setV 0. # set the bias
$_ts < $sys.fdf > $sys.out-V0
# Save the density matrix for zero bias (then we can use
# this as a guess for the following bias)
cp $sys.TSDE V0.TSDE
echo "Calculating the current using tbtrans for 0V..."
tbtrans < $sys.fdf > $sys.tbt-out-V0
mv $sys.AVTRANS $sys.AVTRANS-V0

# Clean up
rm *.T*GF*

for pm in + - ; do

sign=""
[ "$pm" == "-" ] && sign=$pm

# Restore the density matrix from 0V
cp V0.TSDE $sys.TSDE

for V in 0.15 0.3 0.45 0.6 0.75 0.9 ; do
echo "Calculating for $sign$V V..."

setV $sign$V # set the bias
$_ts < $sys.fdf > $sys.out-V$sign${V//./_}

echo "Calculating the current using tbtrans for $V V..."
tbtrans < $sys.fdf > $sys.tbt-out-V$sign${V//./_}
mv $sys.AVTRANS $sys.AVTRANS-V$sign${V//._}

# Clean up
rm *.T*GF*
done

done

# Clean up weird files... ;)
rm INPUT_TMP* fdf-*

# Create the I-V curve
echo "# Bias[V] Current[A]" > IV.dat
for V in -0.9 -0.75 -0.6 -0.45 -0.3 -0.15 0 0.15 0.3 0.45 0.6 0.75 0.9 ; do
I=`grep Current $sys.tbt-out-V${V//./_} | awk '{print $5}'`
printf "%f\t%f\n" $V $I >> IV.dat
done

echo "Done with collecting information, plot the file IV.dat to see the I-V 
curve..."

popd

Re: [SIESTA-L] Intel mkl libraries for siesta

[I. Camps]

Yes, its part of the parallel compilation.

Attached is the full arch.make.

Also, take a look in the list message bellow for a guide about install the
extra library netCDF:

http://www.mail-archive.com/siesta-l@uam.es/msg09275.html


[]'s,

Camps

On Wed, Nov 9, 2016 at 6:16 PM, Riya Rogers <rogers.riy...@gmail.com> wrote:

> Dear Camps
>
> Thank u so much for your quick reply. I didnt provide the path to my mkl
> libraries. I think because of tht i m getting errors.
>
> Do you make this arch file for parallel siesta compilation?
>
> Regards
> Riya
>
> On 10-Nov-2016 1:35 am, "I. Camps" <ica...@gmail.com> wrote:
>
>> Hi,
>>
>> What I have in my arch.make:
>>
>> #
>> MKLPATH=/opt/intel/composer_xe_2015/mkl/lib/intel64
>>
>> SUGGESTED_LIBS=$(MKLPATH)/libmkl_scalapack_lp64.a \
>>-Wl,--start-group \
>>   $(MKLPATH)/libmkl_intel_lp64.a \
>>   $(MKLPATH)/libmkl_sequential.a \
>>   $(MKLPATH)/libmkl_core.a \
>>   $(MKLPATH)/libmkl_blacs_intelmpi_lp64.a \
>>-Wl,--end-group \
>>-lpthread
>> #
>>
>> Also, I have sourced the path for the Intel compilers (that include the
>> path to the MKL files):
>>
>> source /opt/intel/parallel_studio_xe_2015/psxevars.sh
>>
>>
>> []'s,
>>
>> Camps
>>
>> On Wed, Nov 9, 2016 at 5:52 PM, Riya Rogers <rogers.riy...@gmail.com>
>> wrote:
>>
>>> Dear all
>>>
>>> I am using intel mkl library but not able to modify LIBS variable
>>> properly hence at the end of installation, i am getting error saying:
>>>
>>> No such file or directory
>>>
>>> How to modify LIBS variable?
>>>
>>> Kindly help me out...
>>>
>>> Regards
>>> Riya
>>>
>>
>>


arch.make
Description: Binary data

Re: [SIESTA-L] Intel mkl libraries for siesta

[I. Camps]

Hi,

What I have in my arch.make:

#
MKLPATH=/opt/intel/composer_xe_2015/mkl/lib/intel64

SUGGESTED_LIBS=$(MKLPATH)/libmkl_scalapack_lp64.a \
   -Wl,--start-group \
  $(MKLPATH)/libmkl_intel_lp64.a \
  $(MKLPATH)/libmkl_sequential.a \
  $(MKLPATH)/libmkl_core.a \
  $(MKLPATH)/libmkl_blacs_intelmpi_lp64.a \
   -Wl,--end-group \
   -lpthread
#

Also, I have sourced the path for the Intel compilers (that include the
path to the MKL files):

source /opt/intel/parallel_studio_xe_2015/psxevars.sh


[]'s,

Camps

On Wed, Nov 9, 2016 at 5:52 PM, Riya Rogers  wrote:

> Dear all
>
> I am using intel mkl library but not able to modify LIBS variable properly
> hence at the end of installation, i am getting error saying:
>
> No such file or directory
>
> How to modify LIBS variable?
>
> Kindly help me out...
>
> Regards
> Riya
>

Re: [SIESTA-L] << problem with electrodes >>

[I. Camps]

Thank you very much Nick.

I changed the positions of the carboxyl atoms, below the first 24 atoms
(corresponding to the electrodes) and the calculation runs without errors.


[]'s,

Camps

On Mon, Oct 24, 2016 at 4:59 AM, Nick Papior <nickpap...@gmail.com> wrote:

> The short answer is that transiesta requires a strict input sequence of
> atoms. In pre-4.1 versions transiesta requires the first atoms to be
> left-buffer+left-electrodes, and the last atoms to be
> right-electrode+right-buffer atoms.
>
> In 4.1 and beyond, this restriction has been lifted while it still
> requires that electrode atoms are "blocked" together.
>
> If you endeavour into transiesta calculations I would highly suggest you
> to read the manual and the corresponding articles concerning the
> implementation.
>
> transiesta pre 4.1
> DOI: 10.1103/PhysRevB.65.165401
> transiesta post 4.1
> DOI: 10.1016/j.cpc.2016.09.022
>
> 2016-10-22 18:06 GMT+02:00 I. Camps <ica...@gmail.com>:
>
>> Hello SIESTers,
>>
>> I begin playing with TranSIESTA. To do that I began with some tutorials
>> from the SIESTA site. Specifically with one from the link bellow:
>>
>> Link: http://departments.icmab.es/leem/siesta/tlv14/index.html
>>
>> From the example "11. Quantum electronic transport: TranSiesta basic, we
>> got an script that directly run the combination SIESTA/TranSIESTA/TBTrans
>> to obtain the IV curve (http://departments.icmab.es/l
>> eem/siesta/tlv14/Exercises/TS.tar.gz) (folder "09. IV").
>>
>> I run the example without any problem (in the attachment, the file called
>> pristine.zip).
>>
>> Then, I modified the scattering region binding a carboxil group to the
>> surface of the nanotube at its center position (in the attachment, the file
>> called functionalized.zip).
>>
>> Now, when running the functionalized setup I got an error with the
>> electrodes:
>> "The electrodes are not situated in the same coordinates. Please correct."
>>
>> I am not understanding the origin of this error, once I didn't modified
>> the corresponding electrodes file, neither modified the Z periodicity of
>> the scattering region.
>>
>> Could any one help me with this issue?
>>
>> Many thanks in advance.
>>
>> PS: the scattering region is not optimized, it is just with the carboxil
>> added to its surface.
>>
>> []'s,
>>
>> Camps
>>
>
>
>
> --
> Kind regards Nick
>

Re: [SIESTA-L] mobility, effective mass etc..

[I. Camps]

Also for thermal related calculations you can take a look at for Phono3py:

http://atztogo.github.io/phono3py/

Also this software calculate the Joint density of states (JDOS) (that you
ask in previous message).


[]'s,

Camps

On Sun, Oct 2, 2016 at 9:22 AM, Suman Chowdhury 
wrote:

> Dear SIESTA use,
> Does anyone know how to calculate effective mass, mobility, thermal and
> electrical conductivity, Seebeck coefficient through siesta simulation???
>
> --
>
>
>
> *Senior research fellow Dept. of Physics, University of Calcutta Kolkata-
> 79, West Bengal, India.*
> * Ph no-+91-9830512232 <%2B91-9830512232>*
>
>

Re: [SIESTA-L] mobility, effective mass etc..

[I. Camps]

Please Mostafa,

Create your own threat, do not reuse questions from other users!


[]'s,

Camps

On Sun, Oct 2, 2016 at 5:39 PM, Mostafa Shabani <
mostafa.nanophys...@gmail.com> wrote:

> Dear siesta user,
> I have same questions about some transistors key parameters: (ON/OFF
> ratio, transconductance, mobility, subthreshold swing)
> I want to know how we can calculate this parameters? Is it possible to
> calculate them with siesta/transiesta package?
>
> Best regards
>
>
>
> On Sun, Oct 2, 2016 at 3:52 PM, Suman Chowdhury <
> sumanchowdhur...@gmail.com> wrote:
>
>> Dear SIESTA use,
>> Does anyone know how to calculate effective mass, mobility, thermal and
>> electrical conductivity, Seebeck coefficient through siesta simulation???
>>
>> --
>>
>>
>>
>> *Senior research fellow Dept. of Physics, University of Calcutta Kolkata-
>> 79, West Bengal, India.*
>> * Ph no-+91-9830512232 <%2B91-9830512232>*
>>
>>
>

Re: [SIESTA-L] mobility, effective mass etc..

[I. Camps]

Hi,

I found these two codes that can compute the effective masses from XCrysDen
BSXF file format. I am not sure if there is any tools that convert the
SIESTA output files to this formats. The software are:

SKEAF: http://www.wien2k.at/reg_user/unsupported/SKEAFrelease_
v1p3p0_r149.tar.gz
DHVA: https://github.com/danielguterding/dhva



[]'s,

Camps

On Sun, Oct 2, 2016 at 9:22 AM, Suman Chowdhury 
wrote:

> Dear SIESTA use,
> Does anyone know how to calculate effective mass, mobility, thermal and
> electrical conductivity, Seebeck coefficient through siesta simulation???
>
> --
>
>
>
> *Senior research fellow Dept. of Physics, University of Calcutta Kolkata-
> 79, West Bengal, India.*
> * Ph no-+91-9830512232 <%2B91-9830512232>*
>
>

Re: [SIESTA-L] Installation of NetCDF with CDF4 support (also installation of HDF5 and zlib)

[I. Camps]

Hello NIck,

Thank you very much for this!

A question: it could be possible to share this info in the (non official)
SIESTA Facebook group (https://www.facebook.com/groups/1482411542018575/)?


[]'s,

Camps

On Tue, Sep 27, 2016 at 4:39 PM, Nick Papior  wrote:

> Dear list,
>
> Several have asked questions about installation of NetCDF4 successfully.
>
> If you simply download NetCDF and install it using configure without any
> flags you will only get support for CDF-3.
> Although you have downloaded NetCDF-4.4.1 it will NOT intrinsically
> install NetCDF with CDF-4 support. I know this is very confusing, and it is
> indeed very unfortunate.
> To further complicate the issue, SIESTA requires the Fortran library which
> requires a second installation.
>
> To ease the use of the NetCDF features I have created a script which
> should install NetCDF (source version: 4.4.0) with full CDF4 support.
> The script has been tested on Debian.
>
> All you need to do is download these sources to your installation
> directory:
> http://zlib.net/zlib-1.2.8.tar.gz
> https://support.hdfgroup.org/ftp/HDF5/releases/hdf5-1.8.16/
> src/hdf5-1.8.16.tar.bz2
> https://github.com/Unidata/netcdf-c/archive/v4.4.0.tar.gz
> https://github.com/Unidata/netcdf-fortran/archive/v4.4.3.tar.gz
>
> Also download the attached install.sh script to your installation
> directory.
>
> The installation script will NOT install the parallel version, but you
> should be able to adapt the script accordingly if you really want this
> feature enabled.
>
> Please run through the script and read the comments to ensure that it will
> do as you requested.
> I will probably not be able to help you change the script to your liking,
> but feel free to post any changes that adhere to different compilers etc.
>
> Once you have edited the script and read the comments, you may run the
> script:
> $> bash ./install.sh
>
> and it will install, first zlib, then hdf5, then netcdf-c and lastly,
> netcdf-fortran.
>
> --
> Kind regards Nick
>