search

greschd / aiida-optimize

Defines AiiDA workchains that simplify running optimization workflows.
Apache License 2.0
2 stars 6 forks source link

Is there a way to give custom outputs from custom engine? #35

Open unkcpz opened 3 years ago

unkcpz commented 3 years ago

https://github.com/greschd/aiida-optimize/blob/718253280a0881a1cf9140f55b84bb979ec0b991/aiida_optimize/engines/_convergence.py#L188-L197

The _get_optimal_result is fix to give a three elements return value. This limit the chance to give more outputs from the engine inherit from OptimizeWorkChain. How can I add more output into custom engine?

greschd commented 3 years ago

Currently there's no way to control this from the engine implementation. Could you describe the use case in a bit more detail? Do you need to forward outputs from one of the sub-workchains, or a property of the engine itself?

Maybe we can extend the engine interface in a way to make this possible.

unkcpz commented 3 years ago

Could you describe the use case in a bit more detail? Do you need to forward outputs from one of the sub-workchains, or property of the engine itself?

I face two kinds of scenarios which count on this feature:

(1) When I use Convergence engine besides from output the opt_index, opt_input, opt_output I also want to get, for example, the true tolerance to which the result is converged. (2) I reimplement the convergence engine which accepts an extra input(in my case both the ecutrho and ecutwfc at the same time), but within _get_optimal_result I am restricted to only output one of them.

greschd commented 3 years ago

Yeah, I can see the use case for both of these.

For (1) I think we should just extend the engine interface with a method (e.g. _custom_outputs). One thing to consider is how the provenance of the output node works, i.e. should it be created by a calcfunction? This ties into a discussion I had with @zooks97, in general the provenance in aiida-optimize needs improving.

For (2), I think we can modify the OptimizationWorkChain such that _get_optimal_result can decide to return a dictionary of inputs. In that case, it would go to a (new) output namespace, instead of optimal_process_input. While we're at it, we should also think about how multiple outputs are handled (although, we don't yet have an engine that handles multi-dimensional output).

In the meantime, I think (2) can be worked around by going through the process UUID and "manually" getting its inputs. Not ideal, but it should at least work. For (1), I don't see an easy way workaround, so maybe that should be our first priority.