# Notes on DeclarativeChain ###### tags: `design` ## Philosophy CalcJobs are well-defined blocks of computation, can be thought of as basic big transformer functions. WorkChains can string together and combine these functions in exponentially many ways. Does creating a new WorkChain for each of the variations make sense? Can we increase the flexibility of AiiDA? ## User stories - As a OpenModel ... I need to ... in order to ... - As an AiiDA user exploring new calculation routes, I would like to ... in order to ... ## Goals - Allow for quick creation of workflows by combining existing CalcJobs and WorkChains - Json/yaml based -> interoperability with other codes + interact with AiiDA as a web service - Decrease trial/error turnaround time - Lower barrier of entry ## What this proposal makes possible - Fully specify a workchain with a json/yaml file - Straightforward sequence of calcjobs - jsonref to split data from workchain specification - Pretty much anything can be done by dropping Python code into the preprocess and postprocess steps - Loops can be constructed by pushing/inserting to the internal list of calcjobs ## Problems encountered - pre/post process are rather ubiquitous, and rather ugly. - dict2datanode not well-defined. - DataNodes are not just stores of data, i.e. no straight mapping from dict to attribute is possible... - Certain DataNodes can be created just as Str("xyz") whereas some other have to be created through Dict(dict={xyz}) or List(list={xyz}), why? Being worked on in https://github.com/aiidateam/aiida-core/pull/5165 - More versatile creation and linking of datanodes could be useful (cfr Script) ## Ideas not yet explored - Specify pre and postprocess steps in a well-defined manner through json? - Force calcjob output to map to next input? Could be achieved by allowing on-the-fly creation of Calcjob input/output. Spec.define()? ## Comments October 20th 2021 * Leopold: * Please complete the 2 user stories - they are important to guide the design and help us make sure we are (1) tackling problems that are worth solving and (2) that we are actually solving them * Since this proposal is for a declarative "simple" workflow language, of which there are many existing flavors, please check whether there is either an existing standard that we could use, or at least existing high-level guidelines (e.g. on where to draw the line for what should be possible to express in such a language and what not; how to do error handling; ...) that we could follow so that we don't reinvent the wheel and encounter problems down the line that others have already thought about.