Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests does not work for tdl / modules / xrf / xrf_peaks.py #23

Open
belegnar opened this issue Mar 10, 2013 · 4 comments
Open

Tests does not work for tdl / modules / xrf / xrf_peaks.py #23

belegnar opened this issue Mar 10, 2013 · 4 comments

Comments

@belegnar
Copy link

$ python xrf_peaks.py 
Traceback (most recent call last):
  File "xrf_peaks.py", line 1051, in <module>
    test_fit()
  File "xrf_peaks.py", line 1009, in test_fit
    import _test_dat as test_dat
ImportError: No module named _test_dat
@ttrainor
Copy link
Member

Try the following: xrf_peaks.py line 1009 should be changed to read:

from tdl.modules.xrf import _test_dat as test_dat

By the way, we still need to change this to use lsq routine from scipy, current mpfit is VERY slow. I believe Matt is working on this in larch, which has very good built in fitting capabilties....

@newville
Copy link
Member

In fact, just today, I made some progress on XRF analysis with Larch. It now reads XRF spectra from MCA files much, much better, and can do a classic XRF background fit.

I've started looking at the xrf_model.py and xrf_peaks.py code, and these will be a little more work. Well, I have the emission line energies included already, so the lookup code is different.

I'd really like to to get rid of the tricks used for 'energy_flag', 'fwhm_flag' and even 'ampl_factor'. There should be a 'adjust_energy_scale=True'. For the FWHM trick, I'll have a flag to help set that the width should go as "A + B*sqrt(E)", but for the amplitudes, this will be much more robust if one just uses an algebraic constraint. In short, each XRF Peak will allow more fine-grained definition. And, the fitting will be faster and parameter bounds will be more robust....

It could take a while, but I'm trying to get a better XRF Viewer for our maps, so this is a good time to work through this.

@ttrainor
Copy link
Member

Awesome, thanks Matt. Yeah, I agree getting rid of some of the flags will make it much more user friendly...

@belegnar
Copy link
Author

i've found that line 1009 should be

import _test_data as test_dat

but anyway there are a lot of other errors. it looks like function calls were refactored to dictionaries in params, but test code was not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants