search

materialsproject / fireworks

The Fireworks Workflow Management Repo.
https://materialsproject.github.io/fireworks
Other
361 stars 185 forks source link

ENH: Allow propagating modified spec not only to direct children, #407

Closed jotelha closed 4 years ago

jotelha commented 4 years ago

but along all decendants down to workflow leaves by adding a 'propagate' flag to FWAction.

A typical usecase is some descriptive metadata that is not available a priori, but arises at some point along the workflow as a result of some task. That metadata is supposed to be valid for all dependent FireWorks and therefore should trickle down the dependency graph.

computron commented 4 years ago

This is useful, thanks! Merging -

Note - regarding:

         # TODO: wouldn't it be better to update specs after inserting additions
         # and detours in order to propagate modified specs to new FireWorks
         # as well

it's difficult to say what the expected behavior should be. For example, if a user takes the time to set up a new Firework the way they want, they might be surprised if that Firework gets modified after they create it. Stated another way, if the updates are applied after the Firework is created, the user has no choice but to have those update actions apply to the new Firework - whether they want it or not. If the updates are applied beforehand, then the user has more control about whether they want those updates to be part of the new Firework they are designing or not. That said, some users might expect that the updates are automatically applied. For now, I plan to leave it as-is so that the user has more control. But, feel free to start a conversation about this on the discuss (help) channel or Github if you feel strongly about it.