Hi,
I would add the following option to what Marcos says:
You can start with a "standard" atom inp file. See the atom manual for
details. Then do an all electron calculation with atm. So you really want an
ae.inp kind of file.
Keep in mind, atm, unlike siesta, has a very *rigid* readout format, so *keep
all spacings in your input files as in the template ae.inp file* that you can
get, for instance on the Tutorial directory of atom. Otherwise you will get
all kind of errors during the ae.sh script run.
Once you have a successful atm calculation, go to your Bi.ae.inp directory,
that will be created if a successful run did happen, and opent the
OUT
file.
In this file you will have a bunch of data. Go to the channels you want your
pseudo to have and dismiss the previous channels (you get all channels here
'cause this is an all-electron calculation). Check the biggest
r extr
for the channels you are interested in. For instance, from one of my files:
.
.
.
n = 5 l = 1 s = 0.5
a extr 0.290 -0.408 0.601 -1.120
b extr -0.055 0.022 -0.013 0.008
r extr 0.037 0.138 0.351 0.979
r zero 0.075 0.216 0.528
r 90/99 % 1.597 2.266
.
.
.
(and assuming I wanted the 5p orbital to be in the valence) I would write down
0.97 as a starting point for my rc in my pseudo. You get the idea.
Please PLOT the radial part of your all electron result. Your rc must be away
enough from parts where your wavefunctions cross the r axis (ie, bigger than
the biggest r zero value).
Okay, suppose you wrote down your r extrs. Now take a template pg (or pe for
that matter) file. Replace the rcs in that file (and the atomic number as
well as the pseudo flavor to suit!) by the ones you just got. Sometimes is
safe to choose one of your r_extrs for all rcs (the smallest, the biggest,
some value in between,...)
Run the pg.sh script. Go back to your output dir (something like Bi.pe.inp)
and plot the wavefuncions once more. pg(pe) wavefunctions should overlap
outside rc.
On a more stringent test of your pseudo, you can check in the atom manual how
to test for transferability.
All this is good but,
-sometimes atm changes your input radii (See OUT file for actual taken
values).
-even though you are happy with your pseudo, siesta discovers GHOST states
(...and crashes). Then you have to go back to your pseudo inp file and modify
some options slightly.
-if your pseudo makes for a sucessful siesta run, do *check* some bulk
properties: Lattice constants and the like.
Bottom line is, it will take you a couple of days to get comfortable with the
process of generating pseudos but it is worth (and perhaps even necessary if
you consider using SIESTA in the long run) the effort.
Best regards,
Salvador.
On Thursday 05 October 2006 09:08, Marcos Verissimo Alves wrote:
> Hi Bozo,
>
> > Hi Marcos
> >
> > thanks for your mail and sorry for not giving full information, I just
> > wanted to keep mail as short as possible so people can go quickly
> > through it.
>
> Don't keep the e-mail short when you have a problem whose cause you cannot
> identify. In some cases, a more lengthy (but not too lengthy) explanation
> is necessary, in order to identify possible sources of error.
>
> > So, what I did is: I went to SIESTA webpage, then to LINKS and there
> > you can find ABINIT with the list of pseudopotentials that Siesta can
> > use. So I simply downloaded GGA (PBE) Hartwigsen_Goedecker-Hutter
> > pseudopotentil for Bi as a text file. I named it Bi.psf.
>
> So there is your problem. If you look at the abinit pseudopotential format
> and the .psf format, you will see that they are completely different. What
> the link means is that siesta can use thses potentials because they are
> norm-conserving, but they have to be in the appropriate format. If you can
> find (or anyone in the list can provide) a format conversion tool from the
> abinit format to the siesta format, it will be great. Otherwise, you can
> do:
>
> a) See if, in the abinit file, the core radii are specified. I don't
> remember if siesta has HGH pseudopotential generation (probably not), but
> you could use the rc's from HGH as a starting point for generating your
> own TM GGA pseudo using atom, testing it on elemental Bi. If this is not
> good, you can do
>
> b) a search in the literature, find some paper with calculations for Bi
> which states the channels and core radii for the GGA TM pseudopotential
> are used, and generate your own pseudo from those. Or,
>
> c) you could ask, on the list, if anyone has a good pseudo for Bi.
>
> > I had pseudopotential for Si from before.
> >
> > And then started simulation. I know that pseudopotential for Si is ok,
> > because I did some calculations with silicon in diamond before, and
> > everything worked fine.
>
> Probably because the pseudo was in the right file format (.psf).
>
> > In simulation I am using generalized gradient approximation and also
> > PBE parametrization of the exchange-correlation functional. So that's
> > why I hoped if I download that particular pseudopotential for Bismuth,
> > the things would work.
> >
> > I guess I could try with LDA.
>
> The problem is not LDA or GGA, but then one word of caution: don't mix LDA
> and GGA pseudopotentials, which will not give you good results (I'd say
> good results would simply be a coincidence in this case). If you decide
> that your pseudos are GGA, then they should all be GGA, or else all LDA.
>
> Cheers,
>
> Marcos
>
> > Thank you very much.
> >
> > Regards
> >
> > Bozo
--
----------------------
Salvador Barraza-Lopez
Department of Physics
Virginia Tech
Blacksburg VA, 24060
[EMAIL PROTECTED]
(540) 231 3308
