2. Python environment setup for CAE automation

Before a single line of automation code touches a solver deck, the Python environment must be isolated, reproducible, and able to talk to the CAE toolchain. A CAE workstation typically hosts multiple solver versions (for example, Ansys 2023 R2 and 2024 R1, or Abaqus 2022 and 2023), each shipping its own embedded Python interpreter and its own set of licensed APIs. Installing packages into the system Python or into a solver's bundled interpreter is the fastest way to break both the solver and your scripts. This chapter establishes a clean separation: a dedicated virtual environment for your automation logic, and a controlled bridge to the solver's own runtime and license server.

Why Virtual Environments Are Non-Negotiable in CAE

CAE automation depends on libraries with tight version coupling: numpy for result array manipulation, pandas for tabular report assembly, matplotlib or plotly for dashboards, and vendor SDKs such as ansys-mapdl-core, pyansys, or abaqus Python modules. A dashboard project pinned to pandas==2.1.4 will silently produce wrong column dtypes if another project upgrades pandas to 2.2. Virtual environments give each project its own dependency graph, so upgrading one dashboard never destabilizes a solver post-processing script.

Use venv (standard library, no extra install) for most work. Conda is preferable when you need compiled scientific stacks or when the solver vendor distributes conda packages. The rule of thumb: one environment per automation project, never per solver.

# Create and activate a project environment (Windows)
py -3.11 -m venv .venv
.venv\Scripts\activate

# Linux / HPC login node
python3.11 -m venv .venv
source .venv/bin/activate

# Confirm isolation
python -c "import sys; print(sys.prefix)"

The printed prefix must point inside .venv, not to C:\Program Files\Ansys Inc or /opt/abaqus. If it does, activation failed and every subsequent pip install will contaminate the solver installation.

Package Management and Reproducibility

Pin dependencies in a requirements.txt or, better, a pyproject.toml with a lock file. CAE reports are audited artifacts; a report generated in March must be reproducible in September. Record exact versions, not ranges.

# requirements.txt — pinned for a report automation project
numpy==1.26.4
pandas==2.1.4
matplotlib==3.8.2
openpyxl==3.1.2
ansys-mapdl-core==0.68.3
pyvista==0.43.0

Install with pip install -r requirements.txt. For air-gapped CAE clusters, pre-download wheels on a connected machine using pip download -r requirements.txt -d ./wheels, transfer the directory, then install with pip install --no-index --find-links=./wheels -r requirements.txt. This avoids the common failure where a compute node has no outbound internet and pip hangs for minutes before timing out.

IDE Configuration for CAE Work

VS Code and PyCharm both work well, but the interpreter selection is what matters. Point the IDE at .venv/Scripts/python.exe (Windows) or .venv/bin/python (Linux), not at the solver's Python. Configure the following:

• Interpreter: the project virtual environment, verified via the IDE's interpreter status bar.
• Linting: ruff or flake8 with a line length of 100–120, since CAE API calls are often long.
• Formatting: black with --line-length 100 for consistent diffs in shared repositories.
• Launch profiles: store solver paths and license variables in .vscode/launch.json or run configurations, never hard-coded in scripts.

A practical launch.json entry for a MAPDL automation script sets the environment before launch:

{
  "name": "Run MAPDL Report",
  "type": "debugpy",
  "request": "launch",
  "program": "${workspaceFolder}/generate_report.py",
  "env": {
    "ANSYSLMD_LICENSE_FILE": "1055@license01.cae.local",
    "PYMAPDL_START_INSTANCE": "false"
  }
}

Integrating with Solver Installations and License Servers

The integration layer has three distinct concerns: locating the solver executable, pointing the client library at it, and ensuring the license server is reachable. These are separate from your virtual environment and should be handled through environment variables or a configuration file.

For Ansys, ansys-mapdl-core launches MAPDL either as a local process or connects to a remote instance. Set AWP_ROOT241 (or the version-appropriate variable) so the library can find the installation, and set ANSYSLMD_LICENSE_FILE to port@host. For Abaqus, the abaqus Python modules are only importable from the solver's own interpreter, so the standard pattern is to run a small script inside abaqus python that dumps results to JSON, then process that JSON in your virtual environment.

# Bridge pattern: solver interpreter writes data, venv reads it
# Step 1 — run inside Abaqus Python
abaqus python extract_odb.py --odb job.odb --out results.json

# Step 2 — process in the project venv
python build_dashboard.py --input results.json

License connectivity should be verified before any long automation run. A quick check on the license port prevents a 40-minute solve from failing at minute 39 because the license was checked out by another user.

# Verify license server reachability (example port 1055)
python -c "import socket; s=socket.create_connection(('license01.cae.local',1055),timeout=5); print('license reachable'); s.close()"

Typical failure symptoms and their causes: ModuleNotFoundError: ansys.mapdl.core means the package was installed into the wrong interpreter; License server does not respond means the port or host variable is wrong or the firewall blocks it; MAPDL exited with code 1 immediately after launch usually indicates AWP_ROOT points to a non-existent or mismatched version directory.

Verification Checklist Before First Automation Run

Run these checks in order. Each one isolates a different layer, so a failure tells you exactly where to look.

With the environment isolated, dependencies pinned, IDE pointed at the correct interpreter, and solver plus license connectivity verified, the automation scripts in later chapters can assume a stable foundation. The next step is to structure the automation code itself so that solver calls, data extraction, and report generation remain independently testable.