Re: [SIESTA-L] Graphene based study using Siesta

2015-09-17 Por tôpico Abraham Hmiel
Dear Rajan,

Although SIESTA has a well-documented history of studying graphene's
transport and interface properties, one caveat regarding the locality of
the LCAO basis set and its consequences is written about here in this
article by Derek Stewart of Cornell:
https://courses.cit.cornell.edu/das248/index_files/cautionary_tale_of_two_basis_sets_and_graphene.pdf

Cheers,
Abraham Hmiel

On Thu, Sep 17, 2015 at 1:12 AM, Monica Garcia <m.gar...@simune.eu> wrote:

> Dear Rajan,
>
> Here you have some references in which SIESTA was used to simulate
> different Graphene properties,
>
>  - Comparison of the electronic transport properties of metallic graphene
> and silicene nanoribbons; S. Yamacli, J. Nanopart. Res. (2014) 16.
>
>  - The interaction of metallic clusters on reduced graphene oxide; E.
> Gracia Espino, G. Hu, A. Shchukarev, and T. Wagberg, J. Am. Chem. Soc.
> (2014), 136, 6626.
>
>  - Quantum transport in chemically modified two-dimensional graphene; N.
> Leconte, A. Lherbier, F. Varchon, P. Ordejon, S. Roche, and J.-C. Charlier,
> Phys. Rev. B 84, (2011) 235420.
>
>  - The potential of graphene nanoribbons (GNR’s) as molecular-scale
> sensors; R. Chowdhury, S. Adhikari, P. Rees, S. P. Wilks and F. Scarpa,
> Phys. Rev. B 83, (2011) 045401.
>
>  I hope you find them useful,
>
> Regards,
> Mónica
>
>
> Mónica García-Mota
> Simulations Manager
> Tolosa Hiribidea 76 | 20018 Donostia - San Sebastián | Spain
> T.: +34 943 57 40 68 | m.gar...@simune.eu <m.gar...@simune.eu> |
> www.simune.eu[image: SIMUNE Atomistic Simulations] <http://www.simune.eu/>
>
> On 17 Sep 2015, at 09:51, RAJAN SINGH <singhrajan.i...@gmail.com> wrote:
>
> Dear Sir/Madam
>
> I want to use Siesta for my research work. I want to use it for study the
> Graphene and its interface with different materials. Can you suggest me
> some tutorials regarding that. I also want to know what are the limitations
> of using Siesta for Graphene interface study?
>
> Please enlighten me with your comments.
>
> Thank You.
>
>
>


-- 
*Abraham Hmiel, Ph. D.*
http://abehmiel.net/about


Re: [SIESTA-L] PAO-basis block for As

2015-06-11 Por tôpico Abraham Hmiel
My guess regarding the compilation errors: there's no need to use sudo for
this install, and your compiler in the makefile is pointing to f77, is it
that the same compiler you used to install SIESTA? It doesn't have to be,
but if SIESTA compiles you should use what works there. Your FC line should
be pointing to f90, or whatever fortran compiler (pg90, ifort, ifc,
gfortran, etc.) you used in the SIESTA install. Check your Obj/ folder in
the SIESTA source tree for the arch.make.

I could not reproduce your error when I used my own f77 compiler or f90 or
gfortran so that's strange. Try using gfortran, perhaps? You should not
have to edit the source code to get this utility to work. Just try a
different compiler until you can get it to work. My gfortran is: GNU
Fortran 95 (GCC) 4.1.2 20070115 and it compiles without error. Swarm is
Open-MP enabled, so you could compile it in parallel as well.

On Thu, Jun 11, 2015 at 6:29 AM, Ludwig, Stephan 
stephan.lud...@pi1.physik.uni-stuttgart.de wrote:


 Hello Abraham,


 thank you for your suggestion. Unfortunately I have proplems to install
 the optimization programm.

 typing 'make swarm simplex' I receive the error message

 i1@QuanQal2:/home/siesta-3.2-pl-5/Util/Optimizer$ sudo make swarm simplex

 f77 -c io.f
 io_assign:
 Error on line 2: syntax error
 Warning on line 13: ignoring text after end.
 Warning on line 13: local variable out never used
 Warning on line 13: local variable intend never used
 Error on line 13: Declaration error for intend: adjustable dimension on
 non-argument
 /usr/bin/f77: aborting compilation
 make: *** [io.o] Fehler 25

 The io.f file looks like this


 SUBROUTINE io_assign(lun)
 integer intend(out) :: lun
 logical used
 integer iostat
 c
 c Looks for a free unit and assigns it to lun
 c
 do lun= 10, 99
 inquire(unit=lun, opened=used, iostat=iostat)
 if (iostat .ne. 0) used = .true.
 if (.not. used) return
 enddo
 end SUBROUTINE io_assign

 

 Can you help me to find the syntax error?


 Best regards

 Stephan




 -Original message-
 *From:* Abraham Hmiel abehm...@gmail.com
 *Sent:* Wednesday 10th June 2015 17:42
 *To:* Siesta, Self-Consistent DFT LCAO program, http://www.uam.es/siesta 
 siesta-l@uam.es
 *Subject:* Re: [SIESTA-L] PAO-basis block for As

 Stephan,

 Creating a PAO basis set from scratch is a nontrivial exercise even for
 experts. The way I usually use involves the simplex tetrahedral method,
 which allows you to vary several parameters at a time and find their
 optimized values. There is an implementation included with SIESTA.

 Look in the Util/Optimizer folder of the siesta source tree. There are
 some examples there which will allow you to use the simplex method code in
 a basic manner for a water molecule to optimize basis set parameters. Take
 a look at the files and study them and run the example calculations.
 They're pretty quick. From there, it's not a big stretch to apply the
 principles to arsenic. You will still have to figure out the format of the
 PAO basis block corresponding to your pseudopotential and desired size of
 the basis set. You might try using As2S3 or solid arsenic as input, and
 optimize for bond length and total energy minimization. I'd offer that you
 might learn more doing it this way.

 Kind regards,

 On Wed, Jun 10, 2015 at 7:27 AM, Nick Papior Andersen 
 nickpap...@gmail.com wrote:

 I would suggest you ask your supervisor/professor (I suspect you have
 one?).

 2015-06-10 16:24 GMT+02:00 Ludwig, Stephan 
 stephan.lud...@pi1.physik.uni-stuttgart.de:

 Hello everybody,


 I'm an absolute beginner in DFT calculations (I'm a Master student) and
 now I have to cope with a material containing Arsenid.

 The pseudopotential of As in the database has a semicore state so I have
 to implement the PAO-basis block in the fdf-file.


 I have no idea how to choose the parameters of this block to obtain
 reasonable results.

 I was able to start siesta by using a PAO-basis block which was
 originally designed for iron:


 %block PAO.Basis # Define Basis set
 As 1  # Species label, number of
 l-shells
 n=3 2 2 # n, l, Nzeta
 6.000 0.000
 1.000 1.000
 %endblock PAO.Basis




 Can anybody please deliver a suitable PAO-basis and a pseudopotential
 for As.

 Or can anybody help me to find a suitable PAO-basis for the
 pseudopotential I use. You can find it in the attachment

 It would be a great help and I would learn a lot through it


 Thanks and regards


 Stephan Ludwig






 --
 Kind regards Nick




 --
 *Abraham Hmiel, Ph. D.*
 http://abehmiel.net/about

 -Original message-
 *From:* Abraham Hmiel abehm...@gmail.com
 *Sent:* Wednesday 10th June 2015 17:42
 *To:* Siesta, Self-Consistent DFT LCAO program, http://www.uam.es/siesta 
 siesta-l@uam.es
 *Subject:* Re: [SIESTA-L] PAO-basis block for As

 Stephan,

 Creating a PAO basis set from scratch is a nontrivial exercise even

Re: [SIESTA-L] PAO-basis block for As

2015-06-10 Por tôpico Abraham Hmiel
Stephan,

Creating a PAO basis set from scratch is a nontrivial exercise even for
experts. The way I usually use involves the simplex tetrahedral method,
which allows you to vary several parameters at a time and find their
optimized values. There is an implementation included with SIESTA.

Look in the Util/Optimizer folder of the siesta source tree. There are some
examples there which will allow you to use the simplex method code in a
basic manner for a water molecule to optimize basis set parameters. Take a
look at the files and study them and run the example calculations. They're
pretty quick. From there, it's not a big stretch to apply the principles to
arsenic. You will still have to figure out the format of the PAO basis
block corresponding to your pseudopotential and desired size of the basis
set. You might try using As2S3 or solid arsenic as input, and optimize for
bond length and total energy minimization. I'd offer that you might learn
more doing it this way.

Kind regards,

On Wed, Jun 10, 2015 at 7:27 AM, Nick Papior Andersen nickpap...@gmail.com
wrote:

 I would suggest you ask your supervisor/professor (I suspect you have
 one?).

 2015-06-10 16:24 GMT+02:00 Ludwig, Stephan 
 stephan.lud...@pi1.physik.uni-stuttgart.de:

  Hello everybody,


 I'm an absolute beginner in DFT calculations (I'm a Master student) and
 now I have to cope with a material containing Arsenid.

 The pseudopotential of As in the database has a semicore state so I have
 to implement the PAO-basis block in the fdf-file.


 I have no idea how to choose the parameters of this block to obtain
 reasonable results.

 I was able to start siesta by using a PAO-basis block which was
 originally designed for iron:


 %block PAO.Basis # Define Basis set
 As 1  # Species label, number of
 l-shells
 n=3 2 2 # n, l, Nzeta
 6.000 0.000
 1.000 1.000
 %endblock PAO.Basis




 Can anybody please deliver a suitable PAO-basis and a pseudopotential for
 As.

 Or can anybody help me to find a suitable PAO-basis for the
 pseudopotential I use. You can find it in the attachment

 It would be a great help and I would learn a lot through it


 Thanks and regards


 Stephan Ludwig






 --
 Kind regards Nick




-- 
*Abraham Hmiel, Ph. D.*
http://abehmiel.net/about


Re: [SIESTA-L] Energy levels for a single fullerene

2015-05-27 Por tôpico Abraham Hmiel
68.9985269.00356
  69.0070069.8322669.8333469.8386670.10739
  70.1077370.1100370.1127270.1251170.40924
  70.4122370.4140072.1514372.1525772.16014
  72.1630573.1207773.1250373.1335673.13520
  73.1388374.9945274.9971975.0033975.01031
  75.0107176.8235476.8279076.8432976.86721
  76.8700776.8749476.8772376.9185876.92214
  76.9288677.5347377.5387277.5585077.66816
  77.6707077.6721277.6796177.6814978.95244
  78.9544278.9567178.9601780.6100680.61769
  80.6184980.6208281.6730281.6762881.67931
  84.3271884.3320984.3384384.3458484.34987
  90.6700590.6752090.6823390.6945993.87314
  93.8788993.8792693.8827593.88424   101.09874
 101.10956   101.11326   101.11994   101.37630   101.37675
 101.38497   103.36522   103.37822   103.38777   103.38884
 104.33887   104.34513   104.34915   104.35560   104.36248




-- 
*Abraham Hmiel, Ph. D.*
http://abehmiel.net/about


Re: [SIESTA-L] Why don't appear the electric density of Al in my simulation?

2015-05-05 Por tôpico Abraham Hmiel
Hello,

I'm pretty sure that in your case, the electronic charge density is indeed
printed volumetrically, but it's inside the radius of the aluminum atom in
your molecular visualizer, which is opaque. So, you have some options:

1) reduce the radius of your atomic sphere models
2) lower the threshold of the charge density isosurface
3) plot the charge density heat map in planar cross-sections, without
sphere models (this is the manner that I see most often in publications)
4) change the opacity of your atomic models (depends on the visualizer)

Any one of those should work in your case.

Kind regards,


On Tue, May 5, 2015 at 9:30 AM, Guilherme Maia Sawyer 
guisaw...@yahoo.com.br wrote:

 *Ab initio* calculations in the *AlFeO*3 compound have been performed
 using the SIESTA program package. Calculations of atomic geometry and
 electronic structure were performed within first-principles of
 Dendity-Functional Theory (DFT) under the generalized gradient
 approximation (GGA) of Perdew, Burke, and Ernzerhof (PBE) including spin
 polarization. A 490 Ry cutoff was employed for the plane wave basis, and
 integrations over the Brillouin zone of the orthorhombic crystal were
 sampled with a 5 X 5 X 5 k-points mesh.

 My question is, Why don't appear the electron density for the Al?
 Appear for the O, and Fe... but not for the Al!!
 Anyone can help me with this issue?!
 *Why don't appear the electric density of Al in my simulation?*.

 ___
 Guilherme Maia Santos

 Doutorando (PhD student)
 Multifunctional Devices Development Lab - MDDL
 Departamento de Física - DF
 (Departament of physics)
 Universidade Estadual de Maringá - UEM
 (State University of Maringá)
 University of Texas at San Antonio - UTSA




-- 
*Abraham Hmiel, Ph. D.*
http://abehmiel.net/about


Re: [SIESTA-L] Fwd: Antiferromagnetic system calculations

2014-06-18 Por tôpico Abraham Hmiel
Anita,

It would be helpful to the list to see your input file and which version of
siesta you are running, along with the context of where your error occurs
in the program's output.

ZPOTRF is a LAPACK/SCALAPACK routine that computes the cholesky
factorization of a real hermitian matrix that is positive definite.
According to the routine's help page
http://www.netlib.org/lapack/explore-html/da/d7a/_v_a_r_i_a_n_t_s_2cholesky_2_r_l_2zpotrf_8f.html,
the error thrown seems to be an invalid number for the leading dimension.

My guess is that something is amiss in your input file which is causing
this behavior. Perhaps someone with more experience than me with magnetism
in SIESTA can help you once you give us the information that we need to
look deeper into your problem.

Best regards,

On Wed, Jun 18, 2014 at 2:49 PM, Anita Rani ranianit...@gmail.com wrote:

 Hello to all siesta users

 I want to study magnetic properties of (GaMn)As calculations for 32
 atoms. (15Ga 1Mn 16As) but at the end of run i got the problem i.e.

  On entry to ZPOTRF parameter number  4 had an illegal value
 I could not understand what the problem was. I have given same
 parameters for FM calculations. There was no problem like this.

 plz give some suggestions. If anybody have Input file Regarding
 Antiferromagnetic properties .Plz send me.

 Thanks alot.

 with Regards

 --

// \\  Anita Sharma
   //   \\ Assistant Professor in Physics
  // ... \\Guru Nanak College for Girls
 //   \\   Sri Muktsar Sahib, (Punjab)
 (9465305760)



 --

// \\  Anita Sharma
   //   \\ Assistant Professor in Physics
  // ... \\Guru Nanak College for Girls
 //   \\   Sri Muktsar Sahib, (Punjab)
 (9465305760)




-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, SUNY College of Nanoscale Science and Engineering
http://abehmiel.net/about


Re: [SIESTA-L] Structure does not converge

2014-01-24 Por tôpico Abraham Hmiel
Tobias,

I'm curious, what do the results of the following commands look like?
1) fgrep constrained 1.out
2) fgrep outcell: Cell vector modules (Ang) 1.out
*where 1.out is the name of the output log file

You don't have to print them and send them our way, as they'll be very
large, but what can you say about them in general? Are the forces
fluctuating about a small amount that isn't quite as small as the threshold
you've chosen? Are the lattice parameters very different from what you
started with? Is everything blowing up?

In general, this is what I do. Instead of doing one relaxation with a very
large number of CG steps, perform several in steps, making sure the
UseSaveData flag is set to true so that you don't have to come up with a
new density matrix each time and can use the previous CG trajectory
information as well:
1) Do one with MD.NumCGSteps ~ 10 and MD.MaxCGDispl ~ 0.15 Ang, to perform
a very coarse relaxation (it is unlikely you will meet the threshold, and
that's okay. You're not done). Call the output file 1.out or something like
that.
2) Do one with MD.NumCGSteps ~ 20 and MD.MaxCGDispl ~ 0.05 Ang, to perform
a coarse relaxation. Call the output file 2.out
3) Do one with MD.NumCGSteps ~ 20 and MD.MaxCGDispl ~ 0.01 Ang, to perform
a finer relaxation. Call the output file 3.out
...
as many successive steps as you need with as much fineness as desired or
until you meet your force convergence criteria, at which point you will
have a relaxed structure. If 'everything is blowing up' then you may have
to take another look at your simulation parameters. Sometimes choosing the
wrong Pulay mixing parameters will prevent your simulation from falling
into a convergence basin, so another look at that may be helpful.
Transition metals sometimes call for using small (~0.01 or smaller)
DM.MixingWeight with a kick every several steps (see the manual).

Warm regards,

-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, SUNY College of Nanoscale Science and Engineering
http://abehmiel.net/about


On Fri, Jan 24, 2014 at 1:09 PM, Kraemer, Tobias t.krae...@hw.ac.uk wrote:

  Dear SIESTA users,





 I am very new to the SIESTA code, so to start with I am familiarising
 myself with the protocols involved to run

 calculations with the code. I am trying to reproduce some numbers from a
 paper, where a crystal structure

 (triclinic system) of a Ru-allyl complex was relaxed (Organometallics,
 2013, 32, 3784). I have set up a SIESTA input for relaxing

 this structure, using PBE with the default DZP basis sets for all atoms,
 along with pseudopotentials from the SIESTA

 database (I am aware that this might not be the best choice, but to start
 with it might be a fair option). The calculation

 seems to fail to converge to a minimum structure and stops after the
 default 500 opt cycles. This makes me suspicious,

 since my feeling is that the structure should have converged within 500
 cycles. The SCF cycles converge fine.



 I have attached my input file below, the structure is read in from an
 external xyz file (attached). I have used as many

 default settings for the moment as possible. I would appreciate if you
 could share your experience and advice on this subject.



 Is such an input in principle a good starting point for the task at hand?
 What could I improve?

 Would the use of a Monkhorst-Pack grid be a better choice? There are some
 other

 Questions regarding dispersion corrections but first I need to play around
 with what I

 understand from the manual.





 Kind regards, thanks for everybody’s help. Really trying to learn how to
 get reliable results.





 Tobias







 SystemName  [Ru(AcCN)2(Cp*)(eta3-phenylallyl) unit cell

 SystemLabel ru_allyl

 NumberOfAtoms   160

 NumberOfSpecies 7

 WriteMullikenPop1



 %block ChemicalSpeciesLabel

 1  44 Ru  # Species index, atomic number, species label

 2  15 P

  3   9 F

 4   8 O

  5   7 N

 6   6 C

 7   1 H

 %endblock ChemicalSpeciesLabel



 MeshCutoff   400.0 Ry



 NetCharge 0.00



 XC.functional GGA

 XC.authors PBE

 SpinPolarized.false.



 DM.NumberPulay4

 DM.MixingWeight   0.3

 DM.UseSaveDM  .true.



 NeglNonOverlapInt False



 AtomicCoordinatesFormat  NotScaledCartesianAng

 AtomicCoordinatesAndAtomicSpecies  ru_allylinput.xyz



 LatticeConstant 1.0 Ang



 %block LatticeParameters

9.5347 11.7495 15.8787 109.395 96.719 100.965

 %endblock LatticeParameters



 WriteCoorXmol True

 WriteForces .true.

 WriteMullikenPop 1



 SaveDeltaRho  .true.







 MD.TypeOfRun   cg   # Type of dynamics: Conjugate
 gradients

 MD.NumCGsteps   500 # number of CG steps

 MD.MaxCGDispl  0.15 Ang

 MD.MaxForceTol 0.04 eV/Ang

 MD.UseSaveXV   yes

 MD.VariableCell.true.









 



 Dr. Tobias Kraemer

 Research Associate

 Institute

Re: [SIESTA-L] atoms

2014-01-24 Por tôpico Abraham Hmiel
Suman,

I think the answer you're looking for is 42. Only 42-atom simulations are
considered by peer review ;)

But joking aside, you should look to previously-published ab-initio results
in your system of interest or something close to it. Even if such results
exist, you should perform methodological checks on system size, i.e.
size-convergence simulations with respect to: the number of layers in a
surface slab, or supercell dimensions if you're simulating a bulk compound
(perhaps with a defect or other non-homogeneity), different sizes of
nanowire, etc. Some of the most important current problems in nanoscience
involve quantum size-effects, and you don't really know how many atoms a
good simulation requires until you try it- the physics of a particular
solid-state system can vary dramatically based on small size increments!

So, to answer the question you posed, no real number of atoms guideline
exists. Use what is feasible and timely for your computational setup while
giving trustworthy, meaningful, repeatable results! By the way, the T in
siesta stands for Thousands (but this only really makes sense with the
order-N functional). The number of atoms in a SIESTA simulation could be
anywhere in the range {10^0, 10^4}.

-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, SUNY College of Nanoscale Science and Engineering
http://abehmiel.net/about

On Fri, Jan 24, 2014 at 8:21 AM, Suman Chowdhury sumanchowdhur...@gmail.com
 wrote:

 Dear all,
 what is the typical number of atoms one should use for publishable results
 using SIESTA?



Re: [SIESTA-L] reciprocal lattice vectors in SIESTA

2013-09-27 Por tôpico Abraham Hmiel
Hello Diana,

As far as I'm aware, SIESTA doesn't print the reciprocal lattice vectors by
default and no keyword exists to print them. However, it is relatively easy
to create a short script in python or Matlab or such a program that will
calculate them by inputting the unit cell vectors and then taking cross
products (http://www.lcst-cn.org/Solid%20State%20Physics/Ch22.html) or, if
you're ambitious, you can modify the code to print them in a new file or
something.

Regards,

*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, SUNY College of Nanoscale Science and Engineering
http://abehmiel.net/about


Re: [SIESTA-L] Re: Question

2013-08-15 Por tôpico Abraham Hmiel
Mohammad,

First, you don't need mpirun to run gnubands. The program only takes a few
moments to run, even with very large systems and there is no
parallelization implemented. It just reshapes the band structure arrays
into something more easily plotted. Just use:

$ gnubands  QD.bands  QD_bands.dat

Second, if you navigate to the directory where gnubands.f lies and open
gnubands.f with your favorite file editor, you will see that there are some
maximum limits that can halt the program. (the line - if(overflow)
stop...) Adjusting, for example, maxb upwards to a higher value (perhaps a
MUCH higher value) where it is originally declared as 100, then recompiling
gnubands, will fix your issue with the program. Likewise, if you continue
to obtain the same error, perhaps you have breached the maxk limit for the
number of k-points in your plot.

Friendly regards,

-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: [SIESTA-L] BiYO3 optimization

2013-08-06 Por tôpico Abraham Hmiel
Dear Ulas,

I've looked at your .out file and it seems to me that your method is mostly
good, but I do have a suggestion and I hope it helps, regarding your basis
set: with transition metal oxides, I have found that the inclusion of
semicore states is at times absolutely essential to find the correct global
energy minima. That could be your problem here. In your case I would
include 4p semicore states for Y and the 4f and 5d states for Bi. For help
on how to do this, take a look at this basis input for Bi with semicore
states included (or other elements, or search SIESTA-L):
http://www.icmab.es/leem/siesta/Databases/BasisSets/Bi/gga/ - you will need
to explicitly specify the basis of all your atoms in the fdf file and also
need to create a new pseudopotential files for Y and Bi, created with the
atom program. For O, you can look for a basis set inside a metal oxide as
well. You can try to approach a reasonable lattice constant first, then use
the simplex method in siesta-xxx-/Util/Optimizer to fine tune the soft
confinement parameters and cutoff radii of the basis with your
half-optimized crystal structure, then relax the lattice vectors again
using your optimized basis. There are ample tutorials on the simplex
method, both included in SIESTA's documentation in the Optimizer directory
and also elsewhere on SIESTA-L. I'm pretty sure the inclusion of semicore
states with correct pseudopotentials and a well-defined optimized basis set
will get you to where you want to be just fine.

Hearty cheers!


On Tue, Aug 6, 2013 at 9:43 AM, Ulas Koroglu ulaskoro...@gmail.com wrote:

 Dear Siesta Users and Developers,

 I try to optimize BiYO3 crystal that has the cubic structure. While
 experimental value of lattice parameter is a=5.484 Angstrom, but I found
 a=4.095 Angstrom during the geometry optimization in Siesta 3.1.
 There is a big different between the two (experimental and theoretical)
 values. I used many ways to correct the theoretical result ( a=4.095
 Angstrom) but, I didn't achieve. I did not understand what problem is. If
 you can suggest me a solution, I would be very appreciated.

 I have attached the input and output files.

 Best regards.

 Ulas Koroglu.





-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: [SIESTA-L] Charge transfer Calculation from an atom to the other

2013-07-26 Por tôpico Abraham Hmiel
Kiarash,

To add to Ruslan's response, two and a half years ago on SIESTA-L there was
a correspondence between Gao Min and Martin Zoloff on how to create charge
density difference plots-
http://www.mail-archive.com/siesta-l@uam.es/msg02700.html - Martin made a
fortran code for creating charge density difference plots from .RHO files.
It is quite useful and I find myself using it often. Just make sure you use
the same grid, system size, etc. for all 3 pieces.

Other options you can look into are Bader and Hirschfield charge analysis,
but I would definitely start with charge density difference.

Cheers,

-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about

On Fri, Jul 26, 2013 at 5:58 AM, Руслан Жачук zhac...@gmail.com wrote:

 The best way is to do like this:
 1) Calculate charge density of isolated atom, n_at
 2) Calculate charge density of another isolated system, which you are
 interested, for example, surface, n_surf
 3) Calculate charge density of combined system , atom on the surface,
 n_combined

 Then charge transfer is: delta_n = n_combined - n_at - n_surf

 Check out PhysRevB 81, 165424 ( 2010 ) for details.

 Regards
 Ruslan Zhachuk



 2013/7/26 Kiarash Hosseini kiarash.hosse...@gmail.com

 Dear All,
 Good time.

 I want to compute the charge transfer from an atom to the other in an
 ensemble quantitatively. As far as I am concerned I have two choices:

 1. Using Local Density of states (LDOS).
 2. Using *Mulliken population* analysis.

 Please let me know if any of the above mentioned options work?
 Also please suggest any other way to compute charge transfer from among
 specific atoms.
 Thank you in advance.

 --
 Yours Sincerely,
 Kiarash Hosseini
 Mechanical Engineering MSc
 Tehran
 Iran





Re: [SIESTA-L] Selective Van Der Waals interactions

2013-07-26 Por tôpico Abraham Hmiel
Ian,

You can turn on/off the a posteriori vdW Grimme correction for only the
atoms and species that you want, but as far as I know the self-consistent
vdW is applied to the entire simulation box like any other xc-functional.
Other than that, I think if you're using a vdW-xc functional that gets the
correct geometric and electronic structure of the bulk form of your
substrate, you should be in good hands (except for the matter of increased
computational time).

Cheers,

*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany

On Fri, Jul 26, 2013 at 8:16 AM, Ian Shuttleworth 
shuttleworth@gmail.com wrote:

 Siesterers

 I am using siesta-trunk-421 / 433.

 Is there any way to turn on van der Waals interactions for just a
 specific part of the system you're looking at?

 For example, organics adsorbed on a surface : I want to investigate vdW
 between the adsorbates but I dont want to use vdW for the substrate.

 The only command I can find it XC.hybrid which seems to apply to all
 species.

 Thanks

 Ian Shuttleworth



Re: [SIESTA-L] Binding energy of argon dimer overestimated

2013-06-27 Por tôpico Abraham Hmiel
Vitor,

Although I agree that you will have to perform a counterpoise correction on
the energy, that will only lower the binding energy by about 0.1-0.2 eV.
So, something else is wrong here.

I took another look at the original Grimme paper and found that you're
using too high of a Grimme potential parameter. Supposing C6 for Argon is
4.61 (Table 1) from the paper J. Comput. Chem. Vol 27, 1787-1799 (2006),
the geometric average of C6 for two Argon atoms (eq. 13) is, unsuprisingly,
4.61 and that is the value you should use in your MM.Potentials Block,
rather than 47.85.

There is a parameter, MM.Grimme.S6, missing in your input file. Experience
suggests that the default value for this parameter is usually not good
enough to capture the physics of the vdW interaction.

As Herbert said, plotting Ar-Ar distance versus the binding energy will
clearly show you the trend (you will have to perform a ghost atom
calculation for each distance, look elsewhere on the list for help with
that, I believe I answered a similar question some time ago). You should
see that the PBE functional does not bind Ar-Ar together, with no minimum
in Binding E vs distance, and the DFT-D+PBE scheme will probably bind it
slightly.

Increasing your basis set size is going to play a big role in how your
calculation comes out. If you don't want to use the simplex method to
optimize your basis, try out TZDP or a similar, larger basis. You must
declare your own basis set if you wish to include diffuse orbitals (s-like
orbitals of higher principal quantum number).

Cheers!


On Thu, Jun 27, 2013 at 8:25 PM, Vitor Damiao vitordam...@gmail.com wrote:

 Hi Abraham,

 follows the file .fdf  to see if you can help me.

 argon dimer calculations showed acceptable results with the vasp and g03
  programs.

 thanks,
 Vitor.


 2013/6/27 Abraham Hmiel abehm...@gmail.com

 Hello Vitor,

 GGA functionals typically do a poor job of capturing the physics of
 systems with strong van der Waals character like the Ar dimer. Typically
 LDA performs better than GGA because of fortunate cancellation of error,
 but is still far from correct.

 Try installing a recent version of SIESTA's development trunk, available
 from the website. You will be able to use the vdW-DF (DRSLL), vdW-DF2
 (LMKLL), and opt-b88 (KBM) functionals which may significantly improve your
 Ar-Ar bond distance and binding energy at the expense of additional time
 spent calculating the xc energy. There is a decent pool of computational
 results in the literature to draw from here, as well.

 Furthermore, these self-consistent vdW functionals will give you the
 tools to engineer a better optimized basis for Ar. Using an optimized basis
 rather than the automatically-generated ones can be useful and it probably
 couldn't hurt to add additional zetas, polarization orbitals and diffuse
 orbitals to your basis. Without your .fdf file though, it's difficult to
 give you a more exact perscription, but using some form of vdW-DF could be
 a decent start, I feel.

 Best of luck,


 On Thu, Jun 27, 2013 at 2:28 PM, Vitor Damiao vitordam...@gmail.comwrote:

 Hi all,

 Have anybody calculated the argon dimer with SIESTA program? It appears
 that the binding energy (BE) is overestimated. Please, see a DFT-PBE
 calculation using a DZP basis set for Ar---Ar:
 BE (DFT) = 1.3 kcal/mol
 BE (DFT+D) = 2.4 kcal/mol
 BE (Expt.) = 0.28 kcal/mol

 I have tried using different pseudopotentials schemes, but the binding
 energies appears to be too high. I would be grateful if someone could
 explain me this trouble.

 Thanks in advance
  Vitor




 --
 *Abraham Hmiel*
 Katherine Belz Groves Fellow in Nanoscience
 Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
 http://abehmiel.net/about





-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: [SIESTA-L] Fwd: Error

2013-06-11 Por tôpico Abraham Hmiel
Hello Mohammad,

We'd like to help you solve your problem, but we are going to need more
information from you. You should attach:

1) the last ~10 lines of your output file which can provide a guide for us
to see where the program halted
2) a copy of the .fdf you used to run SIESTA
3) a copy of the arch.make file that was used to compile SIESTA, if you can
4) tell us the bash shell command that you used to run SIESTA

Any or all of that information would be appreciated. In the meantime, check
with your sysadmin to make sure there is no limit placed on how much CPU
time you are allowed to use on your cluster and that the memory required by
SIESTA is something that you are able to furnish, as both a user on a node
(ulimit -a) and on the cluster's hardware itself. Can you reproduce the
error if you use fewer processors or a totally different system?

Best regards,


On Tue, Jun 11, 2013 at 11:25 AM, mohammad mahdi Tavakoli 
mehdy.tavak...@gmail.com wrote:


 Dear siesta users

 Hi

 I have an error which is killed my run.

 mpirun noticed that process rank 3 with PID 3026 on node
 user-virtual-machine exited on signal 9 (Killed).

 Can you guide me?

 Thanks.




-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


[SIESTA-L] Re: defining k path for surfaces

2013-06-06 Por tôpico Abraham Hmiel
 plane,
 for example, for the (110) plane.

 I think (but I may be wrong) that if I put a path from the bulk when
 calculating the surface, I will waste computing resource, and some bands in
 the direction perpendicular to the plane will be null or flat.

 Regards,

 Hatuey

   --

 *On Wed, Jun 5, 2013 at 10:19 PM, Abraham Hmiel abehm...@gmail.comwrote:
 Hi Hatuey,*

 What you're looking for is here: http://www.cryst.ehu.es/**
 cryst/get_kvec.html http://www.cryst.ehu.es/cryst/get_kvec.html - find
 the space group for SnO2 and enter it in the box. The k-vector coordinates
 that SIESTA uses in a band structure calculation are in the first set of
 columns, CDML. If you input coordinates this way, it is important to use
 BandlinesScale   ReciprocalLatticeVectors in your .fdf file.

 Then, the manual page http://www.icmab.es/leem/**
 siesta/Documentation/Manuals/**siesta-3.1-manual/node55.htmlhttp://www.icmab.es/leem/siesta/Documentation/Manuals/siesta-3.1-manual/node55.html
  **for information on how to define the path in k-space which will of
 course be implemented in your .fdf file.

 Defining the path in k-space has no implications for the density of states
 calculation. I always use the projected density of states output options,
 as I have a lot more control over what orbitals I'm looking at for my own
 analysis. That particular page is here: http://www.icmab.es/**
 leem/siesta/Documentation/**Manuals/siesta-3.1-manual/**node60.htmlhttp://www.icmab.es/leem/siesta/Documentation/Manuals/siesta-3.1-manual/node60.html

 With PDOS, it is usually a good idea to have a finer k-grid than your SCF
 calculation. For example, if you are simulating a surface with a converged
 k-grid of:

 %block kgrid_Monkhorst_pack
 6 0 0 0.0
 0 6 0 0.0
 0 0 1 0.0
 %block kgrid_Monkhorst_pack

 The following k-grid may be suitable for a PDOS calculation:

 %block PDOS.kgrid_Monkhorst_pack
 16 0 0 0.0
 0 16 0 0.0
 0 0 1 0.0
 %block PDOS.kgrid_Monkhorst_pack
 *
 De:* Hatuey Hack hatuey_h...@yahoo.com.br
 *Para:* siesta-l@uam.es siesta-l@uam.es
 *Enviadas:* Quarta-feira, 5 de Junho de 2013 11:17
 *Assunto:* defining k path for surfaces

 Dear all,

 I am trying to calculate the band structure for different 2D systems. My
 systems consist in nanosheets of SnO2 obtained in the 101 and 110 direction
 from a tetragonal structure grown in the xy plane with the vacum in the z
 direction.

 I would like to know how to define the k path in the Brillouin zone for
 electronic band and DOS calculation.

 Best regards,

 Hatuey





-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


[SIESTA-L] Re: defining k path for surfaces

2013-06-06 Por tôpico Abraham Hmiel
Sorry, I  already realize I've made a proofreading mistake:

'use X for the reciprocal short direction, X' for the reciprocal long
direction, and M as the vector composition of both X and X'. The reciprocal
short direction is parallel to the surface unit cell long direction,
correct?'

should instead read:

'use X for the reciprocal long direction, X' for the reciprocal short
direction, and M as the vector composition of both X and X'. The reciprocal
short direction is parallel to the surface unit cell long direction,
correct?'

apologies.




On Thu, Jun 6, 2013 at 10:08 AM, Abraham Hmiel abehm...@gmail.com wrote:

 Hello again Hatuey,

 Yes, the k-band utility from Bilbao will give you the band paths for the
 bulk. For a surface, it is indeed a little different but not really any
 more difficult. The question you asked is not especially relevant to
 SIESTA, but I will answer it anyway because it's a good pedagogical example.

 I am using this paper as a sample reference for your case:
 http://www.cmdmc.com.br/redecmdmc/lab/arquivos_publicacoes/2781_Density%20Functional%20Theory%20Study%20on%20the%20Structural%20and%20Electronic%20Properties%20of%20Low%20Index.pdf
 -- they are dealing with composite TiO2//SnO2 rutile surfaces but in the
 same Miller index planes that you are interested in, and also TiO2 and SnO2
 individually so it makes for a good example. Usually it is a good idea to
 adopt the conventions of previously published research, especially if you
 are making direct comparisons to them.

 Draw your attention to pages 8948 and 8949 where they depict the
 calculated band structure. They also show the Brillouin zone of the
 surface. The surface Brillouin zone ought to be a rectangle for this
 material because we are dealing with a cubic crystal cut along a face
 diagonal, so one dimension of the surface Brillouin zone will be longer
 than the other. The labels M and X, now, are NOT the same as the bulk M and
 X high-symmetry points.

 Consider the (110) plane case: If you make a cut to the bulk crystal along
 (110) and then orient your viewpoint so that [110] is normal to your line
 of sight (the z-direction, like in your simulation), one choice of lattice
 vectors that yield a rectangular surface unit cell is: {1 -1 0} and {0 0
 1}. You are probably already using this in your surface unit cell. The
 paper, and its predecessor on which the label conventions are based (
 http://prb.aps.org/pdf/PRB/v64/i7/e075407) use X for the reciprocal
 short direction, X' for the reciprocal long direction, and M as the
 vector composition of both X and X'. The reciprocal short direction is
 parallel to the surface unit cell long direction, correct? So now, for
 the SnO2 rutile (110) case, we arrive at the conclusion that X is along [0
 0 1] and X' is along [1 -1 0], and M is along [1 -1 1]. Pretty simple,
 right? But we're not done because we need to tell SIESTA what to do with
 this information and it doesn't care about the bulk crystal, just the
 surface unit cell for the purposes of finding reciprocal lattice vectors
 and so on. In this unit cell, the x direction is along [0 0 1], and the
 y-direction is along [1 -1 0] in the bulk crystal.

 We need to remember that the 1st Brillouin zone's boundary is half the
 length of the reciprocal cell vectors (see
 http://upload.wikimedia.org/wikipedia/commons/2/22/Brillouin_zone.svg for
 a graphical example), so, for the surface unit cell of (110) Rutile SnO2:
 The Gamma point is at [0 0 0] (that's easy)
 The X' point is at [0 0.5 0] (because it's parallel to the y-direction,
 the reciprocal short direction)
 The M point is at [0.5 0.5 0] (because it's the sum of vectors X' and X,
 therefore x+y unit vectors)
 The X point is at [0.5 0 0] (again, the x-direction in the surface unit
 cell, the reciprocal long direction)

 And then, creating this path in reciprocal space in a way SIESTA can
 understand (and I'm estimating the number of points in each line):

 WriteBands .true.
 BandLinesScaleReciprocalLatticeVectors

 %block BandLines
 10 0 0 \Gamma
 20   0.5 0 0 Xprime
 50   0.5 0.5 0 M
 20   0 0.5 0 X
 50   0 0 0 \Gamma
 %endblock BandLines

 Then, run: (assuming your systemlabel is SnO2_110)
 bash gnubands  SnO2_110.bands  SnO2_110_bands.dat

 When plotted with software like matplotlib or gnuplot, this should create
 a plot that is similar to figure 2b in the 1st reference I gave you once
 you choose the correct viewing window. Keep in mind that your energies will
 be with respect to the program's energy zero and not the VBM, Fermi energy,
 or vacuum level unless you write a script to subtract that energy from the
 second column of SnO2_110_bands.dat.

 If you calculate the lengths of each reciprocal lattice vector in 1/bohr
 or Angstrom you can probably make a more consistent band lines scale than
 the one I used above for the number of points along each line, but I'll
 leave that as an exercise for you. Also another exercise for you: do you
 have

Re: [SIESTA-L] defining k path for surfaces

2013-06-05 Por tôpico Abraham Hmiel
Hi Hatuey,

What you're looking for is here: http://www.cryst.ehu.es/cryst/get_kvec.html -
find the space group for SnO2 and enter it in the box. The k-vector
coordinates that SIESTA uses in a band structure calculation are in the
first set of columns, CDML. If you input coordinates this way, it is
important to use BandlinesScale   ReciprocalLatticeVectors in your .fdf
file.

Then, the manual page
http://www.icmab.es/leem/siesta/Documentation/Manuals/siesta-3.1-manual/node55.html
for
information on how to define the path in k-space which will of course be
implemented in your .fdf file.

Defining the path in k-space has no implications for the density of states
calculation. I always use the projected density of states output options,
as I have a lot more control over what orbitals I'm looking at for my own
analysis. That particular page is here:
http://www.icmab.es/leem/siesta/Documentation/Manuals/siesta-3.1-manual/node60.html

With PDOS, it is usually a good idea to have a finer k-grid than your SCF
calculation. For example, if you are simulating a surface with a converged
k-grid of:

%block kgrid_Monkhorst_pack
6 0 0 0.0
0 6 0 0.0
0 0 1 0.0
%block kgrid_Monkhorst_pack

The following k-grid may be suitable for a PDOS calculation:

%block PDOS.kgrid_Monkhorst_pack
16 0 0 0.0
0 16 0 0.0
0 0 1 0.0
%block PDOS.kgrid_Monkhorst_pack

Best regards,

*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: [SIESTA-L] Convergence for charged system...

2013-05-29 Por tôpico Abraham Hmiel
Hi Luigi,

A few suggestions:

1) Your MaxCGsteps and MaxSCFIterations are both very large, convergence in
many problems can be adequately approached by using a small number of CG
updates, like 10-50 to perform a stepwise convergence, changing mixing
parameters slightly between runs, observing how the forces change between
CG steps and using UseSaveData = .true. to use saved DM's, XV's and so on.
MaxSCFIterations could be around 100-250, much more than that and you're
wasting your time, might I add.
2) Try using more Pulay convergence parameters. This will probably get you
to convergence if you choose them right. You will have to modify them until
you attain something that works. For starters, try:
DM.NumberPulay  5
DM.MixingWeight 0.002
DM.NumberKick  12
DM.KickMixingWeight0.0766
I've found that oftentimes the Pulay kick will knock your SCF cycle into
a convergence basin, especially with charged systems or hard
pseudopotentials. Look in the manual to see how these are defined.
3) I'm not sure why SimulateDoping would help you, it seems unphysical to
me in a molecule rather than a solid. Your meshcutoff also seems low, but
it won't help your convergence problem. Look into converging that value
once you can close your SCF loop.
4) 30x30x30A cell is a big box for a small molecule, perhaps there may be a
benefit to using a smaller cell, since a Madelung correction term is
applied for molecules? If you go to a 20x20x20 cell does the convergence
issue get worse?

That's all I can think of for now, definitely look into the Pulay
convergence acceleration though.

Warm regards,

*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


[***Posible SPAM***]Re: [SIESTA-L] DOS ploting

2013-04-30 Por tôpico Abraham Hmiel
Jafar,

I think you're using the wrong unix pipe command. Try:

$ ./Eig2DOS  Si.EIG  Si.dos

Or you can try using the %ProjectedDensityOfStates block, which will give
you much more valuable information, in my opinion. See the manual for
details.

You may want to do some basic bash shell/unix pipe tutorials because your
questions in this thread have little to do with SIESTA and more to do with
proper shell command syntax. Look here for a beginner's introduction:
http://arachnoid.com/linux/shell_programming.html

Best,
-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: [SIESTA-L] DOS ploting

2013-04-30 Por tôpico Abraham Hmiel
Jafar,
Upon closer inspection, it seems that you have the correct command syntax.
Sorry for the confusion. You wrote it the wrong way once and the right way
once in your message.

I'm still having trouble replicating your error, though. Have you copied
the eig2dos file to $HOME/usr/bin or some other directory that is within
the scope of your $PATH environment variable (in .bashrc or .profile in
your home directory)? If you do this, you don't need to use ./ to run the
executable and you don't need to have the executable in the same directory
as your data.

I am curious, from what version of siesta did you build the eig2dos
utility? Did you use the same fortran compiler that you used to build
siesta? Are you sure that you're using the correct spelling and case of the
filenames?

Cheers,


On Tue, Apr 30, 2013 at 11:17 AM, Abraham Hmiel abehm...@gmail.com wrote:

 Jafar,

 I think you're using the wrong unix pipe command. Try:

 $ ./Eig2DOS  Si.EIG  Si.dos

 Or you can try using the %ProjectedDensityOfStates block, which will give
 you much more valuable information, in my opinion. See the manual for
 details.

 You may want to do some basic bash shell/unix pipe tutorials because your
 questions in this thread have little to do with SIESTA and more to do with
 proper shell command syntax. Look here for a beginner's introduction:
 http://arachnoid.com/linux/shell_programming.html

 Best,
 --
 *Abraham Hmiel*
 Katherine Belz Groves Fellow in Nanoscience
 Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
 http://abehmiel.net/about




-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: [SIESTA-L] Error in Cholesky... (Abraham Hmiel)

2013-03-31 Por tôpico Abraham Hmiel
Hamidreza,

You're trying to fit 20 atoms into a 2.159Ax2.169A rhomboid unit cell in a
flat geometry? That sounds like a pretty bad idea to me. Like I said
before, rethink your atomic positions. You are getting an error because
when your atomic positions are translated back into your primary unit cell,
they overlap with one another and introduce a ridiculous electron density
distribution which throws off the diagonalization algorithm.

How have you 'converged' your k-point grid and meshcutoff with respect to
total energy if you are getting errors like this? I refuse to believe that
the 'best Meshcutoff' for this system occurs at zero. I have performed this
simulation myself and obtained an optimal value around 300 Ry. Same with
k-points. If you are looking to reproduce the Dirac Cone in the band
structure, you are not going to get anywhere with the k-point mesh you are
using. This is a very well-studied problem. Please search the list for more
help and double-check your input files to make sure they make sense.

Best,
Abraham Hmiel


On Sun, Mar 31, 2013 at 8:06 AM, Hamidreza Balangi 
hamidrezabala...@yahoo.com wrote:

 Hi   **
 My friend Abraham Hmiel
 Idid input file (fdf) according to the manual, and email list.
 While convergence Lattice Constant, PAO.Basis, kgrid_Monkhorst, cut off
 obtain with respect to total energy
 The following error appeared to converge better with smaller
 LatticeConstant
 *Error in Cholesky factorisation in cdiag error stop from Node:   0*
 *Finally*, 1 - The atomic coordinates of obtained with AutoCAD software***
 *
 2 - the best cut off appear at zero
  3 - In case the error is not explained in the manual and mailing list is
 not given the correct answer to this question.
 4 - I have Input file attachment for you.
 please help me in this problem. 
 With thanks and best wishes to you
 hamidreza balangi
 ** **
 ** **
 ** **
 ** **
 ** **
 ** **
 ** **
 ** **
 ** **
 ** **
 ** **
 ** **




-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: [SIESTA-L] Fw: This is an error Cholesky on run sheet Graphene

2013-03-30 Por tôpico Abraham Hmiel
Hamidreza,

I'd like to help you solve your problem, but it seems like you have not
read the manual to learn how to perform a proper calculation. Please do so.
Additionally, if you search the mailing list archives, you will find
working graphene input .fdf files that yield plausible results because this
question has been asked dozens of times. For example:
http://www.mail-archive.com/siesta-l@listserv.uam.es/msg02155.html

Here is what comes to mind when I read your input file:

1. Why are you using siesta 2.0.2? The most recent version is profoundly
better and has more features. Unless there is a specific reason to use
2.0.2, you should upgrade to the new version.
2. For an infinite graphene sheet, 10x10x1 M-P k-point grid is not good
enough because it is too coarse around graphene's dirac points in the BZ.
You will need at least 48x48x1 from experience.
3. 20 Ry is way too small for the MeshCutoff. Try at least 10 times this
value, and you will need to converge this value with respect to total
energy.
4. (The reason why your simulation is not working) you have no atoms listed
inside your AtomicCoordinatesAndAtomicSpecies block. If you have no
species listed here, I believe the program will make the coordinates of
everything (0,0,0), hence why it prints that warning that specific atoms
are too close together.

Finally, when attaching items in an email to the list, please use plain
text (or .png for figures) from now on. I'm also not sure why you posted
your message five times to the list, it is mildly irritating to see such a
thing in my inbox and might make people less willing to help you.

Hope this helps and good luck with your calculation,
-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: [SIESTA-L] problem

2013-01-30 Por tôpico Abraham Hmiel
Zahra,

You've posted to the list before with regards to this system. Why are you
still plotting a band structure path in reciprocal space of a molecule?
Please prove to us that you can explain what you're trying to do and then
we can help you solve your issue. By the way, it's always helpful to
include the relevant figures in your email to show us what you mean. No one
really wants to run this system ourselves to see your result (not that we
could, without knowing which pseudopotentials you're using).

Best,

On Wed, Jan 30, 2013 at 2:07 PM, Zahra Talebi talebi_z2...@yahoo.comwrote:

 hi every body,
 I runned this fdf with siesta but I don`t know why my DOS diagram doesn`t
 show the same band gap as my band structure showes. Can any body tell me
 about that. or guid me that how can I solve this question.
 regards




-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: Fw: [SIESTA-L] why my running did stop.

2013-01-15 Por tôpico Abraham Hmiel
I found the line,

# MD.NumCGsteps  550  # Number of CG steps for

which is out-commented. (550 steps is very large, by the way! Try 20 or 30
at a time)

Remove the '#' to perform a geometry relaxation. If you don't specify the
number of steps, the computer will just assume I am going to do a
single-point energy calculation. Also, because you are simulating a
molecule (a graphene flake passivated by H, it seems), you do not need
nearly as many k-points as you are using and the band lines you are using
don't really make any sense because of the 0D symmetry.

Also, you might want to upgrade to the latest version of SIESTA. Go to the
home page for the newest release. http://icmab.cat/leem/siesta/

Best,

On Tue, Jan 15, 2013 at 9:47 AM, Zahra Talebi talebi_z2...@yahoo.comwrote:



 hi every body,
 I attached my out file after running a siesta, can any body explain for me
 that why the running stoped.
 best regurds




-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: [SIESTA-L] Siesta: System type = molecule

2012-11-14 Por tôpico Abraham Hmiel
Hakkim,

SIESTA will automatically detect the molecule, chain, slab, or bulk type
depending on how close the images of each atom are across the x, y, and z
dimensions of your simulation cell. This is done in the shaper.f
subroutine. If your unit cell is big enough in all 3 dimensions such that
no orbitals interact (in a certain range) in your atom list's periodic
image, you will have a molecule. If they interact in one dimension, you
will have a chain (or nanowire), two, a slab, and all three dimensions, a
bulk system.

If you are seeking to do a force minimization calculation on a bulk system
and you are getting System type = molecule in the output, you need to
check the dimensions of your unit cell to make sure it is small enough that
image atoms in all three dimensions will interact with the atoms whose
position you've explicitly declared in the unit cell. Maybe your dimensions
are proportionally correct to the crystal you'd like to simulate but your
lattice constant is too big.

On Wed, Nov 14, 2012 at 9:36 AM, Hakkim Vovusha 
hakkim.vovu...@physics.uu.se wrote:

 HI,

 I am doing force minimization calculation (periodic system) in siesta and
 I have found in the output Siesta: System type = molecule  but i need to
 change the molecule into bulk i.e. Siesta: System type = bulk. Can any one
 help how to change these molecule into bulk.

 with regards
 hakkim




-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: Re: Re: [SIESTA-L] post-processing the energy band

2012-11-08 Por tôpico Abraham Hmiel
Liu,

I have tried to run your input file with siesta-trunk-364, siesta-3.1pl-9,
and siesta-trunk-411, and it seems that trunk-411 is hanging at the
writewavefunctions step for me. It's not printing out any 'maxk' business,
just not completing the wavefunction-writing output in 30 minutes when it
took 45 seconds in the other codes I've tried. If you are not using the
vdw-xc that is included in the trunk versions, why not just use a different
version of siesta to write the wavefunctions? Have you tried a more recent
trunk version? I have checked the changelog and saw that writewave.f has
been amended to include greater functionality at trunk-414, you might wish
to try trunk-424 and see if that version will write the wavefunctions
correctly.

Also, unrelated to your issue, I noticed you may want to tighten up your
Monkhorst-Pack k-point grid to at least 30x30x1 to get a good description
of the dispersion of the energy bands close to the K point in the BZ. It
may make the difference between a band structure that makes sense and one
that looks like garbage.

Best,

On Thu, Nov 8, 2012 at 1:42 AM, liuyunlong0902 liuyunlong0...@126.comwrote:

 Thanks for your suggestion. Here I include the input and output file,
 which is just an example for calculating graphene energyband. This work can
 run well on the old version 'siesta-3.0-rc2' ,but not the new version
 'siesta-trunk-411'. I check the 'maxk' in 'writewave.F' of both version,
 but find nothing difference.


 Best,
 --
  Liu


 At 2012-11-08 09:54:03,Abraham Hmiel abehm...@gmail.com wrote:

 What follows is a general explanation for what to do in this case and ones
 like it. In this case, what I did is to run the following command in the
 /Src/ directory of my SIESTA build to see where all the instances of 'maxk'
 were (I'm using trunk-364 at the moment, it shouldn't be too different,
 though):

 [Src]  grep 'maxk' *

 and the output found files that use 'maxk' in a bunch of the files. There
 is a lot of output here, and I'll spare you the whole list, but one of
 these files has the error message you specificed, so take a look at
 'writewave.F' to see if you're doing anything wrong.

 You didn't include your input file with your message, and it would help to
 diagnose the problem. I would double-check that you're using the correct
 syntax for the WaveFuncKPoints fdf block by examining the source core for
 the initwave and wwave subroutines.

 There is no substitute for reading the source code :)

 On Wed, Nov 7, 2012 at 11:34 AM, liuyunlong0902 liuyunlong0...@126.comwrote:

 Dear Abraham Hmiel,
 Thanks for your help!
 Besides, I have another problem in running SIESTA new version
 'siesta-trunk-411', when submit a siesta work, the output file give the
 warning Writing Wavefunction: parameter Maxk too small, So how I can
 change the parameter 'Maxk' ? Thanks again.

 Best,
 --
 Liu
 At 2012-11-05 19:33:31,Abraham Hmiel abehm...@gmail.com wrote:

 Liu,

 Try increasing the value of the 'maxb' parameter in gnubands.f,
 (increasing from 100 to something like 5000) and then re-compiling
 gnubands.f and then trying it again.

 Best,

 On Mon, Nov 5, 2012 at 6:15 AM, liuyunlong0902 liuyunlong0...@126.comwrote:

 Dear all,
I have difficulty in post-processing the energy band. When the
 generated '*.bands' file is handled by 'gnubands', warning is that
 'Dimensions in gnubands too small'. Would anyone help me solve the problem?

 Regards,

 ---
 Liu


 --
 *Abraham Hmiel*
 Katherine Belz Groves Fellow in Nanoscience
 Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
 http://abehmiel.net/about







 --
 *Abraham Hmiel*
 Katherine Belz Groves Fellow in Nanoscience
 Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
 http://abehmiel.net/about







-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: [SIESTA-L] SIESTA-L-fdf format

2012-11-05 Por tôpico Abraham Hmiel
Hakkim,

What I believe Sergio was asking you is, what is the shell command you use
to run siesta? For example,

 mpirun -np 8 siesta  input.fdf  1.out 

Best,

On Mon, Nov 5, 2012 at 4:14 AM, Hakkim Vovusha hakkim.vovu...@physics.uu.se
 wrote:

  I have generate fdf file for my molecule from xyz coord using GDIS then
 i started to run the siesta. I have attached the fdf file.

 regards
 hakkim
 On 11/2/2012 6:25 PM, Sergio Ferrari wrote:

 Hi Hakkim,
  How exactly do you run Siesta?
Regards, Sergio Ferrari

 2012/11/2 Hakkim Vovusha hakkim.vovu...@physics.uu.se

 Hi,

I have generated fdf file from the link

 GDIS http://gdis.sourceforge.net/. then I start to run siesta (md
 calculation) its running but i havenot find nothing in the output file. can
 any one help in this regards

 with regards
 hakkim






-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: [SIESTA-L] SIESTA-L-fdf format

2012-11-05 Por tôpico Abraham Hmiel
Hakkim,

You have not told SIESTA what to do in your .fdf file. Therefore, I don't
really know what you want to do either but you need some lines like this:

MD.TypeOfRun  Nose
MD.InitialTImeStep 1
MD.FinalTimeStep  1000
MD.LengthTimeStep1.0 fs
MD.VariableCell .false.
MD.TargetTemperature   278.0 K
MD.InitialTemperature278.0 K
MD.NoseMass   100.0 Ry*fs**2

Also, I see in your .fdf file that you did not define the LatticeVectors
block. You need to tell SIESTA the size of the simulation cell, she can't
guess this automatically.

You need to read the manual, especially the pages on Molecular Dynamics
parameters

Best,

On Mon, Nov 5, 2012 at 6:26 AM, Abraham Hmiel abehm...@gmail.com wrote:

 Hakkim,

 What I believe Sergio was asking you is, what is the shell command you use
 to run siesta? For example,

  mpirun -np 8 siesta  input.fdf  1.out 

 Best,


 On Mon, Nov 5, 2012 at 4:14 AM, Hakkim Vovusha 
 hakkim.vovu...@physics.uu.se wrote:

  I have generate fdf file for my molecule from xyz coord using GDIS then
 i started to run the siesta. I have attached the fdf file.

 regards
 hakkim
 On 11/2/2012 6:25 PM, Sergio Ferrari wrote:

 Hi Hakkim,
  How exactly do you run Siesta?
Regards, Sergio Ferrari

 2012/11/2 Hakkim Vovusha hakkim.vovu...@physics.uu.se

 Hi,

I have generated fdf file from the link

 GDIS http://gdis.sourceforge.net/. then I start to run siesta (md
 calculation) its running but i havenot find nothing in the output file. can
 any one help in this regards

 with regards
 hakkim






 --
 *Abraham Hmiel*
 Katherine Belz Groves Fellow in Nanoscience
 Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
 http://abehmiel.net/about





-- 
*Abraham Hmiel*
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany
http://abehmiel.net/about


Re: [SIESTA-L] Negative phonon frequency problem.

2012-11-02 Por tôpico Abraham Hmiel
Saikat,

Your issue here is that you are using the default value of:

MD.MaxForceTol0.04 eV/Ang

because you are not using it in your fdf file. For what you are trying to
accomplish, I think a MD.MaxForceTol of about 0.001 eV/Ang is more
appropriate.This is a good target for small molecules. Try using far fewer
MD.NumCGsteps too, I usually use about 30-50 at a time so that if something
goes wrong you can trace it without waiting forever, a good practice if
you're moving from small molecules to molecules adsorbed onto a surface or
something. MaxSCFiterations is very high as well, should something
unfortunate happen with your convergence. It won't affect anything here,
though. You can also use:

UseSaveData .true.

To restart simulations that go to the full # of CG steps using saved
density matrices and atomic positions, and recent CG history.

The reason why you were seeing negative frequencies is because your
geometry optimization is not finding the global minimum, so that when atoms
are displaced in the FC step by very small amounts, it might find a lower
energy state. This topic is discussed at length elsewhere on the list.

-- 
Abraham Hmiel
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany


Re: [SIESTA-L] mpi error while running siesta

2012-06-23 Por tôpico Abraham Hmiel
Dear Karan,

We are going to need a lot more information than the error message you
provided to solve your problem.

What is the command you used to invoke the program?
What are the contents of your arch.make file and the input fdf file?
What few things have you tried, exactly?
Does the invocation of siesta work in serial mode?
Has siesta with mpi ever successfully run? Is this a chronic problem or
does it happen seemingly at random?

The more information you put forward to the listserv, the more able we are
to help you.

Best,



On Sat, Jun 23, 2012 at 10:19 AM, karan deep kara_nd...@yahoo.co.in wrote:

 Dear users  i m suddenly getting this error while running siesta

  Fatal error in MPI_Comm_group: Invalid communicator, error stack:
 MPI_Comm_group(150): MPI_Comm_group(comm=0x0, group=0x7fff0c620494) failed
 MPI_Comm_group(74).: Invalid communicator

 i try few things but nothing is working




-- 
Abraham Hmiel
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany


Re: [SIESTA-L] siesta relaxation question

2012-04-11 Por tôpico Abraham Hmiel
Personally I would only trust an 100 Ry cutoff calculation to provide a
starting point for a geometric configuration destined for further
relaxation. My experience tells me if you use oxygen you should always be
using 350 Ry or more, and typically for some materials I've been simulating
recently, as high as 550Ry. Incidentally, depending on your simulation
cell, any cutoff will set the *actual* grid used to be higher, sometimes
much higher. If you take a stable geometry and perform a single-point
energy (0 CG steps) convergence test with respect to the meshcutoff, try
and see what happens when you increment the mesh cutoff by steps of about
100 Ry or so all the way to about 2000 Ry- you should find that the energy
won't change by much after a certain point, and the cutoff you should
choose will balance being respectably close to that converged energy.
Always record the meshcutoff used by siesta, not the one in your input file.

For example, a while ago with bulk TiO2, I found that the difference in
total energy between a ~1400 Ry cutoff and a ~550 Ry cutoff was about the
same as the difference between ~450 Ry and ~550 Ry. I chose the 550 Ry grid
as it was 'sufficiently converged' for my purposes, did an egg-box test,
printed the proof in a couple quick plots and saved it somewhere
accessible. Having a tight grid that is balanced by its memory usage is a
trick you kind of have to get a knack for. It is true that some problems
really do require tight expensive grids and a lot of memory, and it might
seem to squeeze a lot of the time benefits out of using LCAO-based approach
(vdW xc-functionals come to mind). In these cases your parallelization
scheme and how you select initial reference geometries will make a lot of
difference! The egg-box convergence test is another one you will find
yourself doing often to check the reliability of your numerical grid, look
elsewhere on the list for that.

The bottom line is, I would always explicitly include the MeshCutoff as an
input in an fdf of mine for research purposes. Even when I need a 'quick
and dirty' estimate of something or perhaps a stepping stone to a reference
geometry to iron out some of the more expensive force-fluctuation math.

On Wed, Apr 11, 2012 at 6:36 PM, Yi Gao yigao1...@gmail.com wrote:


 Dear siesta users,

 Recently I have been using siesta to find optimized structure of crystal
 such as anatase.

 According to what I have found, if we run the CG or Broyden method to
 search for atom positions with least forces, say, 0.02 eV/Ang, the default
 MeshCutoff (e.g., 100.0 Ry) gives a configuration. However, if I simply
 displace the origin of my lattice from somewhere to some atom, keeping the
 primitive vectors unchanged, the forces exerted on each atom will change,
 which is unphysical.

 What I can do is to increase the MeshCutoff to try to get converged
 results, i.e., displacing the origin of the lattice does not change the
 forces on each atom, and finally in agreement with experiments. But it
 turns out to be MeshCutoff = 500.0 Ry, so large that it is difficult to
 extend to larger systems.

 My question is that how can I trust the atom configuration with the
 default MeshCutoff? Is it always necessary to set MeshCutoff to an
 exceedingly large value to get converged results?

 Best wishes!

 Yi




-- 
Abraham Hmiel
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany


Re: [SIESTA-L] how to explain

2011-10-10 Por tôpico Abraham Hmiel
Zahra,

When you calculated DOS with SIESTA, what method did you use? Did you use
EIG2DOS or did you use a PDOS utility (then sum the PDOS on each atom and
orbital), or something else?

I would trust your 'band' energy diagrams for this molecule. The DOS
calculation uses a Gaussian smearing parameter that you set yourself. If the
HOMO-LUMO gap around the Fermi energy is close to your smearing parameter,
what you show in the DOS you shared will happen. Try lowering the value for
the smearing parameter (According to your plots it looks like it is around
0.250).

If you used eig2dos with a first line like this:
-3.4561 0.25 1000 -10 10

reduce the second number to something less than, about 0.05. How you would
plot a DOS curve is something of a personal preference, considering clarity
and value of information presented. A smaller smearing width will change how
the curve looks somewhat. Change the parameters until you get something you
are satisfied with.

Also, using many k-points when calculating an isolated molecule is not
usually a good idea. Use a 1x1x1 k-point mesh for a molecule and only worry
about convergence with respect to the real space mesh cutoff.

Best of Luck,

Abraham Hmiel
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany

On Mon, Oct 10, 2011 at 8:45 AM, Zahra Talebi talebi_z2...@yahoo.comwrote:

 hi dear siesta usrs,
 t first I hope to be able to ask my question in a right way, because my
 english isnot good.
 I just did some run and got the result as band structure and dos for the
 special run of siesta. As you notic I attached them to my e-mail. my band
 structure showes a very smal band gap arround gama and because I am running
 for molecule, the band structure must be the same in other path of beriloan
 zone too, by such a band strucute I expect to see a very small gap in my DOS
 arrround fermi energy but  not only I don`t have any gap there is a tick
 near fermi energy. can any body tell me why this happen. if you need my fdf
 I can send it for you.
 also I have some other run too which Ihave the same problem for them. I
 mean I have a gap arround fermi energy in my band structure but in my DOS
 diagram I can see the DENSITy arround the frmi energy.
 Thanks for your help.




Re: [SIESTA-L] no gradient calculation

2011-10-04 Por tôpico Abraham Hmiel
Robert,

It is absolutely possible to do this, the total energy is printed a few
times when the run ends.
To calculate single point energy, use:

MD.TypeOfRun  cg
MD.NumCGsteps 0

So that atoms are frozen in place, then once the run is finished either look
for a siesta: total Energy line in the output file, or you can use grep to
look for the specific line in the file. Try:

 fgrep siesta: FreeEng
if you want the free energy or

 fgrep siesta: Etot
for the total energy (in many instances, they will be the same). The grep
command used this way will return two values, the first is the (unconverged)
total energy from the beginning of the run, and the second is the converged
energy at the end of the cg/scf loop. Towards the end of the output file,
you can also find lines like these:

siesta: Final energy (eV):
siesta:  Band Struct. =  -28113.082516
siesta:   Kinetic =   62511.903467
siesta:   Hartree = 1851209.928718
siesta:Ext. field =   0.00
siesta:   Exch.-corr. =  -19076.142766
siesta:  Ion-electron =-3768244.293672
siesta:   Ion-ion = 1753136.700291
siesta:   Ekinion =   0.00
siesta: Total = -120461.903961

Where the energy is partitioned into all of its components. You have to
carry the calculation through to completion, either by satisfying some
atomic force convergence condition or a maximum of conjugate gradient steps
to get this information, so you won't see it if you are interrupting the
calculation somehow.

Best of luck,

Abraham Hmiel
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany

On Tue, Oct 4, 2011 at 7:53 AM, robert.sed...@marge.uochb.cas.cz wrote:

 Hello SiestaUsers,

 I'm new member of SiestaUsers family. I have one small question,
 is it possible to calculate only single point (electronic) energy with
 siesta ... . In my output I can see also gradients, but I would like to
 calculate only energy.

 Thanks in advance.

 Best Regards

 Robert Sedlak







Re: [SIESTA-L] Band Identification

2011-09-29 Por tôpico Abraham Hmiel
Hello Abbas,

This is usually a multi-step process. At a general level, you need to look
at the quantities derived from orbital populations. Projected density of
states is an important one. If you use the pdos utility or a special script
you write, you can separate the PDOS data file into PDOS aggregated onto a
specific atom, group of atoms, orbital, or selected orbitals on selected
atoms. You should re-read the section in the manual about PDOS, how to
create it, etc. The other thing you can look at is the crystal orbital
overlap population by running the COOP utility mprop. Look elsewhere on the
list for information in how to set that data file, basically, you select
pairwise atoms/orbitals and a range of distances and it will calculate COOP.
You will have to manually prepare a lot of data and look at it side by side
to determine which orbitals are interacting strongly at what energies.

From that, you can see a general energy range of where to look for the local
(spatial) electronic density of states (plotted with grid2cube), which can
be supplied as a range of energies in the fdf. The other way to do is is to
plot a lot of wavefunctions and use the denchar utility to make .cube files
then plot isosurfaces of the complex wavefunction at a particular grid
density using a program of your choosing. If you look at them side by side
in sequence, you can discern characteristics that mark the spatial patterns
of what you're looking for. Unfortunately, sometimes these visualization
files can get quite large and cumbersome for some computers to handle, but
either way you should then have a pretty good idea of which band since
they are numbered sequentially up from the lowest energy state. It's not
going to tell you BEEP: THIS BAND IS PI* but it is a judgment you will
have to make.

And then have the band structure handy for reference  to put everything in
perspective. You should write a script or something that can identify an
energy band in the k-range you specify in a crystal. Combined, these things
are all ingredients of good convincing arguments in a publication.

Best of luck,

-- 
Abraham Hmiel
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany


On Thu, Sep 29, 2011 at 9:54 PM, Abbas Ebnonnasir aebno...@mymail.mines.edu
 wrote:

 Dear SIESTA users,

 I'm trying to find out how I can identify each band in band structure plot,
 resulted from SIESTA, i.e, I need to know which band belongs to which
 molecular/crystal orbital (which one is Pi, which one is Pi*, Sigma).

 Any comment will be appreciated.
 Thank you in advance.

 All the wishes,

 -Abbas





Re: [SIESTA-L] graphene

2011-09-01 Por tôpico Abraham Hmiel
Zahra,

The cause of your incorrect DOS is due to the fact that in graphene, there
are only a few ways of sampling the Brillouin zone while keeping the Dirac
Point as a member of the mesh. When you go from exactly describing the
desired k-point grid with the %block kgrid_monkhorst_pack to using
kgrid_cutoff, you no longer demand specific points in the mesh so you might
end up avoiding the area of reciprocal space around the dirac point, which
is responsible for a lot of the physics. You need a pretty dense mesh to get
the DOS correct because of the special feature at the Dirac point which must
include the Dirac Point, and SIESTA doesn't 'know' to do this when you use a
numerical cutoff value. It has less to do with graphene being 2D and more to
do with its Fermi surface being just a single point which should be sampled
densely and the k-mesh chosen carefully.

A related question appears on another thread and you should observe the
answer given there:
http://www.mail-archive.com/siesta-l@uam.es/msg00935.html - for starters, a
21x21x1 mesh seems to do a good job, presuming the rest of the input file is
nearly the same style as the one in that thread.

Best,

Abraham Hmiel
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany


On Thu, Sep 1, 2011 at 4:45 AM, Zahra Talebi talebi_z2...@yahoo.com wrote:



   Hi dear users
 I am working on graphene. before this I used kgrid Mokharest pack in my fdf
 file but just recently I tried kgrid cutoff.  it caused that I don`t get
 the right DOS. why this happen?
 Is it because graphene is two dimention and I cannot use kgrid cutoff for
 that.
 If any body knows the answer please let me know.
 regards,
 Zahra.





Re: [SIESTA-L] Can siesta preform the nudged elastic band (NEB) calculation?

2011-07-17 Por tôpico Abraham Hmiel
There is not an implementation within the SIESTA code as of now for nudged
elastic band, but there is an implementation in the python package 'ASE' -
google 'atomic simulation environment' for more info. Basically, you can use
SIESTA as a calculator for the total energies and forces and let ASE perform
the set of minimizations along the chain of images.

Abe
On Jul 16, 2011 8:17 AM, Jingbin Li jingbin...@gmail.com wrote:
 Hi Hongyi,

 As far as I know, there is no NEB implementation in Siesta yet.

 Thanks,

 On Sat, Jul 16, 2011 at 1:49 AM, Hongyi Zhao hongyi.z...@gmail.com
wrote:

 Hi all,

 I know that VASP can do the NEB calculation for finding saddle points and
 minimum energy paths between known reactants and products. But don't know
 whether we can perform the similar job within siesta?

 Regards
 --
 Hongyi Zhao hongyi.z...@gmail.com
 Institute of Semiconductors, Chinese Academy of Sciences
 GnuPG DSA: 0xD108493



Re: [SIESTA-L] question about post-process output file .PDOS

2011-07-15 Por tôpico Abraham Hmiel
If I understand your question correctly, you're having trouble getting
useful information out of a PDOS file.

There is a PDOS parsing utility in the main /Util directory, but I usually
don't use it. Look elsewhere on the list for help with that.

This is the way I peel the tag garbage off:
If you know exactly how many orbitals for atom, number of bins, and you make
a separate list of the indexes of the atoms, you can remove all the xml tags
with this unix command:

bash$ grep -ve \ -ve \ -ve = systemlabel.PDOS  systemlabel_PDOS.dat

then use the remaining file with a matlab or python script to chop up that
large PDOS file into atoms of like orbitals, etc. This requires you to be
consistent in your indexing scheme and you should become very familiar with
your basis set if you do it this way.

Best,

Abraham Hmiel
Katherine Belz Groves Fellow in Nanoscience
Xue Group, College of Nanoscale Science and Engineering at SUNY Albany

On Fri, Jul 15, 2011 at 4:40 PM, lily zheng lilyclem...@gmail.com wrote:

 Dear all,


 How to give those parameters which show up as the head of .PDOS file?

  pdos
 nspin1/nspin
 norbitals   6/norbitals
 energy_values units=eV


 It seems that we need modify them, otherwise, it gives us the error message
 like:

 At line 53 of file eig2dos.f (unit = 5, file = 'stdin')
 Fortran runtime error: Bad real number in item 1 of list input



 Any hint would be much appreciated!


 Lily
 --


Re: [SIESTA-L] Single point energy calculation within SIESTA.

2011-05-24 Por tôpico Abraham Hmiel
Hongyi,

MD.TypeOfRun  cg
MD.NumCGsteps 0

Will provide you with a single-point energy calculation. It tells the
conjugate gradient minimum-finder algorithm to stop after achieving
convergence in the Self-Consistent Field loop no matter what the forces on
the atoms are. Use more than 0 steps for a geometry relaxation, and
increment your number of CG steps carefully if you run into issues with
wrong geometries, failed convergence, or oscillating forces so that you can
diagnose problems.

Best,
Abraham Hmiel
Katherine Belz Groves Graduate Fellow in Nanoscience, Xue Group
The College of Nanoscale Science and Engineering at SUNY Albany

Clouds are not spheres, mountains are not cones, coastlines are not
circles,
and bark is not smooth, nor does lightning travel in a straight line. -
Benoit Mandelbrot

On Wed, May 25, 2011 at 12:36 PM, Hongyi Zhao hongyi.z...@gmail.com wrote:

 Hi all,

 I've learned that the single point energy calculation should be the
 most appropriate method for any type of convergence testings (whether
 that be k-point, cutoff, fine grid or cell size).  I want to know if there
 are keywords/flags within SIESTA for single point energy calculation?

 Regards.
 --
 Hongyi Zhao hongyi.z...@gmail.com
 Institute of Semiconductors, Chinese Academy of Sciences
 GnuPG DSA: 0xD108493



Re: Re: [SIESTA-L] about basis-set superposition error (BSSE)

2011-03-29 Por tôpico Abraham Hmiel
Should I set a ghost atom between the molecule and the nanotube ?

No, this is what you must do:

You've already got the relaxed structure of the nanowire + adsorbed molecule
system, right? Let's call this system A and its total energy is E-A

You need 6 more calculations to complete the puzzle this is pretty much what
you should do:

1 calculation with the same k-point grid, mesh grid, and cell size as system
A, but only for the nanotube, fully relaxed to a similar tolerance as system
A. Find its total energy. Call this E-NT.

1 calculation with the same k-point grid, mesh grid, and cell size as system
A, but only for the adsorbed molecule, fully relaxed to a similar tolerance
as system A. Find its total energy. Call this E-AD

1 single-point calculation (0 CG steps) of the nanowire in the relaxed
geometry of system A (use the final .XV file or .xyz file or whatever you
want but remove the adsorbed molecule). Find its total energy. Call this
E-noghost-NT

1 single-point calculation (0 CG steps) of the adsorbed molecule in the
relaxed geometry of system A (use the final .XV file or .xyz file or
whatever you want but remove the adsorbed molecule). Find its total energy.
Call this E-noghost-AD

1 single-point calculation (0 CG steps) of the nanowire in the relaxed
geometry of system A, except replace any adsorbate chemical species with
ghost atoms. If you have species in the adsorbate that are present in the
nanowire, for example, a simulation of H2O on a hydrogen-passivated SiNW (or
C in methane on a CNT), then copy the H.psf file to a new file like
H_ghost.psf and then create a new chemical species H_ghost with atomic
number -1 and a different atomic species index. Replace any index of the H
in the adsorbate with the new index, and introduce a new basis set for
H_ghost that is identical to the one you used for H (except for the label
H_ghost). Find its total energy. Call this E-ghost-NT

1 single-point calculation (0 CG steps) of the adsorbed molecule in the
relaxed geometry of system A, except replace any nanowire chemical species
with ghost atoms and follow the procedure above if you have any species in
the adsorbate that are also present in the nanowire. Find its total energy.
Call this E-ghost-AD

The counterpoise correction is: (E-ghost-AD - E-noghost-AD + E-ghost-NT -
E-noghost-NT) call this E-CC. It should be a fraction of an eV, have a
negative sign and very sensitive to the adsorption site geometry. The BSSE
should _reduce_ the adsorption energy...

and the energy of adsorption is: E-NT + E-AD - E-A + E-CC

And that is how you do the counterpoise correction with SIESTA.

Best,
Abraham Hmiel

Katherine Belz Groves Graduate Fellow in Nanoscience, Xue Group
The College of Nanoscale Science and Engineering at SUNY Albany
Clouds are not spheres, mountains are not cones, coastlines are not
circles,
and bark is not smooth, nor does lightning travel in a straight line. -
Benoit Mandelbrot

On Wed, Mar 30, 2011 at 12:09 AM, yf liu liuyf1...@gmail.com wrote:

 Dear Herbert Fruchtl:
  thank you very much for your reply.  I have read the manual carefully,
 but find little message about the ghost atoms. the new question is: How can
 I use the ghost atom to correct the binding energy etc. ?  For example, I
 want correct the calculation about the molecule adsorption on the nanotube.
 Should I set a ghost atom between the molecule and the nanotube ?

 looking forward your reply.

 2011/3/20 Wei Hu gyrw4...@mail.ustc.edu.cn

I am sorry, I am a freshman about the siesta. The input is listed in
 the following.
My calculations about the binding energy do not meet the experimental
 results,so,I have to check the ghost atoms calculations.Now,The impact is
 acceptable.
Another problem is how to get the chemical potential or total energy of
 free C or N atom. Does it need to calculate the the ghost atoms affected by
 the supercell?

 SystemName  C62N_ghost
 SystemLabel C62N_ghost
 NumberOfSpecies 3

 %block ChemicalSpeciesLabel
  1   6   C
  2   7   N
  3  -6   Cg
 %endblock ChemicalSpeciesLabel

 %block PS.lmax
 C 1
 %endblock PS.lmax

 %include coord.fdf

 PAO.BasisSize DZP

 #SolutionMethod   dm_on


 SolutionMethod   diagon

 MeshCutoff  200.000 Ry

 #MD.TypeOfRun  Broyden
 #MD.TypeOfRun  CG
 #MD.NumCGsteps 500

 WriteForces

 MD.MaxForceTol 0.04 eV/Ang
 #DM.UseSaveDM T

 MaxSCFIterations 100
 DM.MixingWeight  0.1
 DM.NumberPulay   6
 #DM.MixingWeight 0.25
 #DM.NumberPulay 0


 SpinPolarized .true.
 #FixSpin .true.
 #TotalSpin 2.0

 WriteMullikenPop  1

 NetCharge  -1.0

 %block kgrid_Monkhorst_Pack
   2  0  0  0.0
   0  2  0  0.0
   0  0  2  0.0
 %endblock kgrid_Monkhorst_Pack



  -Original E-mail-
  From: Herbert Fruchtl herbert.fruc...@st-andrews.ac.uk
  Sent Time: 2011-3-18 20:06:46
  To: siesta-l@uam.es
  Cc:
  Subject: Re: [SIESTA-L] about basis-set superposition error (BSSE)
 
   From the energy part of the output alone we can't tell if the input

Re: Re: [SIESTA-L] about basis-set superposition error (BSSE)

2011-03-29 Por tôpico Abraham Hmiel
An edit to my post:

the line.
1 single-point calculation (0 CG steps) of the adsorbed molecule in the
relaxed geometry of system A (use the final .XV file or .xyz file or
whatever you want but remove the adsorbed molecule). Find its total energy.
Call this E-noghost-AD

should actually read

1 single-point calculation (0 CG steps) of the adsorbed molecule in the
relaxed geometry of system A (use the final .XV file or .xyz file or
whatever you want but remove the NANOTUBE). Find its total energy. Call this
E-noghost-AD

By the way, BSSE corrections should ALWAYS be performed in SIESTA because it
uses an incomplete basis set (atomic orbitals), not just when your
adsorption energy calculations are different than experiment or you want to
lower your adsorption energy to make your calculations look nice for a
paper. If you are still seeing vast differences between your adsorption
energy calculations and experiments, it may be a good idea to look into
different functionals like the van-der-Waals functionals implemented in the
SIESTA-trunk version. Or, additionally, you can try to use diffuse basis
functions (s-like) to help complete the basis set in the region
corresponding to adsorption.

On Wed, Mar 30, 2011 at 12:50 AM, Abraham Hmiel abehm...@gmail.com wrote:

 Should I set a ghost atom between the molecule and the nanotube ?

 No, this is what you must do:

 You've already got the relaxed structure of the nanowire + adsorbed
 molecule system, right? Let's call this system A and its total energy is
 E-A

 You need 6 more calculations to complete the puzzle this is pretty much
 what you should do:

 1 calculation with the same k-point grid, mesh grid, and cell size as
 system A, but only for the nanotube, fully relaxed to a similar tolerance as
 system A. Find its total energy. Call this E-NT.

 1 calculation with the same k-point grid, mesh grid, and cell size as
 system A, but only for the adsorbed molecule, fully relaxed to a similar
 tolerance as system A. Find its total energy. Call this E-AD

 1 single-point calculation (0 CG steps) of the nanowire in the relaxed
 geometry of system A (use the final .XV file or .xyz file or whatever you
 want but remove the adsorbed molecule). Find its total energy. Call this
 E-noghost-NT

 1 single-point calculation (0 CG steps) of the adsorbed molecule in the
 relaxed geometry of system A (use the final .XV file or .xyz file or
 whatever you want but remove the adsorbed molecule). Find its total energy.
 Call this E-noghost-AD

 1 single-point calculation (0 CG steps) of the nanowire in the relaxed
 geometry of system A, except replace any adsorbate chemical species with
 ghost atoms. If you have species in the adsorbate that are present in the
 nanowire, for example, a simulation of H2O on a hydrogen-passivated SiNW (or
 C in methane on a CNT), then copy the H.psf file to a new file like
 H_ghost.psf and then create a new chemical species H_ghost with atomic
 number -1 and a different atomic species index. Replace any index of the H
 in the adsorbate with the new index, and introduce a new basis set for
 H_ghost that is identical to the one you used for H (except for the label
 H_ghost). Find its total energy. Call this E-ghost-NT

 1 single-point calculation (0 CG steps) of the adsorbed molecule in the
 relaxed geometry of system A, except replace any nanowire chemical species
 with ghost atoms and follow the procedure above if you have any species in
 the adsorbate that are also present in the nanowire. Find its total energy.
 Call this E-ghost-AD

 The counterpoise correction is: (E-ghost-AD - E-noghost-AD + E-ghost-NT -
 E-noghost-NT) call this E-CC. It should be a fraction of an eV, have a
 negative sign and very sensitive to the adsorption site geometry. The BSSE
 should _reduce_ the adsorption energy...

 and the energy of adsorption is: E-NT + E-AD - E-A + E-CC

 And that is how you do the counterpoise correction with SIESTA.

 Best,
 Abraham Hmiel

 Katherine Belz Groves Graduate Fellow in Nanoscience, Xue Group
 The College of Nanoscale Science and Engineering at SUNY Albany
 Clouds are not spheres, mountains are not cones, coastlines are not
 circles,
 and bark is not smooth, nor does lightning travel in a straight line. -
 Benoit Mandelbrot


 On Wed, Mar 30, 2011 at 12:09 AM, yf liu liuyf1...@gmail.com wrote:

 Dear Herbert Fruchtl:
  thank you very much for your reply.  I have read the manual
 carefully, but find little message about the ghost atoms. the new question
 is: How can I use the ghost atom to correct the binding energy etc. ?  For
 example, I want correct the calculation about the molecule adsorption on the
 nanotube.  Should I set a ghost atom between the molecule and the nanotube
 ?

 looking forward your reply.

 2011/3/20 Wei Hu gyrw4...@mail.ustc.edu.cn

I am sorry, I am a freshman about the siesta. The input is listed in
 the following.
My calculations about the binding energy do not meet the experimental
 results,so,I

Re: [SIESTA-L] Strange halting behavior after DM initialization due to mesh?

2011-03-15 Por tôpico Abraham Hmiel
This problem has been solved. The offense is a stack size parameter in my
user setting that was too low.

The command:
 ulimit -s unlimited

should be added to your .bashrc settings if you are having similar problems,
or increase the stack size to something high enough. It appears that
large-scale DFT calculations may frequently exceed default user memory
limits and is not discussed in the manual.

Thanks and cheers for the responses,

Abe


Re: [SIESTA-L] ifort+mpich2 compiling error

2011-03-11 Por tôpico Abraham Hmiel
Hi Reza,

From your errors in compiling the FoX library, it seems that you might be
using v11 of ifort, which has problems. If you haven't seen this yet, follow
these instructions to remove the FoX libraries from the compilations:
http://www.icmab.es/siesta/SIESTA/News/IntelV11

The only thing this will affect are xml output, not the SIESTA method. Or,
you can use less aggressive optimization options for the FoX library and
still compile it. Instructions for that are on that link, too.

The only other piece of advice I'd tell you to try is to roll back the intel
compiler to v10, or use gfortran4.4  openmpi.

Best,
Abe Hmiel


Re: [SIESTA-L] Blocks about geometry of graphene

2010-10-25 Por tôpico Abraham Hmiel
Clersson,

Please do not be impatient. Followers of this list are busy and you sent us
two nearly identical messages in two hours.

With regards to your fdf file, I saw some errors. First of all I don't think
your Atomic coordinates are right. What you should do if you feel unsure
about this is set up a for loop in the programming language of your choice
and print out the atomic coordinates, and then use Xmol or avogadro or
something to visualize them. If your graphene lattice vectors are in the
first and fourth quadrants making a 30 degree angle with the x-axis as in
your file, your atomic coordinates block should be a basis of two carbon
atoms lying on a line parallel to the x-axis (again, plot it out if you have
to). This is not what you have. You need to make sure you're keeping track
of units, too. The units in your coordinates block are in Angstrom. That
means that two carbon atoms in your file are separated by sqrt(2*1/3^2)
angstroms, less than 1/2 an angstrom.

I plotted a sketch of what your system is and attached it. It is highly
suspect, I would recommend you fix the coordinates and lattice vectors. It
seems that you included an extra factor of the lattice parameter in the
block LatticeVectors to me, but other than that I won't tell you the right
answer. Besides that, you need to specify some lattice vector in the
c-plane. You can't just use zero. Use at least 12 angstroms so you have no
overlap. Your kgrid mesh looks fine. The bandlines block is also wrong, the
number at the beginning of the line should be the index of that point on the
x-axis of your band plot, so instead of 1 50 50 100 you should have
something like 1 51 101 151 if you want 50 points per high symmetry
direction. MD.NumCGSteps = 0 is what you do for a single-point energy
calculation, but you need to relax the geometry of your system before you
can get anything meaningful out of it.

And finally, why are you including all the transport flags in the
relaxation? You haven't even performed the relaxation yet, so save all the
transiesta stuff (and maybe the PDOS and LDOS as well) until after you've
attained the electronic ground state. You might even want to use
MD.Variablecell to relax the lattice vectors along with the coordinates and
you might need to tune the mixingweight and numberpulay to hasten
convergence.

And please do the tutorial exercises and try to search the mailing list
archives next time before you ask the community twice for anything. DFT is
not an easy field to get into and you need to understand what you're doing
before you just jump in and calculate the band structure of graphene. Which,
by the way, is not an easy task once you've got everything right judging
from the activity on this list for such a pedagogical example, so you'll
probably need to play around with a lot more parameters.

This is the matlab script I whipped up in a couple minutes to check your
geometry. I essentially ignored the c-lattice parameter and left it as all
zeroes.

latt = 2.42;
imax=3;
jmax=3;
coords = zeros(imax*jmax*2,3);
basis1 = [0.0 0.0 0.0]
basis2 = [0. 0. 0.0];
latt1 = [2.13 1.2297];
latt2 = [2.13 -1.2297];

index=1;

for i=0:imax
for j=0:jmax
coords(index,1) = basis1(1)+i*latt1(1)*latt+j*latt2(1)*latt;
coords(index+1,1) = basis2(1)+i*latt1(1)*latt+j*latt2(1)*latt;
coords(index,2) = basis1(2)+i*latt1(2)*latt+j*latt2(2)*latt;
coords(index+1,2) = basis2(2)+i*latt1(2)*latt+j*latt2(2)*latt;
index=index+2;
end
end

%to plot in an xyz file, you have to add the character 'C' to the beginning
%of each line with atomic data and then print the total number of atoms as
%the first line, then skip a line (or use for comment), then begin with
%coordinates on the third line. This must be in Angstrom.

Please print out a copy of the latest version of the SIESTA manual for your
reference and do and read the tutorial exercises. It makes a world of
difference. If you still need help with convergence and attaining a proper
band structure of graphene, this topic has been beaten 9/10s to death on the
SIESTA-L list already so please check there first. I hope this helps point
you in the right direction for your research and future SIESTA exploits.
Best of luck to you.

Abraham Hmiel
Ph.D. student at CNSE, SUNY Albany

On Mon, Oct 25, 2010 at 1:35 PM, Clersson Nascimento clerisson...@gmail.com
 wrote:


 dear siesta users,

 I'm interested in to calculate the band structure of graphene but i have
 some doubts about how to construct the blocks that refer to geometry
 structure.
 I have the following block:

 %block AtomicCoordinatesAndAtomicSpecies
  0. 0. 0. 1
  0. 0. 0. 1
 %endblock AtomicCoordinatesAndAtomicSpecies

 so, i made the following blocks

 %block LatticeVectors
2.13 1.2297560733739 0.00
2.13-1.2297560733739 0.00
0.00 0.000.00
 %endblock LatticeVectors

 %block

Re: [SIESTA-L] Blocks about geometry of graphene

2010-10-25 Por tôpico Abraham Hmiel
Ok, no problem, glad I could help out and sorry for being a little abrasive
if I came off that way. No harm was meant. For some good texts on electronic
structure, I found Richard Martin's book very helpful, as well as Jorge
Kohanoff's book, Electronic Structure Calculations for Solids and
Molecules. You should read the original SIESTA paper to get a handle on
their method and the things that go into the computation, and of course, be
very astute about what you're putting into your files. It really helps to be
able to quickly generate geometry files and then display them with a piece
of software or export them into a format that can be read by SIESTA or other
programs. I end up using spreadsheets and emacs a lot. It seems from the
file you're interested in doing some transport calculations. I would
definitely get up to speed on the proper details as to how to obtain
electronic structure data from the geometry relaxation first and how this
relates to the physics in your systems before your foray into transport with
this software. Building good pseudopotentials and basis sets and testing
them are also not really discussed in the SIESTA manual either, and they are
learned skills that come about with practice so for this it is very
important to know the right terminology and what all these little parameters
mean so you don't use oodles of supercomputer time crunching nonphysical
things. This community and list is very helpful but always remember to check
the archives first and be creative in your search terms, and
double-and-triple-check your fdf files.

Best of luck to you on your journey,
Abraham

On Mon, Oct 25, 2010 at 4:24 PM, Clersson Nascimento clerisson...@gmail.com
 wrote:

 Dear Abrahan,

 First, my apologies for send two e-mails. That was my first e-mail to mail
 list and i was not sure the e-mail had been sent. Actually, I thought I
 should have gotten the message(since I was also a member of the list), for
 this I sent it twice.

 With regards your answer, I am very grateful for your patient explanation
 about my mistakes. These are my first steps in the field of eletronic
 structure. I'm still looking where to find information in this turbulent
 beginning of my research. So your answer was providential.

 Thaks again,
 Best regards.

 Clerisson Nascimento