Materials-Consortia / OPTIMADE

Specification of a common REST API for access to materials databases
https://optimade.org/specification
Creative Commons Attribution 4.0 International
77 stars 37 forks source link

Trajectories #34

Open davidwaroquiers opened 6 years ago

davidwaroquiers commented 6 years ago

Trajectories should be a simple extension of the structure API (see Issue #23)

Suggestion :

lattice_vectors_trajectory : list of each lattice_vectors-like (as defined in structure, see Issue #23) at each time step or relaxation step cartesian_site_positions_trajectory : list of each cartesian_site_positions-like (as defined in structure) at each time step or relaxation step For a trajectory/relaxation to be "activated", at least one of the previous field has to be defined.

For trajectories, the following (optional) fields can be given : md_start_time : Starting time of the trajectory (suggested unit : fs) md_time_step : Time step of the MD trajectory (if time step is constant), in suggested unit fs md_times : If variable time steps are allowed, list of times of the MD trajectory, in suggested unit fs

We suggest that the rest of the structure field stays the same (dimension_types, species, ...). Assemblies could also be used for e.g. Path Integral Molecular Dynamics.

rartino commented 6 years ago

So, I guess the suggestion is that the above defines a trajectory entry, i.e., the above + what is in structure, but with lattice_vectors replaced by lattice_vectors_trajectory and cartesian_site_positions replaced by cartesian_site_positions_trajectory?

(Or is the proposal that these can be added on top of a structure?)

It was brought up in the discussion that this may lead to single records that are too big to send over 'in one go'. My suggestion was, in such a situation, to rely on the mechanisms in http for partial transfers, e.g., https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206