-
Notifications
You must be signed in to change notification settings - Fork 4
update the QPA categories #89
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
update the QPA categories #89
Conversation
I started writing up how to use them, and realised I had overthought things.
This reverts commit 6d67666.
|
Something that we endeavour to do in CIF is to make sure that the way in which a value is used is not changed by the values of other data names. An extreme example would be a data name called What is OK is for the derivation of the value to be different: so So I'm concerned that the |
|
Probably not directly answering your question, but I'm addressing what I'm trying to do. As you say here, I'd like to include information that allows the quantification to be rederived from values in the collection. Looking at ZMV formulism, this requires the scale factor. This isn't currently recorded anywhere, and depends on phase, diffractogram, and the exact analysis program and version used. In the above nomencalture, the inverse of a phase's ZMV is For RIR, this requires a peak intensity, sum of peak intensities, or a scale-type factor. Again, this isn't currently recorded anywhere, and depends on phase, diffractogram, and the exact analysis program and version used. In the above nomencalture, a phase's RIR is For PONCKS, this is a little different. The peak intensities assigned to the phase, when combined with a 'synthetic' ZMV-like value, and a scale factor can give you quant. In this case, the peak intensities have a meaningful value only when combined with the synthetic ZMV - but they aren't F_squared_meas values, or counts, or intensities. They can also exist as reflections or arbitrary peaks. In the above nomencalture, the inverse of a phase's 'synthetic' ZMV is The same goes with absorption-diffraction; the calibration value depends on the exact intensities used, and so we need to ensure that the properly calibrated intensities are either recorded, or some . It is trivial to make |
Here's a summary of how it currently works in this PR: Categories and data items
How it's supposed to workA given diffractogram is marked as being quantified by having The various methods are:
where W is the weight fraction, p represents the pth phase, I or S is the intensity or scale factor used to quantify that phase, P is the total number of phases, and μ*m is the mass absorption coefficient of the entire specimen. Cp is the calibration factor which puts the intensities/scale factors of the constituent phases onto a common scale to allow for quantification. Ip and Sp would be recorded using The definition of Cp changes, depending on the The various defintions are:
ConclusionsIn all cases, If you want EpilogueBut when doing quant on a diffractogram, the So, after writing all of that out, I think that there should be many data items in |
but with 'other' still at the end
…ed QPA algorithms
…all.method" This reverts commit eef0a91.
…wlesmr/Powder_Dictionary into update-QPA-related-categories
I like your analysis above, which shows very clearly that the values are used in the same way, even if they are derived in different way, and so I agree that a single data name |
cif_pow.dic
Outdated
| This value is not, in general, transferable between different program types | ||
| and versions, as each software package may incorporate different constants | ||
| or normalisations into their calculations. However, if all values for a | ||
| given diffractogram, or CIF container, are self-consistent, then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what is meant by "CIF container" here. Is the intended meaning that there is a collection of diffractograms? What would be lost by dropping this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I was trying to say that if I had a bunch of diffractograms (eg in situ), and they all were analysed in a self-consistent manner, then I can compare the _pd_qpa_intensity_factor.value between all of the phases in all the diffractograms. As the sentence is written, ", or CIF container," can be removed without any loss of meaning. One can probably assume that values are self-consistent within a single experiment.
|
Happy for this to be merged after that single query on "CIF container" is sorted. |
I started writing up how to report QPA, and realised I had overthought things.
Key changes:
PD_QPA_RIR.PD_QPA_CALIB_FACTOR(Set, keyed on_pd_qpa_calib_factor.phase_id)PD_QPA_RIRinasmuch as it allows a phase to be given a_pd_qpa_calib_factor.value. For RIR, this data value is the RIR.PD_QPA_OVERALL(Set, keyed on_pd_qpa_overall.diffractogram_id)_pd_qpa_overall.method, which is an enumerated list of how the diffractogram was quantified. It can be used just as an information item, but can also be used to provide context to any value associated with_pd_qpa_calib_factor.value. The enumerations were taken from Chapter 3.9 of ITC H.PD_QPA_EXT_STDandPD_QPA_INT_STDtoPD_QPA_EXTERNAL_STDandPD_QPA_INTERNAL_STDto remove one level of abbreviation.PD_QPA_INTERNAL_STDto say that internal std can be used with a variety of quantification methods in order to give absolute phase quantification (not just Rietveld)..
Possible other considerations for the future:
PD_QPA_INTENSITY_FACTOR(Loop, keyed on_pd_qpa_intensity_factor.phase_idand_pd_qpa_intensity_factor.diffractogram_id)_pd_qpa_intensity_factor.value. This is the value which is divided by_pd_qpa_calib_factor.valuein order to give the value which is used in quantification.