[SIESTA-L] geometry correction!
Dear Siesta users, I really really need your help on making the correct supercell. I am simulating first diameter wire. The supercell I have made is as follows: LatticeConstant 6.49985 Ang # it is equal to double the cell parameter in the bulk# %block latticevectors 5.000 0.000 0.00 -2.500 4.3301270 0.00 #hexagonal lattice X 5# 0.00 0.000 0.800570 %endblock latticevectors AtomicCoordinatesFormat Fractional %block AtomicCoordinatesAndAtomicSpecies 0.0666 0.0111 0.00 1 0.0111 0.0666 0.50 1 0.0666 0.1333 0.00 1 0.1333 0.1666 0.50 1 0.1666 0.1333 0.00 1 0.1333 0.0666 0.50 1 0.0666 0.0111 0.625000 2 0.0111 0.0666 0.125000 2 0.0666 0.1333 0.625000 2 0.1333 0.1666 0.125000 2 0.1666 0.1333 0.625000 2 0.1333 0.0666 0.125000 2 %endblock AtomicCoordinatesAndAtomicSpecies Although the number of atoms in the supercell is 12 but in the output file I have 48 atoms. Please let me know how I can make the correct supercell for this wire and the ones with higher diameters. Regards, Sara
Re: [SIESTA-L] Plrho compilation problem
Hello Eduardo, Thanks for your answer. I'll try it. By the way, which linux distribution and fortran compiler do you recommend me to use? Thanks in advance, John 2008/11/3 Eduardo Anglada <[EMAIL PROTECTED]> > Hello, > > On 01/11/2008, at 11:48, Johnny Dry wrote: > > Hello Eduardo, > > I'm getting the error: > > > -- > plrho.f: In program `plrho': > plrho.f:38: > real, allocatable :: >^ > Invalid type-declaration attribute at (^) -- must be one of: > DIMENSION(array-spec), EXTERNAL, INTRINSIC, PARAMETER, or SAVE > plrho.f:39: > . f(:,:) > ^ > Expression at (^) has incorrect data type or rank for its context > plrho.f:39: > . f(:,:) > ^ > Expression at (^) has incorrect data type or rank for its context > plrho.f:39: > . f(:,:) >^ > Expression at (^) has incorrect data type or rank for its context > plrho.f:39: > . f(:,:) > ^ > Expression at (^) has incorrect data type or rank for its context > plrho.f:39: > . f(:,:) >1 > plrho.f:50: (continued): > open( unit=1, file='plrho.dat', > 2 > Invalid declaration of or reference to symbol `f' at (2) [initially seen at > (1)] > plrho.f:73: >allocate( f(np,2) ) >^ > Invalid declaration of or reference to symbol `allocate' at (^) [initially > seen at (^)] > plrho.f:73: >allocate( f(np,2) ) > ^ > Invalid form for assignment statement at (^) > iorho.f: In subroutine `iorho': > plrho.f:70: warning: > call iorho( 'read', fname, dcell, mesh, nsm, np, nspin, > 1 > iorho.f:11: (continued): > subroutine iorho( task, fname, cell, mesh, nsm, maxp, nspin, > 2 > Argument #8 (named `f') of `iorho' is one type at (2) but is some other > type at (1) [info -f g77 M GLOBALS] > plsurf.f: In subroutine `plsurf': > plrho.f:204: warning: > call plsurf( origin, cell, mesh, mesh, > 1 > plsurf.f:11: (continued): > SUBROUTINE PLSURF( ORIGIN, CELL, NMESH, NSPAN, > 2 > Argument #5 (named `f') of `plsurf' is one type at (2) but is some other > type at (1) [info -f g77 M GLOBALS] > plrho.f:204: warning: > call plsurf( origin, cell, mesh, mesh, > 1 > plsurf.f:11: (continued): > SUBROUTINE PLSURF( ORIGIN, CELL, NMESH, NSPAN, > 2 > Argument #8 (named `color') of `plsurf' is one type at (2) but is some > other type at (1) [info -f g77 M GLOBALS] > > > g77 doesn't compile f90, so you have to use a f90 compiler. > > > > [EMAIL PROTECTED] Plrho]$ f95 plrho.f -lX11 -lpgplot -o plrho > icolor.f:179.72: > Included at plrho.f:223: > > IF(J.GT.97.OR.J.LT.1)PAUSE >1 > Warning: Obsolete: PAUSE statement at (1) > plsurf.f:176.72: > Included at plrho.f:226: > > IF (ALLHGH .OR. ALLLOW) GOTO 10 >1 > plsurf.f:244.72: > Included at plrho.f:226: > >10 ENDDO >2 > Warning: Obsolete: GOTO at (1) jumps to END of construct at (2) > /usr/bin/ld: cannot find -lpgplot > collect2: ld returned 1 exit status > > > The f95 can't find the pgplot libraries. You usually can specify its > location using the -L flag. > > > > > * > I've compiled pgplot with GNU f77 compiler and trying to use the same > compiler for plrho, which I think is the source of error. Also I have tried > to compile the Denchar Util with f95 compiler, that I have used for Siesta, > I got an error like: > * > > - > [EMAIL PROTECTED] Src]$ make denchar > f95 -o denchar \ > m_denchar_init.o m_denchar_geom.o m_denchar_io.o > m_denchar_neighb.o m_denchar_work.o denchar.o precision.o recipes.o > f2kcli.o bessph.o chkdim.o dismin.o dot.o iodm.o memory.o paste.o radfft.o > io.o spatial.o volcel.o parallel.o parallelsubs.o memoryinfo.o sys.o > listsc.o atmparams.o atmfuncs.o atm_types.o m_memory.o radial.o > spher_harm.o basis_io.o basis_types.o pseudopotential.o chemical.o xml.o > files.o nag.o pxf.o \ > libfdf.a dc_lapack.a liblapack.a libblas.adc_lapack.a > liblapack.a libblas.a > f2kcli.o: In function `__f2kcli__get_command': > /home/bias/siesta-2.0.1/Src/f2kcli.F90:83: undefined reference to `iargc_' > /home/bias/siesta-2.0.1/Src/f2kcli.F90:87: undefined reference to `getarg_' >
Re: [SIESTA-L] Bulk cohesion energy
Ok, but how to know that, a priori, before starting a simulation? I mean, how many atoms besides the ones explicitly defined in my input should I take into account? Roberto From: Eduardo Anglada <[EMAIL PROTECTED]> To: SIESTA-L@listserv.uam.es Sent: Tuesday, November 4, 2008 1:33:54 PM Subject: Re: [SIESTA-L] Bulk cohesion energy Hola, You sum the multiplication of the number of basis functions of each species by the number of atoms of that species. You should take into account more than the atoms explicitly defined in your input. Best, Eduardo On 04/11/2008, at 11:38, Roberto Veiga wrote: Thank you, Eduardo. How do I obtain the total number of basis functions for a condensed system? Should I take into account more than the atoms explicitly defined in my input? Roberto From: Eduardo Anglada <[EMAIL PROTECTED]> To: SIESTA-L@listserv.uam.es Sent: Tuesday, November 4, 2008 9:45:34 AM Subject: Re: [SIESTA-L] Bulk cohesion energy Hi, At the beginning of each SIESTA run, during the generation of the atomic orbitals, the number of basis functions for each species is written. Best Eduardo On 03/11/2008, at 21:05, Roberto Veiga wrote: Where in the output can I find the number of basis functions? Roberto From: Oleksandr Voznyy <[EMAIL PROTECTED]> To: SIESTA-L@listserv.uam.es Sent: Monday, November 3, 2008 3:41:53 PM Subject: Re: [SIESTA-L] Bulk cohesion energy > I did like that: > E=E(Fe-bulk)-E(Fe-isolated) > and I obtained 4.80 eV This doesn't mean anything yet. It's the same as fitting pseudopotential to obtain better lattice constant. > So I think that in this case the BSSE correction is negligible. Try it before saying it. The single atom vs atom in the bulk is the situation when one would expect the strongest BSSE.
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] 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] 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. It is necessary also to add core correction? We used the following values in a paper that will issue in PRB soon: rc(s)=2.50 , rc(p)=2.17, rc(d)=0.90, rcc=1.20. The pseudo was built in GGA. If you have a look at the PWSCF site, they propose ultra soft pseudo for V where they incorporate 3s and 3p states. The semi core states really matter. By the way is it scheduled in SIESTA to include soon or later ultrasoft pseudo? Alexandre
