There is a quantum chemistry and physics framework called QuantumLab.jl, but It seems there are no updates for a while, and it doesn’t work with the latest Julia and libraries.
Does anyone know if there are any alternatives or prospects to revive the framework?
In general, I search something like PySCF alternative
Unfortunately to the best of my knowledge there are no active registered quantum chemistry packages in Julia.
WRT QuantumLab.jl it’s probably best to fill an issue, but it seems to me its development stopped.
This project is in very early stages, but I have, as part of my PhD research, recently begun work on an electronic structure package called JuES (Julia Electronic Structure). The package isn’t much to write home about, but outside help is very welcome! GitHub - mdav2/JuES.jl: Quantum chemical simulation in Julia
EDIT EDIT: I realized I was more answering @mdav2 than OP. Sorry about the confusion.
There is JuliaAtoms (disclaimer: I’m the author): Home · JuliaAtoms
It is written mainly for atomic physics, but with wider applicability in mind for the future. You could benefit from EnergyExpresions.jl that sets up symbolic energy expressions between lists of Slater determinants, which you then have to interpret, depending on what kind of orbitals you are working with. For atoms, the interpretation is done by AngularMomentumAlgebra.jl. For molecules, you need some implementation of molecular orbitals (and preferrably also some group theory). I will add that in the future, but it is not high on my priority list.
For SCF there is SCF.jl, which is also independent of which quantum system you study. So far it only works reliably on the Hartree–Fock level. It performs linear optimization by solving eigensystems for the different orbitals using ArnoldiMethod.jl. After a certain level of convergence is reached, it switches to non-linear optimization using BFGS from Optim.jl
(EDIT: Nothing from JuliaAtoms is registered as a package yet, since I don’t feel the test coverage is high enough.)
However, if you’re learning how to write quantum chemistry codes (as I am), I think it is more useful for you to write the basic building blocks yourself, to understand the details on all the levels. If you want to be productive in calculations, it would conversely be more efficient to use an already existing code (MOLPRO, &c), since it is really a multi-year (some decades) effort.
CC @antoine-levitt could have other input; I think he is also working in electronic structure
I’m developing Elsa.jl (it will probably change name when I finally release it). It aims to be a tight-binding modeling and computation package, a bit like python’s kwant (kwant-project.org), including electronic bandstructure, green’s function and transport. I am very committed to its development and have lots of plans for it, but as a solo dev the pace is not so fast at the moment. Input welcome!
Currently you can build arbitrary lattices and (multiorbital) Hamiltonians and compute bandstructures. The kind of syntax is like this (e.g. spinless next-nearest-neighbor graphene 3x3 superlattice with random on-site potential)
julia> using Elsa, ElsaPlots
julia> h = LatticePresets.honeycomb() |> hamiltonian(hopping(1, range = 1) + onsite(r->rand())) |> unitcell(3)
Hamiltonian{<:Lattice} : Hamiltonian on a 2D Lattice in 2D space
Bloch harmonics : 7 (SparseMatrixCSC, sparse)
Harmonic size : 18 × 18
Orbitals : ((:a,), (:a,))
Element type : scalar (Complex{Float64})
Onsites : 18
Hoppings : 162
Coordination : 9.0
julia> bs = bandstructure(h; resolution = 81, method = LinearAlgebraPackage())
Step 1/2 - Diagonalising: 100%|███████████████████████████████████████████████████████████████████████████████████████████████████| Time: 0:00:00
Step 2/2 - Connecting bands: 100%|████████████████████████████████████████████████████████████████████████████████████████████████| Time: 0:00:00
Bandstructure: bands for a 2D hamiltonian
Bands : 9
Element type : scalar (Complex{Float64})
Mesh{2}: mesh of a 2-dimensional manifold
Vertices : 6561
Edges : 19360
julia> plot(bs)
The plot command uses Makie. In this case it produces these bands
Unfortunately documentation and test coverage are still WIP (we have docstrings though), and the package is still not stabilized
We develop https://github.com//JuliaMolSim/DFTK.jl/, which does kohn sham DFT in a plane wave basis. We setup the JuliaMolSim org with @cortner to group packages in that area ; anybody interested can join!
@pablosanjose that looks very nice! Christoph also has a tight binding code
Cool! Link? There is also GitHub - cometscome/TightBinding.jl: This can construct the tight-binding model and calculate energies
Thanks for the info about your package, I’ll definitely check it out. And yes, to be clear my package is mostly for personal education and later for working on ML accelerated solution of CC equations; I use MOLPRO and Q-Chem for my “real” work.
Our TB code(s) focus on potential energy surfaces and molecular mechanics rather than electronic structure. (And are still quite experimental) Maybe there is a chance at some later point though to combine some of these packages.
For playing with different self-consistent field methods based on pregenerated integrals, I started GitHub - mfherbst/SelfConsistentField.jl: A Julia toolbox for coding self-consistent field algorithms at some point, which never made it past the trial stage and is kind of abandoned now in favour of working on DFTK.jl. But maybe someone still finds it useful in the discussed context …
Thank you @XVilka for raising an issue on the QuantumLab github page and making me aware of this thread. I hadn’t realized people were waiting for an update.
I will release a new version in a few days. I’ve pushed some code today and the code on github should be mostly up-to-date now.
Before I can tag a new release, however, I still need to make some major changes to the BasisSetExchangeModule, because the new BSE webpage has gone live and the interface has changed completely. So the CI tests don’t pass yet, but as long as you don’t need those you should be good. For now you can just download basis sets manually, making sure to disable sharedSPDF in the advanced section of BSE. Note that the TX93 format is now called “PQS” by BSE.
I looked a few months ago and found that pyscf was far more developed than any Julia package, including QuantumLab.jl.
That is certainly true. I started developing QL before joining the Chan group here at Caltech (the driving force behind pyscf) and these days even I am mostly working in pyscf for my everyday research.
QL is a long-term project, but for the the foreseeable future pyscf will stay the framework of choice. Simply because most quantum chemists know python but hardly anyone knows julia — so every julia project necessarily lacks the manpower.
Based on observation, I think people often choose python over Julia for computational projects because they don’t know the difference between them. If you understand what Julia and python can do, choosing python over Julia for a long term project just because you know python better is irrational.
This is a general statement that applies in many cases, but certainly not all. If there are well-developed and performant libraries for your project in python that do all the heavy lifting you need, and they don’t exist for Julia and you can’t afford to write them, then choosing python makes sense. I also have preferred python in rather scripty, but still scientific, situations where the lack of jit penalty makes up for the irritation of its limitations.
I’m not an expert, but pyscf looks like a great piece of software that encodes great expertise. You could judge better, but at least in terms of performance, it doesn’t seem to suffer for being largely python. (Expressiveness is another matter) Still, it’s great to see QL being developed. If I have to use pyscf again, I’ll revisit QL.
On the other hand, the performance and memory use of OpenFermion suffer greatly from being written in (pure) python. It would be relatively easy (say compared to pyscf) to write this in Julia with huge performance gains. Otherwise, OpenFermion is a great project. I don’t know if Julia was considered, but I think OpenFermion was started before 1.0, which would have been a mark in the disadvantage column.
One point to consider is that most of these codes have well-identified bottlenecks (eg computation of bielectronic integrals, tensor contractions, FFTs, diagonalizations…). In that case, as long as you take care of these parts and don’t screw up the rest too much it doesn’t matter so much what language you choose performance-wise. There are a number of python codes that have their bottlenecks written in C/Fortran, and manage to keep complexity to a minimum (eg pyscf, gpaw). Julia is much nicer than python for scientific computing, but performance often does not matter that much, and the productivity boost going from python to julia is much smaller than the one going from C/Fortran to python. I’d be happy enough when everybody in the community has switched from Fortran to python; julia is the next step.
Yes. pyscf is a good example of code where the bottlenecks are written in C and maximum advantage is taken of the dynamic language. In my limited experience, it outperforms psi4, which (If I’m not mistaken), has a higher ratio of c++ to python (ie It claims to be a python wrapper on c++ core). Maybe every case is exceptional so that generalizations aren’t worth much. In any case, OpenFermion is riddled with inefficient parts, and pure python data structures. For large enough systems, it’s not just slow, it runs out of memory. For small systems, it’s quite usable.
Choosing not to rewrite a nice python package in Julia is reasonable. Starting a project that is well suited for Julia in 2020 and choosing python instead is harder to defend.
That’s correct. pyscf is basically a python code, where independent kernels are “outsourced” into low-level languages and Psi4 is the reverse, i.e. a (rather big) C++ code, where the largest chunk of the functionality is made available to python and development to a large extent happens now on the high level. Historically Psi4 was only C++ and to the best of my knowledge they were the first to integrate python at all.
Generalisations are seen rather critical in the quantum-chemistry community from my experience. I think that is on the one hand due to the fact that quantum chemistry is inherently a complex problem, such that the right generalisation is far from easy to find. Naturally, some aspects, however, keep coming up over and over and thus are attempted to generalise. This includes rather computationally intensive parts such as integral computations, tensor contractions, solving response problems etc. In some codes this has lead to rather involved hierarchies of classes and OOP-style inheritances for these procedures, which are not easy to deal with as a developer… Also this makes it harder for compilers / people to spot places for optimisation, such that it is a belief in the community that general code is slower and more complex. As a result people seem to favor code duplication to generalisation.
Psi4 and pyscf make a good attempt in my opinion to show how a high-level approach to quantum chemistry can work. Still in both codes pealing off the layers of classes and methods until one gets to the place where things are actually done can be a bit of a challenge … Part of the reason is certainly that both projects are implemented using two languages, but part is also that OOP approaches inherently lead to a split of functionality into many different classes, functions and files in my experience. One can certainly work hard to limit this. I know that pyscf for example tries to be more functional and keep inheritance hierarchies minimal, but such approaches are less in line with the design of python and C++ as languages.
In this aspect I think Julia’s more functional approach building on multiple dispatch has a clear advantage. In my experience decoupling code, keeping flat call hierarchies and low code complexity is a lot more natural to obtain. I therefore think that a true Julian design brings more advantages to quantum chemistry codes than just the performance.
I’ve just registered the newest version of QuantumLab. It should be running smoothly again. Sorry this took a few days and please feel free to raise any issues you may encounter going forward at https://github.com/vonDonnerstein/QuantumLab.jl
And just to answer the question at the head of this thread:
QuantumLab.jl has not been abandoned and will continue to be maintained! 
You can use PySCF from Julia as well (it is almost straightforward). I have an example where I do up to CCSD with Julia and check results against PySCF. It is here: https://github.com/zyth0s/SciAlgs.jl/blob/master/src/ElStruct/pyscf.jl
If you want to test novel methods with the help of a robust package you may be seriously benefited from using Julia. I had the same script written in Python and the CCSD part was much slower.
