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
As discussed with @dddijulio and @XuShuqi7, we should support primary extinction correction to Bragg diffraction by adopting the model by Sabine:
The flow of radiation in a real crystal
T. M. Sabine. International Tables for Crystallography (2006). Vol. C, ch. 6.4, pp. 609-616 [ doi:10.1107/97809553602060000603 ]
There is only one free parameter, the crystallite (mosaic block) size (D), although one could of course also consider supporting a spread in these (not initially).
One thing is that the Darwin-Hamilton equation solved without the paper also needs a ${\mu}{\cdot}\texttt{D}$ correction where $\mu$ is the "absorption" attributed to everything except Bragg diffraction.
It is possible to simply assume ${\mu}{\cdot}\texttt{D}<<1$ and thus implement the model with $\mu=0$. However, at least for validation purposes it might be nice to support a proper $\mu$, which of course means that the factory code must be able to initialise Scatter objects for inelas/incoh_elas/... and also Absorption. However, this is super tricky, since we don't know if e.g. an `";inelas=0" in the cfgstring is there because the user would like to truly emulate the absence of inelastic scattering (so inelas SHOULD NOT contribute to ${\mu}{\cdot}\texttt{D}$, or because the user would like to simply create a plot showing the different components of a cross section (meaning inelas SHOULD contribute to ${\mu}{\cdot}\texttt{D}$).
So probably we should (for experts only) be able to select how to treat $\mu$ in the cfg-string. Or perhaps for these validation purposes simply have a special helper class (with a utility function exposed to python).
Concerning the implementation in PCBragg [#199]/SCBragg/LCBragg. Unfortunately, it seems the correction factors are lambda-dependent, so presumably we can't just modify the structure factors and feed to the same code. This is a pretty big deal, since we will then have to add special support for this in all the models. And to keep it fast would be an added challenge... but perhaps not so much for the single crystal models, since they would anyway have to sum up all the individually contributing planes? So perhaps SCBragg/LCBragg merely need to accept a new callback function for implementing wavelength dependent corrections to the structure factors? TBD.
Another subject to consider is where does the configuration of this go: NCMAT or cfg-string. And equally, does it go on Info or Scatter objects. Currently I am leaning towards cfg-strings + Scatter objects, but if certainly might be nice to get the mosaic block size on the Info object (implemented caching-wise like the density override perhaps), and to expose some utility functions for accessing the correction factors in both C++ and Python APIs.
Also, ideally, "mosaic block size" would mean the same in the Sabine model as it does in the Scherrer model (#26), so we could simply switch between the two models as needed on the fly. That would mean that we could simply have a single new parameter with a tantalizingly simply physical meaning.
The text was updated successfully, but these errors were encountered:
After more talks with @dddijulio, trying to digest the paper now, collecting my thoughts here:
One concern is whether we need to include a factor of mu (i.e. a coefficient for absorption/incoherent/inelastic processes) which comes from the Darwin equations. I have come to the conclusion that we should do the simple thing and use mu=0, because otherwise we would be double-counting. This is most easily seen from how mu enters the extinction factor in the forward direction (El), which is just as $exp(-{\mu}D)$. That is the same as the usual attenuation factor, and since we are handling the processes separately in our code, we should not also have $\mu\ne0$. That is of course very fortunate, since it simplifies the work [followup: there was quite a discussion regarding this elsewhere].
With $\mu=0$, we can use the expressions for $E_l$ and $E_b$ from equations 6.4.5.3-6.4.5.7 directly, with $y=0$ and x a function of $\lambda$ (in addition to block size, structure factor, etc.).
With eq. 6.4.7.1 we can then get the extinction factor for a given reflection: $E = E_L(\lambda)\cos^2\theta+E_B(\lambda)\sin^2\theta =E_L(\lambda) + \sin^2\theta(E_B(\lambda)-E_L(\lambda)) =E_L(\lambda) + \frac{\lambda^2}{4d^2}(E_B(\lambda)-E_L(\lambda))$
As discussed with @dddijulio and @XuShuqi7, we should support primary extinction correction to Bragg diffraction by adopting the model by Sabine:
There is only one free parameter, the crystallite (mosaic block) size (D), although one could of course also consider supporting a spread in these (not initially).
One thing is that the Darwin-Hamilton equation solved without the paper also needs a${\mu}{\cdot}\texttt{D}$ correction where $\mu$ is the "absorption" attributed to everything except Bragg diffraction.
It is possible to simply assume${\mu}{\cdot}\texttt{D}<<1$ and thus implement the model with $\mu=0$ . However, at least for validation purposes it might be nice to support a proper $\mu$ , which of course means that the factory code must be able to initialise Scatter objects for inelas/incoh_elas/... and also Absorption. However, this is super tricky, since we don't know if e.g. an `";inelas=0" in the cfgstring is there because the user would like to truly emulate the absence of inelastic scattering (so inelas SHOULD NOT contribute to ${\mu}{\cdot}\texttt{D}$ , or because the user would like to simply create a plot showing the different components of a cross section (meaning inelas SHOULD contribute to ${\mu}{\cdot}\texttt{D}$ ).
So probably we should (for experts only) be able to select how to treat$\mu$ in the cfg-string. Or perhaps for these validation purposes simply have a special helper class (with a utility function exposed to python).
Concerning the implementation in PCBragg [#199]/SCBragg/LCBragg. Unfortunately, it seems the correction factors are lambda-dependent, so presumably we can't just modify the structure factors and feed to the same code. This is a pretty big deal, since we will then have to add special support for this in all the models. And to keep it fast would be an added challenge... but perhaps not so much for the single crystal models, since they would anyway have to sum up all the individually contributing planes? So perhaps SCBragg/LCBragg merely need to accept a new callback function for implementing wavelength dependent corrections to the structure factors? TBD.
Another subject to consider is where does the configuration of this go: NCMAT or cfg-string. And equally, does it go on Info or Scatter objects. Currently I am leaning towards cfg-strings + Scatter objects, but if certainly might be nice to get the mosaic block size on the Info object (implemented caching-wise like the density override perhaps), and to expose some utility functions for accessing the correction factors in both C++ and Python APIs.
Also, ideally, "mosaic block size" would mean the same in the Sabine model as it does in the Scherrer model (#26), so we could simply switch between the two models as needed on the fly. That would mean that we could simply have a single new parameter with a tantalizingly simply physical meaning.
The text was updated successfully, but these errors were encountered: