rename variables in mud_calculator.py and write more informative docstring#146
rename variables in mud_calculator.py and write more informative docstring#146sbillinge merged 5 commits intodiffpy:mainfrom
mud_calculator.py and write more informative docstring#146Conversation
|
|
||
|
|
||
| def _top_hat(x, slit_width): | ||
| def _top_hat(x, half_slit_width): |
There was a problem hiding this comment.
change slit_width to half_slit_width to avoid confusion
|
|
||
| This function loads z-scan data and fits it to a model | ||
| that convolves a top-hat function with I = I0 * e^{-mu * l}. | ||
| The fitting procedure is run multiple times, and we return the best-fit parameters based on the lowest rmse. |
There was a problem hiding this comment.
add description to docstring
There was a problem hiding this comment.
add a reference to your paper.
Also, I wonder if we should move this function out to diffpy.utils.tools?
| """ | ||
| x_data, I_data = loadData(filepath, unpack=True) | ||
| best_mud, _ = min((_compute_single_mud(x_data, I_data) for _ in range(10)), key=lambda pair: pair[1]) | ||
| best_mud, _ = min((_compute_single_mud(x_data, I_data) for _ in range(20)), key=lambda pair: pair[1]) |
There was a problem hiding this comment.
change number of loops from 10 to 20
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #146 +/- ##
=======================================
Coverage 99.31% 99.31%
=======================================
Files 6 6
Lines 293 293
=======================================
Hits 291 291
Misses 2 2
|
sbillinge
left a comment
There was a problem hiding this comment.
please see inline comments. Since we have the theoretical mu calculator in diffpy.utils, I wonder whether we should move the z-scan mu calculator there too?
|
|
||
|
|
||
| def _extend_x_and_convolve(x, diameter, slit_width, x0, I0, mud, slope): | ||
| def _extend_x_and_convolve(x, diameter, half_slit_width, x0, I0, mud, slope): |
There was a problem hiding this comment.
I think these x's should be z's right?
|
|
||
| This function loads z-scan data and fits it to a model | ||
| that convolves a top-hat function with I = I0 * e^{-mu * l}. | ||
| The fitting procedure is run multiple times, and we return the best-fit parameters based on the lowest rmse. |
There was a problem hiding this comment.
add a reference to your paper.
Also, I wonder if we should move this function out to diffpy.utils.tools?
|
Yeah we can move it - I think this'll be more convenient. Shall I move it under tools or should we add a new module for these two functions? |
Let's put them in tools for now. They are "tools". We can break them out later if we want. |
|
Let's finish this PR and merge it, then make another PR that moves it out, which is just a cut and paste. |
|
@sbillinge ready for review |
|
|
||
|
|
||
| def _top_hat(x, slit_width): | ||
| def _top_hat(z, half_slit_width): |
There was a problem hiding this comment.
change all x to z
| min_radius = -diameter / 2 | ||
| max_radius = diameter / 2 | ||
| h = x - x0 | ||
| x = z - z0 |
There was a problem hiding this comment.
change h to x to avoid confusion, since we used h as full slit width in the paper
There was a problem hiding this comment.
please see my comment above. We shouldn't use x here. For ease of reading the code, we could just leave it everywhere as (z-z0). This is how it is in the paper I think. If we want to define a new variable it would be better to call it dz, delta_z or z_s or something like that?
| The full mathematical details are described in the paper: | ||
| An ad hoc Absorption Correction for Reliable Pair-Distribution Functions from Low Energy x-ray Sources, | ||
| Yucong Chen, Till Schertenleib, Andrew Yang, Pascal Schouwink, Wendy L. Queen and Simon J. L. Billinge, | ||
| in preparation. |
There was a problem hiding this comment.
add reference
sbillinge
left a comment
There was a problem hiding this comment.
much better. A couple of more comments.
| compute the model function with the following steps: | ||
| 1. Recenter x to h by subtracting x0 (so that the circle is centered at 0 and it is easier to compute length l) | ||
| Compute the model function with the following steps: | ||
| 1. Recenter z to x by subtracting z0 (so that the circle is centered at 0 and it is easier to compute length l) |
There was a problem hiding this comment.
I don't think we are using x correctly here either, right? In the paper, z is the vertical direction centered on the center of the beam. x is the direction of the x-ray beam. We didn't define an x0 (and don't need to) but it could be something like the center of the sample. So I am not sure that it makes sense to say "recentering z to x..."
There was a problem hiding this comment.
Yes I will change x to dz and change this docstring here
| min_radius = -diameter / 2 | ||
| max_radius = diameter / 2 | ||
| h = x - x0 | ||
| x = z - z0 |
There was a problem hiding this comment.
please see my comment above. We shouldn't use x here. For ease of reading the code, we could just leave it everywhere as (z-z0). This is how it is in the paper I think. If we want to define a new variable it would be better to call it dz, delta_z or z_s or something like that?
| expected_mud = 3 | ||
| actual_mud = compute_mud(file) | ||
| assert actual_mud == pytest.approx(expected_mud, rel=1e-4, abs=0.1) | ||
| assert actual_mud == pytest.approx(expected_mud, rel=0.01, abs=0.1) |
There was a problem hiding this comment.
is there a reason you are making this so loose? In general, it doesn't give me huge confidence if we need it to be so loose t pass tests....
General comments for PRs, while there is an issue connected, could you pls also make titles more descriptive so that I (co-maintainers) can later identify the PR for debugging/understanding by scrolling? I like using gh CLI and great titles are great. (meant to write this comment in diffpy.utils below) |
|
I will merge this, but @yucongalicechen maybe we could edit the title of the closed PR. Since we are working on "best practices" let's do that. A good thing would be for you two to figure out what the best title would be for future maintainers... So we can learn best practices for docstring titles... |
mud_calculator.pymud_calculator.py and write more informative docstring
closes #122
@sbillinge ready for review. This PR is just some small edit in functions and docstring.