Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

missing task_type field for non-GGA calculations #258

Open
rkingsbury opened this issue Sep 3, 2021 · 4 comments
Open

missing task_type field for non-GGA calculations #258

rkingsbury opened this issue Sep 3, 2021 · 4 comments

Comments

@rkingsbury
Copy link
Collaborator

It appears that the task_type field is blank or null for all non-GGA tasks in Knowhere/tasks. I discovered this when testing the API tasks endpoint on r2SCAN, SCAN, and PBEsol tasks. Checking the database collection gives

image

For example, try task_ids

  • mp-1942988
  • mp-1943782
  • mp-1536256

For all of these, the task_type field is actually missing from the document.

@rkingsbury rkingsbury changed the title blank task_type for non-GGA calculations missing task_type field for non-GGA calculations Sep 3, 2021
@shyamd
Copy link
Contributor

shyamd commented Sep 7, 2021

Is it possible the task_type functionality isn't working for these calcs or is just in the materials docs where this is going awry?

@rkingsbury
Copy link
Collaborator Author

This is actually in the task docs (or whatever it is that the Tasks endpoint serves from) not the materials docs . Could this be a simple question of when the tasks were ingested? In my personal tasks collection, none of my tasks has a task_type field.

The validation and materials collections associated with my PR #536 (building with the new build system) on Knowhere / mp_core_build appear to have correctly-populated calc_type and calc_types fields, respectively.

@shyamd
Copy link
Contributor

shyamd commented Sep 7, 2021

The task docs won't have a valid task_type since I think that was hot-patched for a short while until I realized that even pymatgen was buggy and decided that it should be in the Materials Doc.

@mkhorton
Copy link
Member

mkhorton commented Sep 8, 2021

In that case, we should probably remove task_type from the API doc?

I see the value in having it from the tasks endpoint directly, but since it needs to be built separately, one option would be to offer a /tasks/task_types route. Another option would be an on-the-fly aggregation, so that the returned task doc has the built task type, but that would probably mean we couldn't search on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants