Bug/Feature/Help request: propagation of objects that are part of the datastore in dynamical workflows

[JaGeo]

This pull request here ( https://github.com/materialsproject/jobflow/pull/409) seems to have unintended side effects when it comes to dynamical workflows (e.g., as described here: https://github.com/materialsproject/atomate2/issues/572).

Ideally, it should be possible to switch off or enable that the information, on which objects are part of the datastore, are transferred to the subsequent dynamically generated jobs. Possibly even better, this information should be combined as this is likely the best solution.

[utf]

Thanks for raising this. I'm a bit confused how this is causing the bug. From what I can tell, the specific part of the atomate2 workflow that is failing is doing a replace with a single job. However, PR #409 is only modifying the case where a job is replaced by a flow. So it shouldn't have an impact.

One possibility is that the job is getting converted to a flow before the copying over of kwargs occurs but this would need a test.

[JaGeo]

Thanks for pointing this out.

I will test further: I am quite sure that I am not fully getting the problem yet (see title of this issue).

[utf]

Actually, I think it makes more sense. In the Atomate2 workflow, lobster_static_maker is actually a flow maker that does both a static and a uniform. With this in mind, I will think about the logic of kwargs copying.

[JaGeo]

One thing I can say: the issue is certainly related to recent updates in jobflow.

[JaGeo]

I will make some more tests and then also update on the situation.

[JaGeo]

I will close it. I think the issues in atomate2 are not related to the discussed points here. Only one of the objects is not inserted in the datastore, another one is.