Interest for DFT simulations job control package?


#1

Hi all,

I’ve worked on a package that automates a lot of tedious work one has to do when working with Density Functional Theory packages/simulations. It’s pretty fully featured, although ofcourse a lot extra could be added. At this point, it was developed as I was using it, so additions should and can be easily made, since the framework is all in place.

Features include:

  • Focused heavily on Quantum-espresso and WANNIER90 support
  • Tools to automatically set flags and other cards in different calculation input files
  • Job generation starting from .cif files ( cif->qe provided by cif2cell)
  • A lot of tools to read outputs and input files
  • Some post processing tools, like plotting band structures and DOS
  • Some Abinit support, but seen as I don’t often use it, must be improved
  • Integration with Juno for nice display of Jobs

Up until now it has been only me that used it actively, and there is no unified documentation and no real examples. Bearing this in mind, are there people interested in such a package? If so, I could put some more effort into getting documentation and examples going.


#2

This is certainly within the scope of Julia and at some point in the future someone will probably find this package to be useful. So if you are willing to provide documentation, I think it would be a good addition to the ecosystem.


#3

Yes please! Parsers/plotters/utilities are usually a pain, so anybody writing one ought to put it in the public domain and have a statue erected for their service. These things are useful as bits of code to steal in other projects, so a disordered collection of routines with example usage is better than a monolithic well-documented package where every file depends on the rest, IMHO. I have some tools for reading wannier90 input files and doing computations with them, if you’re interested: https://github.com/antoine-levitt/wannier. Out of curiosity, there are several tools for managing workflows in DFT (mainly python), why did you write one?

(cc @cortner)


#4

Okay cool, so I completely forgot to actually link the current package. It’s at DFControl.jl. I will start work on decent documentation and examples.

Well it’s one of those things that start small and end up being bigger. I didn’t really know there were these things when I started this (I actually still don’t know many). Also when I looked at for example AbiPy, it’s so convoluted and not straight forward. This package is really more like a tool to help you do what you would normally be doing: changing flags in input files. So it’s also structured like that. I didn’t aim for it to dumb down the interaction with the packages, merely as a way to uniformly interact with their input files, and also hopefully take out some of the easy mistakes like typos and the like. I’m using it every day, and I must say it makes everything a lot more streamlined.

Also as usual, issues, feature requests, pull request and the rest of the shebang are muy apreciado!


#5

I have added a README with basic getting started and installation. I also added 3 examples that should get you up and running!

I also added all current documentation, but this will get improved upon later.

Please let me know what you think, I will try to get the package registered, after which I’ll do a real announcement.


#6

Please have a look at Libatoms/ASE.jl - it allows you to call any model available within ASE from Julia.


#7

PS: I didn’t mean to imply what you are doing is already available - I actually doubt it, but it could be nice to either use what we already have or at least coordinate.


#8

Oh yes, I’ll have a look at it! The way Structures work was a pretty late addition, I forgot to have a look around for package that handle that.

I also wanted to be as independent of Python as possible, it adds a lot of startup time it seems.


#9

Also - ASE.jl came out of some refactoring, and still needs some cleanup. Specifically, you need JuLIP branch jatoms to get it to run. Any problems, Please file issues and I’ll respond ASAP.


#10

True about startup times, this is one of the reasons for the refactoring I mentioned, but when it comes with a unified and well maintained interface to ALL major dft codes . . .


#11

Euhm yes, I actually didn’t know about ASE until pretty far into this :sweat_smile: