Using Specialized Linux Software in Lab and Research Environments

Due to modernization efforts, use of Software in the Linux Labs has changed substantially as of Fall 2026.

The TLDR is that there are now two steps to run your software properly. In your terminal of choice:

1. module load mysoftware/suite where mysoftware is a standin for the software of your choice.
2. mysoftware-run example where mysoftware and example are the software name and the program to execute.

Unless you have particular versioning needs, loading the suite, e.g. module load mentor/suite should be sufficient.

If you are an advanced user, a researcher, troubleshooting, or just curious -- read on for more details.

Modules

The module tool is a key component in ensuring your applications run properly. Module allows for flexible and ordered configuration of the often complex environments specialized software needs to run properly. It allows granular control of software version when desired.

module will not run your software for you, it simply prepares the environment. Module may occasionally print helpful messages or warnings when circumstances arise, such as when you have two distinct softwares loaded that offer a particular integration, or in the case that two modules will conflict and interfere with one another.

Module grants CAE the flexibility to even create modules per class, though this can only be implemented on-demand.

Common Module commands

Launching your Software

To launch your software, there are two choices:

1. Use the provided launch tool. The general pattern is mysoftware-run program. Tab completion can help you here.
   • If you want to enter the software environment and have an interactive shell, simply omit the program portion. In particular, this interactive shell will be inside the container environment.
2. Run the program directly. This is reserved for native and less picky software, and will break more complex installs.

See the Software Launch Strategies for a table of software that has a corresponding launch tool. Additionally, if your software requires a launch tool, you should check out the containerization section below.

Containerization

Some software installations are extremely particular about the computing environment in which they run. The Labs currently run Debian, but some software will ONLY run on RedHat, or SUSE, and even then only on outdated versions of these OS's. To ensure our software deployments are both portable between operating systems and maintainable into the future, certain software is installed and can only be run inside container environments.

The launch tools discussed above are what gets you into a container session. When inside a container, your shell prompt will change to reflect the software you invoked, such as cadence> or synopsys>.

WARNING: Container environments are temporary. Files created inside containers will vanish when the container stops, unless you save to your usual storage paths, such as /userspace/username/ or ~/ which should be the same place. Using the proper software-run tools will ensure that these more-permanent storage paths are present inside the container.

What Does This Mean for You, the User?

For the most part, this information about containers is for your edification. Whether or not a piece of software must be run inside a container determines whether a software needs a special tool to run it, such as mysoftware-run. Containerization consists of process and path isolation. This means that, without proper use of provided launch tools, files placed in your "home" inside the container will not exist when you exit the container. CAE tools such as mysoftware-run automatically connect the paths you need to the process inside of the container.

Software Launch Strategies