OPTIMADE
OPTIMADE copied to clipboard
Specification of a common REST API for access to materials databases
This is a proposed solution for #406 Before you fire up your keyboards to comment on all the many ways this can/should be extended to allow other possible aspects representing...
In discussions related to issue #406 we've found that the current handling of unknown properties in OPTIMADE is not optimal for interoperability, as queries using a new property will generate...
There is interest in including magnetic moments in the OPTIMADE specification (also mentioned in #426). The purpose of this issue is to discuss this and collect relevant data. What probably...
Currently our `file` entry type has a 1-to-1 mapping with a file on disk, however there are many cases where databases serve archive files that aggregate data on multiple structures....
During the discussion on PR#480, the issue came up that it was not clear how the data type of fields with nested values should be described. In the text, we...
The space group symmetry operation descriptions (#464) apply to the whole crystal and not to a single molecule or atom cluster. For this reason they can only contain crystallographic symmetry...
After the PR for the space group operations is (hopefully) merged, we need to continue and specify 4D and higher dimension symmetry operations for incommensurately modulated structures and quasicrystals. The...
At the workshop, we discussed a file format specification that would allow an entire OPTIMADE API to be stored in a single file on disk. This would be useful for...
Currently we expected relationships filtering to be a two-step process: > Note: formulating queries on relationships with entries that have specific property values is a multi-step process. For example, to...
In #368 SMILES property for structures was proposed. PR #392 was proposed to introduce string-valued SMILES property, however, there were opinions that internal semantics of SMILES strings have to be...