Changing how `task_types` are determined

[matthewkuner]

https://github.com/materialsproject/emmet/blob/c4580e2a220d2148ff3543f18c3b2ab3281491b0/emmet-core/emmet/core/vasp/calc_types/utils.py#L106

Can we change the identification of deformation calculations to be dependent on a transformations.json file instead of on ISIF=2? And along the same vein, can we have Structure Optimization tasks be for any ISIF >= 2? This is especially necessary if we want to crowd-source external calculations which may relax their structures using ISIFs other than 3.

My envisioned replacement (pseudo-)code would look like:

elif <INSERT LOGIC FOR deformation detected via transformations.json file>:
    calc_type.append("Deformation")

elif (incar.get("ISIF", 2) in range(2,9)) and (incar.get("IBRION", 0) > 0):
    calc_type.append("Structure Optimization")

Note that this order of calc_type assignment is opposite of the current logic (i.e. the current logic has the elif statement for Structure Optimization first, and then Deformation)

This may impact downstream builders / require data patching--I'm ignorant to the implications. @munrojm @tschaume @yang-ruoxi @tsmathis please let me know if you have any comments/concerns about this

[munrojm]

@matthewkuner I'm pretty this would be okay, however I would want to double check under what conditions the transformations file is written out by atomate/atomate2.

[tschaume]

@matthewkuner in addition to @munrojm's comment, we'd have to take into account what happens when the transformations file should be present but isn't. This can happen when the user forgets to add it to the upload, or internally, when we forget to restore it from HPSS. Is there any way we could deduce from the INCAR or other standard VASP input files that a transformations file should be present? I would also want to hear @esoteric-ephemera's opinion on the allowing other ISIF values.

[esoteric-ephemera]

For atomate2, the transformations.json file is written for the elastic and EOS workflows. Not sure about atomate flows

Allowing certain other ISIF values is OK. ISIF = 2 or 4 keep the cell volume fixed but let other degrees of freedom relax, which is why both are commonly used for EOS fitting, and why ISIF = 2 is marked as a deformation run

I've personally never had a need to use 5 <= ISIF <= 8; they are just other combinations of which degrees of freedom relax

Which values we allow depends on which kinds of runs we want to accept generally. For a structure to be fully relaxed wrt all possible degrees of freedom (the true lowest energy / ground state structure), ISIF = 3 is necessary. But there are good reasons to use the other values

[matthewkuner]

@computron @utf Does Atomate 1's VASP elastic constant workflow always output a transformations.json file?

Moreover, are there any cases where the VASP elastic constant workflow in Atomate 1 would create multiple transformations.json files in a single directory?