Installation

Windows and Linux each have one complete TDSE installation. The same installed tree supports model authoring, host integration, diagnostics, deployment preparation, and local operation. These are usage scenarios; there is no Authoring/Deployment choice and no second commercial package.

What A Customer Receives

Windows:

1. TDSE-<version>-Windows-x86_64.exe
2. authorization material or instructions for the trusted OEM host, when its provider requires them
3. TDSE-<version>-Windows-x86_64.exe.sha256

Linux:

1. one complete package: TDSE-<version>-Linux-<arch>.tar.gz
2. authorization material or instructions for the trusted OEM host, when its provider requires them
3. the package checksum

The delivery is prepared for the customer's contracted combination. TDSE Runtime and CPU capability are always present. TDSE Circuit is present only in its contracted Runtime package; GPU and FPGA Add-ons are present only after their contracted Add-on package has been installed into that same Runtime. Package filenames deliberately do not encode that combination. After install, share/tdse/tdse_installation.json on Windows or share/tdse/tdse_linux_installation.json on Linux records the exact products, Add-ons, optional technical components, release, and source identity.

Formal hardware qualification is recorded separately for each enabled Add-on; a CPU or Circuit result does not imply GPU or FPGA qualification.

System Requirements

• Windows 10 or later, x64
• supported x86_64 GNU/Linux distribution
• glibc-based AArch64/Linux with the bundled, architecture-matched OpenBLAS provider; formal distro package acceptance remains host-specific
• MSVC 2019 or later for applications that compile against TDSE
• GCC or Clang compatible with the shipped Linux C++ ABI for Linux hosts
• CMake 3.21 or later for CMake package consumption
• sufficient disk space for the contracted composition and customer model data

The installer includes the selected release's TDSE and third-party runtime closure. The trusted OEM host supplies authorization; a separate provider component may be present when required by that OEM integration, but it is not a mandatory TDSE package file. Do not install another cuDSS, CUDA, SuiteSparse, or OpenBLAS copy into the TDSE directory.

Hardware drivers are host prerequisites, not extra TDSE packages. A GPU host needs the qualified NVIDIA driver. An FPGA host needs the qualified vendor XRT runtime and driver before TDSE starts; TDSE installs its FPGA host adapter but does not redistribute the board driver or platform firmware. The selected XRT version, device, xclbin, and qualification evidence must match the deployment.

The Linux layout contract is architecture-neutral: x86_64 and future promoted AArch64 packages expose the same public paths and package names while containing native machine code and an architecture-matched OpenBLAS provider. The current GitHub-hosted package lane produces and smokes x86_64 archives. AArch64 Runtime and provider evidence does not become a customer package until the same archive, clean-install, and consumer gates run on an AArch64 release host.

When TDSE Circuit is present, the installation includes the KLU/AMD/COLAMD/BTF/ SuiteSparse_config shared-library closure, its notices, and share/tdse/third_party_sources/suitesparse/TDSE-SuiteSparse-KLU-7.8.3-Source.zip. KLU is part of TDSE Circuit and requires no separate SKU. Customers exercising their shared-library replacement rights should leave the installation intact and use TDSE_LGPL_LIBRARY_OVERRIDE_DIR as described in Circuit Solver Selection and Performance.

Install On Windows

Interactive:

TDSE-1.0.0-rc1-Windows-x86_64.exe

Silent:

TDSE-1.0.0-rc1-Windows-x86_64.exe /VERYSILENT

The installer asks only for the destination and optional system integration, such as adding bin to PATH. It does not ask which usage scenario applies. It also does not ask the customer to select products or Add-ons: those are fixed by the contracted build.

The default directory is:

C:\Program Files\TDSE

Install On Linux

Extract the one complete relocatable archive; do not combine it with split packages or install a separate development package:

tar -xzf TDSE-<version>-Linux-<arch>.tar.gz

The archive extracts one TDSE-<version>-Linux-<arch>/ root and can be relocated as a unit. There are no tdse-runtime, tdse-runtime-authoring, tdse-circuit-sdk, or tdse-full-sdk customer packages. DEB and RPM are not currently produced by this repository and must not be advertised until their native package and clean-host gates are implemented.

Installed Tree

TDSE/
├── bin/
│   ├── tdse[.exe]
│   ├── tdse.dll                        Windows
│   ├── tdse_plugin_doctor[.exe]        when plugins are explicitly included
│   └── selected runtime dependencies
├── include/
│   └── tdse/
│       ├── tdse.h
│       ├── tdse_builder.h
│       └── circuit/...                 when Circuit is included
├── lib/
│   ├── tdse.lib                        import library for tdse.dll
│   ├── libtdse.so                      Linux Runtime library
│   ├── tdse_circuit.lib / libtdse_circuit.a
│   │                                   Circuit link library when included
│   ├── cmake/
│   ├── pkgconfig/
│   └── plugins/sim/                    when Simulation Plugins are included
└── share/tdse/
    ├── tdse_installation.json          Windows identity
    ├── tdse_linux_installation.json    Linux identity
    ├── product/
    ├── examples/
    ├── legal/
    ├── third_party_notices/
    └── dependency and release evidence

On Windows, TDSE Runtime is delivered as tdse.dll; tdse.lib is its MSVC import library, not a second Runtime implementation. On Linux the equivalent Runtime library is libtdse.so. Circuit and some command modules are link-time static libraries, while simulation providers are runtime DLL/DSO plugins. Use the installed CMake targets instead of hard-coding this layout.

tdse.dll or libtdse.so is the only customer-visible primary Runtime implementation. Selected OpenBLAS or CUDA shared libraries beside it are bundled third-party runtime dependencies, not alternative TDSE runtimes. Private static archives may appear only in static or embedded SDK compositions that require their link closure.

The complete install intentionally includes headers, link libraries, Builder APIs, CMake/pkg-config metadata, curated examples, Profiler, diagnostics, and runtime dependencies. Their presence does not create additional licensed products.

Verify The Installation

Verify the installer checksum before running it:

Get-FileHash .\TDSE-1.0.0-rc1-Windows-x86_64.exe -Algorithm SHA256

On Linux:

sha256sum -c TDSE-1.0.0-rc1-Linux-x86_64.tar.gz.sha256

Inspect the installed release and its readiness:

tdse doctor

For support automation, write the same report as JSON:

tdse doctor --json-out tdse-doctor.json

If the installation identity's technical_components list explicitly includes simulation_plugins:

set TDSE_PLUGIN_MANIFEST=C:\Program Files\TDSE\lib\plugins\sim\plugin_manifest.json
set TDSE_PLUGIN_STRICT_MODE=1
tdse_plugin_doctor.exe

The same commands on Linux use normal shell continuation and /opt/tdse/lib/plugins/sim/plugin_manifest.json.

Windows uses share\tdse\tdse_installation.json; Linux uses share/tdse/tdse_linux_installation.json. The customer-facing identity records commercial products and hardware Add-ons separately from optional technical components. It also records the platform, release version, provider policy, runtime linkage, full source commit, and build fingerprint so tdse doctor rejects mixed-build and wrong-composition installations. There is no usage-role or Authoring/Deployment field.

Hosted GPU and FPGA Add-on deliveries supplement the same installation. Their private binaries and required vendor-runtime files are packaged independently from the public Runtime, so adding or removing an Add-on does not replace tdse.dll, libtdse.so, or the customer's link input.

An authorized Add-on delivery contains one install and one uninstall script. Pass the existing TDSE installation root; no compiler, CMake, Python, application rebuild, or relink is required:

install.cmd "C:\Program Files\TDSE"

./install.sh /opt/tdse

The matching uninstall.cmd or uninstall.sh accepts the same root. These scripts are installer entry points, not additional TDSE CLIs. Installation checks Runtime compatibility before copying any Add-on file.

To replace an installed Add-on with a newer delivery, run the matching uninstall script first and then the new install script. The scripts use the package-owned payload list, so a failed install and a normal uninstall remove the provider and its bundled dependency files together rather than leaving a partial accelerator installation.

The same installation identity contains a hosted_addons object that records the installation-relative path of each installed GPU or FPGA module. An installer adds that record only after the module is present, and removes it only before the module is removed, so an interrupted uninstall cannot leave Runtime pointing at a missing file. The identity update is atomic and must match the installed Runtime's release, source, platform, and build fingerprint. This is installation bookkeeping, not Runtime hot loading or unloading; vendor runtime files that may be shared with another TDSE product remain under the installer's ownership.

With the default Runtime initialization configuration, Runtime reads those records and loads only compatible Add-ons from paths inside the same installation. The public initialization configuration may instead name an explicit absolute path to a TDSE-supported vendor implementation; that is an explicit integration choice, not a hot-load or unload mechanism. tdse doctor exercises the identity-based default discovery and load path rather than maintaining a second default. Its JSON hosted_addons section distinguishes an Add-on that is not installed, a missing module file, an incompatible or failed module load, unavailable hardware or driver, denied authorization, and a ready device. An Add-on problem is reported as attention and is never converted into CPU execution for an explicitly requested accelerator.

The current identity schema is tdse.installation_identity.v2. Version 2 introduces the separate technical_components list; a version 1 identity must not be copied into a current installation or used to describe its contents.

Build Against TDSE

Prefer the installed CMake package:

find_package(tdse CONFIG REQUIRED)
add_executable(my_host main.cpp)
target_link_libraries(my_host PRIVATE tdse::runtime)

Builder is part of the same Runtime target:

#include <tdse/tdse.h>

For Circuit:

find_package(tdse CONFIG REQUIRED)
target_link_libraries(my_host PRIVATE tdse::runtime tdse::circuit)

find_package(tdse) is the canonical customer entry point for every contracted composition. A Runtime-only installation exposes tdse::runtime, which includes the Builder API; it does not expose a separate Builder CMake target. A Runtime + Circuit installation adds tdse::circuit through the same package. The Runtime target is always tdse::runtime; the retired Runtime package and target aliases are not installed.

After find_package(tdse), TDSE_AVAILABLE_PRODUCTS lists the contracted composition. TDSE_HAS_CIRCUIT, TDSE_HAS_GPU_ADDON, and TDSE_HAS_FPGA_ADDON provide matching boolean checks; they describe products, not separate packages or installation roles. TDSE_HAS_SIMULATION_PLUGINS and TDSE_AVAILABLE_TECHNICAL_COMPONENTS report optional technical content without adding it to the product list. TDSE_EXTERNAL_RUNTIME_PREREQUISITES reports the host driver/runtime prerequisites implied by installed hardware Add-ons; it does not identify additional TDSE products or packages.

For a prerelease, pin the complete release identity before the unversioned lookup:

set(TDSE_REQUIRED_RELEASE_VERSION "1.0.0-rc1")
find_package(tdse CONFIG REQUIRED)

CMake's numeric version grammar cannot represent the -rc1 suffix. Therefore find_package(tdse 1.0.0 CONFIG REQUIRED) deliberately rejects an installed 1.0.0-rc1 package instead of silently treating it as the final release.

Authorized Partner Redistribution

RTDS, OPAL-RT, and other authorized OEMs develop against the same complete TDSE installation. They may embed a TDSE-provided, agreement-bound Redistributable Payload in a terminal installer. That payload can omit headers, link libraries, examples, and development tools; it is not another product or installation choice. Partners should follow the internal partner integration and redistribution guide supplied with their agreement rather than manually copying libraries.

The promoted Windows partner payload is named TDSE-<version>-Windows-x86_64-Redistributable.zip. Names containing internal technical profiles or package compositions are not customer releases.

Linux Archive Migration

Current Linux delivery is one complete archive. Remove retired split-package trees before extracting a promoted archive so a host cannot silently mix old Runtime or Circuit files with the new complete installation.

The internal CMake install components remain available to TDSE's build and ABI tests. They are not CPack components, customer downloads, or package-manager choices.

Troubleshooting

After installation succeeds, continue to Hands-On Tutorial.