Open broeder-j opened 3 years ago
A garbage collection command would be nice. I.e workflows should not autodelete, but could write something in the extras.
Example all wc which fail write:
tash_fail: True
Test submission scripts write:
tash_test: True
If we do this, we can simple expose a command which runs a usual aiida delete over all those. This has to be taken with care, since not further connected inputs will also be deleted.
commands to prepare easily wf parameter and other dict nodes, also commands to list the default inputs of a certain workchain.
The -s structurefile option should support the inpgen input file The --fleurinp option should support inp.xml files, or a list of files with an inp.xml file.
A command aiida-fleur code inspect
or aiida-fleur code configure
which looks into a configured fleur code to figure out it's properties and them as extras. Then we maybe can start using these extras optionally to get rid of some of the quirks of the current code configuration, meintioning hdf5
in the description
An additional aiida-fleur code show
to display these extras together with the standard configuration
Here we collect feature requests for further cmdline options. Not all were yet implemented in the first cmdline implementation.
Collected:
Vasily:
I think I have come up with several suggestions:
Jens:
is easy I will add this, because I will add an option to run this through spglib and get the sym group, number and ggf other information. Overall, I do not want to add to much of these, since you can already do this with:
aiida-fleur data fleurinp cat <pk> | grep -i3 symOp
or withaiida-fleur data fleurinp cat <pk> | grep row-
Since we can cat any file in fleurinp, one can just grep for everything.With this I also agree, Fleurinpmodifier is also meant to be used interactively for example in ipython. Through, I currently do not see how to best expose the whole Fleurinpmodifier functionality in one command. Or do we just expose a fixed small set of cases on the cli that people often want to do?
Would first have to be designed and implemented as an internal function/tool also with choice to keep the provenance. Which interface we then expose on the command line. I like this idea to give the user power to clean up 'per hand' on failed stuff. In general for this one should also disable (certain) failed calculation as valid caches. ;-)