-
Notifications
You must be signed in to change notification settings - Fork 10
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
Migdal cox model #17
base: master
Are you sure you want to change the base?
Migdal cox model #17
Conversation
Cox's package relies on relative paths to run. It assumes the main Python process is running in its root dir. This wrapper runs the necessary methods within the root of the submodule and then moves the working dir back to the original one. It returns a configured instance of the Migdal class from the submodule for which the probabilities and total probabilities have already been computed.
Refactored the code so that the Migdal model can be selected using a simple keyword argument. Examples will be prepared in the notebooks/ dir. Two tests have been added: - One for Cox's full model for single ionization rates - One for Cox's model using dipole approximation
This reverts commit 8bde989.
This reverts commit e0d51d4.
Without it, pytests do not recognise wimprates.data.migdal.Cox modules
Ok, I'm removing every instance of |
Can we still require |
Cox's package relies on relative paths to run. It assumes the main Python process is running in its root dir. This wrapper runs the necessary methods within the root of the submodule and then moves the working dir back to the original one. It returns a configured instance of the Migdal class from the submodule for which the probabilities and total probabilities have already been computed.
Refactored the code so that the Migdal model can be selected using a simple keyword argument. Examples will be prepared in the notebooks/ dir. Two tests have been added: - One for Cox's full model for single ionization rates - One for Cox's model using dipole approximation
This reverts commit 8bde989.
This reverts commit e0d51d4.
Without it, pytests do not recognise wimprates.data.migdal.Cox modules
This reverts commit 180e391. These commits have been cherry-picked from another branch.
This reverts commit d2b44da.
This reverts commit a7c2e0d.
This reverts commit c1d26c0.
This reverts commit df7d904.
…to migdal_cox_model
I just rebased this branch onto master (locally) to apply the changes to the CI/CD |
Hello,
This PR introduces a further Migdal effect implementation based on a recent paper by Peter Cox et al.
The two model that are now implemented are the one by Ibe et al (Ibe) and the one by Cox et al (Cox).
While Ibe was explicitly implemented in the
wimprates/migdal.py
module using data files in thewimprates/data/
directory, Cox provides a python module that prepares a wide variety of interpolators for computing differential probabilities of different modes of the Migdal effect. In his paper, Cox does not use the dipole approximation to limit the calculations to the single ionisation case, but expands his calculations to second ionisation/excitation (and higher) and considers cases at higher energies than the ones concerning WIMP-nucleus scattering. Nonetheless, the paper by Cox shows that, at the energies of interest for DM-nucleus scattering, single ionisation is the only relevant case, and that the dipole approximation performed by Ibe is valid.As this package is called
wimprates
I only took the interpolators for single Migdal ionisation from his module to compute Migdal rates for WIMP-nucleus scattering. To compute scattering between neutrons and nuclei, other interpolators among the ones he proposes will be necessary.Since the repository by Cox is not structured to be a Python package, I could not use it as a requirement for the installation of
wimprates
(by adding it torequirements.txt
, for instance). I instead added it as a git submodule and checked out the v1.0.0 tag.The Migdal.py module implemented by Cox assumes the python process is running in the root dir of the repo. To solve this issue I wrote a wrapper function around the submodule.
In the main
__init__.py
file ofwimprates
, I import the wrapper function to use withinwimprates/migdal.py
.Within
wimprates/migdal.py
, I implemented theShell
class (maybe the name should be changed to Orbital, or something more accurate) which is a dataclass containing the quantum numbers of an orbital, the binding energy relative to the orbita, and an attribute to hold the interpolator that computes the single ionisation probability from the chosen model (Ibe, Cox, or Cox+dipole approximation).This class was created so that the code for the rest of the module could be written more linearly, without having to resort to repetitive if-else-statements, and to make the module as model-independent as possible (especially in case other models arise in the future).
Keeping both models available and having the ability to switch from one to the other by changing just a single argument is useful for comparison studies.
The function that was previously implemented for obtaining the Migdal transition probabilities from Ibe's data files has been deprecated, but left in the file. It can still be used but a "deprecated" warning will be raised upon its use.
I have done my best to maintain the procedural structure of this package, but my OOP mind struggled a bit 😅 Please let me know if you prefer I changed the strucutre of my code to better match the rest of the package.
I also updated the MIgdal.ipynb notebook to showcase the new features. The plot showing the comparison between the Ibe differential rate and the one obtained by the LUX collaboration shows some discrepancy after running... I have yet to understand why, but I'm pretty sure it's not due to anything I have introduced as it also happens upon rerunning the notebook using wimprates==v0.5.0.
The extra package that was added to
requirements.txt
(importlib_metadata
) is needed by Cox's submodule.Finally, I added a
pyproject.toml
file as recoomended by this guide and added typing information to the migdal.py module; the implementation requires the use ofpython>=3.11
. If you'd rather I remove this requirement, I can reduce the amount of typing I've introduced.