GUIs for Quantum Chemistry... Where are they?

Question

I have a general and maybe a little silly / funny question.

Why don't most CompChem or QuantumChem software have a GUI? SIESTA is trying with Simune as far as I know, but even proprietary software like GAUSSIAN or VASP is not doing any good.

It seems that the development of a GUI for such software is somewhat obvious and would cause an explosion of interest. Essentially, with a good GUI all you would need to do DFT calculations, say as an experimentalist then, would be an understanding of DFT and even a marginal understanding of the parameters. You can then create an * input * file from a series of lists and choices, then run the calculation with a button (a bit like the optimization function in AVOGADRO but with DFT and many more parameters). You can then add a graphical interface for your spectra and a visualization program. You can maybe interface this with the multiple software that are available (sort of like what ASE is doing ?).

I'm a bit lost with what I am trying to say. Maybe a sort of MATLAB for matter modelling would be the more appropriate way of defining what I feel is lacking in this space.

EDIT on 18/11/2021 : Thank you everyone for these very clear answers !

Answer 1

Gaussian has Gaussview, QChem has IQMol, Schrodinger has Maestro, Quantum ATK and BIOVIA Material Studio each have their own GUI. Notice, that both the program and GUI in these cases are paid products (except IQMol). There are also paid GUIs that work for several different programs, such as the Amsterdam Modeling Suite and Chemcraft. This hints at part of the problem: for developers in academia/industry, time spent on a GUI is time spent not doing other research or developing their core software. This leads to developers charging for their GUIs, only incrementally developing them, or just not making one at all.

However there are also a number of free GUI, both for setting up and actually running calculations. To give just a few examples:

• Gabedit- allows you build molecules, make/run input files for several different electronic structure programs, and view results from output.
• Avogadro and Avogadro2- builds molecules, makes input files, and views results.
• MoCalc2012- interface to Avogadro/JSmol to make molecules, can make/run input files for several different electronic structure programs.
• WebMO- build molecules, make/run input, view results.

Some of these are supported by donations, some have tiers where only the basic program is free, and some have ceased development altogether. While there are a number of programs that can build/visualize molecules, it can challenging to make a program that goes from build->input->results because of the variety of programs that one could potentially have to support for the latter two steps, not to mention possible licensing issues with interfacing to these external programs.

The takeaways from all this are:

1. There are a wide variety of GUI programs, both free and proprietary, available for various stages of setting-up/post-processing a calculation. Some even work end to end.
2. It might be more challenging than you would think to make a general purpose GUI for even just Quantum Chemistry simulations, let alone the various other types of Computational Matter Modeling (Molecular Dynamics, Docking, Cheminformatics, Material Design, etc).

Answer 2

My answer to "GUI for DFT calculations" is a good introduction to my stance on this issue, but I will address your more specific questions here. First for some preliminaries:

• Software development is expensive (whether monetarily, to hire developers, or temporally, in terms of the time and energy that goes into it). Almost all of computational chemistry and quantum chemistry is developed and used in academia, where money and time are scarce. There's companies that are in the business, but I imagine that it's hard for them to make a profit when the field is already dominated by people in academia who make open-source and free software involving lots of hard work and labor for very little financial return.

• In both the question and the first (and only) comment so far, Gaussian and VASP are the two poster cases mentioned. Both of them are expensive and have "unusual" business practices which suggest that they're not doing extremely well financially, or need to resort to extreme tactics in order to do so: (1) Gaussian bans anyone who compares its performance to other programs, often along with their institutions, and kicked out its founder, Nobel Prize winner John Pople; (2) VASP doesn't allow anyone to use their online forum unless they have paid for the expensive license. I don't know as much about VASP, but Gaussian is far from state-of-the-art for what it does. It is one of the slowest electronic structure programs, and can't do things like CCSDT which is available in free software like CFOUR, MRCC, NWChem, etc., cannot do (in the publicly purchasable version) the 1- and 2-electron integrals for basis sets containing L-type orbitals and beyond, whereas OpenMolcas, MRCC, Psi4, etc. can treat L-type, and often even more types of orbitals. Gaussian also can't do more modern electronic structure techniques like FCIQMC, DMRG, SCHI, etc., which are all things that have been incorporated into open-source packages like OpenMOLCAS and/or PySCF. As with almost everything in academia, quantum chemistry is constantly evolving, which makes it very hard to develop and maintain GUIs.

• "It seems that the development of a GUI for such software is somewhat obvious and would cause an explosion of interest."

I am not convinced that there would be an "explosion of interest". Enrollment in chemistry and physics has decreased in recent years, while interest in computer science, economics and even psychology has increased. I don't think any of us have thousands of students knocking on our doors asking to work on computational chemistry projects, and I'm certain that introducing GUIs will not change that. Maybe some experimentalists would like to see a GUI, but evidently there hasn't been a big enough demand for anything beyond things like GaussView, otherwise like most things in academia, where there is a demand there is a supply (from people who wouldn't mind having their citation count "explode").

"You can then add a graphical interface for your spectra and a visualization program."

The word "spectra" can mean a lot of different things, but the spectroscopy software PGOPHER does have a GUI that allows you to visualize spectra, and while it does have a lot of users in the small-molecule spectroscopy community, that community is relatively small compared to some other areas which interest computational chemists. Honestly, despite going to a PGOPHER workshop, I never quite figured out how to use PGOPHER the way I did the command-line electronic structure theory programs (maybe because I had someone show me one-on-one how to use MOLPRO at the beginning, which I didn't have for PGOPHER, or maybe because I never read the PGOPHER manual as thoroughly as I did the manuals for other small-molecular spectroscopy programs like DParFit, DPotFIT, BetaFit, LEVEL, RKR, etc., but largely because I found all the buttons on the GUI quite overwhelming!).

" Maybe a sort of MATLAB for matter modelling would be the more appropriate way of defining what I feel is lacking in this space."

I absolutely love that you said that, for so many reasons! MATLAB is my favorite software for general numerical computing, and I've mentioned it a lot here. The first electronic structure software that I used heavily was MOLPRO, and I often called it the "MATLAB of quantum chemistry", although it doesn't have a GUI. The GUI is not the main feature of MATLAB either (the comparison was more for it's speed, convenience, and of course, price, among other things). There's a couple things for me to say regarding MATLAB, GUIs, and computational chemistry:

MATLAB's primary strength is in doing fast calculations from the command line, not in its GUIs. I can't talk about every single GUI that MATLAB has, but I'll mention the three main ones I've used (which I do like, don't get me wrong about that!):

• The curve fitting toolbox GUI. This is so convenient for fitting data, especially compared to only using the command line, because it's so important to see how well the fit actually matches the shape of the curve (a single RMSD value without any visual information is not enough!) but when you use it, I'm sure you often find yourself frustrated with its lack of options to grab the "hidden" data, and you might find yourself needing to combine the use of this GUI with the actual command window.
• The command window and editor. These are extremely slow, which you can see by opening MATLAB as a GUI vs opening the command-line version. Especially on a compute server (which is pretty much ubiquitous in computational chemistry), you don't want to be using a GUI (see my answer to "How can I use a GUI on a supercomputer?"). The editor is just an editor, like VIM or emacs, but I do admit that it's extremely useful for debugging MATLAB code. Unfortunately even MATLAB's debugger is nothing compared to an EDI like Dr. Java or Eclipse, and you probably don't need me to explain why making a full-fledged GUI debugger for GAUSSIAN, VASP, or any other matter modeling software is not high on the priority list.
• MATLAB's GUI for making figures. This is where I think MATLAB really wins against its competitors like numpy, Mathematica, Sage, etc. However, it does have its flaws and glitches, and on top of that, I always use it in combination with the command window. Based on the quality of MATLAB's GUI for making figures, despite its decades of development and multiple billions of dollars of total revenue, you can imagine that it won't be easy for a matter modeling researcher (or company) to make a great GUI for making publication-quality figures. It's inconvenient, but I just copy my data from the matter modeling software, into MATLAB to make my figures, as I explained in my answer to this question which I already mentioned here: "How can I use a GUI on a supercomputer?").

Answer 3

As two people asked me to convert a comment to an answer, voilà:

The notion of an "easy to use, spits out the result GUI" is an "industry approach" where obtaining a result matters more than the minutiae of how said result is obtained. For this group there exists at least one commercial quantum chemistry product from the Netherlands. I used a trial version and the automation actually irritated me... - There you built a molecule and the software would go as far as to suggest a functional and method. "Input in, output out."

If we move to the quantum chemistry research field which is significantly bigger than industry use (at present), the users are either learning how to use quantum chemistry or are already experienced in it. In this case you want to be able to explicitly control your inputs - maybe compare functionals, basis sets: a GUI can even be a hindrance if you like using scripts. (Its easy to run a benchmark when scripts do a lot of work ;). Keep in mind that most calculations in quantum chemistry are relative and not absolute. You want to compare the difference between A and B, you need to be sure that A and B are calculated using the same methods.

Now an interface could accommodate all possible combinations, however once you attempt to cover all options, you arrive at an unnecessarily complex GUI. As a result, a GUI will often propose only a subset of options. The most frequently or well known functionals, commonly used basis set. If you use the GUI as a text editor, then its use is limited - especially if you need to know your inputs anyway. A light text editor is much faster. (Look up the GMTKN benchmark - there is one from 2017 which evaluated functionals. How do you want to support all in a GUI in an easily usable manner? You cannot. Given the number of functionals that exist, documentation with a long list and a text editor is actually the best solution for experienced users. And then you need to update it every time a new functional comes out...)

The main interest in/reasons for using a GUI in quantum chemistry are:

• building the initial molecule (though you might even be running calculation son an existing benchmark set of xyz co-ordinates)
• visualizing frequencies (I do not think you can really understand the frequencies without a GUI, BUT you can easily calculated with the resulting values without seeing them.)
• visualizing for example an IRC calculation to verify that you have obtained the correct transition state.) The vast majority of information that you obtain from quantum chemistry calculations are available in plain text in the output file, you do not need a GUI to read the value. In some cases, you can even be unsure as to what the actual value in the GUI is... (There is a certain US product where I believe the GUI and text file provided different E0 energies, possibly shifted by the Zero Point vibrational Energy...) So once again, if you are doing research, it is much faster to run a script to pull the values from the text file than clicking around a GUI to do the same thing. - Plus you know exactly what value you are getting from where and how. Now it can be said that the output of some quantum chemistry code is atrocious in its formatting - mainly a result of the age of the underlying code and there GUIs invariably provide some benefit, but they aren't the perfect solution either. (See my E0/ZPE comment...)

Nowadays my favourite quantum chemistry code is ORCA, which, due to having a much younger code base compared to other codes, provides very clear and structured output that you are much better off accessing "as is".

This brings along another important question: Should software retain the same file format when the limitations become more and more obvious? - If your output file is not easily usable, it makes more sense to update the output in a future release to be more legible, rather than creating software that attempts to interpret data displayed in an overly complex manner. (Typically a concise manner relate to limitation in Fortran several decades ago.)

The utility of a user interface further directly depends on the complexity of the input. Standard "Gaussian type functional" quantum chemistry has today become (in many forms of its application) trivial and standardized with xyz input and ouputs for geometries. (Yes, I know that metals and heavy atoms require a careful choice of method from functionals to basis sets.)

In contrast, setting up a quantum chemistry simulation for periodic systems using plane waves benefit a lot more from user interfaces. While it is easy to specify a "trivial" structure such as for example solid diamond based on literature parameters, the investigation of real life crystal structures (maybe with adsorbents) benefits tremendously from assistive software. I looked at plane waves briefly a good 10 years ago - and defining a good input is already a non-trivial subject. (Also the fact that neighbouring cells interact, etc. etc.) Back then I was shown a specialized GUI in another department - which helped them define their systems. - And these softwares are not cheap as far as I am aware. On the free side I am aware of only ECCE (for NWChem) and VESTA.

Another field that benefits a lot more from user interfaces is Molecular Dynamics. While I'm sure experts can configure these easily from text files once the initial configuration is done, developing the initial understanding is not trivial. However as far as I am aware, in the case of GROMACS, the input has changed multiple times in incompatible ways between versions... (Again, about 5 years ago I looked at Molecular Dynamics and failed and stuck to my Gaussian type functionals/calculations that I know how to do.) As far as I am aware there is maybe one major Molecular Dynamics interface that can be had for free (for academic use) which is VMD. After that, the interfaces that exist are often commercial: Potentially because we return to the previous point. Industry wants results (and Molecular Dynamics if of interest in the pharmaceutical filed) while scientists want to understand the system and thus often want to modify minutiae in the configuration.

Answer 4

There are quite a few graphical programs for quantum chemistry programs. The problem is that, as a rule, you need several of them at once. Each small subtask has its own program. There are programs that allow you to visualize structure, 3D data, etc. All kinds of charts are built in specialized programs. Users of not the most common programs have problems. They have to write small scripts or programs on their own to convert their data to formats supported in existing programs.

The idea of writing a program that almost automatically creates input files, runs the calculation and displays the results seems to me almost impossible for scientific calculations. In addition to the rapid development of quantum-chemical programs, which will require constant refinement of the function of generating input files, there is also a more serious problem. Quantum chemistry programs are very computationally intensive. They are run on remote clusters. These clusters use task queues. It may so happen that the task will be launched only after a few days. There is no need to talk about any real-time visualization here. In addition, the choice of simulation parameters is a scientific task. It cannot be automated.

I have been using the SIESTA program for many years. Despite the abundance of scripts (console) for processing the calculation results, I was constantly missing something and I was writing my programs. At some point, a program appeared that I was not ashamed to show to the scientific community, and I posted it on the github (GUI4dft, https://github.com/sozykinsa/GUI4dft). The program is my attempt to help SIESTA users get rid of the need to combine multiple programs and get away from the console. I really hope this will lower the barriers to entry for new users.

Answer 5

As mentioned by other answers, there are multiple programs already.

Certainly what you describe, is why I created Avogadro in the first place. A program that makes it easy to build molecules, materials .. systems, allows you to run multiple programs (which we do for research), read the output, and perform analysis, etc.

Avogadro has perhaps been too successful - it's hard to get momentum to finish v2 because people are still using v1.

What we've tried to do with Avogadro 2, is make it easier to edit / update interfaces to computational programs. They're all Python scripts, and available on GitHub: https://github.com/openchemistry/avogenerators

There's also code for plotting, generating surfaces.. etc.

ASE has done quite a bit towards a "MATLAB for computational chemistry." It's maybe not ideal for molecular transformations, but I think that's largely because Open Babel and RDKit handle many of those tasks.

I agree a lot with Tyberius' answer in that many commercial packages funnel license fees into graphical interfaces. (GaussView isn't actually developed by Gaussian, but that's a different story.)

Otherwise, it's a matter of people with time / interest in contributing to open source efforts like Avogadro.

Answer 6

I come from an entirely different academic field and my answer is based on what I've seen across a variety of disciplines and my experience with software development.

You can essentially break down any scientific GUI program into two parts: the part with the core functionality that can work perfectly fine as a console application, and the part that is the UI.

The first part is essentially mandatory; you can't run an analysis without the core functionality. That means someone has to spend time and resources creating it. Writing a console application is relatively simple, especially if you want it to be cross platform. There could be some platform specific features you need that complicates this, but many of the core things you need are platform agnostic (like adding two numbers) and the language you're using will handle the platform specific details in the background.

UI development is very different. Every platform has it's own libraries for creating UI components. There are libraries that abstract this away and allow you to write cross-platform UI code, but they can be very complex and time consuming to learn. Time that could be spent on other tasks, like developing more functionality in the core program, developing different programs for different tasks, or even doing other things like lab research that has clearer advantages for one's career.

On top of learning how to code UI's, you also have to learn to how to design good and effective UI's. That is very difficult to do and takes time to get right. You have to learn to balance usability and intuitiveness for the user with how to provide full functionality. And you may end up in a situation where adding or changing something major in your core program forces you to spend a lot of time redesigning your UI when with command-line parameters all you might have to do is add a new flag.

But then, after the GUI has been designed and created, it's a new source of maintenance burden. That means a program with a GUI will have to have time dedicated to fixing GUI issues for users, especially if an OS (or other system library) update breaks it. That's time that could be spent on other things more productive to one's career or research aspirations.

A final thing is documentation. Creating good documentation for GUI software is more difficult and time-consuming than for command-line parameters (including lots of screenshots involved). And changing the design of the UI potentially means significant documentation updates.

Now, there certainly are benefits to a GUI. In my field, researchers tend to be less technically proficient with computers and have very little experience with the command-line. That means they tend to avoid console applications and are drawn to software with a GUI. In that case, taking the time to develop a GUI for a piece of software may make sense for growing a large user base. Personally, I have the background in software development where I'm hoping to make a career of writing software with good UIs for researchers in my field (which is why the question title caught my interest on the homepage). But for other fields where people might be more proficient with things like the command-line, it may not make sense as a time investment.

Answer 7

The commandline scales, a GUI doesn't

There have been some excellent answers so far, but I'd like to add a general one. I'm a computational biology researcher, so different field, but we spend considerable effort teaching Phd and Msc students how to use commandline tools. Why? Because they let you do bigger computation.

A GUI is great, until you've outstripped the available compute power of the computer or server you're working on. Then, suddenly, you're into an High Performance Compute Environment. Even a university one is unlikely to have a way of handling a GUI. If it does, it will be clunky, and not let you get the most out of the jobs you're writing.

If you have to go up another step, to something like a national tier cluster, there is no chance of a GUI. Jobs you submit are tightly controlled, and extremely automated. Lessons you learnt while getting the previous steps to work are vital here.

Commercial companies often supply GUIs. This generally is because their next computing tier is a cloud based thing, normally accessed through a website. There's also a certain amount of value for them in obfuscating a little what their software is doing in the background, either because it's commercially sensitive, or because the tools they are using are freely available elsewhere.

The other point to note is on reproducibility. A script or a series of commands is great here. When you come to publish your paper, the exact script you used can be included in the appendix or methods. Along with the (versioned) list of software you used, and the original data files, a person reading the paper should have no problem recreating precisely what you did. This isn't possible with a GUI. Do you remember which buttons you clicked three months ago when you've come to publish?

So, I think, at least for research environments, we prefer commandline. It keeps a consistent experience through the whole project, and hopefully means you can take a script from start, to bigger compute environments, to publication.

Answer 8

Another software that comes with a GUI is WIEN2k with its W2web web-interface. This interface is convenient for beginners, which I know because I had a course about wien2k when I had no idea about quantum chemistry.

But the professor told me that somewhat experienced users only work from the command line because it is actually much faster once you are accustomed to it. Anyone dabbling in quantum chemistry would hit this bar pretty soon. I imagine it would be the same for all other codes.

Answer 9

The solution to this problem is actually significantly easier (but tedious) than expected. All quantum chemistry codes use specific identifiers in the input script to notify the code about the settings applied by the user. For example, the ibrav flag in QuantumEspresso notifies the code of the Bravis lattice specification.

To build a GUI, a web based tool such as javascript can be used where the user can select the individual settings from drop down menus thereby giving the GUI. At the end of configuration through the GUI, it is easy to take into account all the provided information and create a text file where the text is formatted according to the input specifications of the DFT code.

However, to do this, someone will have to comb through the user manual of the DFT code and include each and every required input command while setting default values to be printed in the text file if the user does not specify any information regarding a specific setting.

Adding to the fact that developers sometimes (although rarely) opt to change the names of individual settings, provide new options and so on, updating the code will require some communication with the developers as well.

Also, this can be extended to multiple DFT packages as well. However, the commands for each individual DFT code will have to be included, which is a tremendously tedious task.

Answer 10

When I was a grad student, I mostly used used Molden for interactive visualization. I used Mathematica code I wrote myself for generating input files for VASP and Gaussian, and used Mathematica for producing figures.