You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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
user selects "compute muD from known density" radio button
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.
user enters the other info (browses for files etc.)
user hits start
code runs.
UC3b - user has muD
user selects "enter muD manually"
mudCalc presents a box to type in a float "muD value"
as UC3a 3-end
UC3c - user doesn't know density
user selects "estimate muD from composition"
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.
as UC3a 3-end
UC4
as UC3a.1-2
user clicks run calc
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.
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.
@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.
Activity
yucongalicechen commentedon Dec 8, 2024
@sbillinge In addition to the muD lookup table, shall I move the z-scan file fitting module from labpdfproc to here?
sbillinge commentedon Dec 8, 2024
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 commentedon Dec 9, 2024
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:
UC2:
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 commentedon Dec 10, 2024
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_tablewhich 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
UC3b - user has muD
UC3c - user doesn't know density
UC4
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 commentedon Dec 12, 2024
@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 issuefunctionality to refer back to the original post.yucongalicechen commentedon Dec 12, 2024
Will do that soon!
yucongalicechen commentedon Dec 13, 2024
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 commentedon Dec 13, 2024
@yucongalicechen Thanks!
@sbillinge For these issues, could you pls assign these new issues under 3.6.0 or 3.7.0?
sbillinge commentedon Dec 13, 2024
@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 commentedon Dec 13, 2024
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.
bobleesj commentedon Dec 30, 2024
@yucongalicechen oh! I guess it's 3.6.0 now!