Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions AUTHORS
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,8 @@ The OPTIMADE API has been developed with contributions by the participants of th
- the CECAM in Lausanne, Switzerland (virtually) 2021-06-07 to 2021-06-11
- the CECAM in Lausanne, Switzerland 2022-05-30 to 2022-06-03
- the CECAM in Lausanne, Switzerland 2023-06-05 to 2023-06-09
- the CECAM in Lausanne, Switzerland 2024-06-10 to 2024-06-14
- the Vilnius University Life Sciences Center in Vilnius, Lithuania 2025-09-15 to 2025-09-19

Initial and major contributors to the development of the OPTIMADE specification and implementation in alphabetical order:
Casper Andersen
Expand All @@ -23,6 +25,7 @@ Pauline Colinet
Gareth Conduit
Stefano Curtarolo
Davide Di Stefano
Nathan Daelman
Alexander Dorsk
Claudia Draxl
Shyam Dwaraknath
Expand All @@ -36,6 +39,7 @@ Matteo Giantomassi
Abhijith Gopakumar
Marco Govoni
Saulius Gražulis
Algirdas Grybauskas
Geoffroy Hautier
Vinay Hegde
Matthew Horton
Expand Down
31 changes: 31 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,36 @@
# Changelog

## v1.3.0-rc.1 (November 2025)

This release extends the OPTIMADE specification with new entry types and properties with an emphasis on applying the partial data protocol from v1.2 to the new trajectories endpoint, for which each resource is likely to be too large to be served in a single response.

As part of this release, the OPTIMADE consortium also adopts the Contributor Covenant (3.0) Code of Conduct for all community interactions.
Please see [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) for details of the contributor expectations, as well as reporting and enforcement procedures.

Minor OPTIMADE releases are always intended to be backwards-compatible for clients, meaning that any client code written for v1.x should continue to work, and any breaking changes should be reported as bugs to be fixed in a patch v1.3.x release.

## New features

- **Trajectories endpoint** ([#377](https://github.com/Materials-Consortia/OPTIMADE/pull/377), [#481](https://github.com/Materials-Consortia/OPTIMADE/pull/481))
): A new trajectories entry type has been added to the specification to share data belonging to ordered sequences of structures, such as those arising from molecular dynamics simulations or geometry optimizations.
In order to handle large individual entries, this endpoint makes use of the partial data protocol introduced in v1.2, with additional specialisations for slicing (e.g., the `dimension_slices` URL parameter) and representing dimensions that remain constant throughout a trajectory, whilst retaining the ability to filter using the normal OPTIMADE syntax via the `reference_frame` field.
- **Provider-specific data types** ([#560](https://github.com/Materials-Consortia/OPTIMADE/pull/560)): Providers and namespaces can now define custom data types for their properties that let them use specific query semantics that differ from the standard OPTIMADE data types.
For example, a provider could define a field that uses a string format for a field, but a custom data type that allows for e.g., `CONTAINS` queries to do something other than pure substring matching.
- **New fields for structures entries (`fractional_site_positions`, `site_coordinate_span`, `site_coordinate_span_description`, `optimization_type`, `wyckoff_positions`)**
([#539](https://github.com/Materials-Consortia/OPTIMADE/pull/539), [#562](https://github.com/Materials-Consortia/OPTIMADE/pull/562), [#570](https://github.com/Materials-Consortia/OPTIMADE/pull/570)): Several new fields have been added to the structures entry type to improve symmetry representation and to provide information about the provenance of the structure:
- `fractional_site_positions`, `site_coordinate_span`, `site_coordinate_span_description`: New fields that can be used to describe positions of atoms as an alternative to `cartesian_site_positions`, to be used in conjunction with `space_group_symmetry_operations_xyz` when providing only the asymmetric unit of a structure.
The additional `site_coordinate_span` and `site_coordinate_span_description` fields can be used to describe the extent of the atoms that have been provided as fractional coordinates and can take values such as `asymmetric_unit`, `unit_cell`, `molecular_entities`, etc.
- `wyckoff_positions`: This field can be used to provide the Wyckoff positions of each site in the structure, if known, following the IUCr definitions of labelling.
- `optimization_type`: This field can be used to describer the type of optimization that has been performed on a structure, if any.
For example, the optimization could be relative to experimental evidence (`experimental`) (e.g., minimising discrepancy with a diffraction pattern), relative to some kind of Hamiltonian (e.g., density-functional theory or a force-field), and whether the optimisation scope was `local` or in some sense `global` (minimised relative to a global energy surface of possible decompositions and other structural configurations).
- **JSONLines standardization for serializing OPTIMADE APIs to disk** ([#531](https://github.com/Materials-Consortia/OPTIMADE/pull/531)): An appendix has been added to the specification with a suggestion for how to serialize OPTIMADE entries, or full APIs (including e.g., info endpoints) to a single file using the [JSONLines format](https://jsonlines.org/).
This format is already in-use by several tools in the ecosystem and is RECOMMENDED for interoperability.
- **Extended filtering on relationships** ([#524](https://github.com/Materials-Consortia/OPTIMADE/pulls/524), [#523](https://github.com/Materials-Consortia/OPTIMADE/pull/523)):
Additional metadata fields describing relationships between entries (`description` and `role`) have been added between all entry types.
An additional dummy field `target` has been added to enable direct querying (i.e., without requiring a join) on properties of the target of a relationship, for example: `/structures?filter=references.target.doi="10.1234/56789"`.
In addition, relationships specifically between `files` and `calculations` entries can now specify a `role` that describes whether the file is an `input`, `output`.


## v1.2.0 (June 2024)


Expand Down
6 changes: 3 additions & 3 deletions optimade.rst
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
=========================================
OPTIMADE API specification v1.3.0~develop
=========================================
======================================
OPTIMADE API specification v1.3.0-rc.1
======================================

.. comment

Expand Down