JuDFTteam / aiida-fleur

AiiDA plugin of the high-performance density functional theory code FLEUR (www.judft.de) for high-throughput electronic structure calculations.
https://aiida-fleur.readthedocs.io
Other
14 stars 7 forks source link

further cmdline features requested #99

Open broeder-j opened 3 years ago

broeder-j commented 3 years ago

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:

  1. Fleurinp: print out symmetries since they are bound to k-mesh
  2. FleurinpModifier: in general the modification of an existing Fleurinp could be implemented as cdm options
  3. Some methods that automatically generate inputs to continue a workchain. For example, If SCF failed due to time/iteration limits (but was converging), one wants to continue the SCF. That would be much easier to just type-in aiida-fleur generate inputs --from (workchain_pk) which returns required inputs and some info on how to modify and use it. Please refer to the figure below for details: for some reason user decides to continue converging SCF 1. For this he/she needs to not only gather basically the same input Dicts and Codes, but also find the corresponding RemoteFolder in the SCF 1 which is not user friendly. Hence that would be nice to have a method that prepares an input dict from SCF 1: it gathers the same Fleur Code, input Dicts and also adds RemoteFolder from the last FleurCalculation. Of course we should give a user a chance to modify input parameters - I would call this cdm option as a 'builder'. Such kind of cdm options would be very helpful for all of the workchains: EOS - to add new volumes; Relax - to continue from partly relaxed structure; magnetic workchains - to perform force theorem calculations starting from already converged reference; CreateMagnetic - to start from any place from EOS to final generation of the magnetic structure.

image

Jens:

  1. 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 with aiida-fleur data fleurinp cat <pk> | grep row- Since we can cat any file in fleurinp, one can just grep for everything.

    1. 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?

    2. 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. ;-)

broeder-j commented 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.

broeder-j commented 3 years ago

commands to prepare easily wf parameter and other dict nodes, also commands to list the default inputs of a certain workchain.

broeder-j commented 3 years ago

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.

janssenhenning commented 2 years ago

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