Hi, Here's a feff6 curiosity. Take this atoms.inp file: title = TiN space = 225 a = 4.24173 b = 4.24173 c = 4.24173 core = Ti edge = K rmax = 7.0 atoms ! elem x y z Ti 0.00000 0.00000 0.00000 N 0.50000 0.50000 0.50000 Run atoms, then run feff6l (the one that comes with Ifeffit, it's the only version I've tried this with). Feff ends with this error message: Eliminating path degeneracies... Plane wave chi amplitude filter 2.50% np, np1x= 12001 12000 Fatal Error: at PATHSD: np > np1x This message comes from pathsd.f, but I don't understand either the message or the part of the code it comes from. Does anyone else have a hint as to the problem? One more datum. If you reduce rmax to 6.7 in the atoms.inp file, the problme persists. If you make rmax 6.6, feff6l is happy. Thanks, B -- Bruce Ravel ----------------------------------- bravel@anl.gov -or- ravel@phys.washington.edu Environmental Research Division, Building 203, Room E-165 Argonne National Laboratory phone: (1) 630 252 5033 Argonne IL 60439, USA fax: (1) 630 252 9793 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
[Ifeffit] odd feff6 behaviorBruce, I checked that the same problem existed for the original FEFF601.f fortran file in UNIX. I looked for the string "np > np1x" and found that the code stops when this condition is true. np1x is a fixed parameter defined in the code as parameter (np1x = 12000). When np (the paths counter) becomes 12001 (it is incremented in the code as the paths are counted), the code stops. Apparently, for this structure it happens for rmax exceeds 6.6 . When rmax = 6.6, the number of paths is less than 12000, and the code does not stop. I do not know why 12000 was chosen as a threshold... we can ask Alex.Therefore, if you have access to the feff6 source that is used in IFEFFIT (I assume you do), you can increase the np1x and recompile. Regards, Anatoly ****************** Anatoly Frenkel, Ph.D. Associate Professor Physics Department Yeshiva University 245 Lexington Avenue New York, NY 10016 (YU) 212-340-7827 (BNL) 631-344-3013 (Fax) 212-340-7788 anatoly.frenkel@yu.edu http://www.yu.edu/faculty/afrenkel -----Original Message----- From: ifeffit-bounces@millenia.cars.aps.anl.gov [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov]On Behalf Of Bruce Ravel Sent: Friday, June 10, 2005 3:43 PM To: XAFS Analysis using Ifeffit Subject: [Ifeffit] odd feff6 behavior Hi, Here's a feff6 curiosity. Take this atoms.inp file: title = TiN space = 225 a = 4.24173 b = 4.24173 c = 4.24173 core = Ti edge = K rmax = 7.0 atoms ! elem x y z Ti 0.00000 0.00000 0.00000 N 0.50000 0.50000 0.50000 Run atoms, then run feff6l (the one that comes with Ifeffit, it's the only version I've tried this with). Feff ends with this error message: Eliminating path degeneracies... Plane wave chi amplitude filter 2.50% np, np1x= 12001 12000 Fatal Error: at PATHSD: np > np1x This message comes from pathsd.f, but I don't understand either the message or the part of the code it comes from. Does anyone else have a hint as to the problem? One more datum. If you reduce rmax to 6.7 in the atoms.inp file, the problme persists. If you make rmax 6.6, feff6l is happy. Thanks, B -- Bruce Ravel ----------------------------------- bravel@anl.gov -or- ravel@phys.washington.edu Environmental Research Division, Building 203, Room E-165 Argonne National Laboratory phone: (1) 630 252 5033 Argonne IL 60439, USA fax: (1) 630 252 9793 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/ _______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Anatoly and Bruce: What value would you recommend for nplx? Carlo On Fri, 10 Jun 2005, Anatoly Frenkel wrote:
[Ifeffit] odd feff6 behaviorBruce,
I checked that the same problem existed for the original FEFF601.f fortran file in UNIX. I looked for the string "np > np1x" and found that the code stops when this condition is true. np1x is a fixed parameter defined in the code as parameter (np1x = 12000). When np (the paths counter) becomes 12001 (it is incremented in the code as the paths are counted), the code stops. Apparently, for this structure it happens for rmax exceeds 6.6 . When rmax = 6.6, the number of paths is less than 12000, and the code does not stop. I do not know why 12000 was chosen as a threshold... we can ask Alex.Therefore, if you have access to the feff6 source that is used in IFEFFIT (I assume you do), you can increase the np1x and recompile. Regards,
Anatoly
****************** Anatoly Frenkel, Ph.D. Associate Professor Physics Department Yeshiva University 245 Lexington Avenue New York, NY 10016
(YU) 212-340-7827 (BNL) 631-344-3013 (Fax) 212-340-7788
anatoly.frenkel@yu.edu http://www.yu.edu/faculty/afrenkel
-----Original Message----- From: ifeffit-bounces@millenia.cars.aps.anl.gov [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov]On Behalf Of Bruce Ravel Sent: Friday, June 10, 2005 3:43 PM To: XAFS Analysis using Ifeffit Subject: [Ifeffit] odd feff6 behavior
Hi,
Here's a feff6 curiosity. Take this atoms.inp file:
title = TiN space = 225 a = 4.24173 b = 4.24173 c = 4.24173 core = Ti edge = K rmax = 7.0 atoms ! elem x y z Ti 0.00000 0.00000 0.00000 N 0.50000 0.50000 0.50000
Run atoms, then run feff6l (the one that comes with Ifeffit, it's the only version I've tried this with). Feff ends with this error message: Eliminating path degeneracies... Plane wave chi amplitude filter 2.50% np, np1x= 12001 12000 Fatal Error: at PATHSD: np > np1x
This message comes from pathsd.f, but I don't understand either the message or the part of the code it comes from. Does anyone else have a hint as to the problem?
One more datum. If you reduce rmax to 6.7 in the atoms.inp file, the problme persists. If you make rmax 6.6, feff6l is happy.
Thanks, B
-- Bruce Ravel ----------------------------------- bravel@anl.gov -or-
ravel@phys.washington.edu Environmental Research Division, Building 203, Room E-165 Argonne National Laboratory phone: (1) 630 252 5033 Argonne IL 60439, USA fax: (1) 630 252 9793
My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
_______________________________________________ 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
Hi Anatoly, Bruce, Carlo, Anatoly is right on the meaning of the "np > np1x" message. It would be trivial to increase this. There are 4 integer arrays and 1 double precision arrays with this dimension. Increasing this to 40000 would add less than a megabyte of memory. Anyone remember when adding a megabyte here or there was a legitimate concern? It would probably let you go beyond 7 Ang in nearly any structure. Since feff6l is intended for EXAFS analysis (and only EXAFS analysis), that seems perfectly reasonable to me. But: I think the real problem ist that feff6l stops completely with a cryptic Fatal Error message when it exceeds np1x paths (even Bruce couldn't decipher it!?!). Of course, it may have to stop enumerating paths at some point, but it should continue on to GENFMT if runs out of memory for the paths. I'll try to make both changes for the next release, and look for other silly 'Fatal Error' messages that could be warnings. --Matt
On Friday 10 June 2005 18:32, Matt Newville wrote:
But: I think the real problem ist that feff6l stops completely with a cryptic Fatal Error message when it exceeds np1x paths (even Bruce couldn't decipher it!?!).
Thank you, Matt, for understanding the point of my question. I can, after all, read Fortran just as well as Anatoly. The issues are (1) the error message conveyed no information and (2) the code is uncommented and so failed to convey clear information. What is np1x? Why is it set to it's value? What the purpose of the test being done at that point in pathsd.f? The input data I used was not unusual, so what was it about the situation I posted that triggered the problem? Why haven't we seen that warning a million times before? I am still at least a bit interested in some better answers than what I was able to glean from the error message, the code, or any of the posts in response to my question. B -- Bruce Ravel ----------------------------------- bravel@anl.gov -or- ravel@phys.washington.edu Environmental Research Division, Building 203, Room E-165 Argonne National Laboratory phone and voice mail: (1) 630 252 5033 Argonne IL 60439, USA fax: (1) 630 252 9793 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Hi Bruce, I agree 100% with your sentiments. The problem you had was with Feff's design (especially that it stopped when it could have gone on). Feff is not particularly amenable to running as a "module" or embedded in another program. Even as a standalone executable run in "batch mode", Feff isn't very good at at giving meaningful error messages to the user. Fortunately, we can change the source code for Feff6, even if it is not necessarily easy to do so. I've made several changes to Feff6 already, and am willing to make more. So far, no one else has volunteered to take this on. As a relevent example, there are currently more than 50 places where feff6 may end execution because of an error (fortran 'stop'). Right now, Ifeffit only does this on reading a corrupted PAD-format data file, which aren't used with artemis/athena. Ideally, all of these could be replaced with "write meaningful message, and go on as best as you can". I'm not sure how easy that will be. --Matt
participants (4)
-
Anatoly Frenkel -
Bruce Ravel -
Carlo Segre -
Matt Newville