[Ifeffit] Re: Possible bug in Artemis. (Bruce Ravel)

joshua jason kas hebhop at u.washington.edu
Tue Jan 24 18:08:51 CST 2006


Hi Bruce,
Thanks for the tips. I fooled around with the feff.inp and found that 
artemis somehow has a problem when feff is run with the

 	RMULTIPLIER

card. This card is purely for convenience, so I took it out and things 
work fine.
This card was used in feff6 although the code runs very slowly with it for 
some reason. Anyway,
here is the feff.inp file that I was using for feff6 or feff8 (they both 
have the problem). 
Thanks, Josh

  TITLE GeCl4
  HOLE 1 1.0
CONTROL 1 1 1 1 1 1  (feff8)
CONTROL 1 1 1 1      (feff6)
  PRINT     1      0     0     0     0      3
  EXCHANGE  0    1   1
CORRECTIONS         1.2427845974         0.0041969513
  RMAX     10.0
  RMULTIPLIER 1.01
  POTENTIALS
          0   32   Ge    -1       -1       1
          1   17   Cl    -1       -1       4
  ATOMS
         0.0000000000         0.0000000000         0.0000000000   0
   1.1568027  1.1568027  1.1568027     1     Cl
   1.1568027 -1.1568027 -1.1568027     1     Cl
  -1.1568027  1.1568027 -1.1568027     1     Cl
  -1.1568027 -1.1568027  1.1568027     1     Cl
  END


> From: Bruce Ravel <bravel at anl.gov>
> Subject: Re: [Ifeffit] Possible bug in Artemis.
> To: XAFS Analysis using Ifeffit <ifeffit at millenia.cars.aps.anl.gov>
> Message-ID: <200601231845.59426.bravel at anl.gov>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> On Monday 23 January 2006 17:47, joshua jason kas wrote:
>> Hi,
>> When I import a feff calculation, or run feff, the paths show up in
>> artemis, but the description is garbled. What I mean is that the path
>> description under Scattering Path which normally looks like
>>
>>  	[+] Cl [+] O ...
>>
>> looks like
>>
>>  	[+] <?> [+] <?> ...
>
> This looks like another version of a bug that has cropped up here and there.
> The algorithm for generating the interpretation page parses the feff.inp file
> and a couple of feff's output files.  Every so often, someone throws a
> hand-made feff.inp file at Artemis that works in feff but breaks the rather
> crufty parser I wrote.
>
> If you can send me the feff.inp file that would help.  The artemis project
> file might help also, so send that along.  Even if it is one that makes
> Artemis do bad things when you try to read, I can still peak on the inside and
> figure out what's going on.
>
> B
>
>
>
> -- 
> Bruce Ravel  ---------------------------------------------- bravel at anl.gov
>
> Molecular Environmental Science Group, Building 203, Room E-165
> MRCAT, Sector 10, Advanced Photon Source, Building 433, Room B007
>
> Argonne National Laboratory         phone and voice mail: (1) 630 252 5033
> Argonne IL 60439, USA                                fax: (1) 630 252 9793
>
> My homepage:    http://cars9.uchicago.edu/~ravel
> EXAFS software: http://cars9.uchicago.edu/~ravel/software/
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 23 Jan 2006 20:18:42 -0500
> From: "TAO, Ye" <yetao at chem.uga.edu>
> Subject: Re: [Ifeffit] Possible bug in Artemis.
> To: "XAFS Analysis using Ifeffit" <ifeffit at millenia.cars.aps.anl.gov>
> Message-ID: <00f001c62084$1d8d28c0$3b05c080 at RASD800>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> 	reply-type=original
>
> Josh,
>
> Have a try to set  the absorber coordinate as origin (0 0 0) in feff.inp,
> then it should work.
>
> Ye
> ----- Original Message -----
> From: "joshua jason kas" <hebhop at u.washington.edu>
> To: <ifeffit at millenia.cars.aps.anl.gov>
> Sent: Monday, January 23, 2006 6:47 PM
> Subject: [Ifeffit] Possible bug in Artemis.
>
>
>> Hi,
>> When I import a feff calculation, or run feff, the paths show up in
>> artemis, but the description is garbled. What I mean is that the path
>> description under Scattering Path which normally looks like
>>
>>  [+] Cl [+] O ...
>>
>> looks like
>>
>>  [+] <?> [+] <?> ...
>>
>> and if I save the project file and reopen it, it can't
>> I have attached a screenshot.
>> Here is some info on my software
>> 1) artemis 0.8.004
>> 2) ifeffit 1.2.8
>> 3) perl -e 'use Tk; print $Tk::VERSION,$/' gives 804.027
>> 4) perl v5.8.7
>>
>> I tried updating Tk, and that works about as well as it always has on my
>> system. Most of the tests passed, a few failed.
>> This may be a problem with my version of Linux, or my version of perl/Tk.
>> Anyway, any help would be much appreciated.
>> Thank you very much,
>> Josh Kas
>
>
> --------------------------------------------------------------------------------
>
>
>> _______________________________________________
>> Ifeffit mailing list
>> Ifeffit at millenia.cars.aps.anl.gov
>> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
>>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 24 Jan 2006 11:43:30 -0300
> From: "Renato Canha Ambrosio" <rcanha at ccet.ufrn.br>
> Subject: [Ifeffit] RESTRAINTS IN IFEFFIT
> To: ifeffit at millenia.cars.aps.anl.gov
> Message-ID: <20060124142316.M21887 at ccet.ufrn.br>
> Content-Type: text/plain;	charset=iso-8859-1
>
> Hi Folks, this is my first message on the list. Perhaps someone could help
> me. The subject is how to include restraints on exafs refinement. There is
> just scanty information about this on the ifeffit reference manual.
>
> I'm trying to refine the exafs data of a rhombohedral perovskite.
>
> The main MS contributions to the signal at about 3.5 A (non phase correct)
> arise from M – O – M  interactions  being  M the absorber .  We have a
> significant SS path, a two-legged and a three-legged path. The structural
> parameters of these three terms are correlated since all refers to the same
> A-B-C triangle and the A-B and B-C distances must be that found for
> M-O1 nearest-neighbor configurations. For these reasons
> we constrained the photo electron path length for three-legged to the
> M-O nearest-neighbor distance:R(three-leg = 2*RM-O). I'm trying to
> intoroduce the quantity  defined as delta = R(three-legged)-R(two-legged)
> and thus define the SS half path length as a function of delta R(SS) = R
> (three-legged) - 2*delta. I think it is a restraint not a constraint.
> So I defined (def) the delta function on the line above the command FEFFIT
> also delr for the SS path. I introduced the restraint in the line FEFFIT as
> restraint = delrSS). The fit produce the same results as obtainde without
> the definition of delta and delrSS (function of delta).
> So I need to know how to introduce this restraint in the fit in order to
> calculate de M - O - M bond angle (this angle should be calculated using
> simple geometric relationships) - perhaps introduce the bond angle as a
> restraint.
> Someone can say me where I introduce the definitions of restraint parameters?
>
> Thank you very much for your kind attention
>
> Renato Canha
>
> Universidade Federal do Rio Grande doNorte
> Departamento de Quimica
> Natal - RN - BRAZIL
> Open WebMail Project (http://openwebmail.org)
>
>
> ---------- Original Message -----------
> From: ifeffit-request at millenia.cars.aps.anl.gov
> To: ifeffit at millenia.cars.aps.anl.gov
> Sent: Mon, 23 Jan 2006 12:00:13 -0600
> Subject: Ifeffit Digest, Vol 35, Issue 14
>
>> Send Ifeffit mailing list submissions to
>> 	ifeffit at millenia.cars.aps.anl.gov
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
>> or, via email, send a message with subject or body 'help' to
>> 	ifeffit-request at millenia.cars.aps.anl.gov
>>
>> You can reach the person managing the list at
>> 	ifeffit-owner at millenia.cars.aps.anl.gov
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Ifeffit digest..."
>>
>> Today's Topics:
>>
>>    1. Re: Re: I should be able to find this somewhere... (Bruce Ravel)
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sun, 22 Jan 2006 16:58:07 -0600
>> From: Bruce Ravel <bravel at anl.gov>
>> Subject: Re: [Ifeffit] Re: I should be able to find this somewhere...
>> To: XAFS Analysis using Ifeffit <ifeffit at millenia.cars.aps.anl.gov>
>> Message-ID: <200601221658.07513.bravel at anl.gov>
>> Content-Type: text/plain;  charset="iso-8859-1"
>>
>> Hi,
>>
>> In fact, Artemis and Athena both attempt to deal correctly with input
>> chi(k) data that is not on the expected grid.  Both codes perform a
>> test to see if the data is on the standard grid and, if not,
>> front-loads the data with zeros and uses Ifeffit's boxcar rebinning
>> function to put the data on the expected grid.
>>
>> Alas, there was a bug in the rebinning macro used by A&A which caused
>> it to fail in a particular situation met by the data in Matthew's
>> example.  This bug will be fixed in the next release.
>>
>> If you import mu(E) data into Athena and then import data from the
>> Athena project file into Artemis, you will never see the problem that
>> Matthew reported.
>>
>> B
>>
>> On Tuesday 17 January 2006 16:09, Matt Newville wrote:
>>> Hi Matthew, Bruce,
>>>
>>> OK, I think it's a bug.  Well, maybe it's just a consequence of a
>>> "known but not well advertised" problem.
>>>
>>> The chi(k) data you have doesn't start at k=0.  By itself, this should
>>> be OK, and the fit seems to be mostly fine.  There seems to be a bug
>>> in Ifeffit that the output fit chi(k) has the same number of data
>>> points as the input chi(k) data. In this case is incorrect -- it
>>> should go to the last data point in k.  From looking at the code, I'm
>>> pretty sure this has no effect on the fit and is only an error in the
>>> output array.  But the shortened chi_fit(k) will have an impact on the
>>> way Bruce is calculating the residual.   Even if that were fixed, the
>>> residual would still be wrong, as the residual in Artemis is
>>> calculated as
>>>    set(data0_res.k = data0.k)
>>>    set(data0_res.chi = data0.chi - data0_fit.chi)
>>>
>>> and then Fourier transforming to R-space.   Since the data and fit
>>> aren't aligned in k-space, the residual is incorrect.  It should be
>>>
>>>   set(data0_res.chi = data0.chi - interp(data0_fit.k, data0_fit.chi,
>>> data0.k))
>>>
>>> or some variation on that.
>>>
>>> Sorry for the trouble.  It's definitely a result of narrow-mindedly
>>> expecting that all chi(k) data comes from Ifeffit/Athena and will
>>> always start at k=0.  We should get this fixed (it's mostly there!) so
>>> that data from other sources can be used.  Right now, the easiest
>>> work-around is to pre-pack the chi(k) data with zeros (starting from
>>> k=0.00)
>>>
>>> --Matt
>>>
>>> _______________________________________________
>>> Ifeffit mailing list
>>> Ifeffit at millenia.cars.aps.anl.gov
>>> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
>>
>> --
>>  Bruce Ravel  ---------------------------------------------- bravel at anl.gov
>>
>>  Molecular Environmental Science Group, Building 203, Room E-165
>>  MRCAT, Sector 10, Advance Photon Source, Building 433, Room B007
>>
>>  Argonne National Laboratory         phone and voice mail: (1) 630
>> 252 5033 Argonne IL 60439, USA                                fax:
>> (1) 630 252 9793
>>
>>  My homepage:    http://cars9.uchicago.edu/~ravel
>>  EXAFS software: http://cars9.uchicago.edu/~ravel/software/
>>
>> ------------------------------
>>
>> _______________________________________________
>> Ifeffit mailing list
>> Ifeffit at millenia.cars.aps.anl.gov
>> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
>>
>> End of Ifeffit Digest, Vol 35, Issue 14
>> ***************************************
> ------- End of Original Message -------
>
>
>
> ------------------------------
>
> _______________________________________________
> Ifeffit mailing list
> Ifeffit at millenia.cars.aps.anl.gov
> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
>
>
> End of Ifeffit Digest, Vol 35, Issue 16
> ***************************************
>


More information about the Ifeffit mailing list