Hi all,
First question is regarding unexpected behaviour in ‘add_additional_fields_to_taskdocs’ – I’m pretty sure I’m making a basic error, but I’m having trouble tracking it down…
Here’s a minimal example:
fws = []
vis = MPRelaxSet(structure)
fws.append(OptimizeFW(structure, vasp_input_set=vis, vasp_cmd=">>vasp_cmd<<", db_file=">>db_file<<", name="test workflow"))
wf = Workflow(fws)
wf = add_additional_fields_to_taskdocs(wf, {'wf_uuid': "test uuid"})
When I check the additional fields dictionary, with:
for idx_fw, idx_t in get_fws_and_tasks(wf, task_name_constraint="VaspToDb"):
print(wf.fws[idx_fw].tasks[idx_t]["additional_fields"])
It prints {‘task_label’: ‘test workflow’, ‘wf_uuid’: ‘test uuid’} as expected.
However, when I then print ‘wf.as_dict()’, additional_fields reads just {‘task_label’: ‘test workflow’}, with no wf_uuid, and indeed, if running the workflow, the wf_uuid is missing from the final taskdoc.
What am I missing here?
···
Secondly, on the topic of workflows/workflow uuids, I can see a lot of workflows follow the pattern of adding a tag, e.g. tag = "gibbs group: >>{}<<".format(str(uuid4()))
to keep track of what workflow a taskdoc resulted from. It seems it might be useful to formalize this somewhere, e.g. having all workflows have a uuid and name that’s inserted into the taskdoc?
Related to this, when writing my own workflows, it seems that a lot of the existing workflows in preset/core.py implement a lot of the same boilerplate code (e.g. take a c
dict, check for a few common config params) … is there a standard ‘workflow template’ that should be followed, or maybe this boilerplate could be put into VaspWorkflow base class? I’m asking this question from the point of view of ensuring that, when writing a workflow, I want to make sure I’m supporting all the same features as other workflows, to reduce confusion for the end user.
Best,
Matt