Activate COD, TCOD, NOMAD, OQMD, AFLOW, JARVIS, MPDS when compliant or with work-arounds

[csadorf]

I just (2020-11-04 14:35 CEST) tried to perform a search query on the COD database via the OPTIMADE client hosted here, which failed with the following error message:

[CasperWA]

Just tried this and didn't get this issue.
This may be a temporary issue that can not be reliably mediated. Perhaps a better error message would be nice though?

[csadorf]

I just tried again and the connection appeared to work, but the query fails:

[CasperWA]

Indeed, this is an issue on COD's side not correctly implementing the specification for the version they specify, where structure_features is a mandatory field for querying.
Furthermore, this issue is the subject of #125.

[csadorf]

Where can I report this bug so that it is resolved?

[CasperWA]

Where can I report this bug so that it is resolved?

You can try and contact @merkys. He is the main implementer of the OPTIMADE implementations related to crystallography.net.

But maybe this would indeed be valuable information to present in the client as well! To whom one shoule address issues unrelated to the client. There is usually some information available in the list of providers.

[merkys]

I see this issue is due to COD not handling queries on structure_features right now. This issue is reported in COD's issue tracker as #828.

[CasperWA]

Note, COD, TCOD, and NOMAD have temporarily been "disabled" in the application as of #220.

This issue will now serve as a reminder to "activate" them again, according to compliance with the specification.

[CasperWA]

Added OMDB and OQMD since #248.

[CasperWA]

Added AFLOW and MatCloud since #277, but this is due to them not having a reachable database.

[CasperWA]

Added MPDS since #296 due to it not being supported by the filters used in the client (it doesn't support the ANY operator, which is used to remove all assemblies structures).
It will be added once supported by the client.

[ml-evs]

Would it be helpful if the providers dashboard also served the raw JSON from the validator? You could then exclude providers on client start-up by checking the dashboard for that day against the features you know the client requires (e.g. grepping error messages for "HAS ANY", or we could tag validation requests by the feature they test and provide a better digest).

[CasperWA]

Update: #343 has implemented some improvements so that OMDB can be re-enabled.
In the process of created #343 I also tried all the other currently disabled providers, however, they are all still either missing client-critical query support or have internal implementation bugs.

[unkcpz]

Some updates on this issue. I test COD, TCOD, NOMAD, OQMD, AFLOW, JARVIS, MPDS and OMDB

• OQMD works fine. Only the server respond slow and timeout sometime. We can bring it back to list.
• COD, TCOD still have issue with structure_feature mentioned by @merkys. The workaround is we ignore query this field specifically for COD and TCOD. @merkys could you comment here the plan you have we discussed?
• NOMAD use elasticsearch and have some issue with the sort we used in query.
• OMDB has issue with species not returned as specification required and structure adapter failed to process it but I add a workaround similar on optimade-python-tool to get it from species_on_sites. We can add it back after Tackle issue that some db not return species #431
• JARVIS is fine but only have 5 structures return no matter what query parameters applied. Will not include it.
• MPDS only support page_limit equals to 5, 10, 100, or 750, this can be solved by make it set in the widget. Moreover, MPDS not support ANY which used in structure_feature. This can also be dropped from query request as COD, TCOD.
• AFLOW has issue with even /info not supported by client yet. http://aflow.org/API/optimade/v1/info/structures?response_format=json

[merkys]

@unkcpz

• COD, TCOD still have issue with structure_feature mentioned by @merkys. The workaround is we ignore query this field specifically for COD and TCOD. @merkys could you comment here the plan you have we discussed?

Right, to get COD/TCOD structures without disorder you may query on NOT _cod_flags CONTAINS "disorder".

[CasperWA]

Right, to get COD/TCOD structures without disorder you may query on NOT _cod_flags CONTAINS "disorder".

Since the structure_features is a MUST return field for structures (unless it has changed recently?), could you bump the internal issue in your issue tracker to get this field in for your returned data?

[merkys]

Since the structure_features is a MUST return field for structures (unless it has changed recently?), could you bump the internal issue in your issue tracker to get this field in for your returned data?

I am well aware of the lack of compliance from COD/TCOD side regarding structure_features. I am just unable to make this happen any faster now, alas.

[CasperWA]

Since the structure_features is a MUST return field for structures (unless it has changed recently?), could you bump the internal issue in your issue tracker to get this field in for your returned data?

I am well aware of the lack of compliance from COD/TCOD side regarding structure_features. I am just unable to make this happen any faster now, alas.

Sorry, it wasn't to stress you out - it just seemed that the mapping of the _cod_flags parameter to structure_features was the solution there :) But I'm sure it's more involved than that to implement in the end.
I'd prefer to be able to use standardized OPTIMADE fields for handling the general sorting of results instead of having to use provider-specific fields, since it's a slippery slope, but I suppose it could be done for COD/TCOD for now.
But I might then also set up a CI test to run for testing structure_features in COD/TCOD and have GitHub "add" you whenever the test fails... 😆 😅 just kidding, of course 😅

[merkys]

Sorry, it wasn't to stress you out - it just seemed that the mapping of the _cod_flags parameter to structure_features was the solution there :) But I'm sure it's more involved than that to implement in the end.

No problem :) The trouble here is that COD and OPTIMADE concepts are not 1:1-relatable. The filter I gave earlier excludes most of the disordered structures, but certainly not all of them.

I'd prefer to be able to use standardized OPTIMADE fields for handling the general sorting of results instead of having to use provider-specific fields, since it's a slippery slope, but I suppose it could be done for COD/TCOD for now.

I completely share the preference for standardization :) However, it cannot be properly done right now.

But I might then also set up a CI test to run for testing structure_features in COD/TCOD and have GitHub "add" you whenever the test fails... laughing sweat_smile just kidding, of course sweat_smile

Oh noes 😅 Some time ago there were talks of introducing badges of shame 😅