Re: [Ifeffit] Using windows apj files on linux

[Ravel, Bruce D.]

Hi all,

I spent some time on an airplane this morning fixing this problem that Josh 
reported.  It should be fixed in the next release.  In light of this being a 
linux-only problem, I will probably make a source code release before the new 
windows executables are ready.

B

P.S.  In case you are curious, \x is perl's way of explicitly specifying a 
unicode character and the argument in braces is the character number expressed 
in hex.  \x{d} is, therefore, the carriage return character, sometimes 
written \r.  So basically, perl was trying to tell me that I was handling the 
dos/unix end of line issue incorrectly, but it was telling me in a really 
obfuscated way.  Fascinating stuff ... not!

-Original Message-
From: [EMAIL PROTECTED] on behalf of joshua jason kas
Sent: Tue 5/29/2007 12:13 PM
To: ifeffit@millenia.cars.aps.anl.gov
Subject: [Ifeffit] Using windows apj files on linux
 
Hi,
I recently updated to redhat 4. I am running:
artemis 0.8.009
IFEFFIT 1.2.9
Tk-804.027
perl 5.8.5

I have an artemis project file that I 
started on my win xp machine and would like to use on the linux machine. 
When I open the apj file on linux, some of the information about the fits 
seems to be scrambled. Here are some of the symptoms.

1) The raw logs seem to have aquired the following
escape character at the end of each line: \x{d}
   This shows up as a carriage return or end of line on this screen.

2) Quick summary of selected fits gives 0 for all reported values
   (chisq, rfactor, nidp, etc) and does not report any guessed
parameters.

Here is one of the quick summaries. Note that the \x{d} do not show up 
here, but they do in the artemis message palette. I am also attatching the 
project file.
Thanks for any help,
Josh Kas

Project title   : Fitting pt1_amine_165_he_573.chi

Comment : fer dw, constant delr, ei=0, kw=1, kmin=2.0, rmin=1.2

Figure of merit : 17


Fitting statistics
   Number of independent points : 0
   Number of variables  : 0
   Chi-square   : 0
   Reduced chi-square   : 0
   R-factor : 0
   Measurement uncertainty (k)  : 0
   Measurement uncertainty (R)  : 0

Guess parameters

=*==*==*==*==*==*==*==*==*==*==*==*==*==*==*==*==*==*==*==*=




___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

RE: [Ifeffit] Problems with the flatten option in Athena

[Ravel, Bruce D.]

Flattening involves removing from the data the difference in slope and 
quadrature between the pre-and post-edge lines.  Because this does not make 
sense in the pre-edge, Athena multiplies this difference array by a step 
function centered at E0.  If your E0 is not somewhere sensible (i.e. in the 
swiftly rising part of the spectrum) then you amy see something funny.
 
This question would have been easier to answer had you attached a one-group 
project file conatining the data in question.  Without seeing the data, the 
only thing any of us can do is speculate as to what is happening.  That said, a 
misplaced E0 value seems like the likeliest answer.
 
HTH,
B



From: [EMAIL PROTECTED] on behalf of Jens Kruse
Sent: Wed 10/01/2007 08:56
To: ifeffit@millenia.cars.aps.anl.gov
Subject: [Ifeffit] Problems with the flatten option in Athena



Hi,

I have a normalization problem with Athena. If I turn on the flatten
option in the background removal section, Athena creates in some of the
normalized spectra a step in the pre-edge range.  How can I  get rid of it?

Thanks,

jens
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit



___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit