Re: A question about the new Artemis version
As Bruce and Matt already know, I also have been trying to get Artemis to use the same FEFF calculation set for multiple data sets (in my case fewer data sets than Scott but with more paths). I've been taking the 'bite the bullet' approach and re-entering all the path parameters for each sample, but the ability to clone the calculations would help me a lot as well. I came up against two limits. First there is Ifeffit's limit of 256 paths, so I think Scott's student will hit this in the project he described (11 x 25). Matt has kindly sent me a modified version of Ifeffit which should have an increased limit, but I haven't had the chance to test it yet (partly for reasons described below). The second limit is when Artemis checks that there are not more than 256 paths before running a fit. When I tried running one fit I found that Artemis counts all the files that are opened, not just those selected to be included in the fit, but Bruce is fixing this. However, I suspect that Artemis too will have to be modified before it will let you run a fit with more than 256 paths using a modified Ifeffit. This is where Bruce's suggestion of writing a Ifeffit script and then editing with cut & paste (and find & replace) becomes particularly useful. This is quite similar to what I did with Feffit and Ifeffit before I started using Artemis, and works well but is rather time consuming. I understand that an item on Bruce's (very long) 'to do' list is to allow Artemis to open a Ifeffit script into a project - so that once manually modified you could transfer the project back into Artemis. There is another thing to look out for when constructing very large or complex Artemis projects. I have found that very occasionally Artemis will save a project into Bruces' new zip file format, but neglect to actually add in some (or any) of the data and feff files. The first symptom is that the size of the saved project is much smaller than it should be. Thus when re-opened, the project looks fine, but Artemis cannot open any of the required files when a fit is attempted. The data can be replaced, but I can't find a way of replacing any feff calculations without re-entering all of the parameters. Anyway, the purpose of all that is that if you are putting a lot of work into your Artemis project, it may be worthwhile to back it up occasionally, or save under a new name.
P.S. Thanks to Matt and Bruce again for even making such a thing conceivable.
Hear hear Peter Peter Southon Post Doctoral Fellow School of Chemistry University of Sydney NSW 2006, Australia +61 2 9351 4425
On Wednesday 31 March 2004 09:50 pm, Peter Southon wrote:
I have found that very occasionally Artemis will save a project into Bruces' new zip file format, but neglect to actually add in some (or any) of the data and feff files. The first symptom is that the size of the saved project is much smaller than it should be. Thus when re-opened, the project looks fine, but Artemis cannot open any of the required files when a fit is attempted. The data can be replaced, but I can't find a way of replacing any feff calculations without re-entering all of the parameters.
That's news to me. I have not yet seen that problem myself. The next time it happens, if there is a trap file, please send it my way. If you are in that position again, I believe that you can recover without having to reenter all your path parameters. When you finish the feff calculation and you get the dialog about how many paths to import, choose the "No paths" option. You need to run feff again so that the feff data is in the project folder, but you don't need to import paths since you already have a list of them defined. That's the theory, anyway, and the reason for a "no paths" option. If your milage varies, let me know.
Anyway, the purpose of all that is that if you are putting a lot of work into your Artemis project, it may be worthwhile to back it up occasionally, or save under a new name.
I reckon it is impossible to overstate the wisdom of that advice. 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, Sean (my student) just had the same thing happen. It doesn't look like it trapped anything when the problem occurred, but it did fail to create the temporary folders that Artemis keeps the FEFF calculation in while running. Sean came up with a simple fix that seems to have done the trick for us: 1) Point the data files back where they belong. 2) Try to run the fit. Artemis/IFEFFIT will complain (under the "messages" pallet) that it can't find any of your paths, and it will tell you the folder it looked for them in. Note the name of that folder! It will be something like Ifeffit\horae\stash\artemis.project.17\data0.feff1. 3) Create a folder of the appropriate name in the appropriate location. 4) Copy the proper feff files back into it (assuming you have them somewhere else; otherwise rerun FEFF and then copy them in). 5) Save the project and quit Artemis (not sure if you have to run a fit once first). 6) The project should now work normally when you reopen Artemis. Hopefully this also gives Bruce a clue as to what causes the problem. Since those folders are clearly temporary folders used while the project is running, presumably this kind of problem might be caused by a crash at just the wrong moment, perhaps when Artemis was doing some bookkeeping with those folders? --Scott Calvin Sarah Lawrence College At 01:35 PM 4/1/2004 -0500, you wrote:
On Wednesday 31 March 2004 09:50 pm, Peter Southon wrote:
I have found that very occasionally Artemis will save a project into Bruces' new zip file format, but neglect to actually add in some (or any) of the data and feff files. The first symptom is that the size of the saved project is much smaller than it should be. Thus when re-opened, the project looks fine, but Artemis cannot open any of the required files when a fit is attempted. The data can be replaced, but I can't find a way of replacing any feff calculations without re-entering all of the parameters.
That's news to me. I have not yet seen that problem myself. The next time it happens, if there is a trap file, please send it my way.
If you are in that position again, I believe that you can recover without having to reenter all your path parameters. When you finish the feff calculation and you get the dialog about how many paths to import, choose the "No paths" option. You need to run feff again so that the feff data is in the project folder, but you don't need to import paths since you already have a list of them defined.
That's the theory, anyway, and the reason for a "no paths" option. If your milage varies, let me know.
Peter, Scott, Bruce, The latest version of the ifeffit_10.dll windows binary should support 1024 paths, and 16 data sets. You can see what these limits are for your system by typing show &max_paths, &max_data_sets at the command line prompt. The limits are set to their current values so that Ifeffit+Athena takes well under 64Mb RAM. But these limits are set in one place in the source code (src/lib/consts.h) so that you can easily change them and recompile if you need these limits to be higher. max_paths can be increased easily up to 9999, but going above that would take more work. Hope that helps, --Matt
Hi all, A question from person with very limited coding experience (that's me). :) I'd like to compile ifeffit under Windows XP, so I can increase the path limit to 1024. Here's what I've done so far. 1) Downloaded gnu Fortran. It seems to work. 2) Found the consts.h file and changed mpaths to 1024. So what comes next? Can I run the installer scripts somehow, or does that only work under a UNIX-like system? Can I compile just whatever piece I need, since presumably all the supporting stuff is already installed from when I downloaded the binary directly? Thanks to anyone who has advice... --Scott
Peter, Scott, Bruce,
The latest version of the ifeffit_10.dll windows binary should support 1024 paths, and 16 data sets. You can see what these limits are for your system by typing show &max_paths, &max_data_sets
at the command line prompt. The limits are set to their current values so that Ifeffit+Athena takes well under 64Mb RAM. But these limits are set in one place in the source code (src/lib/consts.h) so that you can easily change them and recompile if you need these limits to be higher. max_paths can be increased easily up to 9999, but going above that would take more work.
Hope that helps,
--Matt
Hi Scott, Sorry, your earlier message that &max_paths was 256 in 1.2.5a (which is indeed true!) somehow got lost in the piles of Ifeffit emails. When I wrote earlier that it was 1024, I had increased this on my own machine, but that was after the 1.2.5a release. This 'super-sized' dll has not been included in any updates -- see below. I put a couple versions of ifeffit_10.dll at http://cars.uchicago.edu/ifeffit/src/Win32_dlls/ there's a MPATHS_1024 folder with a dll that has &max_paths set to 1024 (the consts.h used to build is there as well). I should say I _believe_ it has &max_paths set to 1024. I'm not at a windows machine as I post this, so I'm going from time-stamps and from my own memory. Assuming it does, this version of ifeffit_10.dll can be dropped into C:\Program Files\Ifeffit. Please let me know what this reports for &max_paths and how many paths you can verify work! Given the memory problems discussed earlier this week, keeping the standard distribution at 256 paths seems wise. But I should probably make 'supersized' dlls for future releases too (I may need reminding!). Again, it's likely that this larger version will cause the sorts of memory problems discussed last week, and that the Virtual Memory may need to be increased on some machines. --Matt PS Re Compiling on Windows: For what it's worth, I'm currently using Digital Visual Fortran (or whatever it's called now) to build ifeffit_10.dll. I haven't tried using Gnu Fortran on Windows in a while. I probably should look into using Cygwin again for the Windows build, as it would be much closer to the standard unix build, and so probably easier to maintain (at least after some initial work!), and definitely easier for others to mimic. The tricky part is setting up the link with GrWin/PGPLOT. I have not tried that with anything except Compaq Visual Fortran in a very long time, but I understand it can be made to work. Also, Cygwin now includes XFree86 and I wouldn't be surprised if the whole Unix/GNU approach (including PGPLOT for X11 and using the perl source for horae) could be made to work under Cygwin, though it might take some skill with Unix.
Thanks Matt! I'll give it a try... --Scott
Sorry, your earlier message that &max_paths was 256 in 1.2.5a (which is indeed true!) somehow got lost in the piles of Ifeffit emails. When I wrote earlier that it was 1024, I had increased this on my own machine, but that was after the 1.2.5a release. This 'super-sized' dll has not been included in any updates -- see below.
I put a couple versions of ifeffit_10.dll at http://cars.uchicago.edu/ifeffit/src/Win32_dlls/
there's a MPATHS_1024 folder with a dll that has &max_paths set to 1024 (the consts.h used to build is there as well). I should say I _believe_ it has &max_paths set to 1024. I'm not at a windows machine as I post this, so I'm going from time-stamps and from my own memory. Assuming it does, this version of ifeffit_10.dll can be dropped into C:\Program Files\Ifeffit. Please let me know what this reports for &max_paths and how many paths you can verify work!
Given the memory problems discussed earlier this week, keeping the standard distribution at 256 paths seems wise. But I should probably make 'supersized' dlls for future releases too (I may need reminding!). Again, it's likely that this larger version will cause the sorts of memory problems discussed last week, and that the Virtual Memory may need to be increased on some machines.
It works! Thanks again... --Scott Calvin Sarah Lawrence College
Thanks Matt! I'll give it a try...
--Scott
Sorry, your earlier message that &max_paths was 256 in 1.2.5a (which is indeed true!) somehow got lost in the piles of Ifeffit emails. When I wrote earlier that it was 1024, I had increased this on my own machine, but that was after the 1.2.5a release. This 'super-sized' dll has not been included in any updates -- see below.
I put a couple versions of ifeffit_10.dll at http://cars.uchicago.edu/ifeffit/src/Win32_dlls/
there's a MPATHS_1024 folder with a dll that has &max_paths set to 1024 (the consts.h used to build is there as well). I should say I _believe_ it has &max_paths set to 1024. I'm not at a windows machine as I post this, so I'm going from time-stamps and from my own memory. Assuming it does, this version of ifeffit_10.dll can be dropped into C:\Program Files\Ifeffit. Please let me know what this reports for &max_paths and how many paths you can verify work!
participants (5)
-
Bruce Ravel -
Matt Newville -
Peter Southon -
Scott Calvin -
Scott Calvin