aiida-quantumespresso
aiida-quantumespresso copied to clipboard
aiidateam
Output node documentation
Could you please somewhere document how a standard output node looks like?
I.e just copy paste a standard example of a ParameterData node for a PW (and others) calculation in the docs. That way other plugin developers can stay close to the QE output nodes, (warnings have the same structure, or certain key names are the same). It is not feasible to look in the plugin in code, or run a QE calculation to get this. Also this way users can discuss what might be missing.
Thanks!
Do you mean the structure that the BaseRestartWorkChain now expects, if you decide to use that or just in general? We might actually have to change the output parameters structure a bit in the near future because we want to improve the error/warning messaging system
I mean in general: in the docs it just says that a ParameterData node will be returned for a PW calculation. Not what keys should be expected in the dict, (calc.res), or what values for the keys. When I first started I looked at the QE PW node and made sure that keynames are similar.
When writing software ontop/workflows, queries what ever, its good to know how such a node looks like (key value) not only what type it is.
Currently I had the warning system in mind, because on the side I add here and there some stuff for fleur. So how does the value for the warning key in the output node of PW currently look like?
warnings : {'info': [], 'error': [], 'warning' : [], 'critical' : []}? do you want to change it?
Currently it will always contain at least two keys (unless there was a real exception during or before parsing) warnings and parser_warnings. I never wrote the PwParser so to be honest I do not know the exact qualification for each, but roughly the warnings thrown by pw.x itself will be written to warnings and any parser specific warnings, i.e. it wasn't able to parse something or find a file, are written to the parser_warnings key. They are both lists of strings. In the error handlers of the workchains we then simply search these strings and act accordingly. This system is extremely fragile and we intend on replacing the strings with proper error codes, with human readable strings attached to them. But then at least the workchains can programmatically refer to those well defined error code. The reason I have held off on doing this is because I want to combine it with the effort to move the parsing to using the xml output instead of the stdout file.
As to your edit in the post above: the warnings list contains no structure at all. It is simply a list with strings.... exactly the reason why we should improve it
This is indeed related to #6 but that would only be part of the problem. We would still do well to discuss with prominent plugin developers on a unified input and output definition of common workflows. We are planning to organize a coding week in Lausanne especially for this purpose. Let's keep this issue open for now
Probably not entirely precise in its description anymore, but still relevant considering our woefully outdated docs. Assigned the correct label so I can pick it up in a next round of documentation updates.
