Skip to content
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

_pdbx_diffrn_merge_stat (reflection count) #22

Open
CV-GPhL opened this issue Aug 26, 2020 · 2 comments
Open

_pdbx_diffrn_merge_stat (reflection count) #22

CV-GPhL opened this issue Aug 26, 2020 · 2 comments

Comments

@CV-GPhL
Copy link
Contributor

CV-GPhL commented Aug 26, 2020

We currently have

  • _pdbx_diffrn_merge_stat.number_all (The total number of reflections contributing to this data set.)
  • _pdbx_diffrn_merge_stat.number_obs (The number of reflections satisfying the observed criteria.)

which doesn't make it clear if this refers to

  • the number of actual measurements
  • the number of symmetry-unique (merged) reflections

Is there an intrinsic assumption that a data section with _pdbx_diffrn_data_section.type_merged = false refers to the former and with _pdbx_diffrn_data_section.type_merged = true refers to the latter?

I can see that an unmerged data-section can only refer to the former (since it doesn't describe the result of an optional merging step). But a merged data section should provide both values as is standard, see e.g. Acta F details. It might be better to use

  • _pdbx_diffrn_merge_stat.number_all (The total number of measurements contributing to this data set.)
  • _pdbx_diffrn_merge_stat.number_obs (The total number of symmetry-unique (merged) reflections contributing to this data set.)

which would provide a merged data section with the possibility to use both (as we do in any X-Ray structure paper).

@epeisach
Copy link
Contributor

The dictionary distinguishes between measurements that are not made - and discarded and valid measurements. Think beam stop and between CCDs gaps.

For number_all - I would favor - I think we want some language indicating that rejections have already taken plan before this count.

@CV-GPhL
Copy link
Contributor Author

CV-GPhL commented Sep 14, 2020

There can't be a "measurement that is not made" - if it is not made then it isn't a measurement. It could be a measurable quantity, but is that a useful quantity here? If we want to record the number of measurable reflections that are unmeasured (because of beam stop shadow or module gap etc), why not also record the measurable reflections assuming a circular detector (versus the squarish ones we use most of the time)? After all, if we had a different detector we could measure them (in the same way that a different detector would provide us with pixels in the module gaps) ... but what would we use that number for? Probably to compute a completeness - in which case we could do away with recording the completeness values in other places to avoid duplication ... hmmm.

Given the current practice we are better of recording the completeness and the number of actually measured/observed reflections since together we can then compute the number of measurable reflections to the diffraction limit the completeness relates to.


Apart from that, my main question has to do with the way we've always presented numbers in X-Ray structure papers, namely (1) the number of actual measurements and (2) the number of unique (after symmetry-merging) reflections. Providing a clear indication where those two numbers should go (as these are what everyone records in their Table 1 of the paper) is unrelated to the notion of a theoretical "measureable, but not measured" number here.

It should also be unrelated to the notion of "observation criteria" that is used in the current dictionary definitions: as mentioned previously, there are multiple steps of data selection and rejection taking place all along the data processing process that are nearly impossible to record in the same way as a simple I/sig(I) cut-off - which seems to have been inherited from descriptions related to refinement paractises against merged data in years past.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants