Re: [SIESTA-L] Question regarding subroutine reclat
> Hi all,
>
> I've got a (silly, I'd say) question regarding the subroutine reclat. I
> wanted to see the cartesian components of the reciprocal lattice vectors.
> when I take a supercell of graphene with
> lattice vectors along x and y, I get:
>
> reclat: Unit cell vectors (Bohr):
> a1: 64.2734938385 0.00 0.00
> a2: 0.00 9.2770797408 0.00
> a3: 0.00 0.00 32.4697790909
> reclat: Reciprocal lattice vectors, not scaled by 2*pi:
> b1: 0.0977570213 0.00 0.00
> b2: 0.00 0.6772805110 0.00
> b3: 0.00 0.00 0.1935087174
>
> Now, the direct lattice vectors are correct, but I would expect that
> $b_{1x}=2*pi*a_{2y}$; instead $b_{1x}=2*pi*a_{2x}$, and something
> analogous happens for $b_{2y}$. Am I missing something, or is the
> condition
>
> $\vec b_{i} \dot \vec a_{j}$
>
> not obeyed by the subroutine reclat?
Dear Marcos -
Yes it is: each reciprocal vector is orthogonal to
TWO OTHER ones in the direct lattice.
That means for orthorhombic lattices:
each reciprocal one is aligned with its corresponding direct one,
and has its recioprocal length.
Exactly as you have it...
Best regards
Andrei Postnikov
Re: [SIESTA-L] Crazy SCF with vanadium
> Deal All, > I know tried to replace the V atom with a C instead. After many CG steps, > the same problem in the SCF run suddenly occured. Can it be an issue of > compilation? > > -Joachim Dear Joachim, let's be systematic: 1) can you please confirm that the problem is not due to what I suggested to check several days ago - the maximal spin set up by default on ALL atoms? 2) does the electronic structure (either with V, or without) - position of carbon 2s and 2p bands, charges - remains reasonable until "the same problem in the SCF run suddenly occured"? Or are you having weird results all the way through and only notice it when they start to diverge? Sorry... 3) what happens "afer many CG steps" it terms of structure; in which respect does the crashed structure differ from the good one? You may have the .ANI file stored, or just .XV files from the beginning and from immediately before the crash. If it happens "suddenly" then some crazy forces calculated on atoms might be responsible, whatever the reason for this. Good luck Andrei
[SIESTA-L] Question regarding subroutine reclat
Hi all,
I've got a (silly, I'd say) question regarding the subroutine reclat. I
wanted to see the cartesian components of the reciprocal lattice vectors.
So I added the following code to the siesta main subroutine (file
siesta.F):
if (IOnode) then
write(6,*)
write(6,*) 'reclat: Unit cell vectors (Bohr):'
write(6,"('a1: ', 2x, 3f15.10)"), ucell(1,1), ucell(2,1),
$ucell(3,1)
write(6,"('a2: ', 2x, 3f15.10)"), ucell(1,2), ucell(2,2), ucell
$(3,2)
write(6,"('a3: ', 2x, 3f15.10)"), ucell(1,3), ucell(2,3), ucell
$(3,3)
call reclat(ucell,rcell,1)
write(6,*) 'reclat: Reciprocal lattice vectors, not scaled by 2*
$pi:'
write(6,"('b1: ', 2x, 3f15.10)"), rcell(1,1), rcell(2,1),
$rcell(3,1)
write(6,"('b2: ', 2x, 3f15.10)"), rcell(1,2), rcell(2,2), rcell
$(3,2)
write(6,"('b3: ', 2x, 3f15.10)"), rcell(1,3), rcell(2,3), rcell
$(3,3)
write(6,*)
write(6,*)
call reclat(ucell,rcell,0)
write(6,*) 'reclat: Reciprocal lattice vectors, scaled by 2*pi:'
write(6,"('b1: ', 2x, 3f15.10)"), rcell(1,1), rcell(2,1),
$rcell(3,1)
write(6,"('b2: ', 2x, 3f15.10)"), rcell(1,2), rcell(2,2),
$rcell(3,2)
write(6,"('b3: ', 2x, 3f15.10)"), rcell(1,3), rcell(2,3),
$rcell(3,3)
write(6,*)
write(6,*)
endif
When I use a unit cell of graphene, I get the following result:
reclat: Unit cell vectors (Bohr):
a1: 4.0170933649 2.3192699350 0.00
a2: 4.0170933649 -2.3192699350 0.00
a3: 0.00 0.00 32.4697790900
reclat: Reciprocal lattice vectors, not scaled by 2*pi:
b1: 0.7820561705 1.3545610221 0.00
b2: 0.7820561705 -1.3545610221 0.00
b3: 0.00 0.00 0.1935087174,
which is correct. However, when I take a supercell of graphene with
lattice vectors along x and y, I get:
reclat: Unit cell vectors (Bohr):
a1: 64.2734938385 0.00 0.00
a2: 0.00 9.2770797408 0.00
a3: 0.00 0.00 32.4697790909
reclat: Reciprocal lattice vectors, not scaled by 2*pi:
b1: 0.0977570213 0.00 0.00
b2: 0.00 0.6772805110 0.00
b3: 0.00 0.00 0.1935087174
Now, the direct lattice vectors are correct, but I would expect that
$b_{1x}=2*pi*a_{2y}$; instead $b_{1x}=2*pi*a_{2x}$, and something
analogous happens for $b_{2y}$. Am I missing something, or is the
condition
$\vec b_{i} \dot \vec a_{j}$
not obeyed by the subroutine reclat? This could have some implications for
k-point samplings for this kind of cell... Although this would be easy to
fix by adding a few lines of code to reclat, I would like to be sure that
I am not missing some silly detail here.
Best regards,
Marcos
Marcos
--
Dr. Marcos Verissimo Alves
Post-Doctoral Fellow
Unité de Physico-Chimie et de Physique des Matériaux (PCPM)
Université Catholique de Louvain
1 Place Croix du Sud, B-1348
Louvain-la-Neuve
Belgique
--
Gort, Klaatu barada nikto. Klaatu barada nikto. Klaatu barada nikto.
Free translation:
Gort, Google is your friend. Google is your friend. Google is your friend.
Re: [SIESTA-L] Crazy SCF with vanadium
Deal All, I know tried to replace the V atom with a C instead. After many CG steps, the same problem in the SCF run suddenly occured. Can it be an issue of compilation? -Joachim -Original Message- From: Siesta, Self-Consistent DFT LCAO program, http://www.uam.es/siesta [mailto:[EMAIL PROTECTED] On Behalf Of Joachim Fürst Sent: 5. november 2008 11:06 To: SIESTA-L@listserv.uam.es Subject: Re: [SIESTA-L] Crazy SCF with vanadium Dear All, The V3p are included in the PS I used (it should be anyway!!). So, yes, I agree, it is best to have it in there. I also agree that the SCF shouldn't behave like that with it being in there or not. -Original Message- From: Siesta, Self-Consistent DFT LCAO program, http://www.uam.es/siesta [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 5. november 2008 10:48 To: SIESTA-L@listserv.uam.es Subject: Re: [SIESTA-L] Crazy SCF with vanadium > Quoting Joachim Fürst <[EMAIL PROTECTED]>: > > Dear all, > I followed the discussion about the vanadium deposited on a graphene > sheet. > My experience with vanadium is that it is necessary to insert > semi-core states the 3p with the atom program. Yes I fully agree - V3p are important in order to obtain accurate results, but I don't think their absence was responsible for the "crazy SCF" behaviour, if (even not so good) V potential was working in other systems. > By the way is it scheduled in SIESTA to include soon or later > ultrasoft pseudo? Note that in Siesta the softness of the pseudopotential does not matter to such extent as it does in planewave codes (where this becomes expensive in terms of basis size). In Siesta, even deep pseudos can be (with a bit of luck) treated with appropriate basis sets. Hard cases which demand high mesh cutoffs are not a priori those where the pseudo is hard. Andrei Postnikov
Re: [SIESTA-L] multiple LDOS output
Hi Ruslan you can use the old .DM file to make and it will converge within couple of iteration. Though it still take while to produce the results. add in your output DM.UseSaveDM .true. and include the old SystemLabel.DM in the same directory in which you are running your calculation. Regards Javad On Thu, 6 Nov 2008, ?? ? wrote: Dear SIESTA users, how to generate output for multiple LDOS, each one with its own Uinitial and Ufinal? The system is quite large (about 200 Si atoms) and it takes a long time for SCF to get solution. And then I got only one LDOS for single Uinitial and Ufinal values. Should I save some values from previous runs and restart? Which one? I would be happy to see example of *.fdf file. Kind regards Ruslan
[SIESTA-L] multiple LDOS output
Dear SIESTA users, how to generate output for multiple LDOS, each one with its own Uinitial and Ufinal? The system is quite large (about 200 Si atoms) and it takes a long time for SCF to get solution. And then I got only one LDOS for single Uinitial and Ufinal values. Should I save some values from previous runs and restart? Which one? I would be happy to see example of *.fdf file. Kind regards Ruslan
Re: [SIESTA-L] Broadening Parameter within PDOS
> Hello all, > > I have a question concerning the broadening parameter within the PDOS > block. I understand that the larger this value, > the smoother the resulting PDOS curve Dear Tom, this is correct. > and the larger the possibility one loses information concerning > peaks that may have been smoothed over. This depends on your definition of "one loses". No peak loses its spectral weight on broadening, but might cease to exist as a separate feature. The question is whether you want it or not. In principle the broadening has two aims: 1. In an absence of tetrahedron integration in Siesta, to imitate a continuous DOS of a solid, in place of a bunch of delta-peaks as it comes out from a calculation; 2. To suppress excessive but less informative, often spurious, features, in the DOS, to provide a more obvious comparison with other calculations, or with experimantal spectra. So the selection of broadening parameter is your free choice and really depends on what you want to emphasize in your DOS plots. > Ideally, one would want this to be as small as possible. > Is there anything wrong with this assumption. Only that you may end up with a forest of delta-peaks, not necessarily much instructive. After all, if you care about the exact positions of certain discrete levels (say, in a molecle), you have them directly from the calculation and do not need to broaden them first with infinitely small broadening parameter. > To put > it another way, is there any danger to setting this parameter really low, > say 0.05 for example. This is first of all related to the energy step and the energy window in your DOS plot! Everything is relative... Best regards Andrei interval > > > > Thanks in advance, > > > Tom > > _ > Stay organized with simple drag and drop from Windows Live Hotmail. > http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_102008
