[Bug]: Wrong mapping of dielectric tasks in the mp-api

[Nokimann]

Code snippet

with MPRester(api_key) as mpr:
    docs = mpr.materials.summary.search(material_ids='mp-16236')
docs[0].origins

[PropertyOrigin(name='structure', task_id=MPID(mp-2037117), last_updated=datetime.datetime(2021, 3, 13, 17, 36, 55, 731000)),
 PropertyOrigin(name='energy', task_id=MPID(mp-2037117), last_updated=datetime.datetime(2024, 12, 17, 0, 3, 31, 298000)),
 PropertyOrigin(name='magnetism', task_id=MPID(mp-2037117), last_updated=datetime.datetime(2021, 3, 13, 17, 36, 55, 731000)),
 PropertyOrigin(name='dielectric', task_id=MPID(mp-2420761), last_updated=datetime.datetime(2018, 12, 19, 22, 10, 16, 902000)),
 PropertyOrigin(name='absorption', task_id=MPID(mp-2420761), last_updated=datetime.datetime(2024, 11, 22, 6, 29, 0, 785000))]

What happened?

When we see the dielectric task above, it shows MPID(mp-2420761) and datetime.datetime(2021, 3, 13, 17, 36, 55, 731000)).

However, when we see the Calculations, it doesn't belong to the GGA DFPT Dielectric, i.e., mp-1141549 with Last Updated | December 19, 2018, but to the GGA Deformation, i.e., mp-2420761 with Last Updated | October 07, 2023.

Thus, we also have slightly different structures. This example represents just one case, leading me to suspect that all of the dielectric task ID mappings may be wrong.

Version

Python version Python 3.12.2 / Pymatgen version 2024.11.13 / MP-API version mp-api 0.44.0 / Operating system version Ubuntu 20.04.6 LTS

Which OS?

• MacOS
• Windows
• Linux

Log output

No response

[tschaume]

I'm not sure I follow what the issue is. The code snippet in this forum thread reflects what the website does to display primary and secondary tasks. Does that help?

[Nokimann]

Thank you @tschaume for your guidance.

I've successfully resolved the task ID access issue by implementing suggested approach in your link. Here's what I discovered:

1. Correct Method Found:

with MPRester(API_KEY) as mpr:
    data = mpr.materials.search(
        material_ids="mp-16236",  
        fields=["task_types", "calc_types"]
    )[0]

2. Working Data Access:

Both task_types and calc_types provide accurate task expressions when using mpr.materials.search:

# Using task_types
for k, v in data.task_types.items():
    print(k, v.name, v.value)

# Using calc_types
for k, v in data.calc_types.items():
    print(k, v.name, v.value)

3. Important Note (Bug):

There still appears to be a discrepancy in the Materials Project REST API for accessing the task information:

(Correct) mpr.materials.search via task_types or calc_types
(Incorrect) mpr.materials.summary.search via origins

This distinction is crucial for anyone working with the Materials Project API and seeking accurate task identification.

Would it be helpful to report this discrepancy between the two methods as a potential issue for someone?

[tschaume]

Thanks for reporting back and glad it helped. Would you have a specific example for the discrepancy in a search via task_types/calc_types in #3?