Matthew said:
As it is now, if you want to describe your unknown structure as a distorted version of the one for which FEFF was run, you have to enter formulas for distances by hand. For instance, suppose you're doing a substitutional dopant and you want to use Artemis to fit the displacement of the impurity off-site and the dilation/contraction of the first-neighbor shell. As it is now, you have to do the algebra yourself to compute all the distances in terms of the distortion parameters. It would be really nice if there were some syntax for describing the alteration of atom positions, from which Artemis would automatically compute the displacements. This might have to be a new class of parameters. Such a computation would cover the MS paths as well. What it would still NOT do is account for the effect of leg-to-leg angles on MS paths (deviation from focusing/backscatter), but it would be a step. I realize that this would be a big job to implement in a nice way that wouldn't break everything that came before, but it would be super useful and make the IFEFFIT team (yet again) heros to the community
It's nice to start a new thread when you start a new thread, so I'm starting a new thread. :) I understand exactly what you are asking for. In short, you would like to be able to parameterize atom positions, possibly even crystallographic parameters, and have those propagated through to the math expressions for delta_R for the paths. In fact, Demeter has some of what's needed already built in. There are two things needed to implement that with the way things currently work. 1. The pathfinder needs to remember the all the scattering geometries that contribute to a degenerate set of paths so that a parameterization has the possibility of breaking degeneracies. 2. In the case of using crystal data, Atoms needs to remember the symmetry operations that were done to place each atom in the cluster. This would allow Demeter to propagate a change in a crystal parameter through to delta_R. #1 already exists in Demeter. #2 is something I worked on in the past, but never got working to my satisfaction. The point is that most of #2 is in there, but commented out. That is, it's reasonably close. As you suggest, the hard part is presenting this to the user. I have actually been thinking about this problem lately and am interested in getting back to it. I have another big feff-interface improvement to work on first (an idea for dealing with Feff calculations over multiple, inequivalent sites in a user-friendly and user-efficient way), but I'll think about it. I should mention that Shelly has implemented something like this before for use with Matt's ancient feffit program. You might be able to get her to chime in.... B -- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973 Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel