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