Hi @SVB,
These materials and tasks are still present in the database.
Each material is a group of task ids, of which one is chosen to be the canonical material id.
We make every effort to make sure that the canonical material id remains the same throughout database updates, even as new tasks are added to that individual material. However, there was a bug that affected some tasks (including mvc tasks) in particular that led to the material id changing, as far as I know this bug has been corrected, but the material ids you accessed a few weeks ago are likely among those affected.
The good news is this is very easy to fix. You can either:
- Find the new canonical material id using
get_material_id_from_task_ide.g.:
mpr.get_materials_id_from_task_id('mp-868324') # returns mp-861852
or
- You can change your query to look in the
task_idslist (advanced use):
docs = mpr.query({'task_ids':'mp-868324'}, ['structure'])
This returns the structure for the material which contains the mp-868324 task. To explain how this works, you can see that for this material, the database entry contains:
{'material_id': 'mp-861852', 'task_ids': ['mp-861852', 'mp-863934', 'mp-868324', 'mp-869053', 'mp-869224', 'mp-863263', 'mp-869019']}
(The reason a single material ID has multiple tasks associated with it is as we add a calculation for a new property, e.g. elastic tensor or band structure, a new calculation (task) has to be performed and this is given a unique identifier with the task_id, and is then grouped together with other tasks for the same material)
I hope this helps, and I apologize for the confusion! You are definitely not the only person confused by this, and we’re trying to make efforts to make sure material ids do not change wherever possible.
Best,
Matt