Closed esoteric-ephemera closed 4 months ago
Attention: Patch coverage is 11.76471%
with 15 lines
in your changes are missing coverage. Please review.
Project coverage is 77.11%. Comparing base (
d9d7d21
) to head (7ab775f
).
Files | Patch % | Lines |
---|---|---|
emmet-core/emmet/core/vasp/validation.py | 6.66% | 14 Missing :warning: |
emmet-core/emmet/core/utils.py | 50.00% | 1 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
If there are breaking changes to TaskDoc
, eg for current users of atomate2, could a migration script be provided?
Hi @mkhorton, there shouldn't be breaking changes to TaskDoc
, I've just had to add fields/methods to it for improved compatibility with both atomate2 and TaskDocument
A good example is the TaskDoc.task_type
field, which actually corresponds to TaskDocument.calc_type
in the atomate2 schema. The calc_type
field is the union of TaskDocument.task_type
and TaskDocument.run_type
(a CalcType
)
For compatibility with atomate2, TaskDoc.task_type
still accepts CalcType
as input, but for backwards compatibility with TaskDocument
, there are new calc_type
and run_type
fields on TaskDoc
I presume that the TaskDoc.task_type
field was intended to reduce some of the redundancy of these three fields, but some glue code was needed for full backwards compatibility. These added fields won't be used in atomate2
Apologies in advance for the long-winded answer
merging as rc
Summary
The main goal is removing atomate dependencies from emmet, and transitioning from using
emmet.core.vasp.task_valid.TaskDocumement
toemmet.core.tasks.TaskDoc
. This will allow for eventual deprecation / aliasing ofTaskDocument
Completed:
Changes to
TaskDoc
and its fields are required since it is not directly compatible withTaskDocument
:TaskDocument
are deserialized, thusTaskDocument.calcs_reversed[:].input
will be a dict whereasTaskDocument.calcs_reversed[:].input
is aCalculationInput
object. Calling.model_dump()
doesn't help since this isn't recursive (e.g., the structure in CalculationInput will still be serialized)BaseCalculationModel
toemmet.core.calculation
which just wraps the pydanticBaseModel
with a.get
method to emulate dict key access (needed in the ValidationDoc)TaskDocument
:calc_type
,run_type
, and a post init update fortask_type
TaskDoc
accepts extra model input, and the way that pydantic looks for non-field attrs in the class, there are new private fields defined onTaskDoc
. pydantic first looks for attrs in the model extra field, but then raises anAttributeError
if it can't find it, without looking to see ifhasattr(class,attr)
. There's a longer explanation in a comment near_calc_type
Will be part of a separate PR: ~## To Do:~ ~- Remove atomate dependence from emmet-cli:
VaspCalcDb
--> generic maggma store~ ~- Improve credential handling in emmet-cli settings~