mu T calculator

[sbillinge]

This is functionality that @yucongalicechen is working on for labpdfproc. The UC is that the user inputs some basic information about the sample and experiment (composition and wavelength) and the program returns a mu (linear absorption coefficient) for the sample.

The idea is to put this functionality into diffpy.utils instead so it could be used by other applications.

Probably in diffpy.utils we want it as a library capability (i.e., not an app with an argparser) the arg.parser would be in labpdfproc, this would just have the lookup tables and the functionality.

It is possible that some of the functionality (if not all) is available elsewhere in which case we could decide whether to include that as a dependency instead of implementing it ourselves.

[yucongalicechen]

@sbillinge In addition to the muD lookup table, shall I move the z-scan file fitting module from labpdfproc to here?

[sbillinge]

I think this issue is to have our own python version of that online tool here so that a user can specify things like composition and density and get the \mu back.

We can then make it available in labpdfproc as an app, but using it from here as a library. Something like that. We may want a small app here too. we can discuss that after it is implemented in labpdfpoc.

I think the approach fitting the measured curve could go here too, but be called in app-form in labpdfproc?. Not sure.

This could go in 3.7 release honestly, except that we want it for your paper, which means it would be good to accelerate it.

[yucongalicechen]

Yes, I agree we can start working on this issue now.

As previously discussed in diffpy/diffpy.labpdfproc#126, I think the UCs can be (@sbillinge please check):

UC1:

1. user places sample on diffractometer
2. diffractometer determines weight and dimensions of the sample
3. diffractometer shares this information with diffpy.utils
4. diffpy.utils computes muD

UC2:

1. same as UC1.1
2. user measures basic chemical info
3. user enters the info to diffpy.utils
4. same as UC1.4

Since labpdfproc requires us to work on args too, would it be easier if we first implement the lookup tables here?

Also, we already have implemented the convolutional fitting model in labpdfproc: https://github.com/diffpy/diffpy.labpdfproc/blob/main/src/diffpy/labpdfproc/mud_calculator.py. I can move these codes to diffpyutils here if we want.

[sbillinge]

Sounds good. I like those UCs. Let's put UC2 on this PR. UC1 in the future (needs an interface to hardware....more advanced).

For implementation (which is different than UC), let's have a lookup table somewhere here in diffpy.utils. Look in periodic_table which I think is somewhere in diffpy, to figure out how we handle lookup tables (they go in some kind of static directory) .

Then we want functions that take inputs and do the calcs and return them here.

Then in labpdfproc we would like an app that reads things from the command line (or gooey), calls the functions from here, and goes on its merry way. Its tricky in gooey but we may be able to do one layer of conditional logic, to support a gooey uc like this:

UC3a

1. user selects "compute muD from known density" radio button
2. labpdfproc.mudCalc presents a form pre-filled with defaults containing fields for user to enter mass density in g/cm^3, composition (e.g. ZrO2), wavelength(angstroms), D (mm). Defaults are <Till's zirconia number>, , , 1.
3. user enters the other info (browses for files etc.)
4. user hits start
5. code runs.

UC3b - user has muD

1. user selects "enter muD manually"
2. mudCalc presents a box to type in a float "muD value"
3. as UC3a 3-end

UC3c - user doesn't know density

1. user selects "estimate muD from composition"
2. labpdfproc.mudCalc presents a form pre-filled with defaults containing fields for user to enter powder fraction (number between 0 and 1), composition (e.g. ZrO2), wavelength(angstroms), D (mm). Defaults are 0.5, , , 1. program assumes some reasonable atomic number density by default, since this is not known or given in principle.
3. as UC3a 3-end

UC4

1. as UC3a.1-2
2. user clicks run calc
3. lpp.mudCalc returns the calculated value as output without running the cve calc.

We may want to support UC4 in diffpy.utils. Please could you make an issue for that that we can decide on later.

Implementationally, one way to handle 3a-c in lpp might be that it is not conditional but depending on which fields are filled vs empty different logic is run. It means that some defaults would have to be None.

Not sure if these UCs are quite right, but something along these lines. Till and Filippo could have useful input here.

[bobleesj]

We may want to support UC4 in diffpy.utils. Please could you make an issue for that that we can decide on later.

@yucongalicechen Could you please make an issue?

It would be good to provide a quick overview (maybe a checklist like UC3, UC4, etc.) and use Reference in new issue functionality to refer back to the original post.

[yucongalicechen]

Will do that soon!

[yucongalicechen]

I added new issues: UC1 (#218), UC3 (diffpy/diffpy.labpdfproc#143), UC4 (#220), add periodic table (#219).
@sbillinge Just to clarify, is UC4 the convolutional fitting?

[bobleesj]

@yucongalicechen Thanks!

@sbillinge For these issues, could you pls assign these new issues under 3.6.0 or 3.7.0?

[sbillinge]

@bobleesj @yucongalicechen I moved these to 3.7.0. They are needed for Yucong's paper so it is ok to work on them and finish them sooner, but let's not have them blocking 3.6.0.

[yucongalicechen]

Okay, I reorganized the issues. UC1 (diffpy/diffpy.labpdfproc#144), UC3-4 (diffpy/diffpy.labpdfproc#143), mu lookup table (#219). Will work on this issue (UC2) first.