xraypy / xraylarch

Larch: Applications and Python Library for Data Analysis of X-ray Absorption Spectroscopy (XAS, XANES, XAFS, EXAFS), X-ray Fluorescence (XRF) Spectroscopy and Imaging, and more.
https://xraypy.github.io/xraylarch
Other
132 stars 63 forks source link

Feature request: xraylarch on Apple M1 #365

Open pjf295 opened 2 years ago

pjf295 commented 2 years ago

Hi Matt. I am grateful for your work on xraylarch. Since Apple is moving towards using its own cpus (M1), I am curious as to what the possibilities are of getting xraylarch to work on the M1. As I recall, you commented in January that you were waiting for a M1 laptop to arrive so I presume you are thinking of trying to get xraylarch to work on the M1 as well. What is the status/plans for such an addition. I am thinking of purchasing a new M1 based system for my laboratory so the effort would be greatly appreciated.

newville commented 2 years ago

@pjf295 Hi Paul, great to hear from you. The good news is that M1Max (late 2021) did finally arrive in early March, and I was happy to see that existing built-for-Intel binaries and libraries do run. So, Larch including the intel-built versions for Feff executables and libraries do run on M1Max.

The bad news is that a first attempt to use native gfortran/gcc/clang 11 on M1 does succeed in building Feff8 (https://github.com/xraypy/feff85exafs, okay with a tweak or two) but that fails to run correctly to pass any tests -- feffNNNN.dat files are not generated. I have not yet had time to investigate (like, does gcc11 work to build Feff85 on Linux? New Fortran2018 warnings should be addressed - are those fatal?) beyond observing that Feff thinks that all the paths are "unimportant".

It's on the ToDo list, but since the intel-built versions run (maybe not optimally?), it doesn't seem like today's emergency ;).

pjf295 commented 2 years ago

Hi Matt, I sent this note to the ifeffit mailing list, but I just realized I am not a subscriber currently so I thought I would send a copy to you in parallel.

Hi. Due to the difficulties of getting demeter to work on the Apple M1 machines, I have started to use xraylarch and so far I like the interface as well as the possibility of scripting later on. I had a couple of observations and a question regarding xraylarch usage that I hope could be addressed here.

First, one can load multiple spectra into the (feff) fitting window. It seems, however, that which paths are selected are universal (the selected paths are used for all exafs spectra). Does this mean that multiple edge fitting is not possible. If multiple edge fitting is possible, how is it done? In the fitting window, one can have several spectra loaded and one can select all or some of the spectra to be fit. The interface seems like it was designed for multiple edge fitting, but is it?

Second, it is strange that whenever a parameter is changed that the fitting variable settings (fixed, vary, constrain) are reset. For complex fits, this generates a lot of unnecessary clicking (and the corresponding mistake possibilities)

Third, when one reads in several different feff calculations, one would, in principle, like to have a different value of e0 (the origin of energy offset) for each feff calculation. By default when a feff calculation is read in the variable e0 is defined. When one defines alternative energy offset variables for the different feff calculations and deletes the original e0 value, something strange happens. Accessing the “Edit Parameters” window results in e0 reappearing (even though it has been manually deleted previously). Is this a feature? The same thing may happen for other “automatic” variables as well.

Four. This is really a feature request. When a variable is unused (lets say some additional paths are introduced in the fitting process and a new fit without them is attempted), the choices in the parameter list are (fix, vary, and constrain). There is no option to “skip” like in Artemis. Obviously, one can choose fix, but in doing so the unused variable shows up in the fit result summary and is somewhat confusing. It would be subjectively better to have the option to “skip” a variable and not have it show up in the fit summary.

Just some initial thoughts...

newville commented 2 years ago

Hi Paul,

Thanks for the comments, great to hear from you, and hope you are doing well!

0: Yeah, XAS Viewer as a replacement for Athena and Artemis is heavily inspired by "I need it to run on a Mac"!

1: Yes, currently (and maybe for a while yet), the XAS Viewer GUI only supports fitting 1 data set at a time. My view is kind of that "scripts for complex stuff" are not too hard and also are not unreasonable. But also, fitting 1 data set at a time is just more complicated and harder to expose as a GUI. Suggestions welcome!

  1. I think this can be made more sane -- and I think it might be already in devel versions. But also (and from recent short course and summer school too): yeah, using >8 paths and using many variables is a work in progress.

  2. a) yes it does look like a bug that it insists on have Parameters named "e0" and "s02". Will investigate. And

  3. b) In fact, it would probably be reasonable to read the "Vint" value from the feffNNNN.dat file and use "E0 Path Parameter = vint + e0_feff_run". vint could even be (like Reff) a per-path variable, and the variable for E0 could be (by default) the same for all paths from a single Feff run, but different for different Feff runs. It would interesting to know (but I think there isn't enough clear results) to know whether the value of per-feff-run vint was enough to make the e0 variables really be independent of Feff run.

  4. Another good point: Skip is a good option to have. On the To Do list.

pjf295 commented 2 years ago

Hi Matt,

It is great to hear from you. I really appreciate your efforts with x-ray larch. I think the current interface is pretty close to being useable for multiple edges. I would propose that each experimental data set that is selectable in the left hand side bar of the fitting window have its own set of paths associated with it (e.g. selecting a different data set would result in the tabs containing the paths changing to those that were loaded for the path). The chi^2 values for these data sets would then be added to the fit.

I also realize that this enhancement is probably not going to happen soon as I am sure you have plenty of things to do! I was curious if you had some example scripts of double edge fitting that you could pass along. I have always been curious to have the ability to write a script for fitting and it may be a good excuse to put that curiosity to work. On the other hand, a GUI that allows two edge fitting would be easy to teach four year students how to use…

Changing subjects to a completely different issue, I know demeter has more or less dead on the Mac for a while due to ifeffit issues, but I thought it would be easier to install on my computing cluster running CentOS 7. On the CentOS system, ifeffit compiles without problem, however, there appear to be numerous perl library dependencies (literally more than 100) some of which fail their tests in the script Bruce has included. Do you know if anyone has successfully installed demeter on CentOS? I know this is not your code, so I was just curious if you had installed it for your users on linux before.

Cheers, Paul

On Aug 5, 2022, at 13:01, Matt Newville @.***> wrote:

Hi Paul,

Thanks for the comments, great to hear from you, and hope you are doing well!

0: Yeah, XAS Viewer as a replacement for Athena and Artemis is heavily inspired by "I need it to run on a Mac"!

1: Yes, currently (and maybe for a while yet), the XAS Viewer GUI only supports fitting 1 data set at a time. My view is kind of that "scripts for complex stuff" are not too hard and also are not unreasonable. But also, fitting 1 data set at a time is just more complicated and harder to expose as a GUI. Suggestions welcome!

I think this can be made more sane -- and I think it might be already in devel versions. But also (and from recent short course and summer school too): yeah, using >8 paths and using many variables is a work in progress.

a) yes it does look like a bug that it insists on have Parameters named "e0" and "s02". Will investigate. And

b) In fact, it would probably be reasonable to read the "Vint" value from the feffNNNN.dat file and use "E0 Path Parameter = vint + e0_feff_run". vint could even be (like Reff) a per-path variable, and the variable for E0 could be (by default) the same for all paths from a single Feff run, but different for different Feff runs. It would interesting to know (but I think there isn't enough clear results) to know whether the value of per-feff-run vint was enough to make the e0 variables really be independent of Feff run.

Another good point: Skip is a good option to have. On the To Do list.

— Reply to this email directly, view it on GitHub https://github.com/xraypy/xraylarch/issues/365#issuecomment-1206016527, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQT5S3FPOWDDSOM6GL6I6ODVXSGZTANCNFSM5SYAOQ7A. You are receiving this because you were mentioned.

newville commented 2 years ago

@pjf295

It is great to hear from you. I really appreciate your efforts with x-ray larch. I think the current interface is pretty close to being useable for multiple edges. I would propose that each experimental data set that is selectable in the left hand side bar of the fitting window have its own set of paths associated with it (e.g. selecting a different data set would result in the tabs containing the paths changing to those that were loaded for the path). The chi^2 values for these data sets would then be added to the fit.

Yes, that could work. For multi-edge fitting in the GUI, it is mostly a matter of exposing the set of paths for the different data sets. So, it is sort of a "presentation" problem, and also sort of a question of priority ;).

I also realize that this enhancement is probably not going to happen soon as I am sure you have plenty of things to do! I was curious if you had some example scripts of double edge fitting that you could pass along. I have always been curious to have the ability to write a script for fitting and it may be a good excuse to put that curiosity to work. On the other hand, a GUI that allows two edge fitting would be easy to teach four year students how to use…

Yes. A simple example (Cu at 3 temperatures, 1 shell for each dataset) is at https://github.com/xraypy/xraylarch/blob/master/examples/feffit/doc_feffit3.lar

This probably needs better documentation, and also (as I look at it now) be better translatable into "plain Python".

For a single fit with XAS Viewer, the "results page" can show a "Larch script", which will be a bit more verbose (with lots of possible processing steps commented out), and probably somewhat harder to read. But the idea is that this can be used as a starting script.

For multi-dataset fits, each "fefffit data set" has a set (Group) of chi(k) data, a list of Feff Paths, and Feffit Transform object that describes FT parameters and fit ranges. The feffit() command takes a Group of fitting Parameters, and a list of these "feffit data sets". It probably all needs better documentation and more examples...

Changing subjects to a completely different issue, I know demeter has more or less dead on the Mac for a while due to ifeffit issues, but I thought it would be easier to install on my computing cluster running CentOS 7. On the CentOS system, ifeffit compiles without problem, however, there appear to be numerous perl library dependencies (literally more than 100) some of which fail their tests in the script Bruce has included. Do you know if anyone has successfully installed demeter on CentOS? I know this is not your code, so I was just curious if you had installed it for your users on linux before.

Yes, I have had trouble with demeter on Fedora/CentOS for a while too. I think I submitted a PDL patch at one point, but that most of the scientific packages eventually worked. I don't recall if that was limited to specific Fedora/CentOS versions, or specific Perl versions. But in the end, this also basically got stuck on wxPerl. I have not tried in a year or more. I think it must still run on some Ubuntu/Debian variants, though perhaps these have older OS/gtk/Perl.

I think it really comes down to the fact that wxPerl (and demeter!) have not really had bug-fix releases in 5 years.