[Ifeffit] [ATOMS] supercell input file

[Kelly, Shelly]

Hi Mauro,
 
If I understand correctly, you would like to generate a feff.inp file from an atoms.inp file where the only Fe atom is the absorber. But the resulting feff.inp file can not be run because it always makes an ipot 1 for a neighboring Fe atom but there are not any. So you have to go in by hand and remove that ipot number and shift the list because the ipot numbers have to go in order.
 
Yes, this is a feature and not so much a bug in the way that atoms works. Atoms assumes there will always be at least on Fe neighbor.  It cuts some time by moving the last potential in the ipot list to number 1 so that you don't have to change all of them.  You can also cheat by adding an Fe neighbor to the end that is not used and not close to any of the paths that you do use.
 
Cheers,
Shelly

________________________________

From: ifeffit-bounces at millenia.cars.aps.anl.gov on behalf of Mauro Rovezzi
Sent: Fri 9/19/2008 7:40 AM
To: Ifeffit-ML
Subject: [Ifeffit] [ATOMS] supercell input file



Dear all,

I would like to submit to your attention a problem with Atoms that I
still do not understand. What I would like to do is to generate a FEFF
input file starting from a supercell, that is repeating the unit cell
NXxNYxNZ times and create the crystal with the resulting box.

An example is given in the attached _test-atoms.inp_ created following
this procedure: from wurtzite GaN (a,c cell parameters) that we describe
with 2 atoms I reduce the symmetry and I use 4 atoms, then I create a 72
atoms supercell - 4*(3x3x2) - that has 3ax3ax2c dimensions and finally I
tell atoms to use "P1" space group in order to replicate the supercell
in x,y,z space and shift at the center the absorbing atom.

Here the *problem*: the resulting _test-feff8.inp_ present good values
of distances but strangely it has generated an additional Fe potential
(there is just 1 Fe absorbing atom in the box/list). This is annoying
because I have to remove manually the wrong "ipot" to run FEFF.

Is it a stupid mistake generating the Atoms input file or is it an odd
behaviour?

Cheers,
Mauro

PS: Atoms 3.0.1 (linux) 05/08/15
PPS: Do not pay attention to coordinates and distances, these are just
test-files!

--
Mauro Rovezzi <rovezzi at esrf.fr>
PhD student - GILDA BM08 c/o ESRF (Grenoble, FR)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5203 bytes
Desc: not available
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20080919/d0d5aac7/attachment.bin>