RE: [Ifeffit] artemis development in the near future
Bruce,
* Windows users who would like to be involved with the development branch should consider installing ActiveState's perl distribution on their computers as that would allow you to test the source code as it becomes available. If anyone is interested in this, I can help get you started. But I would encourage only the enthusiastic to consider this. Most users will prefer to use the executables that I will build for the stable version.
Well, to paraphrase some recent declaration, sometimes you have Activestate, sometimes, you haven't, there's this little third category... Yes, I have installed ActiveState a long time ago, but that was just to run some script, and it is unclear to me if you plan to run the development versions of Athena and Artemis as script, or if you will ask each and every Windows user to compile his/her own little executable. In the later case, You'll have to explain me. Othervise, the new version runs fabulously great, apart from a minor point: I can't fit simultaneously several spectra (polarization data) in q-space. TApparently Artemis traps some kind of error message. but the software keeps on running. Otherwise, there's a little practical point which bothers me: when it comes to publishingand citing, we know how to shower praise on Matt, but we are still yearning for some sound reference for the Ravelware. Is there any chance that this 'bug' will get fixed in the near future? Best regards, Michel Schlegel
On Wednesday 28 July 2004 12:47 pm, SCHLEGEL Michel 177447 wrote:
versions of Athena and Artemis as script, or if you will ask each and every Windows user to compile his/her own little executable. In the later case, You'll have to explain me.
Well, the point I was trying to make was that building and testing windows executables adds considerably to my work. I would like to be able to release the development version frequently -- the early-and-often approach to software development. If I have to build windows exes everytime, that will slow me down, wear me out, and make it not worth my time to bother with the whole idea of a fork. So, yes, I am suggesting that windows users who want to help test the development version run them as normal perl scripts (which is, of course, how linux and osx users run them). Obviously this is NOT something that most people (beginnning students, computerphobes, the impatient) would want to do. But for someone who is willing to devote a little bit of time and mental energy, this is a great way that person can contribute substantively to my effort.
Othervise, the new version runs fabulously great, apart from a minor point: I can't fit simultaneously several spectra (polarization data) in q-space. TApparently Artemis traps some kind of error message. but the software keeps on running.
OK, thanks for the report. I'll look into it. q-space fitting is not one of the well-tested corners of the code since I never do that myself.
Otherwise, there's a little practical point which bothers me: when it comes to publishingand citing, we know how to shower praise on Matt, but we are still yearning for some sound reference for the Ravelware. Is there any chance that this 'bug' will get fixed in the near future?
Complain to Physica Scripta and/or the people who ran last year's XAFS conference. The conference proceedings will contain the reference for A&A, but here we are 13 months after the conference and the proceedings languish under the heading "Forthcoming Topical Issues" on the Physica Script web site. If you ask me, this whole situation with the XAFS12 conference proceedings is a fuckin' pile of crap. 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/
On Wednesday 28 July 2004 01:31 pm, Bruce Ravel wrote:
Othervise, the new version runs fabulously great, apart from a minor point: I can't fit simultaneously several spectra (polarization data) in q-space. TApparently Artemis traps some kind of error message. but the software keeps on running.
OK, thanks for the report. I'll look into it. q-space fitting is not one of the well-tested corners of the code since I never do that myself.
The error messages are now only written to the console, which on windows is the task bar item that says "Artemis" but normally stays closed. Cut-n-paste those errors and send them along. I disabled the writing of a file with that information because doing so was often a cause of artemis hanging and chewing up 100% of the CPU. 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/
On Wed, 28 Jul 2004, Bruce Ravel wrote:
the Physica Script web site. If you ask me, this whole situation with the XAFS12 conference proceedings is a fuckin' pile of crap.
hear, hear! -- 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 Bruce, Sorry for taking a few days to come back to this, but I do have a few comments on this plan even if most of the thread devolved into a discussion of current issues with Artemis.... First, the overall plan for a 'development' branch for artemis seems OK to me. Perhaps the principle questions for users are: 1) will both 'stable' and 'development' be supported for bug fixes, and 2) how quickly will developments be folded back into 'stable'. The main concern for me is that it will be too much work for you. So, we all promise to forgive you if you give up on having two different versions of artemis as too much work, and be patient when the very nice features in the development version are slow to make it into the stable version. Second, making 'development' be source-only makes sense. Windows users interested in the development version could use ActiveState perl and the current dlls, or cygwin (I am just coming back to trying cygwin after several years, so I am not sure how easily it will all work, but my understanding is that it can work). Third, your list of proposed developments seems OK to me. I'd guess that many of the listed features-to-add could be added to 'stable' without much chance of breaking other things. But artemis is a hard problem, and deciding that a partial or total redesign is OK. Personally, I don't think you should rule fairly dramatic changes (including asking more from Feff6 and Ifeffit) just to get more features in Artemis. None of the feature on your list are more important than having a well-planned and -documented internal structure that can last many years. Fourth, separating horae into Athena and Artemis for development might be OK - I can certainly understand that Athena seems done - but might cause some problems or limitations too. The first and last item on your proposed list of changes (better atoms interface and 'a bunch of internal changes') might benefit Athena too. Another possible goal might be to make the horae perl modules more "scripter friendly" so that others could use or add to the components of Athena, Artemis, etc. The Xray module with Atoms was (and is) very useful, and I'd suspect that there would be folks interested in using and contributing components, with the CIF/PDB readers being a prime example: I assume you'll rewrite much of these contributions to fit your needs. It might be better to have components that make this and other developments easier. And of course, making it so that others can write elaborate perl programs based on your work would be highly useful. I guess the two points I'm trying to make are that a development branch is a good excuse to _really_ change (and break) things not to just add a few features, and that a sound and documented internal design cannot be overemphasized. --Matt
participants (4)
-
Bruce Ravel -
Carlo U. Segre -
Matt Newville -
SCHLEGEL Michel 177447