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

Make wavelength description independent of diffraction experiment #19

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

jamesrhester
Copy link
Contributor

Fixes issue #505, alternative to #18 .

This is an alternative way of associating more than one wavelength with a diffraction experiment that goes a bit deeper than #18. DIFFRN_RADIATION becomes independent of DIFFRN and then DIFFRN includes an explicit pointer to _diffrn_radiation.id.

The advantage of this approach, apart from the ability to specify multiple wavelengths as in #18 , is that radiation characteristics need be provided only once for multiple measurements using the same source. For example a multi-temperature experiment (imagine 100 temperature measurements) need only set the value of _diffrn.diffrn_radiation_id in the diffrn category of each measurement, instead of respecifying everything in DIFFRN_RADIATION and DIFFRN_RADIATION_WAVELENGTH for every temperature.

The drawback is that mmCIF already has defined _diffrn_radiation.diffrn_id, which this PR deprecates. As this data name has never appeared in a released core dictionary, non mmCIF software does not output it and will not try to interpret it if handed an mmCIF file. It can still be given a well-defined value if there is only one set of diffraction conditions and one source of radiation.

James.Hester added 2 commits November 12, 2024 14:31
…nmental conditions

This change means that the list of wavelengths and associated radiation production
details are specified independent of the sample environment. For example, a
multi-temperature data set would not require restating the wavelength for every
distinct temperature.
@jamesrhester
Copy link
Contributor Author

Note this extended pdCIF example shows how this looks in practice. The first data block describes the radiation source, and that _diffrn_radiation.id is referred to by the next data blocks which describe the experimental conditions.

Copy link
Collaborator

@vaitkus vaitkus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The approach seems reasonable to me. However, I would recommend somebody else (preferably someone with more practical experimental experience) also review this PR.

@@ -124,19 +144,20 @@ save_DIFFRN_RADIATION
;
_name.category_id DIFFRACTION
_name.object_id DIFFRN_RADIATION
_category_key.name '_diffrn_radiation.diffrn_id'
_category_key.name '_diffrn_radiation.id'

save_

save_diffrn_radiation.diffrn_id
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this item should be removed altogether instead of deprecating it?

Arguments in favour of removal:

  1. This item was only recently added to this dictionary.
  2. There are already data items with the same name in the mmCIF and the imgCIF dictionaries so deprecating them here might lead to some confustion.
  3. The item is no longer referenced as a category key so the intended use case in general is a bit unclear.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed the definition as suggested.

This is defined in mmCIF.dic, so is available if someone really
wants it. However, it does not fit into our concept of associating
a single radiation source with a particular experiment; instead
it associates a particular experiment with a particular radiation
source, which can only make sense when there is a one-to-one
relationship between source and experiment. As many measurements
can be performed on a single source, this dataname will rarely
be useful.
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

Successfully merging this pull request may close these issues.

2 participants