Skip to content

mu T calculator #45

Closed
Closed

Description

@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.

Activity

  1. added this to the 3.5.1 release milestone on Nov 15, 2024
  2. yucongalicechen commented on Dec 8, 2024

    @yucongalicechen
    Contributor

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

  3. sbillinge commented on Dec 8, 2024

    @sbillinge
    ContributorAuthor

    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.

  4. yucongalicechen commented on Dec 9, 2024

    @yucongalicechen
    Contributor

    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.

  5. sbillinge commented on Dec 10, 2024

    @sbillinge
    ContributorAuthor

    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.

  6. bobleesj commented on Dec 12, 2024

    @bobleesj
    Contributor

    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.

    Screenshot 2024-12-12 at 2 01 27 PM
  7. yucongalicechen commented on Dec 12, 2024

    @yucongalicechen
    Contributor

    Will do that soon!

  8. yucongalicechen commented on Dec 13, 2024

    @yucongalicechen
    Contributor

    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?

  9. bobleesj commented on Dec 13, 2024

    @bobleesj
    Contributor

    @yucongalicechen Thanks!

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

  10. sbillinge commented on Dec 13, 2024

    @sbillinge
    ContributorAuthor

    @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.

  11. yucongalicechen commented on Dec 13, 2024

    @yucongalicechen
    Contributor

    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.

  12. bobleesj commented on Dec 30, 2024

    @bobleesj
    Contributor

    @yucongalicechen oh! I guess it's 3.6.0 now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions