When trying to run starccm on a vis node in order to use GPU for visualization (not for GPU calculation), the typical way to do this would be to load the virtualgl module and use vglrun
module load virtualgl/3.1.1
module load starccm/19.06.009
vglrun starccm+
However, starccm does not pick up libraries from $LD_LIBRARY_PATH by default, so it does not pick up the necessary graphics libraries
vLLM versions prior to 0.14.1 are deprecated due to security issue CVE-2026-22778 which can allow remote code execution. Clients are advised to use versions 0.14.1+ with module load vllm/0.14.1
https://www.osc.edu/resources/technical_support/known_issues/apptainer_c...
On any compute node, users may encounter the following error when installing packages with apt in Apptainer:
After the most recent downtime we discovered that various OOD apps relying on the "virtualgl" module on Cardinal were broken. We have since updated and pinned the latest virtualgl version for each broken app
Building Apptainer containers on compute nodes may fail during apt update or other package operations. The failure is caused by Apptainer’s build environment not being fully isolated from the host when private /tmp namespaces are in use.
Schrodinger 2023.2 does not launch through OnDemand or OnDemand desktop, failing with "fatal error"
If you do not need 2023.2 specifically, or you are able to transition to 2024 or later versions, please do so. We highly recommend this option over the following workarounds
Schrodinger can be launched on vis nodes, through X11Forwarding, and through batch jobs. If trying to run Schrodinger 2023.2, please use a vis node, use X11Forwarding, or do not use the GUI and run through a batch job
When you run AlphaFold 3, you may encounter a GPU out-of-memory (OOM) failures during model execution. The job terminated with errors similar to:
Trying to download a directory through code server results in the error "ondemand.osc.edu cannot open this folder because it contains system files"
To work around this, tar the directory first and download the .tar file, and untar it on your local machine
Applications such as Quantum ESPRESSO, LAMMPS, and NWChem experienced hangs with MVAPICH 3.0 due to a PMI mismatch. MVAPICH 3.0 was built with PMI-1, while newer Slurm versions on RHEL 9 use PMI-2. Although the development team states that using the PMI-1 interface with Slurm’s PMI-2 implementation should work, there may be a bug in MVAPICH 3.0.
Benchmark AUSURF112 for quantum-espresso/7.4.1 on Ascend aborts. We suspect that this is a lurking bug in Quantum Espresso and are reporting it as a convenience. Concerned users can use Cardinal or Pitzer as a workaround.
Update on November 24, 2025: The issue is resolved with MVAPICH 4 variants.
