Graphics part of bz, the band structure tool

[kamischi]

Hi.

bz, the band structure tool of mopac, can only be used on windows, because it uses an old and windows-only graphics library for its output. My interest is to replace it by a more recent, future proof and cross platform (windows, linux, macOS) library. I have found 2 candidates, sdl2 and gnuplot. sdl2 has its footing more in the gaming field, would be more of a direct replacement of the current library and would create the same band structure plots as the current library. Gnuplot is mostly known for plotting science data from a terminal and has no direct API. But it could be used by sending commands from Fortran through a pipe, which is a bit more involved. With gnuplot, there might be a chance for subsequent changes of the plot through command line commands, which would be more involved with sdl2. However, I am not 100% sure about this. Currently, bz also has a text file output of the data, which can be used with any plotting program. At the moment I would go for sdl2.

Any comments, ideas or even experiences in this field?

Regards - Michael Schindler.

[godotalgorithm]

I welcome any efforts to make the BZ program more useable. We discussed this once before, and I have tinkered with BZ a little bit since then. I did not notice any interactivity that was worth preserving. I believe that the best way to proceed would be to (1) remove the interactive loop of the program and replace it with either command-line options or added options to the beginning of the .brz input file and (2) replace the piping of band-structure data to a graphics program with the writing of the data to a file. Once the data is in a file, it can be visualized with other software such as Gnuplot or matplotlib in Python. I've been using matplotlib for over a decade for all of my publication-quality plotting needs, and the use of Python scripts for plotting makes it very easy to preprocess data as needed. Also, if BZ were reorganized to simplify the evaluation of energy bands at specific k points, then it would be easier to connect it with Python-based tools such as ASE that can generate k-point grids and paths through special points in the Brillouin zone. With so many tools in the Python ecosystem to prepare and plot band structures, I think that is a much better target than any self-contained integration with graphics libraries.

I'm happy to offer more detailed suggestions on specific technical issues involving either BZ's source code or connecting it up with Python-based tools. However, you'll have to take the lead if you want to see any BZ-related development anytime soon. My main development goal this year is to deploy a new MOPAC website, and I don't expect to be involved in any further MOPAC development after that beyond long-term support and maintenance activities. My funding to work with MOPAC is running out, and career priorities will be shifting my attention elsewhere.

[kamischi]

Thanks for your detailed explanations, which widen my perspective a lot. I needed some time to digest it. In short: Overall I agree with your idea, your suggestions and the directions, which should be taken. Basically, it does not make sense to reinvent the wheel in Fortran. However, I am skeptical, whether I will be capable to make this happen, because I lack even some of the theoretical basics. Not, that I would not be interested in getting into them, but this would need some time, which is scarce, since I am on another project as well. Correct me if I'm wrong on the following. Replacing the current windows-only graphics with SDL2 is a much smaller task than what you lined out. I hope this does not sound too stubborn. Personally, it would have the benefit to enable using bz on macOS or linux as a reference for the task you suggested. I am definitely interested to work along the lines you pointed out. With another program I separated IO from the calculations and create a library to be called by anywhere else, be it C, Pascal 😉 or Python.

Sad to hear, that you will have to leave, but such is live.

[godotalgorithm]

I do not have any experience with graphics programming, so I can't seriously comment on how difficult a switch from QuickWin to SDL2 will be. It really depends on how much their elementary operations line up. Using SDL2 would also add a new (optional) dependency to MOPAC, but SDL2 seems to have good CMake support, so I don't think that aspect would be too bad.

I'm mostly suggesting the removal of code and features from BZ itself - whether or not removing a feature is easier than porting it depends on how difficult the porting process gets. It sounds like you want an excuse to tinker with SDL2, so perhaps you are volunteering to figure that out.

If I eventually do anything with BZ myself, it will be to rip out all graphics functionality, all interactivity, and all Brillouin zone scanning, leaving a minimal program that takes a single k-point on the command line and prints the energy bands at that k-point. That is what I see as the minimum-effort solution that preserves the essential usefulness of BZ.

I wish that MOPAC and semiempirical electronic structure research had more resources to work with, but they simply do not because there is insufficient interest on the academic side and insufficient profitability on the commercial side.

[kamischi]

Bevor really starting with SDL2, I'll have a look to bz how much effort such a complete graphic removal would be. My other concern is to loose a reference implementation.