'_odbx_thermodynamics' field is not retrieved in the demonstration-pymatgen-for-optimade-queries tutorial

[JPBergsma]

At the end of the demonstration-pymatgen-for-optimade-queries tutorial, there is a code block with the following line:
example_snl.data['_optimade']['_odbx_thermodynamics']
After executing this line, I however get the error:

KeyError Traceback (most recent call last)
/tmp/ipykernel_247/47798912.py in
----> 1 example_snl.data['_optimade']['_odbx_thermodynamics']
KeyError: '_odbx_thermodynamics'

If I do print(example_snl.data) it shows that the ['_optimade'] field is empty.
This is not surprising, as the executed query was :
https://optimade.odbx.science/v1/structures?filter=(nelements=2)&response_fields=lattice_vectors,cartesian_site_positions,species,species_at_sites

The _odbx_thermodynamics field is missing from the response_fields.

I am therefore wondering whether this is a bug in the OptimadeRester or that the person who wrote the tutorial did not properly understand how the OptimadeRester should work. I did not find anything about the OptimadeRester retrieving database specific fields in the pymatgen documentation.

[ml-evs]

Hmmm, looks like this tutorial used pymatgen 2022.0.14 when it was written, which had a bug where response fields were not properly applied (I fixed this for them in 2022.0.15). This bug was causing failures when querying databases that did not support e.g. species, as this was required by pymatgen and a missing value would cause a crash.

Unfortunately, this means that the user has no way of modifying the response fields from OptimadeRester for >2022.0.14.

I guess we have a few options...

1. Remove this part of the exercise for now (I think this is better than pinning to the old "broken" pymatgen version)
2. Patch pymatgen and wait for a new release (which has approximately monthly releases). It wouldn't be a huge change passing response fields through here.
3. (longer term) Maybe we could add a convenience parameter to the spec, where the user can request certain OPTIMADE fields PLUS e.g. _odbx* for all custom fields served by that provider (may be useful once we add properties) - I can write this up as an issue if we think it is a good idea.

[ml-evs]

4th option... I quickly knock up a PR on a fork, we pin the pymatgen version to current_version+1 in the exercise, and install from my fork if that version is not yet available.

[ml-evs]

Closed by #9.