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

[New data item]: Method for indicating the data source for a structure - experimental vs calculated #475

Open
rowlesmr opened this issue Feb 8, 2024 · 3 comments
Assignees

Comments

@rowlesmr
Copy link
Collaborator

rowlesmr commented Feb 8, 2024

Definition

It would be nice to be able to easily distinguish structures derived from experimental data vs calculations (eg DFT).

There is currently no way to do this in a machine-readble manner.

Restricted values

Value should be drawn from a predefined list

Example

experimental

Explanation of example

the data source for this structure is experimental, (as opposed to calculated)

Looping

top level

Data name

_diffrn.data_source

Type

Word (text with no spaces)

Data structure

None (a single value of type given in Type above)

Comments

_diffrn.data_source experimental
_diffrn.data_source calculated

Suggestions from meeting between CPD and IUCr.

@vaitkus
Copy link
Collaborator

vaitkus commented Feb 8, 2024

Relevant discussion in the coreDMG mailing list: https://www.iucr.org/__data/iucr/lists/coredmg/msg00429.html

There was also a similar discussion by the OPTIMADE developers on introducing a similar enumerator (Materials-Consortia/OPTIMADE#455), however, it was quite difficult to agree on a limit where "experimental" ends and "theoretical" begins. The different types of "theoretical" methods also turned out quite difficult to agree upon.

@rowlesmr
Copy link
Collaborator Author

rowlesmr commented Feb 8, 2024

I missed _exptl.method in searching core.

That does look like the place to put this information, and yes, an enumeration does have a nice appeal.

@jamesrhester
Copy link
Contributor

I think it would be good to pick up @vaitkus 's suggestions in the COMCIFS thread he references above.

The issue is basically whether or not to redefine our own _exptl.method to bring it into line with mmCIF - how many CIFs would we invalidate because they didn't have recognised enumerated values?

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

No branches or pull requests

3 participants