Generating single scattering paths in Artemis
Bruce: Occasionally, I don't know or don't care what the extended crystallographic environment of the absorber. All I want to do is apply single scattering analysis and I need some simple paths from FEFF. At this time, I can't see how to do this within Artemis since the Atoms page requires a space group and more information than I have available. Would it be possible to have the option for a simpler interface which just allows me to generate single scattering paths between two atoms at a specific distance from each other? Perhaps, I could even specify a coordination geometry (tetrahedral, octahedral, etc.)? Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Hi Carlo, Hmmm...my initial reaction was that, rather than loading Artemis with a new option, it's better just to "fake it" by using a low-symmetry space group with a large lattice parameter and then truncating the cluster size at smaller than the unit cell. But I just tried this, and discovered an interesting problem, which you may have come across as well. What I did was attempted to create an octahedral cluster by using a space group of P m 3 m (simple cubic) with a=10, an Fe at 0 0 0 absorbing, and an oxygen at 0.2 0 0 (thus an Fe-O distance of 2 angstroms). The cluster size is set at 5. As expected, that generates an octahedral cluster of oxygens around the Fe as a FEFF.INP file. But here's the problem: Artemis includes a potential for scattering atoms of Fe, and there aren't any in the list. FEFF, in turn, doesn't like that and won't run, causing Artemis to give the error message: " Feff 6L.02 No atoms or overlap cards for unique pot 1 Cannot calculate potentials, etc. Fatal Error: at RDINP This error is probably due the Atoms list in the the Feff input file being too short to contain an example of each unique potential. Try increasing the Rmax on the Atoms page and re-running both Atoms and Feff." This can be fixed by editing the feff.inp file to remove the Fe potential 1, but that's not enough--the oxygen scatterers then have to have their potential renumbered to 1 to make things work. That's a lot of work to do what should be simple. So I vote for changing the way Artemis works in such circumstances so that less editing is needed: if the absorbing atom is not present in the scattering list, then it shouldn't have a second entry in the potential list. As far as the other special arrangements (tetrahedral etc.), if you're not interested in going beyond nearest neighbor direct scattering EXAFS analysis, then there is no difference between them except for a degeneracy factor which can easily be inserted later in the process (i.e. only one FEFF path is needed). --Scott Calvin Sarah Lawrence College
Bruce:
Occasionally, I don't know or don't care what the extended crystallographic environment of the absorber. All I want to do is
Scott: These are just the kind of problems I was having but I would add that for someone who is not savvy about crystallography, having to fake a crystal with a low symmetry space group is not terribly intuitive. I agree with you also about the symmetry of the neighbors but, again, i think that the benefit of an intuitive interface to what the scientist wants to do is a good thing. I think that having to use work-arounds is difficult to explain to new users. Perhaps a new chemistry student knows that his/her atom has an octahedral coordination. It woujld be good to be able to intuitively model that. Just my $0.02 Carlo On Wed, 5 Jan 2005 scalvin@slc.edu wrote:
Hi Carlo,
Hmmm...my initial reaction was that, rather than loading Artemis with a new option, it's better just to "fake it" by using a low-symmetry space group with a large lattice parameter and then truncating the cluster size at smaller than the unit cell. But I just tried this, and discovered an interesting problem, which you may have come across as well.
What I did was attempted to create an octahedral cluster by using a space group of P m 3 m (simple cubic) with a=10, an Fe at 0 0 0 absorbing, and an oxygen at 0.2 0 0 (thus an Fe-O distance of 2 angstroms). The cluster size is set at 5. As expected, that generates an octahedral cluster of oxygens around the Fe as a FEFF.INP file. But here's the problem: Artemis includes a potential for scattering atoms of Fe, and there aren't any in the list. FEFF, in turn, doesn't like that and won't run, causing Artemis to give the error message:
-- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Sorry about that... Hit the wrong button. Anyway, as I was saying, to make a single scattering path is easy-- just open the theory menu in Artemis, click the "New feff input template" button, and fill in the template that opens up. You can put in as many atoms as you want, and it does work perfectly well if you only have two. All you need to know are a few details about what's in a feff input file, and it is relatively quick and painless. The only thing that tripped me up was: there are some underscores in the template to show you where to type in certain information, and before you hit the "run feff" button you need to get rid of all of those or it won't run. If you want to experiment with different coordinations, you can just play with the path degeneracy in Artemis. If I've missed some essential details, let me know, but it seems like this works fine... Mike Groves UW Physics
Mike: I agree, this is an option but my comments from before still hold. It does require some specific knowledge of the structure of a feff input file. This is most likely not as approachable for a beginning user who has never seen a FORTRAN program with its input files. Carlo On Wed, 5 Jan 2005, Michael A Groves wrote:
Sorry about that... Hit the wrong button. Anyway, as I was saying, to make a single scattering path is easy-- just open the theory menu in Artemis, click the "New feff input template" button, and fill in the template that opens up. You can put in as many atoms as you want, and it does work perfectly well if you only have two. All you need to know are a few details about what's in a feff input file, and it is relatively quick and painless. The only thing that tripped me up was: there are some underscores in the template to show you where to type in certain information, and before you hit the "run feff" button you need to get rid of all of those or it won't run. If you want to experiment with different coordinations, you can just play with the path degeneracy in Artemis.
If I've missed some essential details, let me know, but it seems like this works fine...
Mike Groves UW Physics
_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
-- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Re: [Ifeffit] Generating single scattering paths in ArtemisAdding to my previous example of the feff.inp file that calculates single scattering paths only, below are the links to FEFF6 document where the use of SS and OVERLAP cards is explained. As I checked some time ago, without the OVERLAP card, the results may be different (and worse) than with it, so it is more safe to use this card. As reality checks have shown, It produces very similar results for single scattering feffxxxx.dat paths (if the feff.inp file is constructed correctly!) to those calculated when the atoms list is explicitely used to model the structure. http://leonardo.phys.washington.edu/feff/Docs/feff/feff6-4.html#ss http://leonardo.phys.washington.edu/feff/Docs/feff/feff6-4.html#ove Anatoly Anatoly Frenkel Yeshiva University
Hi all, Thanks, Mike, I'd never tried that option before. But I agree with Carlo that it's not that easy a way out, since you still have to understand how to assign potentials in a FEFF.INP file...exactly the sort of thing the Artemis front-end is supposed to protect newbies from, I think. A question for Carlo--I guess I'm not clear on what the impact is of tetrahedral vs. octahedral or whatever if all you're doing is a single-scattering nearest-neighbor EXAFS analysis. Isn't a symmetric octahedral arrangment just the single-scattering path with a degeneracy of 6; a tetrahedral a degeneracy of 4; etc.? Why have FEFF calculate anything other than the single-scattering path? Having said that, I could see an option that lets you generate a single FEFF path via the Artemis front end (and maybe even specify a degeneracy up front). That way you wouldn't have to deal with any of the rigamarole of choosing a low-symmetry space group and putting your atoms somewhere appropriate in the unit cell. It would certainly make things easier for me on occasion (sometimes I have an amorphous component mixed in with the crystalline stuff, for example). The one thing that makes me nervous about this is that I almost don't want to make single-shell single-scattering fits =too= easy for novice users. I work with a lot of undergraduates, and in my experience it's hard for people new to EXAFS and characterization in general to understand just how unreliable such fits can occasionally be, due to high correlations between fitted parameters, leakage from higher-R shells, issues with the background, etc.. A fit with more shells and/or multiple scattering is more likely to =obviously= fail (e.g. yield a poor match between fit and data) if something is wrong. So I guess I kind of like there to be a little bit of a learning process new people have to go through before they can make Artemis do anything, so that they least understand that there can be paths beyond the first. :) But this is really just a gut feeling--it's possible that a single path shortcut like Carlo describes will just make the learning curve easier... --Scott Calvin Sarah Lawrence College
Scott: I think that Anatoly's posts answer this question. The calculation of the overlaps requires some kind of three-dimensional environment (or the use of the OVERLAP card which I was not familiar with and whose documentation in the FEFF manual is a bit cryptic). There are differences between a single neighbor at a specific distance and a coordination shell of the same neighbor at the same distance. Sam's program clearly does the calculation by building a coordination sphere while Anatoly's method lets FEFF do it automagically. Apparently the results are the same. Carlo On Wed, 5 Jan 2005 scalvin@slc.edu wrote:
Hi all,
A question for Carlo--I guess I'm not clear on what the impact is of tetrahedral vs. octahedral or whatever if all you're doing is a single-scattering nearest-neighbor EXAFS analysis. Isn't a symmetric octahedral arrangment just the single-scattering path with a degeneracy of 6; a tetrahedral a degeneracy of 4; etc.? Why have FEFF calculate anything other than the single-scattering path?
-- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Hi Carlo, Good point...but I would note that you're choosing to ignore atoms further out radially in the FEFF calculation, so the 3-dimensional environment isn't right anyway. It would seem to me that the EXAFS differences between, e.g., tetrahedral and octahedral coordination would often be smaller than the error in leaving out the next shell, depending on the material. For example, by my count in an fcc (12-coordinated) lattice including only one shell means each scattering atom has only 3 of its 12 neighbors present in the calculation. To the extent that the FEFF calculation is impacted by such things, this is substantial. Fine for an approximate fit in many cases, but I'm not sure I see that it's worth the trouble of constructing tetrahedral (or whatever) symmetry. On the other hand, I haven't personally compared the tetrahedral to the octahedral to the single-scatterer to the full-crystal case...it might be interesting to try and see how much of a difference each makes to a fit. --Scott Calvin Sarah Lawrence College
Scott:
I think that Anatoly's posts answer this question. The calculation of the overlaps requires some kind of three-dimensional environment (or the use of the OVERLAP card which I was not familiar with and whose documentation in the FEFF manual is a bit cryptic). There are differences between a single neighbor at a specific distance and a coordination shell of the same neighbor at the same distance.
Sam's program clearly does the calculation by building a coordination sphere while Anatoly's method lets FEFF do it automagically. Apparently the results are the same.
Carlo
On Wed, 5 Jan 2005 scalvin@slc.edu wrote:
Hi all,
A question for Carlo--I guess I'm not clear on what the impact is of tetrahedral vs. octahedral or whatever if all you're doing is a single-scattering nearest-neighbor EXAFS analysis. Isn't a symmetric octahedral arrangment just the single-scattering path with a degeneracy of 6; a tetrahedral a degeneracy of 4; etc.? Why have FEFF calculate anything other than the single-scattering path?
-- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre _______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
On Wednesday 05 January 2005 02:23 pm, Carlo U. Segre wrote:
Bruce:
Occasionally, I don't know or don't care what the extended crystallographic environment of the absorber. All I want to do is apply single scattering analysis and I need some simple paths from FEFF. At this time, I can't see how to do this within Artemis since the Atoms page requires a space group and more information than I have available.
Would it be possible to have the option for a simpler interface which just allows me to generate single scattering paths between two atoms at a specific distance from each other? Perhaps, I could even specify a coordination geometry (tetrahedral, octahedral, etc.)?
First off, I should mention that I was off yesterday afternoon judging an elementary school science fair, so I did not see this very interesting thread until this morning. I am going to have a lot to say in response to everything Carlo, Scott, Anatoly, Dave, and Mike said. In this post, I am going to address the issue in the least interesting way. That is, I am going to suggest a strategy for doing this analysis that is fairly simple and works within the framework of the existing code. Later today I'll comment on what new functionality should be put into Artemis. Before I start, I do want to point out that this is a topic that Sam has already addressed in SixPack and is yet another reason that you should give SixPack a look if you haven't already. Scott pointed this out: "Isn't a symmetric octahedral arrangment just the single-scattering path with a degeneracy of 6; a tetrahedral a degeneracy of 4; etc.?" I agree. If you are in the situation where you know almost nothing beyond the species of the absorber and a guess for the species of the scatterer, then you really don't need to be fretting the details. Just do the simplest possible thing. To my mind, the simplest possible thing is rocksalt. I always keep this atoms.inp file lying around somewhere where I can find it quickly: title FeO, rocksalt structure space f m 3 m a = 3.3108 core = Fe atoms Fe 0.00000 0.00000 0.00000 O 0.50000 0.50000 0.50000 Import it into Artemis, change the atomic species to your absorber and scatterer and run Atoms. This will give you 6 scatterers at 1.655 A. That's not an unreasonable number for a transition metal oxide, which is likely what we are talking about. You might choose to make "a" a bit bigger for other things. After Feff finishes, Artemis asks about how many paths you want to import. Choose to import 1 path. On the path page, change the value for N from 6 to 1. At this point you can click the big, green button. The "amp" parameter will be a measure of the coordination multiplied by S_0^2. One could criticize this scheme by saying that a rocksalt crystal is not a good representation of a messy unknown. I agree with Scott that it is close enough, that it is sufficient at this stage of the game to just multiply a reasonable scattering path by a coordination number. Ultimately, I sense that Carlo and some others are suggesting that Artemis should have a one-click solution for a basic first shell analysis problem. What I have written here is certainly not that solution. This will be the topic of my next posting to the list. All that said, my suggestion isn't really that complicated conceptually and it is not so difficult to do with Artemis. It is, in my opinion, pretty much as defensible as any other simple approach to first-shell, cumulant-y analysis, including all of the suggestions made in this thread. B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b 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: In fact, what you describe below is what we do. You understood my point precisely though and I eagerly await your next comment. Carlo On Thu, 6 Jan 2005, Bruce Ravel wrote:
In this post, I am going to address the issue in the least interesting way. That is, I am going to suggest a strategy for doing this analysis that is fairly simple and works within the framework of the existing code. Later today I'll comment on what new functionality should be put into Artemis.
-- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Hi folks, Carlo asked about a simpler way of doing simple, first-shell analysis that what Artemis provides. Let's talk about that. Artemis is complicated program. It may be powerful and effective. Some of you may like it for what it allows you to do. Some of you may consider that it competes favorably against other programs in terms of ease-of-use. Or not. Be that as it may, Artemis is a complicated program and I will be the first to say so. I originally designed and started to write Artemis in a way that would address my analysis needs. I work on some comlicated fitting problems and delve pretty deeply into the guts of Feff and Ifeffit. Artemis' first responsibility is to handle *my* needs. That said, Artemis should not be overtly hostile to novice users. Indeed, there are a number of features in Artemis that were included with the novice in mind: automatic generation of guess parameters when a feff calculation is imported, feedback about unusual values for fitting variables, and so on. I am disinclined to make huge changes to how Artemis works. I like Artemis and it serves my own research needs quite well. The system of various pages -- atoms, feff.inp, feff interpretation, data, path, GDS -- works well for me and gives the Artemis user a high degree of control over the fine details of the fit. That is unlikely to change. We are left with two topics of conversation: (1) What can be done within the framework of Artemis to expedite a simple fit? (2) Should we consider a new application which works differently from Artemis and which is designed principally to handle the simplest problems? #2 is a fine topic of conversation and might be an excellent chore for someone looking to get involved in Ifeffit development. I have some ideas about #1. So it seems do several people on the list. My next message will be about that. B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b 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, Several approaches to the problem of a simple, one-shell fit were proposed with different ideas about incorporating them into Artemis: 1. Scott suggested a solution involving a low symmetry group, but ran into a problem that required some knowledge of Feff to solve -- a situation he suggested that Artemis is supposed to protect the user from. 2. Anatoly suggested using Feff's overlap and ss keywords. Those features of Feff were certainly designed for simple fitting problems, but, I agreed with Carlo when he pointed out that the documentation is a bit cryptic. 3. Mark suggested using the Feff templates in Artemis. That's a good idea and certainly why I included the templates, but it fails to protect the user in the manner Scott recommends. 4. Sam explained how SixPack uses simple coordination geometries and a periodic table interface to address this problem. 5. Finally, I suggested one way of solving the problem using Artemis as it is today. Scott made this comment: "So I vote for changing the way Artemis works in such circumstances so that less editing is needed". OK! I agree! We now agree on what we don't want (lots of editing). Now we need to discuss what we *do* want. None of the solutions above are perfect: 1. The low symmetry solution suffers from requiring the user to understand enough crystallography and enough about Feff to get that solution to run to completion. 2. Like Carlo, I have never quite understood the whole overlap thing in Feff. In any case, I think that the user should eventually be forced to think about paths. Today you might analyse the first shell, but tomorrow you will want to roll up your sleeves and start doing a much better analysis. There is no smooth transition from an overlap first shell analysis to a more sophisticated path-based analysis. It is better, IMHO, to start with paths and stick with paths. 3. The problem with the templates is having to know what to write in the templates. The templates are super-helpful if you can, say, cut and paste atomic coordinates from a Protein Data Bank file, but not so convenient otherwise. The solution I see is a combination of Sam's periodic table thing and the solution I suggested two emails ago. It could work something like this: a. Choose "Single scattering fit" from one of the menus b. Pop up a dialog in which the user tells Artemis: i. the species of the absorber ii. the species of the scatterer iii. the approximate distance to the first shell iv. the geometry c. Artemis constructs a suitable feff.inp file, runs Feff without asking for confirmation, and imports only the first path d. Variables for amplitude, sigma^2, delr, and e0 are generated automatically, just like they are now e. Artemis pops up a dialog asking the user if she wants to run the fit immediately or later. The immediate choice is just like the big green button, the later choice lets the user examine things before pressing the big green button. A few comments: Regarding step b.i. and b.ii.: This could be a periodic table, like Sam uses or a couple of entry boxes, which would be more compact Regarding step b.iv.: I think I would include some real diatomic crystal structures, such as rock salt, cesium chloride, zinc sulfide, along with the things in Sam's list (square planar, octahedral, tetrahedral, according to the screenshot on his web site) This approach is simpler than how Artemis currently works only in that it automatically jumps through several steps without stopping. Once the fit is done, the user is still looking at Artemis and Artemis is just as complicated as it ever was. However, the advantage of this approach over, say the overlap thingie, is that one is in a position to begin using some of Artemis' tools to look beyond a simple first shell fit. In short, the bad news is that it is still Artemis, but the good news is that it is still Artemis. Like Scott, we all vote that Artemis work better. But Artemis is the product of a benevolent dictatorship rather than of a democracy. While you all are welcome to cast a vote for the goodness of Artemis, I'm really looking for concrete design suggestions. B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b 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, It doesn't seem that hard to have a procedure to auto-generate and run Feff6 with a rock-salt or simple tetrahedral environment, either in Artemis or a standalone application -- I'd vote for emulating Sam's approach in Artemis. I strongly agree that no one should be expected to use Rydbergs or the OVERLAP card, or even know that Feff has an input using things called 'cards'. I'd prefer it if the running of Feff was a little more modular, and a little less tied to Artemis, but a decent Feff GUI is probably a separate topic. Another approach would be to recognize that the results of a SS Feff calculation can be stored in ~3kb, so it's not unreasonable to think about making tables of pre-calculated SS paths for nearly all reasonably likely SS paths. It might also be nice to have these in a network-accessible database so that it wouldn't always be necessary to calculate SS paths or store a huge table of them. --Matt
We recently found a very nice package called f2py which converts FORTRAN source code into Python libraries. There is a bit of editing to be done on the source but not too much. Then you have a set of Python callable functions and the Python infrastructure handles the memory allocation. No more input files or output files. Carlo On Thu, 6 Jan 2005, Matt Newville wrote:
I'd prefer it if the running of Feff was a little more modular, and a little less tied to Artemis, but a decent Feff GUI is probably a separate topic.
-- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Hi Carlo, Yep, I know about and have played with F2PY. For Ifeffit I use SWIG because I also need to be able to call Ifeffit from other C-based languages. The issue for Feff is that it is not itself suitable for calling in any manner except as a full application. The Feff6 code is not modular in any sense of the word, and relies heavily on common blocks. Also, a Feff6 calculation cannot be stopped in the middle and restarted reliably (despite what the "CONTROL" cards might imply, if feff.inp changes during a run of Feff6 the results are not easily predictable). The upshot is that it would take an enormous amount of work (including getting rid of many of the common blocks) to do any better than os.system("feff6") Anyway, that's all a separate topic.... --Matt
Bruce: You asked for implementation ideas and so are some thoughts. First of all, I really like the Artemis interface. While it is complex, it needs to be to actually make it useful for complex analysis projects. I like the idea of selecting "Single scattering cluster" and then getting a left hand window with a tab labeled "Cluster" and one labeled "Interpretation". I agree that there is no need for a "feff.inp" tab here because the power user will just use one of the other ways proposed in this thread to generate paths the way they want them. Now, how to best build a cluster. Selecting the absorber and scatterer could be drop down lists as could be the absorbing edge. The distance could be an input box and the coordination would be a drop-down list with common coordination types single (1 atom only), linear (2 atoms in linear arrangement), tetrahedral, octahedral and icosahedral. If there is a desire, one could even offer the complete IUPAC list http://www.iucr.org/iucr-top/comm/cnom/inorg/node4.html but this probably would be overkill, a simple subset should do. There could be a drop down list of standard coordinations from a database that, when selected, would just fill in the boxes appropriately. At the bottom, I would put a big FEFF button and then allow the user to proceed with analysis just like as the current system. Carlo On Thu, 6 Jan 2005, Bruce Ravel wrote:
The solution I see is a combination of Sam's periodic table thing and the solution I suggested two emails ago. It could work something like this:
a. Choose "Single scattering fit" from one of the menus b. Pop up a dialog in which the user tells Artemis: i. the species of the absorber ii. the species of the scatterer iii. the approximate distance to the first shell iv. the geometry c. Artemis constructs a suitable feff.inp file, runs Feff without asking for confirmation, and imports only the first path d. Variables for amplitude, sigma^2, delr, and e0 are generated automatically, just like they are now e. Artemis pops up a dialog asking the user if she wants to run the fit immediately or later. The immediate choice is just like the big green button, the later choice lets the user examine things before pressing the big green button.
A few comments:
Regarding step b.i. and b.ii.: This could be a periodic table, like Sam uses or a couple of entry boxes, which would be more compact
Regarding step b.iv.: I think I would include some real diatomic crystal structures, such as rock salt, cesium chloride, zinc sulfide, along with the things in Sam's list (square planar, octahedral, tetrahedral, according to the screenshot on his web site)
This approach is simpler than how Artemis currently works only in that it automatically jumps through several steps without stopping. Once the fit is done, the user is still looking at Artemis and Artemis is just as complicated as it ever was.
However, the advantage of this approach over, say the overlap thingie, is that one is in a position to begin using some of Artemis' tools to look beyond a simple first shell fit.
In short, the bad news is that it is still Artemis, but the good news is that it is still Artemis.
Like Scott, we all vote that Artemis work better. But Artemis is the product of a benevolent dictatorship rather than of a democracy. While you all are welcome to cast a vote for the goodness of Artemis, I'm really looking for concrete design suggestions.
B
-- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Oops, brain cramp, I meant IUCr in my last message. Not enough sleep... -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
participants (6)
-
Anatoly Frenkel -
Bruce Ravel -
Carlo U. Segre -
Matt Newville -
Michael A Groves -
scalvin＠slc.edu