path-sensitive math expressions
Hi Matt, I have some questions about a subtle detail in ifeffit. It is possible to make a def parameter which is path sensitive in the sense that it will evaluate differently for different paths. Any def parameter which includes reff, eins(), or debye() in its math expression will be that way. Here is a simple, if slightly silly, example: def rrr = reff/10 path(1, feff=feff0001.dat, dr=rrr) path(2, feff=feff0002.dat, dr=rrr) Then show rrr will report 1/10 the R_eff of the *second* path. So here are my questions: 1. Are all def parameters reevaluated every time a new path is evaluated? Or only if the path uses the def parameter in one of its math expressions? (I think the answer is the former.) 2. Is it possible to ask ifeffit which def parameters are path sensitive? Of course, I can scan the def parameters at the level of perl to see if any of them obviously are, but ifeffit might already know that. 3. If you do show ss the value is the value of the last path evaluated. Doing show @path N show ss will indeed display the value of the def parameter appropriate to the Nth path. Is there another way of forcing ss to be evaluated appropriate to a desired path? Thanks, B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Hi Bruce,
I have some questions about a subtle detail in ifeffit. It is possible to make a def parameter which is path sensitive in the sense that it will evaluate differently for different paths. Any def parameter which includes reff, eins(), or debye() in its math expression will be that way.
Here is a simple, if slightly silly, example: def rrr = reff/10 path(1, feff=feff0001.dat, dr=rrr) path(2, feff=feff0002.dat, dr=rrr) Then show rrr will report 1/10 the R_eff of the *second* path.
So here are my questions:
1. Are all def parameters reevaluated every time a new path is evaluated? Or only if the path uses the def parameter in one of its math expressions? (I think the answer is the former.)
Yes: brute-force reevaluation. In the loop over paths (or when you do a show @path N), the values of reff and degen are overwritten with the values for the specified path, then all defined parameters are re-evaluated. The order of evaluation guarantees (I think!!) that they're all consistent so that def( a = reff ) def( b = a / 2 ) def( c = b + a ) will keep a, b, and c consistent. Finally, all path parameters are re-evaluated, and then the XAFS for that path is generated. The variables for the fits done by feffit() and minimize() work in a similar fashion to reff and degen: at each loop in the fit, these values are filled in _before_ the loop over paths is done.
2. Is it possible to ask ifeffit which def parameters are path sensitive? Of course, I can scan the def parameters at the level of perl to see if any of them obviously are, but ifeffit might already know that.
Right now, no. It might be possible, but I think it's not easy. For the definition of 'c' above, it just keeps track that it should evaluate 'b' after 'a', and 'c' after 'a' and 'b', but not that 'c' really depends on 'reff'. It could be possible to list parameters that explicitly depend on 'reff' or 'degen', but catching the implicit definitions and path parameters would be harder.
3. If you do show ss the value is the value of the last path evaluated. Doing show @path N show ss will indeed display the value of the def parameter appropriate to the Nth path. Is there another way of forcing ss to be evaluated appropriate to a desired path?
It appears not. I believe it should be, so that set path_index = 1 show rrr set path_index = 2 show rrr should show 'rrr' given the parameters for path 1, and then path 2. Right now this does not work: path_index is reported correctly as the current path after commands like 'show @path', but setting it does not change the current path. This is easy to fix, and would do what you're asking. Would that be an OK approach? --Matt
On Friday 05 September 2003 05:13 pm, Matt Newville wrote:
It appears not. I believe it should be, so that set path_index = 1 show rrr set path_index = 2 show rrr
should show 'rrr' given the parameters for path 1, and then path 2. Right now this does not work: path_index is reported correctly as the current path after commands like 'show @path', but setting it does not change the current path. This is easy to fix, and would do what you're asking.
Would that be an OK approach?
Yes, and it would be helpful. I spent a solid half hour staring at an Artemis log file today figuring out what I explained in my last email. In the end, I think it would be useful to be able to select a path as the one whose index path_index is set to after a fit finishes. That would clarify how the def parameters are reported by Artemis after a fit -- which is currently confusing, as I discovered today. Thanks! B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Bruce,
Yes, and it would be helpful. I spent a solid half hour staring at an Artemis log file today figuring out what I explained in my last email. In the end, I think it would be useful to be able to select a path as the one whose index path_index is set to after a fit finishes. That would clarify how the def parameters are reported by Artemis after a fit -- which is currently confusing, as I discovered today.
I think this file: http://cars.uchicago.edu/ifeffit/bugfixes/iff_set.f (drop-in-place for src/lib/iff_set.f) fixes the problem. Let me know how this works out, --Matt Maybe it's time to get CVS working on SF.net??
participants (2)
-
Bruce Ravel -
Matt Newville