Skip to content

(2022-09-21) Lab Notebook: VisIt on HPCC


This is as a Lab Notebook which describes how to solve a specific problem at a specific time. Please keep this in mind as you read and use the content. Please pay close attention to the date, version information and other details.

Lab Notebook --- Using VisIt on HPCC (2022-09-21)

VisIt is an Open Source, interactive, scalable, visualization, animation and analysis tool (see the VisIt Docs for more detail)

Currently, there are two challenges using VisIt on HPCC (1) failed installation due to conflicts with GLIBC and (2) running the GUI without it crashing immediately after loading.

Easy Solution, using an older VisIt

To address the install issues, the easiest solution is to use an older (before 3.x) version of VisIt which can be found here. Use the version titled:

Linux - x86_64 64 bit
Redhat Enterprise Linux 7.5, 4.18.9-1.el7.elrepo.x86_64 #1 SMP, gcc 4.8.5

Or use the following command on HPCC:


Once this file is donwloaded, unpack using tar -xzf and then begin and then begin an Interactive Desktop session via OnDemand. This step is necessary because running VisIt from the command line will cause the GUI interface to crash immediately after loading (tested with XQuartz on Mac and MobXterm on Windows). Instead, after creating an Interactive Desktop,navigate to the unpacked VisIt folder, enter the bin folder within, and click on the fie named 'visit'. This should start VisIt within the Interactive Desktop.

Intermediate Solution, using RHEL7 Visit 3.3 with modules

Following from the above solution, I realized that the new (as of writing) version of RHEL7 should work on HPCC without the GLIBC issue, but it doesn't out of the box. However, the fix wasn't difficult once I figured out that right module to load on HPCC, though the combinaton with the need to use OnDemand makes things a little clunky.

First, get the RHEL7 3.3 version of VisIt with Mesa from their website, or use the following command:


Once this file is downloaded, unpack using tar -xzf and then begin an Interactive Desktop session via OnDemand. This step is STILL necessary because running this version of VisIt from the command line ALSO will cause the GUI interface to crash though this time it waits until you try to draw something (tested with XQuartz on Mac).

Because we need to use some module, once the Interactive Desktop is started, open a terminal and navigate to the folder where VisIt was unpacked and go to the 'bin' directory. There, run the following commands:

module load GCCcore/11.2.0
module load PCRE2/10.37

Then, if you are in the bin folder, you can start Visit using:


I think this need to be done in the same terminal window for VisIt to start in the right environment (i.e. with the modules loaded)

Future: Getting CentOS8 Visit to run on HPCC

I've encountered several problem trying to getting any version VisIt 3.x to work on HPCC (tested 3.0 and the current as of now 3.3), though it turns out this was because I was using the CentOS8 version and RHEL7 is close enough to what we use that the workaround is not bad (see above). Using the prebuilt CentOS8 binary files will not work because they are looking for a version of GLIBC later than version 2.17 which is built into CentOS7.

I am looking into this becaue I have encountered this issue before with other easily accessible installs of user requested software (see Pymesh on Conda) and might be a useful method to test software prior to a future OS update on HPCC. As such, I have been using Visit to explore ways to try to install CentOS8 built software on HPCC. Currently, the idea is to use a prebuilt binary on a Singualirty container of Centos8, though when I do this it cannot find the Qt5 library that comes with VisIt or, sometimes, an X11 library(might be able to fix this by messing aroubd with library paths within Singularity)

Why no just build Visit from source, wouldn't that be easier?

Short answer, no.

Long answer, when I try to build VisIt 3.x from source, it fails to build its own version of Qt5 (cannot find the xkbcommon library on the system even though its there) and will not recognize Qt5 on the system. Might be related to the library issues trying to work in Singularity, not sure.