Funny, I thought I did start a new thread... YES! Management of inequivalent sites would be very nice indeed! As it is now, you have to manually make multiple FEFF files, keeping track of the stoichiometry, and setting up multiple FEFF calculations, keeping track yourself of what parameters should be in common. The common thread here is a tighter integration of the structure description (ATOMS, feff.inp) with the FEFF calculation and fitting. Good catch about the degeneracy; I hadn't thought of that, but you're right. I wonder if it would make sense to put in a kludge which, for small enough breaking of the degeneracy, pretends that they're still degenerate but adjusts ss accordingly. I guess the S02 and dr would also get small adjusts because the nearer atoms would be slightly over-represented compared to the farther ones. This kludge would shorten the path list, making it less confusing, and also perhaps save computation time. There would have to be an alarm set for when k*(distance splitting) is too big to allow this approximation. An intermediate case would bring in C3 and C4, in a fixed relation to the distortion parameters. All of this adjusting would, prefereably, be 'behind the scenes', invisible to the user unless he asks to see it. As you show, you need crystal-symmetry operations. In some cases, the cluster being simulated is not derived from a crystal structure, but is instead a molecule or hypothetical structure. At first sight, this might seem to imply a need for two kinds of structures, crystalline and non-crystalline. However, a P1 space group and 100A lattice parameter should take care of the description of non-crystalline clusters. That's how I've used Diamond to display clusters. Another complication is that the distortion you want to implement will often reduce the local symmetry. Thus, maybe it's best after all to work at the feff.inp level, requiring the user to parameterize the movement of each atom. Thus, in octahedral example I gave, if the central atom is at 000 and the neighbors at (r,0,0),(-r,0,0),(0,r,0),(0,-r,0),(0,0,r),(0,0,-r), then the displacements might be (for a 100 distortion), (xoff,0,0) for the central atom and (dr,0,0),(-dr,0,0),(0,dr,0),(0,-dr,0),(0,0,dr),(0,0,-dr) for the neighbors, in a first model. The next model might have the lower symmetry of the site reflected in the neighbor motions: (dr+xoff*fp,0,0),(-dr+xoff*fm,0,0),(0,dr,0),(0,-dr,0),(0,0,dr),(0,0,-dr) with fp,fm being the fraction of the motion of the central atom communicated to the atoms "in front of" and "behind" it. Now, integrating this with the inequivalent-site manager could be a bit tricky. There would have to be some way to make sure that the scattering atoms that were actually the same for the multiple FEFFs get the same motions - or not. If you have a deterministic structure, where every unit cell is the same or there's only one unit cell, such as in a cluster, then you need to do that correspondence. On the other hand, imagine something like a doped spinel. The dopant goes in either the octahedral or tetrahedral site, causing lattice distortion in its near-neighbor shells either way. If it's dilute, then the two FEFF runs correspond to a single substituent in the octahedral site, with distortion around that site, and a single tetrahedral substituent with distortion around the tetrahedral site. These are different patterns of stom movement. Hmmm. The more I think about this, the more complicated it gets to deal with it in general. It's beginning to seem like one needs a new scripting or graphical language for describing this stuff. That argument suggests that it will be necessary to back off and start with some practical subset which is sophisticated enough to handle a useful fraction of problems but simple enough for some busy person to write and the rest of us to learn and use. A danger is that the tool becomes like Photoshop or Word - filled with features 99% of which go unused by 99% of us. When us 99%ers need a 1% feature, we don't even know it exists or how to use it. As Deep Thought put it, "Tricky"! mam On 8/7/2013 2:12 PM, Bruce Ravel wrote:

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