# Starting workchain from a given calculation and change selected parameters **URL:** \ **Category:** General Usage\ **Created:** [March 9, 2026, 9:25pm UTC](https://aiida.discourse.group/t/starting-workchain-from-a-given-calculation-and-change-selected-parameters/717 "2026-03-09T21:25:17Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![bonfus](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/bonfus/32/403_2.png) [@bonfus](https://aiida.discourse.group/u/bonfus)\ **Post date:** [March 9, 2026, 9:25pm UTC](https://aiida.discourse.group/t/starting-workchain-from-a-given-calculation-and-change-selected-parameters/717/1 "2026-03-09T21:25:17Z")
Hi there, I’m sure this has been asked 100+ times, but I could not find the relevant post. I would like to make a workchain that starts from a given calcjob, i.e. it uses the same inputs and the produced temporary files (namely the wavefunctions) and creates new calculations by changing specific input parameters one at a time. I know I cannot start from the Calcjob node itself, so I wonder how you suggest to proceed: - expose the input for the calculation, copy all inputs (including metadata) outside the workchin and add as a second input for the remote folder? - use the uuid as input? This would allow me to use `calc.get_builder_restart()` that is ideal for the task I described. But a uuid of a calcjob as input looks a bit ugly, right? - other options? Thanks! ---
**Author:** ![mbercx](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/mbercx/32/345_2.png) [@mbercx](https://aiida.discourse.group/u/mbercx)\ **Post date:** [March 10, 2026, 8:32am UTC](https://aiida.discourse.group/t/starting-workchain-from-a-given-calculation-and-change-selected-parameters/717/2 "2026-03-10T08:32:56Z")
Hi @bonfus! I’ll just give some off the cuff suggestions, none of these are tested. > - expose the input for the calculation, copy all inputs (including metadata) outside the workchin and add as a second input for the remote folder? That would be my first inclination as well. I assume you want to be able to set any input of the `CalcJob` you are wrapping here, so exposing the inputs makes sense. Excluding the `parent_folder` when exposing the `CalcJob` input and making that a top-level one also seems reasonable. Using the UUID as an input won’t properly link the `CalcJob` node in the provenance. If the `remote_folder` of the `CalcJob` is the `parent_folder` input of your work chain, it’s only two steps to get back to the parent `CalcJob` anyways: ```python workchain.inputs.parent_folder.creator ``` To make it easier to use the workchain, I’d add a `get_builder_from_calcjob` method, where the first input argument is `calcjob` (can provide the `CalcJob` node itself, or any identifier). This will use `get_builder_restart()` and also set the `remote_folder` as the `parent_folder` input in the builder. Afterwards you can adapt the builder to set the new parameters, or you could consider also adding other input arguments to set the new parameters directly in the method. However, you may want to be more explicit in your API in what parameters are adapted, i.e. by adding a `new_parameters` input. Could you explain the use case some more, i.e. what is the goal of this workchain? ---
**Author:** ![t-reents](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/t-reents/32/82_2.png) [@t-reents](https://aiida.discourse.group/u/t-reents)\ **Post date:** [March 10, 2026, 9:37am UTC](https://aiida.discourse.group/t/starting-workchain-from-a-given-calculation-and-change-selected-parameters/717/3 "2026-03-10T09:37:49Z")
Hi @bonfus and @mbercx Just one additional comment. Otherwise, I agree with what has been suggested. Depending on how much you want to keep track of this in the provenance, you could also follow a similar approach to what is done in the `AiiDA-common-workflows`. There, we also want to parse some of the input parameters (i.e. the k-mesh) between the different calculations when computing the equation of state. In case keeping track of the provenance for this calculation is less critical, you could pass the `WorkChain` or `CalcJob` node as an input an make it `non_db`: > However, since you want to reuse some of the produced files, I think that the approach via the `parent_folder` is probably more suitable, as I assume that you want to keep track of the provenance. ---
**Author:** ![bonfus](https://yyz2.discourse-cdn.com/free1/user_avatar/aiida.discourse.group/bonfus/32/403_2.png) [@bonfus](https://aiida.discourse.group/u/bonfus)\ **Post date:** [March 10, 2026, 10:22am UTC](https://aiida.discourse.group/t/starting-workchain-from-a-given-calculation-and-change-selected-parameters/717/4 "2026-03-10T10:22:43Z")
Thank you very much! Just for completeness, I need this because I’m writing some kind of convergence algorithm and this is the structure I have in mind: - `check_convergence_workchain`: - task: checks the variation between simulations differing by one input parameter. Can also consider two calculations and report relative differences. - inputs: - calcjob1: a reference calcjob - calcjob2 (optional): a second reference calcjob whose results should be subtracted to calcjob1 - input\_params: dictionary with parameters to be changed and step to be used. For example in the context of QE it could be {‘ecutwfc’: +20}. - outputs: - dE: dictionary of energy differences between calcjob1 and calcjob1 with parameter in input\_params incremented by specified value. Alternatively, (calcjob1 - calcjob2) - (calcjob1\_with\_incremented\_param - calcjob2\_with\_incremented\_param). I hope notation is clear enough. - dF: same as dE for forces - dM: same as dE for moments This can be used in a variety of context, and one may be - `auto_convergence_workchain`: - task: run `check_convergence_workchain` with relatively small steps, check the largest value in entries of `dE` squared, increment it and run again a new `check_convergence_workchain` starting from the updated set of parameters until threshold is reached. - inputs: - exposed check\_convergence\_workchain - thresholds: when to stop the loop when convergence is reached - boundaries: when to stop because simulations would be too expensive - outputs: - exposed final check\_convergence\_workchain